Problem: Options window still checks for the multi_byte feature.
Solution: Remove the unnecessary check. (Dominique Pelle, closesvim/vim#3990)
76cbe811da
Neovim already removed `evim` (or any similar flags). The 'insertmode'
option is a weird remnant, so get rid of it.
The 'insertmode' option is replaced with a script that closely emulates
the option. This script is documented at :help 'insertmode'
Update runtime files.
cb80aa2d53
Omit runtime/doc/tabpage.txt.
Patch v8.2.1401 is not ported yet.
Port optwin.vim changes without gettext().
Patch v8.2.1544 is not ported yet.
Problem: It is not so easy to write a script that works with both Python 2 and Python 3, even when the Python code works with both.
Solution: Add 'pyxversion', :pyx, etc. (Marc Weber, Ken Takata)
f42dd3c390
Problem: Undo in the options window makes it empty.
Solution: Set 'undolevels' while filling the buffer. (Yasuhiro Matthew,
closesvim/vim#2645)
9c474b2773
After this change we never release blocks from memory (in practice it
never happened because the memory limits are never reached). Let the OS
take care of that.
---
On today's systems the 'maxmem' and 'maxmemtot' values are huge (4+ GB)
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-paging mechanism. This is unnecessary and inefficient since the
operating system already has virtual 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.
> 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.
Problem: Although emoji characters are ambiguous width, best is to treat
them as full width.
Solution: Update the Unicode character tables. Add the 'emoji' options.
(Yasuhiro Matsumoto)
3848e00e01
