Runtime updates that were bundled into the otherwise NA commit:
Problem: "make proto" adds extra function prototype.
Solution: Add vim/vim#ifdef.
5162822914
- Prefer "TUI" where possible to refer to the host terminal.
- Remove obsolete tags and ancient TTY exposition.
- Establish "terminal" to consistently mean "terminal emulator" in all
Nvim documentation. This removes the need for verbose qualifiers in
tags and prose.
References #6280
References #6803
The details are in the on-line help under :help cursor-shape .
The brief precis is that nvim is following the lead of tmux, and going
beyond what tmux does to make cursor shape changes work on a broad range of
terminals. This includes on tmux itself, which is no longer bypassed.
Reverts commit 337b6179dfCloses#6716 at the expense of not being able to use a
multi-key 'pastetoggle' manually.
Multi-key 'pastetoggle' can still be used when inserting the entire
option into the typebuffer at once (though the use here is
questionable).
Also remove those tests to do with waiting for the completion of
'pastetoggle' and mention in the documentation that 'pastetoggle'
doesn't wait for timeout.
Calling cmd.exe in Windows follows a very different pattern from Vim.
The primary difference is that Vim does a nested call to cmd.exe, e.g.
the following call in Vim
system('echo a 2>&1')
spawns the following processes
"C:\Program Files (x86)\Vim\vim80\vimrun" -s C:\Windows\system32\cmd.exe /c (echo a 2^>^&1
^>C:\Users\dummy\AppData\Local\Temp\VIoC169.tmp 2^>^&1)
C:\Windows\system32\cmd.exe /c C:\Windows\system32\cmd.exe /c (echo a 2^>^&1
^>C:\Users\dummy\AppData\Local\Temp\VIo3C6C.tmp 2^>^&1)
C:\Windows\system32\cmd.exe /c (echo a 2>&1
>C:\Users\dummy\AppData\Local\Temp\VIo3C6C.tmp 2>&1)
The escaping with ^ is needed because cmd.exe calls itself and needs to
preserve the special metacharacters for the last call. However in nvim
no nested call is made, system('') spawns a single cmd.exe process.
Setting shellxescape to "" disables escaping with ^.
The previous default for shellxquote=( wrapped any command in
parenthesis, in Vim this is more meaningful due to the use of tempfiles
to store the output and redirection (also see &shellquote). There is
a slight benefit in having the default be empty because some expressions
that run in console will not run within parens e.g. due to unbalanced
double quotes
system('echo "a b')
> The option 'maxmem' ('mm') is used to set the maximum memory used for one
> buffer (in kilobytes). 'maxmemtot' is used to set the maximum memory used for
> all buffers (in kilobytes). The defaults depend on the system used. These
> are not hard limits, but tell Vim when to move text into a swap file. If you
> don't like Vim to swap to a file, set 'maxmem' and 'maxmemtot' to a very large
> value. The swap file will then only be used for recovery. If you don't want
> a swap file at all, set 'updatecount' to 0, or use the "-n" argument when
> starting Vim.
On today's systems these values are huge (4GB in my machine with 8GB of RAM
since it's set as half the available memory by default) so the limits are
never reached in practice, but Vim wastes a lot of time checking if the limit
was reached.
If the limit is reached Vim starts saving pieces of the swap file that were in
memory to the disk. Said in a different way: Vim implements its own memory
swapping mechanism. This is unnecessary and inefficient since the operating
system already virtualized the memory and will swap to the disk if programs
start using too much memory.
This change does...
1. Reduce the number of config options and need for documentation.
2. Make the code more efficient as we don't have to keep track of memory usage
nor check if the memory limits were reached to start swapping to disk every
time we need memory for buffers.
3. Simplify the code. Once `memfile.c` is simple enough it could be replaced by
actual operating system memory mapping (`mmap`, `MemoryViewOfFile`...).
This change does not prevent Vim to recover changes from swap files since the
swapping code is never triggered with the huge limits set by default.