6 ms·

Neovim: input encoding and you

64 points by bpierre 12y ago

coherentpony 12y ago
As a user, what benefit do I have switching from vim to neovim?
- ebiester 12y ago
  Nothing yet. It's not ready. Eventually, better plugins and GUIs without losing what makes vim so productive.
  - coherentpony 12y ago
    Cool, thanks.
- iamartnez 12y ago
  My understanding is that Neovim will make it much easier for plugins to execute tasks in parallel and in the background. I'd use that for running ctags on save without blocking the editor, for example.
  - lorenzfx 12y ago
    like this new Floobits plugin [0] [0] https://news.ycombinator.com/item?id=8559146 https://news.ycombinator.com/item?id=8559146
  - riffraff 12y ago
    The reason I'm following neovim is that I'm hoping for a future where linting doesn't freeze my editor on save. Sadly, I do like my gui, so I'll have to wait a bit more
- wffurr 12y ago
  A plugin like eclim would benefit greatly from the new multi-process model.
- splinterofchaos 12y ago
  The most popular neovim feature (based on reddit's reactions) seems to be job control, although not enough people are using it. You can start an asynchronous job via `jobstart('name', 'prog', ['arg'...])` which will return a job id. You can send data to the job via `jobsend(id, 'text'). Every time the program has some output available, it will trigger an autocmd to let you process it. (This happens synchronously.) We have refactored some of the code base using modern coding standards, which makes it more hackable. Some of these systems have become more efficient by, for example, using pipes over temp files. We accept upstream patches in order to stay on top of vim, so I hope that no one will ever not use neovim because of a feature lacking (aside from a GUI--see below). neovim creates a socket for each instance that external programs can communicate with, allowing one to write a plugin or extension in any language, providing it has a msgpack implementation. These plugins may eventually control things like the GUIs, spell checkers, syntax analysers, allowing nvim to become more focused, like a micro-kernel. As of right now, many people have switched without having any real problems.
  - ThrustVectoring 12y ago
    Any plans for nuking vimscript?
    - wal0 12y ago
      No, Vim plugins wouldn't work anymore. Vimscript will be transpiled to Lua under the hood, though, and other languages will be fully supported for writing plugins.
      - splinterofchaos 12y ago
        They'll work just fine, by being "transpiled".
    - splinterofchaos 12y ago
      Nope. See the bottom item on the FAQ: https://github.com/neovim/neovim/wiki/FAQ#are-plugin-authors-encouraged-to-port-their-plugins-from-viml-to-lua-do-you-plan-to-support-viml-indefinitely-1152 https://github.com/neovim/neovim/wiki/FAQ#are-plugin-authors...
drv 12y ago
If this is the general quality of new code in the Neovim code base, I would be fairly worried. In the first piece of code, which is apparently new to Neovim, there's a bug waiting to happen: casting size_t pointers to int pointers will fail on big-endian platforms where sizeof(size_t) != sizeof(int), and in general, the number of casts sprinkled everywhere is indicative of sloppy coding. The whole area of code also seems to be poorly reimplementing iconv, which is actually supported in the code, but never enabled in Neovim for some reason, according to the footnote - why have two code paths to do the same thing?
- tux1968 12y ago
  Neovim is a fork of the original Vim codebase. Much of the code hasn't been touched yet, including the code quoted in the article.
  - nsmartt 12y ago
    From the article: > The function is short enough to paste below. It is pretty unique to Neovim, as it was wrought for its brand new event-oriented nature:
- octo_t 12y ago
  The problem isn't big-endian, its just platforms where sizeof(size_t) != sizeof(int). I believe the problem is the legacy vim API takes an (int ), so that code will also need to be corrected: char_u *string_convert_ext __ARGS((vimconv_T *vcp, char_u *ptr, int *lenp, int *unconvlenp));
  - aktau 12y ago
    Article author here. You're correct. It's new code that's calling into old, unrefactored code. Hence the casts. convert_input() is new, string_convert_ext() is old. As is mentioned in the article, I'm working on a refactoring of string_convert_ext() that will obviate the casting (and incidentally also some allocating).
  - deleted 12y ago
    [deleted]

64 points by bpierre 12y ago

coherentpony 12y ago

As a user, what benefit do I have switching from vim to neovim?

ebiester 12y ago
Nothing yet. It's not ready. Eventually, better plugins and GUIs without losing what makes vim so productive.
- coherentpony 12y ago
  Cool, thanks.
iamartnez 12y ago
My understanding is that Neovim will make it much easier for plugins to execute tasks in parallel and in the background. I'd use that for running ctags on save without blocking the editor, for example.
- lorenzfx 12y ago
  like this new Floobits plugin [0] [0] https://news.ycombinator.com/item?id=8559146 https://news.ycombinator.com/item?id=8559146
- riffraff 12y ago
  The reason I'm following neovim is that I'm hoping for a future where linting doesn't freeze my editor on save. Sadly, I do like my gui, so I'll have to wait a bit more
wffurr 12y ago
A plugin like eclim would benefit greatly from the new multi-process model.
splinterofchaos 12y ago
The most popular neovim feature (based on reddit's reactions) seems to be job control, although not enough people are using it. You can start an asynchronous job via `jobstart('name', 'prog', ['arg'...])` which will return a job id. You can send data to the job via `jobsend(id, 'text'). Every time the program has some output available, it will trigger an autocmd to let you process it. (This happens synchronously.) We have refactored some of the code base using modern coding standards, which makes it more hackable. Some of these systems have become more efficient by, for example, using pipes over temp files. We accept upstream patches in order to stay on top of vim, so I hope that no one will ever not use neovim because of a feature lacking (aside from a GUI--see below). neovim creates a socket for each instance that external programs can communicate with, allowing one to write a plugin or extension in any language, providing it has a msgpack implementation. These plugins may eventually control things like the GUIs, spell checkers, syntax analysers, allowing nvim to become more focused, like a micro-kernel. As of right now, many people have switched without having any real problems.
- ThrustVectoring 12y ago
  Any plans for nuking vimscript?
  - wal0 12y ago
    No, Vim plugins wouldn't work anymore. Vimscript will be transpiled to Lua under the hood, though, and other languages will be fully supported for writing plugins.
    - splinterofchaos 12y ago
      They'll work just fine, by being "transpiled".
  - splinterofchaos 12y ago
    Nope. See the bottom item on the FAQ: https://github.com/neovim/neovim/wiki/FAQ#are-plugin-authors-encouraged-to-port-their-plugins-from-viml-to-lua-do-you-plan-to-support-viml-indefinitely-1152 https://github.com/neovim/neovim/wiki/FAQ#are-plugin-authors...

drv 12y ago

If this is the general quality of new code in the Neovim code base, I would be fairly worried. In the first piece of code, which is apparently new to Neovim, there's a bug waiting to happen: casting size_t pointers to int pointers will fail on big-endian platforms where sizeof(size_t) != sizeof(int), and in general, the number of casts sprinkled everywhere is indicative of sloppy coding. The whole area of code also seems to be poorly reimplementing iconv, which is actually supported in the code, but never enabled in Neovim for some reason, according to the footnote - why have two code paths to do the same thing?

tux1968 12y ago
Neovim is a fork of the original Vim codebase. Much of the code hasn't been touched yet, including the code quoted in the article.
- nsmartt 12y ago
  From the article: > The function is short enough to paste below. It is pretty unique to Neovim, as it was wrought for its brand new event-oriented nature:
octo_t 12y ago
The problem isn't big-endian, its just platforms where sizeof(size_t) != sizeof(int). I believe the problem is the legacy vim API takes an (int ), so that code will also need to be corrected: char_u *string_convert_ext __ARGS((vimconv_T *vcp, char_u *ptr, int *lenp, int *unconvlenp));
- aktau 12y ago
  Article author here. You're correct. It's new code that's calling into old, unrefactored code. Hence the casts. convert_input() is new, string_convert_ext() is old. As is mentioned in the article, I'm working on a refactoring of string_convert_ext() that will obviate the casting (and incidentally also some allocating).
- deleted 12y ago
  [deleted]