Typing with pleasure(pavelfatin.com) |
Typing with pleasure(pavelfatin.com) |
Back in the Ubuntu 4.0 days (2006 or so), the default terminal was really slow. I didn't really know how to use Linux then, so I would SSH into with Putty on Windows, and use the terminal/Vim that way. This was actually more responsive than a local terminal!
Does anyne else feel a sense of raw power when they switch to a native terminal (Ctrl-Alt-F1) ... ?
I've heard of mosh though -- it sounds cool.
Without that, the latency numbers themselves don't mean much. Some 100 ms latencies are readily noticeable (video game input), others are not (pushbutton responses).
This paper (http://www.tandfonline.com/doi/abs/10.1080/00140137608931531) seems to suggest that typing speed does decrease at higher delays, but recovers after a short time. I can't access this journal though, so I don't know what kinds of delays were tried, and I don't know how long the recovery time actually is.
Great for being on an intermittent and/or slow link.
I've always pushed for this to be in the remote terminals by default as my prototypes took almost no effort to implement. With plenty of benefit, too, for anyone that values instant feedback! That was a throwaway, though. Thanks for the link to a real app doing it. :)
ed: or maybe thats excluded from the measurement but urxvt is double buffered by default?
Compare something like joe editor (the jmacs named executable has emacs-like key bindings) for syntax highlighting; it's night and day. Joe uses state machines (DFA) in a text description format for syntax highlighting. That means that strictly it can only do lexical highlighting, but that's much much better than nothing - and fully correct syntax highlighting requires a deeper analysis than is normally done in emacs modes.
Joe itself would be much faster again if the state machine was compiled to machine code.
I think the quality of the output you're aiming for matters - we as authors (and I speak based on my experiences both running Overleaf and in writing research papers) seem to put up with more latency / compile delays if we feel it's 'worth it' (however badly defined) for what we're looking to produce.
I personally find I do my most creative writing late at night, but my most polished / error free during the day. Whilst I wish I could say I split my work up accordingly, I've never found a way to do this effectively. Anyone else have this / found a solution?
This is an interesting datapoint in the argument between those who prefer the classic theme and those who use Aero, with proponents on both sides saying "it's faster". Perhaps compositing has higher throughput, but non-composited has lower latency. I personally use classic because it does feel more responsive. That extra ~15ms is definitely perceptible.
Another thing I've noticed is that when input latency is high, such as using SSH, I tend to keep typing ahead instead of waiting.
I agree. If you "want" to feel it consciously don't type text on a keyboard but play a melody on a midi keyboard. A latency of 10 ms, let alone 100 ms, feels horrible. For instance, a 1/16 note at 140 bpm has a duration of 107 ms!
I find it quite fascinating that recording midi in, say, cubase is possible at a lower latency than editing a text file in Atom.
I also find it interesting that you claim that humans don't notice latency under 100ms as though it is established fact, considering the OP spends basically the whole first section trying to debunk that incorrect but commonly quoted belief.
Note that even at 100 ms, most of the editors in the final graph are disqualified.
http://xahlee.info/kbd/keyboard_switch_mechanisms.html
Most keyboards (rubber dome, scissor) require the user to press a key to the bottom (i.e. A hard stop). Mechanical keyboards (e.g. spring, MX Cherry) register a keypress part way down. Cherry Blues, for example, have a pronounced sound and tactile feedback. Do these features make people better typist?