neovim/neovim

Vim-fork focused on extensibility and usability

Documentation | Chat

Neovim is a project that seeks to aggressively refactor Vim in order to:

• Simplify maintenance and encourage contributions
• Split the work between multiple developers
• Enable advanced UIs without modifications to the core
• Maximize extensibility

See the Introduction wiki page and Roadmap for more information.

Features

• Modern GUIs
• API access from any language including C/C++, C#, Clojure, D, Elixir, Go, Haskell, Java/Kotlin, JavaScript/Node.js, Julia, Lisp, Lua, Perl, Python, Racket, Ruby, Rust
• Embedded, scriptable terminal emulator
• Asynchronous job control
• Shared data (shada) among multiple editor instances
• XDG base directories support
• Compatible with most Vim plugins, including Ruby and Python plugins

See :help nvim-features for the full list, and :help news for noteworthy changes in the latest version!

Install from package

Pre-built packages for Windows, macOS, and Linux are found on the Releases page.

Managed packages are in Homebrew, Debian, Ubuntu, Fedora, Arch Linux, Void Linux, Gentoo, and more!

Install from source

See BUILD.md and supported platforms for details.

The build is CMake-based, but a Makefile is provided as a convenience. After installing the dependencies, run the following command.

make CMAKE_BUILD_TYPE=RelWithDebInfo
sudo make install

To install to a non-default location:

make CMAKE_BUILD_TYPE=RelWithDebInfo CMAKE_INSTALL_PREFIX=/full/path/
make install

CMake hints for inspecting the build:

• cmake --build build --target help lists all build targets.
• build/CMakeCache.txt (or cmake -LAH build/) contains the resolved values of all CMake variables.
• build/compile_commands.json shows the full compiler invocations for each translation unit.

Transitioning from Vim

See :help nvim-from-vim for instructions.

Project layout

├─ cmake/           CMake utils
├─ cmake.config/    CMake defines
├─ cmake.deps/      subproject to fetch and build dependencies (optional)
├─ runtime/         plugins and docs
├─ src/nvim/        application source code (see src/nvim/README.md)
│  ├─ api/          API subsystem
│  ├─ eval/         Vimscript subsystem
│  ├─ event/        event-loop subsystem
│  ├─ generators/   code generation (pre-compilation)
│  ├─ lib/          generic data structures
│  ├─ lua/          Lua subsystem
│  ├─ msgpack_rpc/  RPC subsystem
│  ├─ os/           low-level platform code
│  └─ tui/          built-in UI
└─ test/            tests (see test/README.md)

License

Neovim contributions since b17d96 are licensed under the Apache 2.0 license, except for contributions copied from Vim (identified by the vim-patch token). See LICENSE for details.

Vim is Charityware.  You can use and copy it as much as you like, but you are
encouraged to make a donation for needy children in Uganda.  Please see the
kcc section of the vim docs or visit the ICCF web site, available at these URLs:

        https://iccf-holland.org/
        https://www.vim.org/iccf/
        https://www.iccf.nl/

You can also sponsor the development of Vim.  Vim sponsors can vote for
features.  The money goes to Uganda anyway.

neovim's Issues

Terminal emulator inside of vim

A terminal emulator inside of vim would be extremely useful. I'm envious of emacs and other editors that have this built-in, while the authors of vim are opposed to doing this.

There was an old patch that offered this, that could potentially be a starting point. I understand that terminal emulators are huge and complicated (see the xterm source), and we would want to keep all of that cruft out of neovim's source, but st is a counterexample of a terminal with a lean and readable source.

The vim plugins that support this, written in python or vimscript (Conque, vterm, etc), are slow and clunky compared to the vim-shell patch. Wrapping a vim session with tmux or screen can also be awkward, because you now have to use tmux/screen's keybindings along with vim's, and do not get most vim editing features in a shell.

Arch Instructions

To build on Arch, you need to install base-devel, cmake and ncurses. So all that is needed for instructions is something like sudo pacman -S base-devel cmake ncurses. The build process works fine for me.

reserved identifier violation

I would like to point out that identifiers like "VIM__H" and "_BE" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

For ubuntu you also depended on `libtool` (for libtoolize)

You may add Readme.mkd on the Ubuntu Dependencies.

Mailing list?

Do you plan to setup a mailing list?

Improve use of Travis CI

This is a lower priority, but here's some followup items for the Travis CI issue:

Every PR:

• Build Neovim binaries for all platforms
• Upload the binaries to some file repository with the PR ID as a suffix (neovim-mac-PR123.tgz) (I'm happy to host this file repo, pay for S3, whatever), and ideally automatically publish a link to the binaries in the related pull request so people can download Neovim and test it with a given pull request included
• Notify IRC that a PR has been submitted

When a PR is merged:

• Rebuild Neovim binaries for all platforms
• Upload the binaries to the same file repo with no prefix (neovim-mac.tgz or whatever)

This way, we can link to the main binaries from the website for people to download and start playing with (without having to build it themselves).

Also, we should add the build status image to the Readme.

Website

I'm not so interested in contributing financially, but I'd like to donate a website to this project. I'm a longtime vim user, and I'm really eager to see this kind of improvement. I have purchased neovim.org, and I can build the website and host it for the foreseeable future.

All I need is input on what should be there!

Port most OS calls to libuv

This will involve reimplementing most of os_unix.c. We'll have to reimplement all the mch_* functions in proto/os_unix.pro in terms of libuv.

[FreeBSD] Build process relies on wget, which is broken.

wget on FreeBSD needs the following arguments:

--ca-certificate /usr/local/share/certs/ca-root-nss.crt

in order to work properly. Without this, the build fails with the following output:

sh -e scripts/get-libuv.sh
--2014-02-21 21:28:40--  https://github.com/joyent/libuv/archive/v0.11.19.tar.gz
Resolving github.com (github.com)... 192.30.252.130
Connecting to github.com (github.com)|192.30.252.130|:443... connected.
ERROR: cannot verify github.com's certificate, issued by '/C=US/O=DigiCert     Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV CA-1':
  Unable to locally verify the issuer's authority.
To connect to github.com insecurely, use `--no-check-certificate'.
SHA1 sum doesn't match, expected '5539d8e99e22b438cf4a412d4cec70ac6bb519fc'    got 'da39a3ee5e6b4b0d3255bfef95601890afd80709'
*** Error code 1

Stop.
make: stopped in /usr/home/brennan/projects/neovim

Automatic builds with Travis CI?

Not sure if that would be a good fit for this project or not, but might be something to look into!

Use GNU gettext on OSX

See #25

Need a logo

Any volunteers for this? It will be used on the organization, webpage and bountysource(Including the rewards).

True Color support in both GUI and console application

See the support/patches for original VIm https://bitbucket.org/ZyX_I/vim/commits/branch/24-bit-xterm
Also, ncurses is not going to have support for that (thanks its author!).
And now it is supported by major part of terminal applications.
Here is the addition info about true colors:

Colors in terminal

It's a common confusion about terminal colors... Actually we have this:

• plain ascii
• ansi escape codes (16 color codes with bold/italic and background)
• 256 color palette (216 colors+16gray + ansi) (colors are 24bit)
• 24bit true color (888 colors (aka 16 milion))

The 256 color palete is configured at start, and it's a 666 cube of
colors, each of them defined as a 24bit (888 rgb) color.

This means that current support can only display 256 different colors
in the terminal, while truecolor means that you can display 16 milion
different colors at the same time.

Truecolor escape codes doesnt uses a color palete. It just specifies the
color itself.

Here's a test case:

printf "\x1b[38;2;255;100;0mTRUECOLOR\x1b[0m\n"

• or http://github.com/robertknight/konsole/tree/master/tests/color-spaces.pl
• or https://git.gnome.org/browse/vte/tree/perf/img.sh?h=vte-0-36

Keep in mind that it is possible to use both ';' and ':' as parameters delimiter.

According to Wikipedia[1], this is only supported by xterm and konsole.

[1] https://en.wikipedia.org/wiki/ANSI_color

Here are terminals discussions:

Now supporting truecolor

• st (from suckless) [delimeter: semicolon] - http://lists.suckless.org/dev/1307/16688.html
• konsole [delimeter: colon, semicolon] - https://bugs.kde.org/show_bug.cgi?id=107487
• iterm2 [delimeter: colon, semicolon] - only in the nighties https://code.google.com/p/iterm2/issues/detail?id=218
• qterminal [delimeter: semicolon] - lxqt/qterminal#78
• Tera Term [delimeter: colon, semicolon] - Windows platform
• FinalTerm [delimeter: semicolon]
• all libvte based terminals (since 0.36 version) [delimeter: colon, semilocon] - https://bugzilla.gnome.org/show_bug.cgi?id=704449
  • libvte-based Gnome Terminal
  • libvte-based sakura
  • libvte-based Terminator
  • libvte-based Lilyterm - since commit Tetralet/LilyTerm@72536e7
  • libvte-based ROXTerm
  • libvte-based evilvte - no release yet, version from git https://github.com/caleb-/evilvte
  • libvte-based Termit
  • libvte-based Termite
  • libvte-based Tilda
  • libvte-based tinyterm
  • libvte-based lxterminal - with --enable-gtk3 configure flag.

But there are bunch of libvte-based terminals for GTK2 so they are listed in the another section.

Parsing ANSI color sequences, but approximating them to 256 palette

• xterm (though doing it wrong: "it uses nearest colour in RGB colour space, with a usualfalse assumption about orthogonal axes")
• mlterm - http://sourceforge.net/mailarchive/message.php?msg_id=31828705

Note about colour differences: a) RGB axes are not orthogonal, so you cannot use sqrt(R^2+G^2+B^2) formula, b) for colour differences there is more correct (but much more complex) CIEDE2000 formula (which may easily blow up performance if used blindly) [2].

[2] #793 (comment)

NOT supporting truecolor

• urxvt - http://lists.schmorp.de/pipermail/rxvt-unicode/2013q3/001826.html
• Terminlogy (E17) - https://phab.enlightenment.org/T746
• mrxvt - https://sourceforge.net/p/materm/feature-requests/41/
• aterm - https://sourceforge.net/p/aterm/feature-requests/23/
• mintty (Cygwin and MSYS) - https://code.google.com/p/mintty/issues/detail?id=431
• fbcon (from linux kernel) - https://bugzilla.kernel.org/show_bug.cgi?id=79551
• FreeBSD console - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191652
• libvte and GTK2 - based:
  • libvte-based GTKTerm2
  • libvte-based stjerm - stjerm/stjerm#39

Terminal multiplexers

• tmux (have workaround[3]) - https://sourceforge.net/p/tmux/tickets/140/ and https://www.mail-archive.com/[email protected]/msg04720.html
• screen

[3] Currently you can use tmux_escape option as a workaround if you want true color in shell run under tmux. No true color in tmux statusline though.

Here are another console programs discussions:

Supporting True Color:

• irssi - irssi/irssi#48

Not supporting True Color:

• mutt - http://dev.mutt.org/trac/ticket/3674
• mc - http://www.midnight-commander.org/ticket/3145#comment:1 - demo patches attached
• s-lang library - http://lists.jedsoft.org/lists/slang-users/2014/0000002.html
• ncurses library - https://lists.gnu.org/archive/html/bug-ncurses/2013-10/msg00007.html
• termbox library - nsf/termbox#37
• mcabber - https://bitbucket.org/McKael/mcabber-crew/issue/126/support-for-true-color-16-millions-colors
• emacs - http://emacs.1067599.n5.nabble.com/RFC-Add-tty-True-Color-support-td299962.html
• vim - https://bitbucket.org/ZyX_I/vim/commits/branch/24-bit-xterm
• tig - jonas/tig#227

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

Check for existing libuv install before installing it ourselves

I'm trying to write a homebrew formula for neovim. I'm currently patching the Makefile so we can use a homebrew-installed libuv.

HAVE_WORKING_LIBINTL - Failed on OSX

I have XCode installed as well as gettext, automate, cmake, and libtool

$ make cmake
rm -rf build
for file in lua mbyte mzscheme small tiny; do \
        rm -f src/testdir/$file.vim; \
    done
mkdir build
cd build && cmake -DCMAKE_BUILD_TYPE=Debug ../
-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for tgetent in termcap
-- Looking for tgetent in termcap - found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of int
-- Check size of int - done
-- Check size of long
-- Check size of long - done
-- Check size of time_t
-- Check size of time_t - done
-- Check size of off_t
-- Check size of off_t - done
-- Performing Test HAVE_WORKING_LIBINTL
-- Performing Test HAVE_WORKING_LIBINTL - Failed
-- Configuring done
-- Generating done
-- Build files have been written to: ~/projects/neovim/build

Establish coding convention

As an avid Vim user, I'm really excited for this project and excited to contribute.

I think we should establish a coding convention for the project that is modern as well. Vim follows a pretty archaic coding style, and we already have a few issues open to clean some it up, such as #37, #39, and #64. I am completely fine with Vim's 2 space indent style, but I think we should use a more modern convention for other aspects such as choosing names for identifiers, types, etc.

Some observations as examples of why we need this:

• Naming convention is inconsistent. For example, there are enums called key_extra, regstate_E, SpecialKey, etc. Similarly for other identifiers.
• Some enums have the comma at the beginning of the next line (see enum key_extra in keymap.h) while others follow the usual convention of keeping the comma at the end of each line (see enum SpecialKey in term.h).
• Most files use 2 spaces for indentation even the file's vim settings are ts=8 sts=4 sw=4 at the top of the file. I think we should stick to 2 spaces and correct these settings.
• Many control structures omit braces. I think that all control structures must have braces, especially since this may have prevented the fun Apple SSL bug we have been hearing a lot about lately.

Voting has been moved to #104

Fix alt usage in terminal?

I've never been able to use proper alt in terminal vim. AFAICR, this is because of legacy and alt and escape kind of being the same thing. Since this project is deprecating a lot of legacy (+1000 about that btw), would it be possible to refactor whatever code is doing this parsing to be modern and support terminals that can make a difference out of alt and escape?

(Note that I might be completely off since it was many moons I thought and/or researched about this.)

Again, cheers for this project!

[FreeBSD] Build process uses wrong sha1 utility.

FreeBSD's equivalent of sha1sum is simply called sha1.

Vim's rebirth for the 21st century

The repo's description should be "... 21st ..." instead of "... 21th...". Potentially the most insignificant of issues.

Should keep src/README.txt from the original vim source tree

https://raw2.github.com/b4winckler/vim/master/src/README.txt
is a nice overview of the code structure.

Possibility of Easter Eggs ?

This is not an issue per se. I wanted to know if some Easter Eggs would be present in Neovim ! 😄

---

Like these in Vim:

• :h 42
• :h holy-grail
• :h map-modes
• :h bar
• :h UserGettingBored
• :Ni! -- Do you demand a shrubbery?
• :help! -- Don't Panic !

---

Or perhaps the addition of some other different Easter Eggs ! 😉

Edit: As @simendsjo mentioned this is NOT top priority ! But, I thought it would be fun to have them !

Switch to "ANSI C" style function declarations

i.e.

void ui_write(char_u  *s, int len)

instead of

void ui_write(s, len)
char_u  *s;
int len;

Expect a PR pretty soon.

Reconsider vi compatibility mode

"Most optional features will no longer be optional (see above), with the exception of some broken and useless features (eg: netbeans integration, sun workshop) which will be removed permanently. Vi emulation will also be removed (setting 'nocompatible' will be a no-op)."

I agree with simplifying the build process, but we still need a minimal vim build (with vi compatibility) for default installation on Linux distributions. See the Debian vim-tiny package for an example:

(lines 46-54) http://sources.debian.net/src/vim/2:7.4.161-1/debian/rules

Zero byte in strings

In vim there is a problem with nul bytes: you cannot have them inside a string and they are replaced with \n, \x01 or just truncate string. Wondering what are the plans on handling this in NeoVim. Lua allows zero bytes in strings and most of the plugin code does not care about NULs, so new VimL can rather safely allow zero bytes. Sucha change is certain to break some of my code though, but I can handle this.

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

Support XDG directory specification

From #26, but I am talking not only about configuration files.

1. Configuration:

   1. populate runtimepath from XDG_CONFIG_DIRS, XDG_DATA_DIRS, XDG_DATA_HOME and XDG_CONFIG_HOME (and $VIMRUNTIME as well):

      $XDG_CONFIG_HOME/nvim
      $xdg_config_dir/nvim (for each directory in $XDG_CONFIG_DIRS)
      $XDG_DATA_HOME/nvim
      $xdg_data_dir/nvim/site (for each directory in $XDG_DATA_DIRS)
      $VIMRUNTIME (looks something like /usr/share/nvim/runtime)
      $xdg_data_dir/nvim/site/after (for each directory in $XDG_DATA_DIRS, reverse order)
      $XDG_DATA_HOME/nvim
      $xdg_config_dir/nvim/after (for each directory in $XDG_CONFIG_DIRS, reverse order)
      $XDG_CONFIG_HOME/nvim/after

   2. init.vim should be taken from the first directory in $XDG_CONFIG_HOME:$XDG_CONFIG_DIRS where it was found (e.g. first from ~/.config/nvim/init.vim, then from /etc/xdg/nvim/init.vim).

2. Default &directory option (it holds swap files there) to $XDG_DATA_HOME/nvim/swap//.
3. Default &backupdir to .,$XDG_DATA_HOME/nvim/backup.
4. Default &undodir to $XDG_DATA_HOME/nvim/undo//.
5. Default ShaDa location is $XDG_DATA_HOME/nvim/shada/main.shada.
6. Default &viewdir to $XDG_DATA_HOME/nvim/view.

OS defaults:

1. On nix operating systems default XDG_ variables according XDG base directory specification.
2. On windows default XDG_CONFIG_HOME and XDG_DATA_HOME to %APPDATA%, XDG_CACHE_HOME and XDG_RUNTIME_DIR to %TEMP% (just in case) and XDG_CONFIG_DIRS to empty (as VIMRUNTIME is handled separately).

Some other notes:

1. In any case respect existing values on any operating system.
2. Entry separator is a colon on any system. It is expected that path separator is a forward slash inside these variables on systems where path separator is a colon.
3. On startup absent environment variables (only XDG_CONFIG_HOME and XDG_DATA_HOME) should be set to their default values for use in scripts. Code that sets default options this will not have to handle this on its own.
4. On startup invalid values (XDG base directory specification says that paths must be absolute, relative paths are to be ignored) are replaced with default ones.
5. Code that sets those variables should live in src/nvim/os/env.c, alongside with restored init_homedir (which currently lives in misc1.c and lacks code for Windows).

Note some renamings: vim74 to 7.4, vimfiles to site-contrib, .vimrc to init.vim. Reasoning behind this: to avoid duplicating data. We already know this directory contains files for neovim since it is named /usr/share/nvim, why should this information be repeated in the subdirectory? Also it is hard to tell from the directory name what is the difference in vim74 and vimfiles contents, but it is easy for 7.4 and site-contrib (names are taken from /usr/share/zsh). Extension designates file type, so no need to remove it, it is for separate purpose.

Update: Renamed rc.vim to startup.vim. Reasoning: this way config file name resembles its purpose. See also #235.

Update 2:

• Renamed neovim to nvim as it is new convention.
• Moved &directory, &backupdir and &undodir defaults to $XDG_DATA_HOME.
• Made &undodir use trailing // as well.
• Removed ~/tmp/$TEMP/etc defaults from &backupdir (backups in %TEMP%?!).
• Removed current directory from &undodir default. If &backupdir was supporting trailing // I would happily remove current directory from there as well: nobody likes spamming working directory with files that are needed only by vim and hardly ever by user.

Update 3: All options sharing the same $XDG_DATA_HOME/nvim directory were supplied with distinct subpaths.

Update 4: Added OS defaults and notes.

Update 5: Renamed startup.vim to init.vim.

Update 6: Added default for ShaDa.

Update 7: Added default for viewdir.

Update 8: Updated init.vim search path, as discussed in some of the PRs.

Using Win8+MinGW gets can't find something resembling -ltermcap

Anyone seen it before?
Using CMake+Win8+MinGW gets the following error
CMake Error at src/CMakeLists.txt:29 (message):
can't find something resembling -ltermcap

Configuring incomplete, errors occurred!
See also "D:/neovim/CMakeFiles/CMakeOutput.log".

OSX HAVE_WORKING_LIBINTL build issue

When using make cmake I get this line.
-- Performing Test HAVE_WORKING_LIBINTL - Failed

I've also made sure that I have installed all dependencies

brew install md5sha1sum cmake libtool automake

Warning: md5sha1sum-0.9.5 already installed
Warning: cmake-2.8.12.2 already installed
Warning: libtool-2.4.2 already installed
Warning: automake-1.14.1 already installed

Build and use neovim files

Until neovim is a drop-in replacement should it be built as neovim (nvim?) and use .neovimrc .neovim/ ?

I have my current vim setup just right. I think it would be easier for me to setup a second vim config under "neovim" then to mess with my current setup. Maybe just supporting an easy config?

Thoughts?

Shouldn't the shell UI run as a "GUI"?

When we get around to implementing the "GUI" system, I think that the shell UI should run as a "GUI", instead of being a special case. Just thinking.

Add `make install`

I'm writing a formula for Homebrew that will allow people to install Neovim from HEAD (including dependencies), but there's no make install option, so the only thing I can do right now is to just have it build-in-place.

Need a github page

Any volunteers?

To-do board

The readme is basically acting as a roadmap.
I've used Waffle before, and I think it would be the best way to go on this kind of project.
Anyone else have alternatives/preferences?

Build broken on OpenBSD

I had a go at making neovim build on OpenBSD (see my pull request), but I kinda lost interest at this point. Looks like a libuv bug perhaps? OpenBSD does not use ldconfig.

Downloading dependencies as part of the build will be a packaging nightmare. Why don't you just list libuv as a dependency?

CC src/unix/libuv_la-kqueue.lo CC src/unix/libuv_la-openbsd.lo CCLD libuv.la make install-am ./install-sh -c -d '/home/edd/source/neovim/.deps/usr/lib' /bin/sh ./libtool --mode=install /usr/bin/install -c libuv.la '/home/edd/source/neovim/.deps/usr/lib' libtool: install: /usr/bin/install -c -m 644 .libs/libuv.so.11.0 /home/edd/source/neovim/.deps/usr/lib/libuv.so.11.0 libtool: install: /usr/bin/install -c -m 644 .libs/libuv.lai /home/edd/source/neovim/.deps/usr/lib/libuv.la libtool: install: /usr/bin/install -c .libs/libuv.a /home/edd/source/neovim/.deps/usr/lib/libuv.a libtool: install: chmod 644 /home/edd/source/neovim/.deps/usr/lib/libuv.a libtool: install: ranlib -t /home/edd/source/neovim/.deps/usr/lib/libuv.a libtool: finish: PATH="/home/edd/source/neovim/.deps/usr/bin:/home/edd/eck2/bin:/home/edd/eck2/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:/sbin:/usr/sbin:/usr/libexec:/usr/local/libexec:/usr/local/jdk-1.7.0/bin:/opt/radar2e/bin:/usr/games:/sbin:/usr/sbin:/usr/libexec:/usr/local/libexec:/usr/local/jdk-1.7.0/bin:/opt/radar2e/bin:/sbin" ldconfig -m /home/edd/source/neovim/.deps/usr/lib ldconfig: /var/run/ld.so.hints.lpgwgUB2nH: Permission denied ./install-sh -c -d '/home/edd/source/neovim/.deps/usr/include' /usr/bin/install -c -m 644 include/uv.h include/uv-errno.h include/uv-unix.h include/uv-bsd.h '/home/edd/source/neovim/.deps/usr/include' ./install-sh -c -d '/home/edd/source/neovim/.deps/usr/lib/pkgconfig' /usr/bin/install -c -m 644 libuv.pc '/home/edd/source/neovim/.deps/usr/lib/pkgconfig' rm: /home/edd/source/neovim/.deps/usr/lib/libuv_.so: No such file or directory rm: /home/edd/source/neovim/.deps/usr/lib/libuv_.dylib: No such file or directory rm: /home/edd/source/neovim/.deps/usr/lib/libuv_.dylib._: No such file or directory cd build && make /bin/sh: cd: /home/edd/source/neovim/build - No such file or directory **\* Error 1 in /home/edd/source/neovim (Makefile:4 'build/src/vim')

README image link is down

Add supported operating systems

Maybe neovim should have an explicit list of operating systems / architectures it supports? One of the issues with Vim is the large number of older operating systems it supports. We could prevent that by declaring up front what operating systems / architectures neovim will work on.

Write contributor guide

CONTRIBUTING.md:

• coding style
• how to test - mention valgrind
• commit message convention

wiki:

• how to find things to work on

$VIM and $VIMRUNTIME

I feel like these would need to be changed, since my neovim can't find it help.txt without me setting $VIM and $VIMRUNTIME, and I don't want to stomp on my existing $VIM, in case the help and such end up changing.

Speaking of help.txt, a find . -name help.txt doesn't find it. Neovim is going to end up having different help, and I'm not sure where it lives.

Debugging with gdb/cgdb

Didn't get any answers in irc, so I'm adding it here so it doesn't get lost

Hmm. What's the best way of running it in gdb? If I try using cgdb I'm not even able to start it because I'm not able to "Press Enter to continue" after it discoveres errors in my rc. Running in gdb starts the application, but of course, the gdb window is replaced by the vim windom, so it's not like I'm seeing much :) Is the right way to start it outside gdb and then attach to it?

Please make ECL work again.

A few years ago there was an ECL integration in VIM.

Please make that available in 'neovim' again.

Thank you very much!

Binary name

I suggest renaming the compiled binary to "neovim" -- both to create a distinction and to allow easy side-by-side compilation. Sorry no patch, didn't see what the best way to do that is right off.

Do not use cmake

cmake is quite sub-par regarding cross building and more cumbersome than other build systems, adding a dependency on a quite large set of dependencies (C++, one or two xmlrpc libraries, even qt optionally) that aren't exactly expected for a project that aims to get a cleaned up vim.

LICENSE/COPYING file

The original vim source code includes a section in the README describing the license under which the code is distributed.

This repository seems to have stripped that README file and also provides no alternative explanation of the license that this code is distributed under.

Please provide a LICENSE/COPYING file or at least add the appropriate section to the new README.

Why not just use emacs in evil mode?

Add Neovim to version information

As this is a separate fork of Vim, the version information should state that this is Neovim rather than vanilla Vim 7.4.
I believe the splash screen information and the --version information should reflect this.

new functions for multi-byte aware indexing and splicing

frogonwheels_ entered the irc with a question we should consider at some point. Apparently, multi-byte character handling is working unintuitively. Allegedly, it's an issue that Bram has been avoiding. Here is what he had to say (I have done some cleanup, summarized, clarified):

If you do let idx=1 | while idx < strlen(txt) | let idx+=1 | let ch = txt[idx] | endwhile then it's going through byte-wise rather than char wise. Essentially, Vim indexes lines per byte, not per character. This leads to complications when plugins try to get character n from the current line.

All the code that loops through characters in a string, or expects the column number to be the same as the index into the line (which happens all the time) will be broken as soon as you have multibyte characters.

col('.') indexes the current column you are in (ie for display) and people do getline('.')[col('.')] to get the current character, but that doesn't work for multibyte. You'd have to do matchstr(getline('.'), '^\(\zs.\)\{'.col('.').'}') to get the correct character. Since regexp indexing is character-wise. This doesn't even take into account the fact that some multibyte chars go over 2 columns.

Currently the only safe way of indexing strings in a character-length independent way is to use '.\{'.n.'}.

The Windows solution to this problem is to use ucs2-le character encoding - which will work until people start using multi-word characters (given that ucs2 is still multi-byte, just less likely to encounter it).

So either it's gotta be internally handled as wide characters (which is in itself limiting, but less so) which is the Windows approach.

A problem arises if we don't have constant-size characters: If you define txt[idx] to be character-wise, then your txt[idx] ends up being an ord(n) operation and the loop becomes bad, so you have to have some kind of indexing or something.

grayb__ observes: There's nothing too expensive about keeping a codebase multibyte safe, the problem is all the code that assumes 7 or 8 bit ascii.

I assume this is something we'll want to do far in the future, so it might be best to archive this issue under an appropriate label.

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

Clean up the tests

As several people have pointed out, the tests are horrible.

I think we should at least:

• remove the hardcoded 200ms sleep
• remove the expectation that they will be running in an 80x24 TTY
• silence the output unless there is an error
• add a one line summary for each test (pass/fail)
• add a one line summary for the whole test run (#tests passed/failed)

VC History?

When you imported to git you abandoned all the history from the old repo. If you are interested I can try to make a git export that can either be grafted or even straight up rebased. I know it's not a huge deal but it would be nice because then you can get sensible blames and might be able to bring in some patches from mainline.

#define ⇒ enum?

Would you like to replace more defines for constant values by enumerations to stress their relationships?

• Ctrl_...
• CSTP_...

Advice against using msgpack

I'm advising against using msgpack with your json-rpc protocol mostly because it only add a lot of complexity and doesn't offer any advantages for your use-case. My advice is to keep it simple.

In general, I feel that binary protocols are a premature optimization and should only be used when all other parts of the system have been sufficiently optimized. Rarely is the transport layer the bottleneck in your system and using a binary protocol like msgpack or protobuf just makes reading the wire harder for debugging.

Where I work we have been very successfully using json-rpc over netstrings. We've written several libraries for it with very little development effort. It's very nice to be able to read a network capture using ngrep or wireshark and not have to do any extra decoding.

Here are the list of tools I developed to give you some examples:

• jsonrpc-ns
• txjason
• jsonrpcake

Here is an example our netstring implementation for libevent.

However, you might not even need any extra protocol since you're only planning on sending commands over fds, so json-rpc on its own might be the best option.

I also recommend using Unix Domain Sockets instead of just stdin/stdout. We found them to be the easiest and most reliable way to communicate with our asynchronous libevent service.

Set the repository's website to something

I think the website for the Neovim repository should be set to something. Eventually we will want it to be Neovim.org, but for now, it might make more sense for it to be the the Bountysource page. That would give us (me and @cweagans) time to flesh out the website content/design before making it really public while also giving plenty of attention to the Bountysource until the funding goal is met. Thoughts?