Problem: The evalfunc.c file is getting too big.
Solution: Move channel and job related functions to channel.c.
0a1f56fcfe
---
N/A patches below:
vim-patch:8.1.0770: inconsistent use of ELAPSED_FUNC
Problem: Inconsistent use of ELAPSED_FUNC.
Solution: Consistently use ELAPSED_FUNC. Also turn ELAPSED_TYPE into a
typedef. (Ozaki Kiichi, closesvim/vim#3815)
1ac56c2d11
vim-patch:8.1.0914: code related to findfile() is spread out
Problem: Code related to findfile() is spread out.
Solution: Put findfile() related code into a new source file. (Yegappan
Lakshmanan, closesvim/vim#3934)
5fd0f5052f
vim-patch:8.1.1004: function "luaV_setref()" not covered with tests
Problem: Function "luaV_setref()" not covered with tests.
Solution: Add a test. (Dominique Pelle, closesvim/vim#4089)
e165f63598
vim-patch:8.1.1551: warning for shadowing popup_dragwin
Problem: Warning for shadowing popup_dragwin. (Dominique Pelle)
Solution: Add missing change.
6c17543b56
vim-patch:8.1.1629: terminal function help is in the wrong file
Problem: Terminal function help is in the wrong file.
Solution: Move the function details to terminal.txt.
6bf2c6264b
vim-patch:8.1.1641: garbage collection may run at a wrong moment
Problem: Garbage collection may run at a wrong moment. (Trygve Aaberge)
Solution: Postpone garbage collection while parsing messages. (closesvim/vim#4620)
6cc7e21412
vim-patch:8.1.1703: breaking out of loop by checking window pointer insufficient
Problem: Breaking out of loop by checking window pointer is insufficient.
Solution: Check the window ID and the buffer number. (closesvim/vim#4683)
6138640806
vim-patch:8.1.1802: missing change to call_callback()
Problem: Missing change to call_callback().
Solution: Add missing change.
b2129068a5
vim-patch:8.1.1853: timers test is still flaky
Problem: Timers test is still flaky.
Solution: Compute the time to sleep more accurately.
52953194af
---
Seems N/A now because of commit 09370eae77
---
vim-patch:8.1.2200: crash when memory allocation fails
Problem: Crash when memory allocation fails.
Solution: Check for NULL curwin and curbuf. (Christian Brabandt,
closesvim/vim#4839)
1cac70953d
vim-patch:8.2.3922: cannot build with dynamic Ruby 3.1
Problem: Cannot build with dynamic Ruby 3.1.
Solution: Add "_EXTRA" variables for CI. Add missing functions. (Ozaki
Kiichi, closesvim/vim#9420)
8bb3fe4d4d
vim-patch:9.0.0546: supporting Ruby 1.8 makes code complicated
Problem: Supporting Ruby 1.8 makes code complicated.
Solution: Drop Ruby 1.8 support, it is ancient. (Ken Takata, closesvim/vim#11195)
236ccbf6f8
vim-patch:9.0.0928: using Ruby LDFLAGS may cause build problems
Problem: Using Ruby LDFLAGS may cause build problems.
Solution: Do not add Ruby LDFLAGS to Vim's LDFLAGS. (Zdenek Dohnal,
closesvim/vim#11592)
1d822afaf6
vim-patch:9.1.1382: if_ruby: unused compiler warnings from ruby internals
Problem: if_ruby: unused compiler warnings from ruby internals
Solution: disable -Wunused-parameter for if_ruby internal code
(Philip H.)
closes: vim/vim#17297411730e277
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: The indent.c file is a bit big.
Solution: Move C-indent code a a new cindent.c file. Move other
indent-related code to indent.c. (Yegappan Lakshmanan,
closesvim/vim#5031)
14c01f8348
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Topline is preemptively updated by line() in WinResized
autocmd with 'splitkeep' != "cursor".
Solution: Set `skip_update_topline` when 'splitkeep' != "cursor".
(Luuk van Baal)
fe803c8c04
Problem:
Not easy to get user-input in prompt-buffer before the user submits the
input. Under the current system user/plugin needs to read the buffer
contents, figure out where the prompt is, then extract the text.
Solution:
- Add prompt_getinput().
- Extract prompt text extraction logic to a separate function
Problem:
vim.uv.os_setenv gets "stuck" per-key. #32550
Caused by the internal `envmap` cache. #7920
:echo $FOO <-- prints nothing
:lua vim.uv.os_setenv("FOO", "bar")
:echo $FOO <-- prints bar (as expected)
:lua vim.uv.os_setenv("FOO", "fizz")
:echo $FOO <-- prints bar, still (not expected. Should be "fizz")
:lua vim.uv.os_unsetenv("FOO")
:echo $FOO <-- prints bar, still (not expected. Should be nothing)
:lua vim.uv.os_setenv("FOO", "buzz")
:echo $FOO <-- prints bar, still (not expected. Should be "buzz")
Solution:
- Remove the `envmap` cache.
- Callers to `os_getenv` must free the result.
- Update all call-sites.
- Introduce `os_getenv_noalloc`.
- Extend `os_env_exists()` the `nonempty` parameter.
Problem: Message kind logic for emitting an error message is convoluted
and still results in emitting an unfinished message earlier than
wanted.
Solution: Ensure emsg_multiline() always sets the kind wanted by the caller
and doesn't isn't unset to logic for emitting the source message.
Caller is responsible for making sure multiple message chunks are
not emitted as multiple events by setting `msg_ext_skip_flush`...
Problem: Various list commands end in a newline to go to a new line on
the message grid for the prompt message, which is unwanted
with ext_messages.
Solution: Don't emit a trailing newline with ext_messages for
inputlist(), :tselect and z=.
Co-authored-by: Tomasz N <przepompownia@users.noreply.github.com>
Problem: Messages preceding a `cmdline_show->prompt` event can not be
distinguished as such when receiving the event. (But since
`msg_show` handlers should be scheduled, one can already check
whether a prompt is active when displaying the message.)
Solution: Rather than add a new kind again, use the `confirm` kind.
Could be seen as slightly misleading where it is more of
a choice rather than a confirmation, but that already applies
to `confirm()` as well...
Problem: has('bsd') is true for GNU/Hurd
Solution: exclude GNU/Hurd from BSD feature flag
(Zhaoming Luo)
GNU/Hurd, like Mac OS X, is a BSD-based system. It should exclude
has('bsd') feature just like what Mac OS X does. The __GNU__ pre-defined
macro indicates it's compiled for GNU/Hurd.
closes: vim/vim#16580a41dfcd55b
Co-authored-by: Zhaoming Luo <zhmingluo@163.com>
Problem: Vim9: Patch 9.1.1013 causes a few problems
Solution: Translate the function name only when it is a string
(Yegappan Lakshmanan)
fixes: vim/vim#16453closes: vim/vim#164509904cbca41
Cherry-pick call() change from patch 9.0.0345.
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Vim9: Regression caused by patch v9.1.0646
Solution: Translate the function name before invoking it in call()
(Yegappan Lakshmanan)
fixes: vim/vim#16430closes: vim/vim#164456289f91591
N/A patch:
vim-patch:8.2.4176: Vim9: cannot use imported function with call()
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Prompts are emitted as messages events, where cmdline events
are more appropriate. The user input is also emitted as
message events in fast context, so cannot be displayed with
vim.ui_attach().
Solution: Prompt for user input through cmdline prompts.
Problem:
`termopen` has long been a superficial wrapper around `jobstart`, and
has no real purpose. Also, `vim.system` and `nvim_open_term` presumably
will replace all features of `jobstart` and `termopen`, so centralizing
the logic will help with that.
Solution:
- Introduce `eval/deprecated.c`, where all deprecated eval funcs will live.
- Introduce "term" flag of `jobstart`.
- Deprecate `termopen`.
"wininfo" is going to be my next victim. The main problem with wininfo
is that it is "all or nothing", i e either all state about a buffer in a
window is considered valid or none of it is. This needs to be fixed to
address some long running grievances.
For now this is just a warmup: refactor it from a linked list to a
vector.
Problem: too many strlen() calls in eval.c
Solution: Refactor eval.c to remove calls to STRLEN()
(John Marriott)
closes: vim/vim#16066bd4614f43d
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: topline might be changed in diff mode unexpectedly
(Jaehwang Jung)
Solution: do not re-calculate topline, when using line() func
in diff mode.
fixes: vim/vim#15812closes: vim/vim#1595005a40e07c2
Co-authored-by: Christian Brabandt <cb@256bit.org>
In the api_info() output:
:new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val')
...
{'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1}
The `ArrayOf(Integer, 2)` return type didn't break clients when we added
it, which is evidence that clients don't use the `return_type` field,
thus renaming Dictionary => Dict in api_info() is not (in practice)
a breaking change.
Problem:
- "process" is often used as a verb (`multiqueue_process_events`), which
is ambiguous for cases where it's used as a topic.
- The documented naming convention for processes is "proc".
- `:help dev-name-common`
- Shorter is better, when it doesn't harm readability or
discoverability.
Solution:
Rename "process" => "proc" in all C symbols and module names.
Problem:
If $NVIM_APPNAME is a relative dir path, Nvim fails to start its
primary/default server, and `v:servername` is empty.
Root cause is d34c64e342, but this wasn't
noticed until 96128a5076 started reporting the error more loudly.
Solution:
- `server_address_new`: replace slashes "/" in the appname before using
it as a servername.
- `vim_mktempdir`: always prefer the system-wide top-level "nvim.user/"
directory. That isn't intended to be specific to NVIM_APPNAME; rather,
each *subdirectory* ("nvim.user/xxx") is owned by each Nvim instance.
Nvim "apps" can be identified by the server socket(s) stored in those
per-Nvim subdirs.
fix#30256
In Vim a lot of filesystem functions have been moved to filepath.c.
However, some of these functions actually deal with file contents, and
Nvim's filesystem-related functions are spread out in a different way.
Therefore, it's better to use a different file for these functions.
This also makes shada reading slightly faster due to avoiding
some copying and allocation.
Use keysets to drive decoding of msgpack maps for shada entries.
- common_function() has always been in evalfunc.c in Vim
- return_register() has always been in evalfunc.c in Vim
- get_user_input() was moved to ex_getln.c in Vim 8.1.1957
- tv_get_lnum_buf() was moved to typval.c in Vim 8.2.0847
Problem: Some functions are not tested
Solution: Add a few more tests, fix a few minor problems
(Yegappan Lakshmanan)
closes: vim/vim#14789fe424d13ef
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: No way to get the arity of a Vim function
(Austin Ziegler)
Solution: Enhance get() Vim script function to return the function
argument info using get(func, "arity") (LemonBoy)
fixes: vim/vim#15097closes: vim/vim#1510948b7d05a4f
Co-authored-by: LemonBoy <thatlemon@gmail.com>
Problem: the recursive parameter in the *_equal functions can be removed
Solution: Remove the recursive parameter in dict_equal(), list_equal()
object_equal and tv_equal(). Use a comparison of the static
var recursive_cnt == 0 to determine whether or not tv_equal()
has been called recursively (Yinzuo Jiang).
closes: vim/vim#150707ccd1a2e85
Co-authored-by: Yinzuo Jiang <jiangyinzuo@foxmail.com>
Problem: Left shift is incorrect with vartabstop and shiftwidth=0
Solution: make tabstop_at() function aware of shift direction
(Gary Johnson)
The problem was that with 'vartabstop' set and 'shiftwidth' equal 0,
left shifts using << were shifting the line to the wrong column. The
tabstop to the right of the first character in the line was being used
as the shift amount instead of the tabstop to the left of that first
character.
The reason was that the tabstop_at() function always returned the value
of the tabstop to the right of the given column and was not accounting
for the direction of the shift.
The solution was to make tabstop_at() aware of the direction of the
shift and to choose the tabtop accordingly.
A test was added to check this behavior and make sure it doesn't
regress.
While at it, also fix a few indentation/alignment issues.
fixes: vim/vim#14864closes: vim/vim#1488788d4f255b7
Co-authored-by: Gary Johnson <garyjohn@spocom.com>
Problem: getregionpos() behaves inconsistently for a partly-selected
multibyte char.
Solution: Always use column of the first byte for a partly-selected
multibyte char (zeertzjq).
closes: vim/vim#14851ef73374dc3
Problem: Can't use a blockwise selection with a width for getregion().
Solution: Add support for blockwise selection with width like the return
value of getregtype() or the "regtype" value of TextYankPost
(zeertzjq).
closes: vim/vim#14842afc2295c22
Problem: Strange error message when using islocked() with a number.
(Yegappan Lakshmanan)
Solution: Check that the name is empty.
1840a7b4e3
Use ll_name_len instead.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: getregionpos() can't properly indicate positions beyond eol.
Solution: Add an "eol" flag that enables handling positions beyond end
of line like getpos() does (zeertzjq).
Also fix the problem that a position still has the coladd beyond the end
of the line when its column has been clamped. In the last test case
with TABs at the end of the line the old behavior is obviously wrong.
I decided to gate this behind a flag because returning positions that
don't correspond to actual characters in the line may lead to mistakes
for callers that want to calculate the length of the selected text, so
the behavior is only enabled if the caller wants it.
closes: vim/vim#148382b09de9104
Problem: Wrong yanking with exclusive selection and virtualedit=all,
and integer overflow when using getregion() on it.
Solution: Set coladd when decreasing column and 'virtualedit' is active.
Add more tests for getregion() with 'virtualedit' (zeertzjq).
closes: vim/vim#14830701ad50a9e
Problem: getregionpos() doesn't handle one char selection.
Solution: Handle startspaces differently when is_oneChar is set.
Also add a test for an exclusive charwise selection with
multibyte chars (zeertzjq)
closes: vim/vim#1482552a6f34887
Problem: too many strlen() calls in search.c
Solution: refactor code and remove more strlen() calls,
use explicit variable to remember strlen
(John Marriott)
closes: vim/vim#147968c85a2a49a
Co-authored-by: John Marriott <basilisk@internode.on.net>
