10 ms·

I made the page as a companion piece to a blog post[1]. The code works, but it's quite buggy. Also, it is almost certainly broken on outdated OSes. It's just th

by ggreer 11y ago

I made the page as a companion piece to a blog post[1]. The code works, but it's quite buggy. Also, it is almost certainly broken on outdated OSes. It's just that nobody uses the latest Vim on IRIX or VMS, so no bug reports get filed. A quick glance shows some obvious errors in RealWaitForChar(). For example: with typical preprocessor defines, it uses gettimeofday() in a select() loop. This will break if the system clock changes, either from user intervention or ntpd. The correct solution is to use a monotonically-increasing timer, such as Linux's clock_gettime() or OS X’s mach_absolute_time(). Vim's UI is powerful, but its codebase is a nightmare. My blog post explains why in more detail. 1. http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-vim/ http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...

Alupis 11y ago
> The code works, but it's quite buggy Could you elaborate a bit? I've never experienced a bug related to keyboard input while using Vim, at least that I know of.
- baby 11y ago
  Depends on what machine you are using Vim from
- cpncrunch 11y ago
  Me neither. I've been using vim for about 20 years and I don't think I've ever spotted a single bug in that time.
  - winternewt 11y ago
    vim crashes or hangs for me about once every month. I've never bothered to find out why since I don't think it's worth the effort. The effort would be lower if the code was cleaner and didn't have so much bloat related to platforms that don't exist. It would definitely be easier to submit a patch if I didn't need to cater to all the platforms I've never seen.
    - Watabou 11y ago
      Are you sure the crashes aren't caused by a plugin you installed? I have only experienced a handful of vim crashes but all of them were caused by plugins.
      - mintplant 11y ago
        vim may still be partly to blame in that case, as it lacks support for async plugins.
        Watabou 11y ago
        Do you also blame Microsoft Word because it doesn't let you play movies?
        mintplant 11y ago
        People have tried to add async plugin support to vim, but the patches have all been rejected. Meanwhile, the plugin support in Neovim is worlds better. Microsoft Word doesn't even accept patches, which I do indeed hold against it.
        Watabou 11y ago
        The patches were rejected because they didn't provide a working solution for cross platform support. The plugin system in Neovim is only "better" for people who actually want async plugins. I am not one of them.
    - jrbrtsn 11y ago
      Most likely you've typed Ctrl-S, which causes the terminal to pause. Here is the what the vim docs have to say about that: Note: CTRL-S does not work on all terminals and might block further input, use CTRL-Q to get going again.
      - omaranto 11y ago
  - vacri 11y ago
    I don't know whether it's technically a bug or not, but vim is often a bit slow. For example, 'o' to open a new line in insert mode sometimes takes up to two or three seconds to work. Not a huge problem, but enough to make my mental flow stumble. I have a small vimrc that's mostly tab-related stuff, so I don't think it's that.
    - simoncion 11y ago
      I've also noticed delays when using 'o'. I've always wondered if it might be related to syntax highlighting.
- solutionyogi 11y ago
  He covers in the blog post: http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-vim/ http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v... From the blog post: That if statement’s conditions span 17 lines and 4 different #ifdefs. All to call gettimeofday(). Amusingly, even the body of that statement has a bug: times returned by gettimeofday() are not guaranteed to increase. User intervention or ntpd can cause the system clock to go back in time. The correct solution is to use a monotonically increasing time function, such Linux’s clock_gettime() or OS X’s mach_absolute_time().
  - harmil 11y ago
    ntpd guarantees (under the default settings now, though that's new... you can ask it to shoot you in the head, but I don't recommend that you use firearms in this way) that the clock will never go backwards. You're thinking of nptdate, a utility provided with ntpd, but which is only ever supposed to run at system initialization time to get the time close enough for ntpd to take over. If ntpd finds that the clock is ahead, it will slow the ticks, allowing it to gradually drift back to the correct time. The system time should NEVER move backwards. Ever. Relying on the system time not moving backwards is not unreasonable for trivialities like how long you wait for a keystroke. If you reset your system time, you might have to hit a key to get vim to wake up. Shucks.
    - zyztem 11y ago
      With Linux/NTP there was two times 23:59:59 UTC not long ago: https://access.redhat.com/articles/15145 https://access.redhat.com/articles/15145
    - dlubarov 11y ago
      ntpd will step backward if error stays above a configurable threshold for a configurable period of time. We saw it happen after the recent leap second. 1 second exceeds the default step threshold of 128 ms. With Linux limiting the slew rate to 500 ppm, gradual correction would have taken 2000 seconds, and by default nptd steps after 900 seconds. > ntpd guarantees (under the default settings now [...]) that the clock will never go backwards. Can you elaborate on what changed? I just downloaded the latest reference implementation, and the man page still seems to indicate that the default behavior is to step when error > 128ms for a prolonged period.
- nothrabannosir 11y ago
  When I press ESC, it takes a while to register, and for the UI (e.g. the little "command in progress" buffer bottom right) to reflect this. CTRL+C doesn't suffer this problem, and is almost functionally interchangeable, so I've retrained myself to use that, now. This is a bug, if you ask me. Or is that impossible for vim to fix?
  - nanofortnight 11y ago
    This is not a bug in vim. This is because Esc was historically used as a Meta key in lieu of the modern use of Alt. For example, if you use tmux, add the following to .tmux.conf: set -s escape-time 0 Other terminal multiplexors and emulators have different commands for this. Edit: There are a few other possible issues you are having: http://www.johnhawthorn.com/2012/09/vi-escape-delays/ http://www.johnhawthorn.com/2012/09/vi-escape-delays/
    - hkmix 11y ago
      In vim, set separate timeout and ttimeout values to get around this. Specifically, set the former high fit regular commands and the latter low to avoid issues like slow Esc processing.
Hoff 11y ago
vim works fine on OpenVMS, as it's in use in some other OpenVMS windows right now. (But thanks for the reminder to upgrade to the most current — upgrades underway.) I'm not particularly inclined to port neovim to OpenVMS right now, as there are a few other projects in the queue ahead of that.
wspeirs 11y ago
Many companies (FactSet for example) still use VMS, and vim on those systems... I think folks would be surprised how many legacy systems are still out there.
- tyho 11y ago
  How likely are these companies to upgrade to the latest vim though? It is not like these companies running VMS are following the latest version, if vim dropped crufty old OS's, then the code would be simpler and the old OS's would not notice.
  - t3f 11y ago
    There are a lot of companies with VMS environments that _must_ be regularly updated/patched/maintained with various security bits for SOX compliance or the like. There certainly are places with static installs that are carefully guarded, but that doesn't mean there isn't a poor admin/dev/user who appreciates an updated or patched version. Heck, he might be the guy doing the porting in his spare time to make his day job better. Often if your seeing regular updates to continue support for an obscure system, its a good bet someone using that environment is the key contributor for their own sanity.
    - spydum 11y ago
      This does raise the question though: when is it appropriate to drop old platform support for any OSS project, and how do you even measure it? User surveys seems insufficient.
  - belden 11y ago
    When I change jobs, I check which version of my editor the dev environments have installed. If it's too old, I build a local copy of the latest version of my editor. No worries asking IT or Ops to update a package for me. When it comes to production servers, I'm more likely to build my editor in my home directory than use my sudo privileges to install my editor in the system. So developers can be building newest versions of code on old systems. I do.
akkartik 11y ago
I too have followed the vim mailing list for many years, and tried and failed to submit a patch to it. I mostly use neovim now, and have successfully submitted a patch to it. Based on these experiences I found your blog post unnecessarily incendiary. The thread of your patch submission (https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZjQ70J https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZj...) was actually quite civil. It didn't do what you want, but let's be precise with language here. To state some blatantly obvious facts, people do open source on their own time, they have limited such time and many commitments, and they explicitly allow forks like neovim for the aspects they can't find time for. Vim and neovim have chosen very different design constraints, and there's no reason why they can't continue to exchange code where it makes sense. Putting one of the two down seems unproductive. The leaders of large projects like Neovim are seldom critical of the competition, and when they express criticism it is measured and proportionate. We should all learn from them. (Your OP here is still quite useful. Thanks for putting it together.)
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- roghummal 11y ago
  Someday 'vi' might symlink to 'nvim' instead of 'vim'. 'VI Improved Improved'! Mr. Greer's post was necessarily incendiary; He's building his brand. Wasting space on the front page of HN is a feather in his cap.
  - anon4 11y ago
    I'm really sad neovim didn't call themselves vi improved improved, or vii. It doesn't just carry the naming tradition of vim, but is also one more than vi.
    - roghummal 11y ago
      If it had we might be running it right now.
eridius 11y ago
Your blog post recommends using NeoVim today. I've considered looking at it several times, but the home page[1] still says Is it ready to download and run now with all the features? No. Although some features are a work in progress, Neovim isn't at a stable point. Using Neovim should be done with caution as things may change. This warning is why I haven't yet tried switching over. Are they just being overly-cautious? [1]: http://neovim.io http://neovim.io
- UberMouse 11y ago
  I use Neovim as my daily editor, it definitely has it's quirks over Vim (sometimes it takes over 10 seconds to write to certain files, locking up Neovim and there are some bugs with the fuzzy finder I use that cause file corruption that aren't present in Vim) but on the whole it's pretty stable. Haven't encountered any issues yet that are more than a minor annoyance.
  - jberryman 11y ago
    File corruption and sketchy saving sounds like a nightmare
  - simoncion 11y ago
    > ...there are some bugs with the fuzzy finder I use that cause file corruption... Having your text editor corrupt the file it's working on sounds like the absolute worst case scenario. Is this fuzzy finder thing some third-party plugin? Do you have any idea why it corrupts the files that you point it at?
    - UberMouse 11y ago
      It's a third party plugin, it's definitely a Neovim issue because the file corruption doesn't happen with Vim. No idea why it happens. I'm fine living with it because I just check the file back out if it corrupts it. It's only an issue when opening a new file so it doesn't cause work to be lost. A github issue about it https://github.com/junegunn/fzf/issues/206 https://github.com/junegunn/fzf/issues/206
coliveira 11y ago
Lots of people know and contribute to vim. If they try to make life easier for you, they will probably make life worse for all those who are already familiar with vim code. It is similar to the situation of the Linux kernel, where some people would prefer to use C++, while everyone who already works on Linux also knows and prefers straight C. Given the vitality of vim, I think you should just learn it and stop trying to change what already works.
deleted 11y ago
[deleted]
tsuyoshi 11y ago
"Vim is, without question, the worst C codebase I have seen." From the example you give, I agree it must be bad. But if you want to see something worse, check out PHP. No, not the billions of programs written in the PHP language (which are, indeed, almost all terrible), but the C source to the PHP interpreter. Obviously PHP was invented by someone who just doesn't care about creating a decent programming language. Everyone knows that; it has been pointed out so many times that it's a cliche. But if you look at the source to the implementation, you will find that it was developed by someone who is so incompetent that whether they care or not is beside the point. Dealing with that codebase (and thinking about how successful PHP has become) made me question my will to live.
- smt88 11y ago
  The best-engineered technology is rarely the most popular. I'd be interested to see a list of well-written code bases that are also popular. The interesting thing about PHP (the program) is that, in my experience, the code doesn't suck because it was hastily written or because it was written a long time. It sucks because the people who write it and work on it have bizarre, nonsensical philosophies about writing code. I've seen some talks by the PHP maintainers (as recently as 2013) that made me want to throw something at my monitor.
  - steve_b 11y ago
    do you have any links to these talks? thanks!
    - jsmeaton 11y ago
      Need an excuse to buy a new monitor by any chance? :)
    - smt88 11y ago
      I can't find the one I was thinking of, and I don't want to comb through literally hours of video to figure it out. This should illustrate my point, though: https://en.wikiquote.org/wiki/Rasmus_Lerdorf https://en.wikiquote.org/wiki/Rasmus_Lerdorf And also here where he makes a breaking commit without running unit tests first: http://www.reddit.com/r/programming/comments/jsudd/you_see_rasmus_lerdorf_creator_of_php_wrecking/ http://www.reddit.com/r/programming/comments/jsudd/you_see_r...
roghummal 11y ago
If you're going to use 'this is a companion piece to...' as a defense you should link to the original article in the 'companion piece' before you have to use it as a defense.
msravi 11y ago
Right. So you recommend neovim, which is good, except that it won't install -- not on some unused OS, but on OS X 10.6.8 (Snow Leopard). Now I know that's a little behind, but really? Beautiful code that won't work on a 2010 OS is just awesome. As an aside, I think it's a growing problem that the formulae in Homebrew are not updated to support 10.6.8. And Vim? It just works. Maybe it's all those #ifdefs that make the code look ugly...
- JupiterMoon 11y ago
  Do Apple supply security updates for Snow Leopard still?
  - plorkyeran 11y ago
    Apple doesn't even supply security updates for 10.9 anymore.
    - JupiterMoon 11y ago
      So the OS is EOL. In that case why should 3rd party software go out its way to support it?

by ggreer 11y ago

Alupis 11y ago

> The code works, but it's quite buggy Could you elaborate a bit? I've never experienced a bug related to keyboard input while using Vim, at least that I know of.

baby 11y ago
Depends on what machine you are using Vim from
cpncrunch 11y ago
Me neither. I've been using vim for about 20 years and I don't think I've ever spotted a single bug in that time.
- winternewt 11y ago
  vim crashes or hangs for me about once every month. I've never bothered to find out why since I don't think it's worth the effort. The effort would be lower if the code was cleaner and didn't have so much bloat related to platforms that don't exist. It would definitely be easier to submit a patch if I didn't need to cater to all the platforms I've never seen.
  - Watabou 11y ago
    Are you sure the crashes aren't caused by a plugin you installed? I have only experienced a handful of vim crashes but all of them were caused by plugins.
    - mintplant 11y ago
      vim may still be partly to blame in that case, as it lacks support for async plugins.
      - Watabou 11y ago
        Do you also blame Microsoft Word because it doesn't let you play movies?
        mintplant 11y ago
        People have tried to add async plugin support to vim, but the patches have all been rejected. Meanwhile, the plugin support in Neovim is worlds better. Microsoft Word doesn't even accept patches, which I do indeed hold against it.
        Watabou 11y ago
        The patches were rejected because they didn't provide a working solution for cross platform support. The plugin system in Neovim is only "better" for people who actually want async plugins. I am not one of them.
  - jrbrtsn 11y ago
    Most likely you've typed Ctrl-S, which causes the terminal to pause. Here is the what the vim docs have to say about that: Note: CTRL-S does not work on all terminals and might block further input, use CTRL-Q to get going again.
    - omaranto 11y ago
- vacri 11y ago
  I don't know whether it's technically a bug or not, but vim is often a bit slow. For example, 'o' to open a new line in insert mode sometimes takes up to two or three seconds to work. Not a huge problem, but enough to make my mental flow stumble. I have a small vimrc that's mostly tab-related stuff, so I don't think it's that.
  - simoncion 11y ago
    I've also noticed delays when using 'o'. I've always wondered if it might be related to syntax highlighting.
solutionyogi 11y ago
He covers in the blog post: http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-vim/ http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v... From the blog post: That if statement’s conditions span 17 lines and 4 different #ifdefs. All to call gettimeofday(). Amusingly, even the body of that statement has a bug: times returned by gettimeofday() are not guaranteed to increase. User intervention or ntpd can cause the system clock to go back in time. The correct solution is to use a monotonically increasing time function, such Linux’s clock_gettime() or OS X’s mach_absolute_time().
- harmil 11y ago
  ntpd guarantees (under the default settings now, though that's new... you can ask it to shoot you in the head, but I don't recommend that you use firearms in this way) that the clock will never go backwards. You're thinking of nptdate, a utility provided with ntpd, but which is only ever supposed to run at system initialization time to get the time close enough for ntpd to take over. If ntpd finds that the clock is ahead, it will slow the ticks, allowing it to gradually drift back to the correct time. The system time should NEVER move backwards. Ever. Relying on the system time not moving backwards is not unreasonable for trivialities like how long you wait for a keystroke. If you reset your system time, you might have to hit a key to get vim to wake up. Shucks.
  - zyztem 11y ago
    With Linux/NTP there was two times 23:59:59 UTC not long ago: https://access.redhat.com/articles/15145 https://access.redhat.com/articles/15145
  - dlubarov 11y ago
    ntpd will step backward if error stays above a configurable threshold for a configurable period of time. We saw it happen after the recent leap second. 1 second exceeds the default step threshold of 128 ms. With Linux limiting the slew rate to 500 ppm, gradual correction would have taken 2000 seconds, and by default nptd steps after 900 seconds. > ntpd guarantees (under the default settings now [...]) that the clock will never go backwards. Can you elaborate on what changed? I just downloaded the latest reference implementation, and the man page still seems to indicate that the default behavior is to step when error > 128ms for a prolonged period.
nothrabannosir 11y ago
When I press ESC, it takes a while to register, and for the UI (e.g. the little "command in progress" buffer bottom right) to reflect this. CTRL+C doesn't suffer this problem, and is almost functionally interchangeable, so I've retrained myself to use that, now. This is a bug, if you ask me. Or is that impossible for vim to fix?
- nanofortnight 11y ago
  This is not a bug in vim. This is because Esc was historically used as a Meta key in lieu of the modern use of Alt. For example, if you use tmux, add the following to .tmux.conf: set -s escape-time 0 Other terminal multiplexors and emulators have different commands for this. Edit: There are a few other possible issues you are having: http://www.johnhawthorn.com/2012/09/vi-escape-delays/ http://www.johnhawthorn.com/2012/09/vi-escape-delays/
  - hkmix 11y ago
    In vim, set separate timeout and ttimeout values to get around this. Specifically, set the former high fit regular commands and the latter low to avoid issues like slow Esc processing.

Hoff 11y ago

vim works fine on OpenVMS, as it's in use in some other OpenVMS windows right now. (But thanks for the reminder to upgrade to the most current — upgrades underway.) I'm not particularly inclined to port neovim to OpenVMS right now, as there are a few other projects in the queue ahead of that.

wspeirs 11y ago

Many companies (FactSet for example) still use VMS, and vim on those systems... I think folks would be surprised how many legacy systems are still out there.

tyho 11y ago
How likely are these companies to upgrade to the latest vim though? It is not like these companies running VMS are following the latest version, if vim dropped crufty old OS's, then the code would be simpler and the old OS's would not notice.
- t3f 11y ago
  There are a lot of companies with VMS environments that _must_ be regularly updated/patched/maintained with various security bits for SOX compliance or the like. There certainly are places with static installs that are carefully guarded, but that doesn't mean there isn't a poor admin/dev/user who appreciates an updated or patched version. Heck, he might be the guy doing the porting in his spare time to make his day job better. Often if your seeing regular updates to continue support for an obscure system, its a good bet someone using that environment is the key contributor for their own sanity.
  - spydum 11y ago
    This does raise the question though: when is it appropriate to drop old platform support for any OSS project, and how do you even measure it? User surveys seems insufficient.
- belden 11y ago
  When I change jobs, I check which version of my editor the dev environments have installed. If it's too old, I build a local copy of the latest version of my editor. No worries asking IT or Ops to update a package for me. When it comes to production servers, I'm more likely to build my editor in my home directory than use my sudo privileges to install my editor in the system. So developers can be building newest versions of code on old systems. I do.

akkartik 11y ago

I too have followed the vim mailing list for many years, and tried and failed to submit a patch to it. I mostly use neovim now, and have successfully submitted a patch to it. Based on these experiences I found your blog post unnecessarily incendiary. The thread of your patch submission (https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZjQ70J https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZj...) was actually quite civil. It didn't do what you want, but let's be precise with language here. To state some blatantly obvious facts, people do open source on their own time, they have limited such time and many commitments, and they explicitly allow forks like neovim for the aspects they can't find time for. Vim and neovim have chosen very different design constraints, and there's no reason why they can't continue to exchange code where it makes sense. Putting one of the two down seems unproductive. The leaders of large projects like Neovim are seldom critical of the competition, and when they express criticism it is measured and proportionate. We should all learn from them. (Your OP here is still quite useful. Thanks for putting it together.)

deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
roghummal 11y ago
Someday 'vi' might symlink to 'nvim' instead of 'vim'. 'VI Improved Improved'! Mr. Greer's post was necessarily incendiary; He's building his brand. Wasting space on the front page of HN is a feather in his cap.
- anon4 11y ago
  I'm really sad neovim didn't call themselves vi improved improved, or vii. It doesn't just carry the naming tradition of vim, but is also one more than vi.
  - roghummal 11y ago
    If it had we might be running it right now.

eridius 11y ago

Your blog post recommends using NeoVim today. I've considered looking at it several times, but the home page[1] still says Is it ready to download and run now with all the features? No. Although some features are a work in progress, Neovim isn't at a stable point. Using Neovim should be done with caution as things may change. This warning is why I haven't yet tried switching over. Are they just being overly-cautious? [1]: http://neovim.io http://neovim.io

UberMouse 11y ago
I use Neovim as my daily editor, it definitely has it's quirks over Vim (sometimes it takes over 10 seconds to write to certain files, locking up Neovim and there are some bugs with the fuzzy finder I use that cause file corruption that aren't present in Vim) but on the whole it's pretty stable. Haven't encountered any issues yet that are more than a minor annoyance.
- jberryman 11y ago
  File corruption and sketchy saving sounds like a nightmare
- simoncion 11y ago
  > ...there are some bugs with the fuzzy finder I use that cause file corruption... Having your text editor corrupt the file it's working on sounds like the absolute worst case scenario. Is this fuzzy finder thing some third-party plugin? Do you have any idea why it corrupts the files that you point it at?
  - UberMouse 11y ago
    It's a third party plugin, it's definitely a Neovim issue because the file corruption doesn't happen with Vim. No idea why it happens. I'm fine living with it because I just check the file back out if it corrupts it. It's only an issue when opening a new file so it doesn't cause work to be lost. A github issue about it https://github.com/junegunn/fzf/issues/206 https://github.com/junegunn/fzf/issues/206

coliveira 11y ago

Lots of people know and contribute to vim. If they try to make life easier for you, they will probably make life worse for all those who are already familiar with vim code. It is similar to the situation of the Linux kernel, where some people would prefer to use C++, while everyone who already works on Linux also knows and prefers straight C. Given the vitality of vim, I think you should just learn it and stop trying to change what already works.

deleted 11y ago

[deleted]

tsuyoshi 11y ago

"Vim is, without question, the worst C codebase I have seen." From the example you give, I agree it must be bad. But if you want to see something worse, check out PHP. No, not the billions of programs written in the PHP language (which are, indeed, almost all terrible), but the C source to the PHP interpreter. Obviously PHP was invented by someone who just doesn't care about creating a decent programming language. Everyone knows that; it has been pointed out so many times that it's a cliche. But if you look at the source to the implementation, you will find that it was developed by someone who is so incompetent that whether they care or not is beside the point. Dealing with that codebase (and thinking about how successful PHP has become) made me question my will to live.

smt88 11y ago
The best-engineered technology is rarely the most popular. I'd be interested to see a list of well-written code bases that are also popular. The interesting thing about PHP (the program) is that, in my experience, the code doesn't suck because it was hastily written or because it was written a long time. It sucks because the people who write it and work on it have bizarre, nonsensical philosophies about writing code. I've seen some talks by the PHP maintainers (as recently as 2013) that made me want to throw something at my monitor.
- steve_b 11y ago
  do you have any links to these talks? thanks!
  - jsmeaton 11y ago
    Need an excuse to buy a new monitor by any chance? :)
  - smt88 11y ago
    I can't find the one I was thinking of, and I don't want to comb through literally hours of video to figure it out. This should illustrate my point, though: https://en.wikiquote.org/wiki/Rasmus_Lerdorf https://en.wikiquote.org/wiki/Rasmus_Lerdorf And also here where he makes a breaking commit without running unit tests first: http://www.reddit.com/r/programming/comments/jsudd/you_see_rasmus_lerdorf_creator_of_php_wrecking/ http://www.reddit.com/r/programming/comments/jsudd/you_see_r...

roghummal 11y ago

If you're going to use 'this is a companion piece to...' as a defense you should link to the original article in the 'companion piece' before you have to use it as a defense.

msravi 11y ago

Right. So you recommend neovim, which is good, except that it won't install -- not on some unused OS, but on OS X 10.6.8 (Snow Leopard). Now I know that's a little behind, but really? Beautiful code that won't work on a 2010 OS is just awesome. As an aside, I think it's a growing problem that the formulae in Homebrew are not updated to support 10.6.8. And Vim? It just works. Maybe it's all those #ifdefs that make the code look ugly...

JupiterMoon 11y ago
Do Apple supply security updates for Snow Leopard still?
- plorkyeran 11y ago
  Apple doesn't even supply security updates for 10.9 anymore.
  - JupiterMoon 11y ago
    So the OS is EOL. In that case why should 3rd party software go out its way to support it?