
Neovim: input encoding and you - bpierre
http://www.aktau.be/2014/11/04/neovim-input-encoding-and-you/
======
drv
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?

~~~
DSMan195276
In general they appear to have a problem with mixing lengths between being
ints and being size_ts (Decently common problem). In that particular instance
they could run into a problem if they compile for 64-bit (64-bit size_t,
32-bit int) and string_convert_ext gives a negative length, since int is
signed.

~~~
aktau
We compile for 64-bit and 32-bit on every commit with travis CI and for many
files activate extra warnings such as `-Wconversion`. We are acutely aware of
the problem. However, we can't refactor the entirety of the (quite large) Vim
codebase in one go. Whenever we add new code or replace old code that calls
into more old code (often), we have to decide whether we will also refactor
said old code to be more modern.

In fact, we have sections of the projects wiki devoted to this type issue:
[https://github.com/neovim/neovim/wiki](https://github.com/neovim/neovim/wiki)
(the specific section: [https://github.com/neovim/neovim/wiki/Integer-types-
refactor...](https://github.com/neovim/neovim/wiki/Integer-types-refactoring-
guidelines)).

It's not perfect, but you'll see we've put at least some thought into it and
we welcome new contributions.

It's a problem of manpower and/or time, not necessarily of misunderstanding C
and making rookie mistakes about types as the grandparent seems to imply.

There, had to get that off my chest. (I'm not seeing Neovim's code, old or
new, is perfect, but it's probably better than what the tone of the comment
implied).

~~~
nate_meurer
aktau, your HN account appears to be dead. I'm guessing it's because this
comment of yours was posted multiple times.

~~~
aktau
Thanks for the heads up. I went back and pressed submit several times because
in my incognito window my comment didn't show up. (I was trying to post while
noprocrast was on, didn't expect something I wrote to hit HN). I wonder now
what I should do to not become dead anymore? I deleted the superfluous
comments, hopefully that's enough. I'll look up what it means to be dead on
HN.

~~~
nate_meurer
Deleting those posts seems to have worked. I can now see your previously
elided comments with my "showdead" set to on.

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

~~~
iamartnez
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.

~~~
riffraff
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

