This is how Nvim behaves when the "abstract_ui" termcap is activated:
- No data is written/read to stdout/stdin by default.
- Instead of sending data to stdout, ui_write will parse the termcap codes
and invoke dispatch functions in the ui.c module.
- The dispatch functions will forward the calls to all attached UI
instances(each UI instance is an implementation of the UI layer and is
registered with ui_attach).
- Like with the "builtin_gui" termcap, "abstract_ui" does not contain any key
sequences. Instead, vim key strings(<cr>, <esc>, etc) are parsed directly by
input_enqueue and the translated strings are pushed to the input buffer.
With this new input model, its not possible to send mouse events yet. Thats
because mouse sequence parsing happens in term.c/check_termcodes which must
return early when "abstract_ui" is activated.
Nvim now relies much less on setting terminal mode to cooked mode, remove most
calls to settmode, except for those that happen on startup or when suspending.
Eventually even those will be handled by the UI layer.
Switch from POSIX's write() to fwrite(stdout,...) and disable buffering
since vim buffers output explicitly and flushes when needed, like when a
key is typed.
Problem: When 'ttymouse' is set to 'uxterm' the xterm version is not
requested. (Tomas Janousek)
Solution: Do not mark uxterm as a conflict mouse and add
resume_get_esc_sequence().
https://code.google.com/p/vim/source/detail?r=v7-4-359
Problem: Making 'ttymouse' empty after the xterm version was requested
causes problems. (Elijah Griffin)
Solution: Do not check for DEC mouse sequences when the xterm version was
requested. Also don't request the xterm version when DEC mouse
was enabled.
https://code.google.com/p/vim/source/detail?r=v7-4-305
gettimeofday() is not portable, replace with os_hrtime() wherever possible.
The new code should behave equivalently to the old implementation.
Because of this, HAVE_GETTIMEOFDAY is no longer necessary To be able to
handle double clicks.
`-Wstrict-prototypes` warn if a function is declared or defined without
specifying the argument types.
This warning disallow function prototypes with empty parameter list.
In C, a function declared with an empty parameter list accepts an
arbitrary number of arguments when being called. This is for historic
reasons; originally, C functions didn't have prototypes, as C evolved
from B, a typeless language. When prototypes were added, the original
typeless declarations were left in the language for backwards
compatibility.
Instead we should provide `void` in argument list to state
that function doesn't have arguments.
Also this warning disallow declaring type of the parameters after the
parentheses because Neovim header generator produce no declarations for
old-stlyle prototypes: it expects to find `{` after prototype.
- The 'stripdecls.py' script replaces declarations in all headers by includes to
generated headers.
`ag '#\s*if(?!ndef NEOVIM_).*((?!#\s*endif).*\n)*#ifdef INCLUDE_GENERATED'`
was used for this.
- Add and integrate gendeclarations.lua into the build system to generate the
required includes.
- Add -Wno-unused-function
- Made a bunch of old-style definitions ANSI
This adds a requirement: all type and structure definitions must be present
before INCLUDE_GENERATED_DECLARATIONS-protected include.
Warning: mch_expandpath (path.h.generated.h) was moved manually. So far it is
the only exception.
- Replace a vim_strsave/free pair with xrealloc
- Use xmallocz() in some places
- Use xrealloc() and forget about the NULL pointer case
- Remove invalid comment
- Remove unnecessary checks
- Replace a complicated xmalloc/STRCPY/free code chunk code with xrealloc()
- Replace a vim_strsave/free code chunk with xrealloc()
Problem: Now that nvim/strings.h is correctly namespaced, an issue
that had been masked until now arises:
When compiling, we get a lot of errors because of everywhere
the functions in nvim/strings.h are used, there's no include
to import them.
But, how could this compile and work previously, then? It
turns out that:
- In every such case, we are also including vim.h, which in
turn includes os_unix_defs.h.
- os_unix_defs.h includes <string.h> and also <strings.h> in
some systems (e.g. OSX).
- Build had been modified previously to (even when importing
system headers), prefer equally-named local ones. That was
in fact done as a previous attempt to solve the same issue
we are trying to solve another way now.
So, we were including our "strings.h" as a side-effect of
including <strings.h> through "vim.h" --> "os_unix_defs.h".
Solution: Correctly include "nvim/strings.h" in every file needing it.
Move files from src/ to src/nvim/.
- src/nvim/ becomes the new root dir for nvim executable sources.
- src/libnvim/ is planned to become root dir of the neovim library.
