libuv provide uv_get_total_mem_kib. So HAVE_TOTAL_MEM should always be
true.
Before that commit in neovim maxmem=5120 and maxmemtot=10240. Now
both equal to half of system memory.
This feature allow to use any white space characters instead of one
<TAB> in tag files. It is disabled in vanilla Vim's default build
configuration. Exuberant ctags use format with exactly one TAB.
Feature description from Vim documentation:
NOTE: this code is currently disabled, as the RISC OS implementation was
removed. In the future this will use the 'filetype' option.
On operating systems which support storing a file type with the file, you can
specify that an autocommand should only be executed if the file is of a
certain type.
The actual type checking depends on which platform you are running Vim
on; see your system's documentation for details.
To use osfiletype checking in an autocommand you should put a list of types to
match in angle brackets in place of a pattern, like this: >
:au BufRead *.html,<&faf;HTML> runtime! syntax/html.vim
This will match:
- Any file whose name ends in ".html"
- Any file whose type is "&faf" or "HTML", where the meaning of these types
depends on which version of Vim you are using.
Unknown types are considered NOT to match.
* With the changes in commit
"events: Refactor how event deferral is handled"
(2e4ea29d2c) the function argument
'defer' of 'job_start' and member variable 'defer' of 'struct job'
can be removed.
* Update/Fix the documentation for function 'job_start'.
Not necessary, as discussed in #980.
From the libuv mailing list:
https://groups.google.com/forum/#!topic/libuv/OD38PeGeVgQ
E.g. this could happen (red: on Windows):
> > alloc_cb(handle1);
> > alloc_cb(handle2);
> > read_cb(handle1);
> > read_cb(handle2);
But this couldn't:
> > alloc_cb(handle1);
> > alloc_cb(handle1);
> > read_cb(handle1);
> > read_cb(handle1);
Because each stream has a 1-to-1 correspondance with a libuv handle. The
code removed was never executed.
Closes#980.
It used to be 1024 bytes, which is very tiny and slows down some operations
(imaging `cat`-ing a large file). Benchmarks show a large speedup for such
cases. ref #978.
For modern systems 0xFFFF bytes (65535 B = 64 KB = 0.0625 MB) per job
shouldn't be a big problem.
This evades the tempfile problem (unless of course one manually adds
redirects to the shell commandline, which some plugins seem to do, e.g.:
vim-easytags).
With the goal to support pipe-only system() calls.
Notes on the second (vim) argument to f_system() (i.e.: redirected input)
and its implications:
- When calling system('cat -', ['some', 'list']), vanilla vim (before a
recent patch that added support for passing lists) just passes an empty
file to the process. This is the same as immediately closing the pipe,
which os_system does when no input is given. If we wouldn't close the
pipe, the process will linger forever (as is the case with `cat -`).
As of now, it's not allowed to pass a non-NULL pointer as the `output`
parameter. In other words, it's not possible to signal disinterst in the
process output. That may change in the future.
Fixes up gcc 4.1 (not specifically a supported compiler but it's standard
for varargs anyway so it's good to have it included and depend less on
implicit includes).
