Problem: Loading file type detection slows down startup.
Solution: Store the last pattern of an autocommand event to make appending
quicker.
462455ee8b
Should actually be silencing that for the sake of the case when `long` is
actually not 64-bit. But it appears that Vim had already defined maximal line
number. And even declared that exact value invalid, so no need in silencing.
Problems:
- In two places in shada_read_when_writing() memory just was not freed. Both
places were verified to cause test failures.
- Numbered marks got assigned incorrect (off-by-one compared to position in the
array) numbers in replace_numbered_mark.
- It was possible to have non-continuously populated array of numbered marks
which messed up code for merging them.
(Note about tests: marks with additional data are always compared different when
merging, that caused some confusion regarding why test did not work the way
I expected.)
closes#8196
For historical reasons, uint64_t and friends are defined both as
typedefs and macros. Some platforms that do that define the macros as
identity (#define uint64_t uint64_t), others like NetBSD define to the
backing type (#define uint64_t __uint64_t). This is normally
transparent, except when multiple levels of macro expansions are used
inconsistently.
Problems so far:
- Marks in the current instance are not adjusted.
- Duplicates are not removed (not that it works in Vim either now, not at
8.0.134 at least).
vim-patch:8.0.0185: system() test fails on MS-Windows
vim-patch:8.0.0197: system() test skips some parts for MS-Windows
vim-patch:8.0.0701: system test failing when using X11 forwarding
Problem: When in Ex mode and an error is caught by try-catch, Vim still
exits with a non-zero exit code.
Solution: Don't set ex_exitval when inside a try-catch. (partly by Christian
Brabandt)
2b7bc567b9
closes#7698
Wrapping a command in double-quotes allows cmd.exe to safely dequote the
entire command as if the user entered the entire command in an
interactive prompt. This reduces the need to escape nested and uneven
double quotes.
The `/s` flag of cmd.exe makes the behaviour more reliable:
:set shellcmdflag=/s\ /c
Before this patch, cmd.exe cannot use cygwin echo.exe (as opposed to
cmd.exe `echo` builtin) even if it is wrapped in double quotes.
Example:
:: internal echo
> cmd /s /c " echo foo\:bar" "
foo\:bar"
:: cygwin echo.exe
> cmd /s /c " "echo" foo\:bar" "
foo:bar
It's a micro-optimization; check path_is_absolute_path(autocmd_fname)
instead.
The main optimization (which is still in place) afforded by Vim 7.2.021
was to avoid resolving <afile> when it is not needed.
During provider dispatch, eval_call_provider() saves global
state--including pointers, such as `autocmd_fname`--into
`provider_caller_scope` which is later restored by f_rpcrequest().
But `autocmd_fname` is special-cased in eval_vars(), for performance
(see Vim patch 7.2.021; this is also the singular purpose of the
`autocmd_fname_full` global. Yay!)
If eval_vars() frees `autocmd_fname` then its provider-RPC-scoped alias
becomes a problem.
Solution: Don't free autocmd_fname in eval_vars(), just copy into it.
closes#5245closes#5617
Reference
------------------------------------------------------------------------
Vim patch 7.2.021
f6dad43c98
Problem: When executing autocommands getting the full file name may be
slow. (David Kotchan)
Solution: Postpone calling FullName_save() until autocmd_fname is used.
vim_dev discussion (2008): "Problem with CursorMoved AutoCommand when
Editing Files on a Remote WIndows Share"
https://groups.google.com/d/msg/vim_dev/kj95weZa_eE/GTgj4aq5sIgJ
