5 ms·

Latency is the reason I just can not use some editors, most notably Atom. You get used to it after a while, but it's not fun. I remember when I used IntelliJ's

Latency is the reason I just can not use some editors, most notably Atom. You get used to it after a while, but it's not fun. I remember when I used IntelliJ's product line for a good while and then opened up Vim. I was dumbfounded that I somehow had not noticed that IntelliJ was slow. It's fast enough - not Atom - but Vim was amazing next to it.

majewsky 9y ago
That reminds me of another thing that I noticed. My vim gets really sluggish (as in, 1 fps and worse) when I have a Firefox window on the other screen showing a Concourse pipeline [1]. If I change to a different tab, vim is suddenly fast again. [1] https://concourse.ci https://concourse.ci
aidenn0 9y ago
Having used vi over low-speed serial links means that I can handle latency just fine. Also hjkl were noticably faster because they sent fewer characters over the lines compared to arrow keys which used escape codes...
- watchdogtimer 9y ago
  Funny, I've noticed just the opposite using vim on a desktop or laptop--and its always driven me nuts. If I'm editing a file and type several repeating j or l commands (e.g., 'jjjjj' in command mode), there is noticeable latency between the last movement command and the last cursor movement. I get no latency, however, when performing the same commands using the right or down arrow keys. The 'h' or 'k' commands have no latency, either, just 'j' and 'l'. I've been using vim for years and still find it frustrating. I haven't noticed the same problem with other vi clones (e.g., nvi or elvis).
  - aoeusnth1 9y ago
    I don't notice any difference with Spacemacs' evil-mode (a vim mode)
    - dkersten 9y ago
      I know this isn't what you're responding to, but... I do notice the difference between vim (or neovim) and spacemacs -- spacemacs is noticeably slower. I do still use spacemacs more than vim now, though, because its Clojure integration is better. (aside-rant: evil-mode is also not really a substitute for vim -- when you say you're a vim user, people often ask "why not just use the vim emulation in editor-X?" and the reason is because vim emulation has never, in my experience, been as good an experience as vim, things always work subtly differently)
      - aidenn0 9y ago
        Having used vi for 25 years and vim for 20 years, I'm going to say that evil-mode is the first vim-emulation editor mode that was close enough for me. I think there were two or three things that weren't right for me out-of-the-box, but 15 minutes and 30 lines of elisp later it was fixed. I really need to maintain a fork or something that is as much like vim as possible, but with options for enabling specific emacs features, because everyone has some things that emacs does that they like better than how vim does it. My personal example: s/foo/bar/g on a line containing "foo Foo" becomes "bar Bar" by default in emacs, which I find to be amazing, but is definitely not how vim works.
        dkersten 9y ago
        Yeah, its minor differences, but they add up. Maybe its time I learned a little elisp and fixed it for myself, I really like spacemacs aside from the (minor) annoyances caused by not being vim.
  - michaelmrose 9y ago
    What OS?
    - watchdogtimer 9y ago
      I've experienced this on every version of Debian or Ubuntu I can recall using.
      - michaelmrose 9y ago
        Do you experience the same thing with a blank config?
  - deleted 9y ago
    [deleted]
  - chr1 9y ago
    do you have a mapping of jl to esc?
al452 9y ago
IntelliJ often shows latency, but it's not "slow", it's doing a stupendous amount of work behind the scenes and building an incredibly rich model of your code and your application. If you're not getting more out of IntelliJ than vim, then sure, vim will make you happier. But also then you're not getting from IntelliJ what it's trying to provide.
- agumonkey 9y ago
  yeah latency is not all. I have an HP48 calc, even though it had a monstrous cpu for its time, the system had layers of interpretation rendering the UX well... sluggish. But the ergonomics and paradigm was so neat, that you didn't need real time. You could keep stacking functions on the HP48 stack, you'd know in advance how it would behave, so it wasn't an issue. And counter intuitively, I enjoyed the pauses so I could think about what to do next.
  - wtallis 9y ago
    The key thing that made the HP48 work in spite of its latency is that the behavior was completely predictable. You could press a long key sequence faster than the GUI could react, but each keypress would be interpreted as if the GUI had kept up. So you could press an arrow key several times to navigate through a menu or dialog box that hadn't been drawn yet. The input event buffer was large enough to handle almost any input sequence that you could actually memorize. On a PC, the latency is both less predictable in occurrence and in how it is handled, so when a window is unexpectedly slow to appear, you have to notice and wait rather than continue to type, otherwise your input may be sent to the wrong window.
    - agumonkey 9y ago
      Agreed
- hvidgaard 9y ago
  I haven't used IntelliJ for the last 5 years or so, so I do not know how it is today. My remark here is not about IntelliJ, but a generally about GUIs. A GUI can be responsive and fast even when doing a lot of work behind the scenes. I'm perfectly fine with it taking it's time figuring out what argument I can use, or something else. But do not drop percieved responsiveness - I want to be able to type and/or click menus at all times.
alecbenzer 9y ago
Hm, when did you last try atom? I just tried picking it up coming from vim in a terminal and haven't really noticed speed as a major difference. Speed where, in how quickly characters show up? Or in doing other things like navigating around?
FridgeSeal 9y ago
For what it's worth, PyCharm (and I assume the other IntelliJ IDE's) has added zero-latency typing [0 (that blog post mentions rolling out the feature in an Early Access build, but given semantic highlighting is in normal Pycharm now, I would imagine zero-latency input is as well). 0: https://blog.jetbrains.com/pycharm/2016/12/pycharm-2017-1-early-access-program-started/ https://blog.jetbrains.com/pycharm/2016/12/pycharm-2017-1-ea...

majewsky 9y ago

That reminds me of another thing that I noticed. My vim gets really sluggish (as in, 1 fps and worse) when I have a Firefox window on the other screen showing a Concourse pipeline [1]. If I change to a different tab, vim is suddenly fast again. [1] https://concourse.ci https://concourse.ci

aidenn0 9y ago

Having used vi over low-speed serial links means that I can handle latency just fine. Also hjkl were noticably faster because they sent fewer characters over the lines compared to arrow keys which used escape codes...

watchdogtimer 9y ago
Funny, I've noticed just the opposite using vim on a desktop or laptop--and its always driven me nuts. If I'm editing a file and type several repeating j or l commands (e.g., 'jjjjj' in command mode), there is noticeable latency between the last movement command and the last cursor movement. I get no latency, however, when performing the same commands using the right or down arrow keys. The 'h' or 'k' commands have no latency, either, just 'j' and 'l'. I've been using vim for years and still find it frustrating. I haven't noticed the same problem with other vi clones (e.g., nvi or elvis).
- aoeusnth1 9y ago
  I don't notice any difference with Spacemacs' evil-mode (a vim mode)
  - dkersten 9y ago
    I know this isn't what you're responding to, but... I do notice the difference between vim (or neovim) and spacemacs -- spacemacs is noticeably slower. I do still use spacemacs more than vim now, though, because its Clojure integration is better. (aside-rant: evil-mode is also not really a substitute for vim -- when you say you're a vim user, people often ask "why not just use the vim emulation in editor-X?" and the reason is because vim emulation has never, in my experience, been as good an experience as vim, things always work subtly differently)
    - aidenn0 9y ago
      Having used vi for 25 years and vim for 20 years, I'm going to say that evil-mode is the first vim-emulation editor mode that was close enough for me. I think there were two or three things that weren't right for me out-of-the-box, but 15 minutes and 30 lines of elisp later it was fixed. I really need to maintain a fork or something that is as much like vim as possible, but with options for enabling specific emacs features, because everyone has some things that emacs does that they like better than how vim does it. My personal example: s/foo/bar/g on a line containing "foo Foo" becomes "bar Bar" by default in emacs, which I find to be amazing, but is definitely not how vim works.
      - dkersten 9y ago
        Yeah, its minor differences, but they add up. Maybe its time I learned a little elisp and fixed it for myself, I really like spacemacs aside from the (minor) annoyances caused by not being vim.
- michaelmrose 9y ago
  What OS?
  - watchdogtimer 9y ago
    I've experienced this on every version of Debian or Ubuntu I can recall using.
    - michaelmrose 9y ago
      Do you experience the same thing with a blank config?
- deleted 9y ago
  [deleted]
- chr1 9y ago
  do you have a mapping of jl to esc?

al452 9y ago

IntelliJ often shows latency, but it's not "slow", it's doing a stupendous amount of work behind the scenes and building an incredibly rich model of your code and your application. If you're not getting more out of IntelliJ than vim, then sure, vim will make you happier. But also then you're not getting from IntelliJ what it's trying to provide.

agumonkey 9y ago
yeah latency is not all. I have an HP48 calc, even though it had a monstrous cpu for its time, the system had layers of interpretation rendering the UX well... sluggish. But the ergonomics and paradigm was so neat, that you didn't need real time. You could keep stacking functions on the HP48 stack, you'd know in advance how it would behave, so it wasn't an issue. And counter intuitively, I enjoyed the pauses so I could think about what to do next.
- wtallis 9y ago
  The key thing that made the HP48 work in spite of its latency is that the behavior was completely predictable. You could press a long key sequence faster than the GUI could react, but each keypress would be interpreted as if the GUI had kept up. So you could press an arrow key several times to navigate through a menu or dialog box that hadn't been drawn yet. The input event buffer was large enough to handle almost any input sequence that you could actually memorize. On a PC, the latency is both less predictable in occurrence and in how it is handled, so when a window is unexpectedly slow to appear, you have to notice and wait rather than continue to type, otherwise your input may be sent to the wrong window.
  - agumonkey 9y ago
    Agreed
hvidgaard 9y ago
I haven't used IntelliJ for the last 5 years or so, so I do not know how it is today. My remark here is not about IntelliJ, but a generally about GUIs. A GUI can be responsive and fast even when doing a lot of work behind the scenes. I'm perfectly fine with it taking it's time figuring out what argument I can use, or something else. But do not drop percieved responsiveness - I want to be able to type and/or click menus at all times.

alecbenzer 9y ago

Hm, when did you last try atom? I just tried picking it up coming from vim in a terminal and haven't really noticed speed as a major difference. Speed where, in how quickly characters show up? Or in doing other things like navigating around?

FridgeSeal 9y ago

For what it's worth, PyCharm (and I assume the other IntelliJ IDE's) has added zero-latency typing [0 (that blog post mentions rolling out the feature in an Early Access build, but given semantic highlighting is in normal Pycharm now, I would imagine zero-latency input is as well). 0: https://blog.jetbrains.com/pycharm/2016/12/pycharm-2017-1-early-access-program-started/ https://blog.jetbrains.com/pycharm/2016/12/pycharm-2017-1-ea...