Problem: statusline may look different than expected
Solution: do not check for highlighting of stl and stlnc characters
statusline fillchar may be different than expected
If the highlighting group for the statusline for the current window
|hl-StatusLine| or the non-current window |hl-StatusLineNC| are cleared
(or do not differ from each other), than Vim will use the hard-coded
fallback values '^' (for the non-current windows) or '=' (for the
current window). I believe this was done, to make sure the statusline
will always be visible and be distinguishable from the rest of the
window.
However, this may be unexpected, if a user explicitly defined those
fillchar characters just to notice that those values are then not used
by Vim.
So, let's assume users know what they are doing and just always return
the configured stl and stlnc values. And if they want the statusline to
be non-distinguishable from the rest of the window space, so be it. It
is their responsibility and Vim shall not know better what to use.
fixes: #13366closes: #13488
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: need more assignment tests
Solution: Add test for using different types in assignment, function
arguments and return values
closes: #13491
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Unsupported option causes rest of modeline test to be skipped.
Solution: Revert the change from patch 8.2.1432.
closes: #13499closes: #13500
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Do not rely on the fact, that the last line matches warning, error,
inappropriate or unrecognized to determine if an error occurred. It
could also be a file, contains such a keyword.
So make the error detection slightly more strict and only assume an
error occured, if in addition to those 4 keywords, also a space matches
(this assumes the error message contains a space), which luckily on Unix
not many files match by default.
The whole if condition seems however slightly dubious. In case an error
happened, this would probably already be caught in the previous if
statement, since this checks for the return code of the tar program.
There may however be tar implementations, that do not set the exit code
for some kind of error (but print an error message)? But let's keep this
check for now, not many people have noticed this behaviour until now, so
it seems to work reasonably well anyhow.
related: #6425fixes: #13489
Signed-off-by: Christian Brabandt <cb@256bit.org>
`:return` cannot be used outside of `:function` (or `:def`) in older Vims
lacking Vim9script support or in Neovim, even when evaluation is being skipped
in the dead `:else` branch.
Instead, use the pattern described in `:h vim9-mix`, which uses `:finish` to end
script processing before it reaches the vim9script stuff.
Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: cannot convert list to string using +=
(after 9.0.2072)
Solution: convert dict index to string later in compile_member()
fixes: #13485closes: #13486
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Also, enable the zip and gzip plugins by default, unless those variables
were not explicitly set by the user.
related: #13413
Signed-off-by: Christian Brabandt <cb@256bit.org>
Follow up to 816fbcc26 (patch 9.0.1833: [security] runtime file fixes,
2023-08-31) and f7ac0ef50 (runtime: don't execute external commands when
loading ftplugins, 2023-09-06).
This puts the logic for safe executable checks in a single place, by introducing
a central vim library, so all filetypes benefit from consistency.
Notable changes:
- dist#vim because the (autoload) namespace for a new runtime support
library. Supporting functions should get documentation. It might make
life easier for NeoVim devs to make the documentation a new file
rather than cram it into existing files, though we may want
cross-references to it somewhere…
- The gzip and zip plugins need to be opted into by enabling execution
of those programs (or the global plugin_exec). This needs
documentation or discussion.
- This fixes a bug in the zig plugin: code setting s:tmp_cwd was removed
in f7ac0ef50 (runtime: don't execute external commands when loading
ftplugins, 2023-09-06), but the variable was still referenced. Since
the new function takes care of that automatically, the variable is no
longer needed.
Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: complete_info() skips entries with 'noselect'
Solution: Check, if first entry is at original text state
Unfortunately, Commit daef8c74375141974d61b85199b383017644978c
introduced a regression, that when ':set completeopt+=noselect' is set
and no completion item has been selected yet, it did not fill the
complete_info['items'] list.
This happened, because the current match item did not have the
CP_ORIGINAL_TEXT flag set and then the cp->prev pointer did point to the
original flag item, which caused the following while loop to not being
run but being skipped instead.
So when the 'noselect' is set, only start with to the previous selection
item, if the initial completion item has the CP_ORIGINAL_TEXT flag set,
else use the 2nd previous item instead.
fixes: #13451closes: #13452
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: sound_playfile() fails when using powershell
Solution: quote filename using doublequotes, don't escape filename,
because it doesn't use the shell
Avoiding powershell escaping because mci open command doesn't support
single quoted filenames: open 'C:\whatever\sound.wav' is not valid.
closes: #13471
Signed-off-by: GuyBrush <miguel.barro@live.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Add shDerefOffset to shDerefVarArray.
Example code:
```bash
declare -a a=({a..z})
echo "${a[@]:1:3}"
```
Signed-off-by: Christian Brabandt <cb@256bit.org>
Strace output, depending on parameters (-ttf this time), can dump both
times and pid:
1038 07:14:20.959262 execve("./e.py", ["./e.py"], 0x7ffca1422840 /* 51 vars */) = 0 <0.000150>
So loose the regexp matching this, so that the above is matched too.
Fixes#13481.
Co-authored-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: code cleanup for option callbacks needed
Solution: remove flag os_doskip, it's not necessary, as we can check,
whether an error message was returned
Remove unnecessary field os_doskip
Callback functions for boolean options set os_doskip immediately before
returning an error message, so os_doskip isn't actually needed.
closes: #13461
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: abstract can be used in interface
Solution: Disallow the use of abstract in an interface
fixes: #13456closes: #13464
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Perl: xsubpp may be in non-standard location
Solution: Add --with-subpp configure option
configure.ac: Add --with-xsubpp configure option
Some environments (such as flatpaks) cannot count on xsubpp being
in the common Perl directory, so a configure option should be used for
clean solution.
closes: #13470
Signed-off-by: Zdenek Dohnal <zdohnal@redhat.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: test_channel may fail because of IPv6 config issues
Solution: Catch and skip the test, if getaddrinfo() fails with
'Address family not supported'
Mark tests as skipped when ch_open encounters E901
On some of the Debian build systems, the IPv6 channel tests fail because
`ch_open('[::1]:<port>', ...)` raises the error "E901: getaddrinfo() in
channel_open(): Address family for hostname not supported".
This appears to happen because getaddrinfo() can't perform the reverse
lookup for the ::1, which is a config issue on that system. Therefore,
instead of reporting a test failure, mark the test as skipped due to the
bad network config
closes: #13473
Signed-off-by: James McCoy <jamessan@jamessan.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: With 'smoothscroll' set, "w_skipcol" is not reset when unsetting 'wrap'.
Resulting in incorrect calculation of the cursor position.
Solution: Reset "w_skipcol" when unsetting 'wrap'.
fixes: #12970closes: #13439
Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
add shDblParen to shLoopList to correctly highlight
arithmetic expressions for Bash and Ksh
This should allow code such as:
```bash
declare -i i j
for i in foo bar
do ((j = 1 << j))
done
```
Signed-off-by: Lucien Grondin <grondilu@yahoo.fr>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: vim9_script test too large
Solution: split vim9 type alias test into
separate test file
Move type alias tests to a separate test file
closes: #13447
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Not all secure options document their status
Solution: Describe secure context :set restrictions in each help entry
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: several problems with type aliases
Solution: Check for more error conditions, add tests,
fix issues
Check for more error conditions and add additional tests
fixes #13434
fixes #13437
fixes #13438closes#13441
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: No support for type aliases
Solution: Implement :type command
A type definition is giving a name to a type specification. This also known
type alias.
:type ListOfStrings = list<string>
The type alias can be used wherever a built-in type can be used. The type
alias name must start with an upper case character.
closes: #13407
Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: TextChangedI may not always trigger
Solution: trigger it in more cases: for insert/
append/change operations, and when
opening a new line,
fixes: #13367closes: #13375
Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Problem: Completion menu may be wrong
Solution: Check for the original direction of the completion menu,
add more tests, make it work with 'noselect'
completion: move in right direction when filling completion_info()
When moving through the insert completion menu and switching directions,
we need to make sure we start at the correct position in the list and
move correctly forward/backwards through it, so that we do not skip
entries and the selected item points to the correct entry in the list
of completion entries generated by the completion_info() function.
The general case is this:
1) CTRL-X CTRL-N, we will traverse the list starting from
compl_first_match and then go forwards (using the cp->next pointer)
through the list (skipping the very first entry, which has the
CP_ORIGINAL_TEXT flag set (since that is the empty/non-selected entry
2) CTRL-X CTRL-P, we will traverse the list starting from
compl_first_match (which now points to the last entry). The previous
entry will have the CP_ORIGINAL_TEXT flag set, so we need to start
traversing the list from the second prev pointer.
There are in fact 2 special cases after starting the completion menu
with CTRL-X:
3) CTRL-N and then going backwards by pressing CTRL-P again.
compl_first_match will point to the same entry as in step 1 above,
but since compl_dir_foward() has been switched by pressing CTRL-P
to backwards we need to pretend to be in still in case 1 and still
traverse the list in forward direction using the cp_next pointer
4) CTRL-P and then going forwards by pressing CTRL-N again.
compl_first_match will point to the same entry as in step 2 above,
but since compl_dir_foward() has been switched by pressing CTRL-N
to forwards we need to pretend to be in still in case 2 and still
traverse the list in backward direction using the cp_prev pointer
For the 'noselect' case however, this is slightly different again. When
going backwards, we only need to go one cp_prev pointer back. And
resting of the direction works again slightly different. So we need to
take the noselect option into account when deciding in which direction
to iterate through the list of matches.
related: #13402
related: #12971closes: #13408
Signed-off-by: Christian Brabandt <cb@256bit.org>
* Update Debian runtime files
Add mantic as a supported Ubuntu release and move buster/kinetic to
unsupported.
Add syntax highlighting for deb822sources filetype.
Add debsources ftplugin to set relevant comment options.
Move common version information to shared/debversions.vim
Closes#11934
Co-authored-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Co-authored-by: James Addison <jay@jp-hosting.net>
Co-authored-by: Viktor Szépe <viktor@szepe.net>
Signed-off-by: James McCoy <jamessan@jamessan.com>
* Add myself as codeowner for Debian-related runtime files
Signed-off-by: James McCoy <jamessan@jamessan.com>
---------
Signed-off-by: James McCoy <jamessan@jamessan.com>
Co-authored-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Co-authored-by: James Addison <jay@jp-hosting.net>
Co-authored-by: Viktor Szépe <viktor@szepe.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: no nr2str conversion in list-unpack
Solution: Generate 2STRING instruction to convert dict index to string
Generate instruction to convert dict index to a string
fixes: #13417closes: #13424
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: objdump files not recognized
Solution: detect *.objdump files, add a filetype plugin
Added the objdump file/text format
closes: #13425
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Colin Kennedy <colinvfx@gmail.com>
Problem: [security] disallow setting env in restricted mode
Solution: Setting environment variables in restricted mode could
potentially be used to execute shell commands. Disallow this.
restricted mode: disable allow setting of environment variables
Setting environment variables in restricted mode, may have some unwanted
consequences. So, for example by setting $GCONV_PATH in restricted mode
and then calling the iconv() function, one may be able to execute some
unwanted payload, because the `iconv_open()` function internally uses
the `$GCONV_PATH` variable to find its conversion data.
So let's disable setting environment variables, even so this is no
complete protection, since we are not clearing the existing environment.
I tried a few ways but wasn't successful :(
One could also argue to disable the iconv() function completely in
restricted mode, but who knows what other API functions can be
influenced by setting some other unrelated environment variables.
So let's leave it as it is currently.
closes: #13394
See: https://huntr.com/bounties/b0a2eda1-459c-4e36-98e6-0cc7d7faccfe/
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: possible to escape bracketed paste mode with Ctrl-C
Solution: Do not handle Ctrl-C specially when key_protocol
is in use, makes bracketed paste mode more robust
When a key protocol is in use Ctrl-C will be sent as an escape sequence,
but a raw Ctrl-C can be sent when pasting data. Pass this through, so
that a Ctrl-C can be pasted and won't result in exiting insert mode
(where the rest of the pasted keys can cause all kind of nasty
side-effects).
Many terminals will strip control characters in paste data (and xterm
will strip ^C since version 388), but this provides some defense in
depth if users change settings like xterm's allowPasteControls.
closes: #13398
Signed-off-by: David Leadbeater <dgl@dgl.cx>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security] overflow in :history
Solution: Check that value fits into int
The get_list_range() function, used to parse numbers for the :history
and :clist command internally uses long variables to store the numbers.
However function arguments are integer pointers, which can then
overflow.
Check that the return value from the vim_str2nr() function is not larger
than INT_MAX and if yes, bail out with an error. I guess nobody uses a
cmdline/clist history that needs so many entries... (famous last words).
It is only a moderate vulnerability, so impact should be low.
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-q22m-h7m2-9mgm
Signed-off-by: Christian Brabandt <cb@256bit.org>
