Problem: CTRL-X CTRL-R only completes individual words from registers,
making it difficult to insert complete register content.
Solution: Add consecutive CTRL-X CTRL-R support - first press completes
words, second press completes full register lines, similar to
CTRL-X CTRL-L and CTRL-X CTRL-P behavior (glepnir).
closes: vim/vim#17395d5fdfa5c9c
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: not easily possible to complete from register content
Solution: add register-completion submode using i_CTRL-X_CTRL-R
(glepnir)
closes: vim/vim#173540546068aae
Problem: regexp: max \U and \%U value is limited by INT_MAX but gives a
confusing error message (related: v8.1.0985).
Solution: give a better error message when the value reaches INT_MAX
When searching Vim allows to get up to 8 hex characters using the /\V
and /\%V regex atoms. However, when using "/\UFFFFFFFF" the code point is
already above what an integer variable can hold, which is 2,147,483,647.
Since patch v8.1.0985, Vim already limited the max codepoint to INT_MAX
(otherwise it caused a crash in the nfa regex engine), but instead of
error'ing out it silently fell back to parse the number as a backslash
value and not as a codepoint value and as such this "/[\UFFFFFFFF]" will
happily find a "\" or an literal "F". And this "/[\d127-\UFFFFFFFF]"
will error out as "reverse range in character class).
Interestingly, the max Unicode codepoint value is U+10FFFF which still
fits into an ordinary integer value, which means, that we don't even
need to parse 8 hex characters, but 6 should have been enough.
However, let's not limit Vim to search for only max 6 hex characters
(which would be a backward incompatible change), but instead allow all 8
characters and only if the codepoint reaches INT_MAX, give a more
precise error message (about what the max unicode codepoint value is).
This allows to search for "[\U7FFFFFFE]" (will likely return "E486
Pattern not found") and "[/\U7FFFFFF]" now errors "E1517: Value too
large, max Unicode codepoint is U+10FFFF".
While this change is straight forward on architectures where long is 8
bytes, this is not so simple on Windows or 32bit architectures where long
is 4 bytes (and therefore the test fails there). To account for that,
let's make use of the vimlong_T number type and make a few corresponding
changes in the regex engine code and cast the value to the expected data
type. This however may not work correctly on systems that doesn't have
the long long datatype (e.g. OpenVMS) and probably the test will fail
there.
fixes: vim/vim#16949closes: vim/vim#16994f2b16986a1
Co-authored-by: Christian Brabandt <cb@256bit.org>
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.
Update runtime files.
38a55639d6
Ignore changes to
* doc/channel.txt, doc/eval.txt, doc/various.txt: Channel related docs
* doc/tags: Generated at build time
* doc/todo.txt, doc/vi_diff.txt: Not relevant to neovim
Updated runtime files.
b4ff518d95
Missing files: runtime/doc/tags, runtime/doc/todo.txt. Changes to
runtime/doc/if_pyth.txt, runtime/doc/options.txt and runtime/doc/quickref.txt
did not aply. Excluded runtime/syntax/vim.vim.
We do not support every Unix flavor in existence so note
that here.
We do not support Windows 95 or NT. Update the list to
the Windows versions we do support.
We only support OS X not classic Mac OS so note that too.
All `{not in Vi}' tags have been removed, so the first sentence is no
longer true. As for the second sentence, the header ("Differences
between Vim and Vi") is already self-explanatory, so it can be removed
as well.
These are more like notes than proper documentation, so remove it as
they're not of much use unless you don't know what you're looking for.
Many of these are somewhat useful, but many also duplicate what's
already documented elsewhere. In any case, vi_diff.txt is the last
place that assorted tips'n'tricks should be located (we already have
tips.txt!!!).
In regards to Nvim, it's very outdated; for an updated list of such
arguments refer to the manual page or `nvim --help`. In all other
regards, it's of little to no use to end-users.
From the documentation itself:
:[range]o[pen] Works like |:visual|: end Ex mode.
{Vi: start editing in open mode}
...
Vim does not support open mode, since it's not really useful. For
those situations where ":open" would start open mode Vim will leave Ex
mode, which allows executing the same commands, but updates the whole
screen instead of only one line.
Part of the reason behind this is to make removing vi_diff.txt easier,
although it's also because :open is not too useful.
Helped-by: @fdinoff
Helped-by: @dsummersl
Helped-by: @mhinz
Helped-by: @justinmk
- CPO_ALL and CPO_VI are identical, so merge them
- No longer check for the environment variable 'VIM_POSIX'
- In vim_diff.txt, mention the removal of 'cpoptions' flags
These options were never implemented in Vim. They are documented under
|missing-options| in runtime/doc/vi_diff.txt:
'autoprint'
'beautify'
'flash'
'graphic'
'hardtabs'
'mesg'
'novice'
'open'
'optimize'
'redraw'
'slowopen'
'sourceany'
'w300'
'w1200'
'w9600'
References #2548.
Regarding |script-here|: despite being a language agnostic piece of
advice, it was in `if_perl.txt`. Regardless, we now only have one
support for one legacy plugin interface, so put it in `if_pyth.txt`
This removes the ability to start nvim via the following aliases in
favor of just using their command line arguments:
ex vim -e
exim vim -E
view vim -R
gvim vim -g
gex vim -eg
gview vim -Rg
rvim vim -Z
rview vim -RZ
rgvim vim -gZ
rgview vim -RgZ
This also removes Vi mode (-v) for consistency. From ':help -v':
-v Start Ex in Vi mode. Only makes a difference when the
executable is called "ex" or "gvim". For gvim the GUI is not
started if possible.
Notes regarding the removal of specific items:
- Aztec C: only on the Amiga.
- mch_check_win(): doesn't exist anymore.
- Comment in ex_cmds.c: It seems the context for this comment was
removed, but the comment was inadvertantly left alone.
Closes https://github.com/neovim/docs/pull/26
Also added stubs for 'cryptmethod' and 'key', and placeholders for
explanation regarding removal of crypto functionality.
