3 ms·

That is an overly simplistic viewpoint. Vim is written in an inedibly old style of C which is not taught anymore, or used by most people. The code if fill of ty

That is an overly simplistic viewpoint. Vim is written in an inedibly old style of C which is not taught anymore, or used by most people. The code if fill of typedefs for AMIGA and OS/2. Useful to a small number of people certainly, but making progression harder too. This is not a total rewrite, it is a massive overdue refactoring.

perlgeek 13y ago
> The code if fill of typedefs for AMIGA and OS/2. Useful to a small number of people certainly, but making progression harder too. Sounds like the code of pretty much every non-trivial C program that is meant to run of many platforms, not just the five or ten most popular ones. I'm not saying that this is a good thing, just that I don't know any good alternatives that don't sacrifice compatibility with lots of platforms.
- kzrdude 13y ago
  It should say ifdefs, not typedefs. Inline ifdef directives everywhere is a real nightmare. The very first commit in neovim includes this log: - Process files through unifdef to remove tons of FEAT_* macros
  - teacup50 13y ago
    Which is exactly the sort of pointless "refactoring" that someone does instead of actual refactoring. It also makes merging back to vim difficult to impossible. Expect to see 'neovim' development dissipate rapidly.
dllthomas 13y ago
Inedibly?
nhaehnle 13y ago
The code if fill of typedefs for AMIGA and OS/2. There's nothing wrong with that as long as those typedefs are properly isolated in some platform-specific header files. It's natural to have an initial feeling of being overwhelmed by that kind of stuff. However, it often turns out that there's nothing to gain from removing that stuff. The only real cost is when people expect a platform to work, but nobody from that platform is willing to put in the testing effort.
- ggreer 13y ago
  Have you looked at the Vim source? There are a few things in platform-specific headers, but most ifdefs are scattered in actual code. There are even ifdefs in the middle of control flow statements. For example, in RealWaitForChar(): https://github.com/b4winckler/macvim/blob/master/src/os_unix.c#L5097 https://github.com/b4winckler/macvim/blob/master/src/os_unix... That function is over 400 lines and has over 50 ifdefs. What does it do? It waits for any key to be pressed. Unfortunately, Vim is single-threaded and synchronously character-driven, so it has to try and process some autocmds and other events in the same loop. Oh and the wait loop uses gettimeofday(), which is not monotonic. To get another taste of Vim's source, take a look at https://github.com/b4winckler/macvim/blob/master/src/eval.c https://github.com/b4winckler/macvim/blob/master/src/eval.c (Warning, may crash your browser.) That file is 25,000 lines and checks hundreds of different ifdefs.
  - tokenrove 13y ago
    If that example (eval.c) is supposed to be bad, I don't think there's a strong case here. It looks like lots of older Unix/BSD code, and most of the ifdefs are feature-related, rather than platform hacks; some of the functions are a bit long, but that's typical in older C code. I've never read the vim code before and I was surprised how cleanly written and well-commented it is, given my expectations set by this thread.
  - kzrdude 13y ago
    I love that if whose condition stretches over 15 lines with inline ifdefs, and then the body of the conditional is just one line without surrounding braces..

perlgeek 13y ago

> The code if fill of typedefs for AMIGA and OS/2. Useful to a small number of people certainly, but making progression harder too. Sounds like the code of pretty much every non-trivial C program that is meant to run of many platforms, not just the five or ten most popular ones. I'm not saying that this is a good thing, just that I don't know any good alternatives that don't sacrifice compatibility with lots of platforms.

kzrdude 13y ago
It should say ifdefs, not typedefs. Inline ifdef directives everywhere is a real nightmare. The very first commit in neovim includes this log: - Process files through unifdef to remove tons of FEAT_* macros
- teacup50 13y ago
  Which is exactly the sort of pointless "refactoring" that someone does instead of actual refactoring. It also makes merging back to vim difficult to impossible. Expect to see 'neovim' development dissipate rapidly.

dllthomas 13y ago

Inedibly?

nhaehnle 13y ago

The code if fill of typedefs for AMIGA and OS/2. There's nothing wrong with that as long as those typedefs are properly isolated in some platform-specific header files. It's natural to have an initial feeling of being overwhelmed by that kind of stuff. However, it often turns out that there's nothing to gain from removing that stuff. The only real cost is when people expect a platform to work, but nobody from that platform is willing to put in the testing effort.

ggreer 13y ago
Have you looked at the Vim source? There are a few things in platform-specific headers, but most ifdefs are scattered in actual code. There are even ifdefs in the middle of control flow statements. For example, in RealWaitForChar(): https://github.com/b4winckler/macvim/blob/master/src/os_unix.c#L5097 https://github.com/b4winckler/macvim/blob/master/src/os_unix... That function is over 400 lines and has over 50 ifdefs. What does it do? It waits for any key to be pressed. Unfortunately, Vim is single-threaded and synchronously character-driven, so it has to try and process some autocmds and other events in the same loop. Oh and the wait loop uses gettimeofday(), which is not monotonic. To get another taste of Vim's source, take a look at https://github.com/b4winckler/macvim/blob/master/src/eval.c https://github.com/b4winckler/macvim/blob/master/src/eval.c (Warning, may crash your browser.) That file is 25,000 lines and checks hundreds of different ifdefs.
- tokenrove 13y ago
  If that example (eval.c) is supposed to be bad, I don't think there's a strong case here. It looks like lots of older Unix/BSD code, and most of the ifdefs are feature-related, rather than platform hacks; some of the functions are a bit long, but that's typical in older C code. I've never read the vim code before and I was surprised how cleanly written and well-commented it is, given my expectations set by this thread.
- kzrdude 13y ago
  I love that if whose condition stretches over 15 lines with inline ifdefs, and then the body of the conditional is just one line without surrounding braces..