Problem:
The next command after `silent !{cmd}` or `silent lua print('str')`
prints an empty line before printing a message, because these commands
set `msg_didout = true` despite not printing any messages.
Solution:
Set `msg_didout = true` only if `msg_silent == 0`
Problem: Peeking and flushing output slows down execution.
Solution: Do not update the mode message when global_busy is set. Do not
flush when only peeking for a character. (Ken Takata)
cb574f4154
PROBLEM:
Currently `:echoerr` prints multi-line strings in a single line
as `:echom` does (Note: `:echon` can print multi-line strings well).
This makes stacktrace printed via echoerr difficult to read.
Example code:
try
lua error("lua stacktrace")
catch
echoerr v:exception
endtry
Output:
Error detected while processing a.vim[5]..a.vim:
line 4:
Vim(lua):E5108: Error executing lua [string ":lua"]:1: lua stacktrace^@stack traceback:^@^I[C]: in function 'error'^@^I[string ":lua"]:1: in main chunk
SOLUTION:
Allow echoerr to print multiline messages (e.g., lua exceptions),
because this command is usually used to print stacktraces.
Output after the fix:
Error detected while processing a.vim[5]..a.vim:
line 4:
Vim(lua):E5108: Error executing lua [string ":lua"]:1: lua stacktrace
stack traceback:
[C]: in function 'error'
[string ":lua"]:1: in main chunk
Problem: complete_info() returns wrong index
Solution: Make order of 'info' in completion_info consistent
Start the iteration from the same point and follow the same direction as
done when assigning the completion numbers. This way we remove the
dependence on the completion direction and make the order of 'info'
consistent.
closes: vim/vim#12230closes: vim/vim#1297169fb5afb3b
Co-authored-by: LemonBoy <thatlemon@gmail.com>
Problem: Vim9: in script cannot set item in uninitialized list.
Solution: When a list is NULL allocate an empty one. (closesvim/vim#8461)
e65081d1b5
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: linebreak applies for leading whitespace
Solution: only apply linebreak, once we have found non-breakat chars in
the line
closes: vim/vim#13228closes: vim/vim#13243dd75fcfbdf
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: linebreak applies for leading whitespace
Solution: only apply linebreak, once we have found non-breakat chars in
the line
closes: vim/vim#13228closes: vim/vim#13243dd75fcfbdf
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: INI files not detected
Solution: detect uppercase .INI as dosini files
It previo~1 only worked for lower-case .ini files, but upperc~1 .INI is
also somewhat common on account of DOS' old 8.3 upperc~2 only filena~1.
closes: vim/vim#133164a82bdfaa8
Co-authored-by: Martin Tournoij <martin@arp242.net>
Using fnameescape() for the path argument of findfile() and finddir() is
wrong, as fnameescape() is intended to be used for parts of Ex commands,
not function arguments.
Problem: Certain compilers (primarily GCC) do not recognize an exhaustive enum switch statement as being exhaustive. This manifests in the form of compiler errors in exhaustive switch statements where each case has a return statement but there isn't a catch-all return statements. These compiler errors are spurious in the context of the Neovim codebase. So #25533 added the `UNREACHABLE` macro to denote apart of the code that's unreachable, which was used after every such switch statement to tell the compiler to treat the switch statement as exhaustive. However, the macro is mentioned nowhere in the style guide,and new contributors would not have any natural way of learning about it as it stands now. This would lead to confusion when they inevitably encounter one of these compiler errors.
Solution: Add a style guideline which shows how to use the `UNREACHABLE` macro to fix these compiler errors.
Problem: The style guide states that all switch statements that are not conditional on an enum must have a `default` case, but does not give any explicit guideline for switch statements that are conditional on enums. As a result, a `default` case is added in many enum switch statements, even when the switch statement is exhaustive. This is not ideal because it removes the ability to have compiler errors to easily detect unchanged switch statements when a new possible value for an enum is added.
Solution: Add explicit guidelines for switch statements that are conditional on an enum, clarifying that a `default` case is not necessary if the switch statement is exhaustive. Also refactor pre-existing code with unnecessary `default` cases.
Problem: cmdline-completion for comma-separated options wrong
Solution: Fix command-line expansions for options with filenames with
commas
Fix command-line expansions for options with filenames with commas
Cmdline expansion for option values that take a comma-separated list
of file names is currently not handling file names with commas as the
commas are not escaped. For such options, the commas in file names need
to be escaped (to differentiate from a comma that delimit the list
items). The escaped comma is unescaped in `copy_option_part()` during
option parsing.
Fix as follows:
- Cmdline completion for option values with comma-separated file/folder
names will not start a new match when seeing `\\,` and will instead
consider it as one value.
- File/folder regex matching will strip the `\\` when seeing `\\,` to
make sure it can match the correct files/folders.
- The expanded value will escape `,` with `\\,`, similar to how spaces
are escaped to make sure the option value is correct on the cmdline.
This fix also takes into account the fact that Win32 Vim handles file
name escaping differently. Typing '\,' for a file name results in it
being handled literally but in other platforms '\,' is interpreted as a
simple ',' and commas need to be escaped using '\\,' instead.
Also, make sure this new logic only applies to comma-separated options
like 'path'. Non-list options like 'set makeprg=<Tab>' and regular ex
commands like `:edit <Tab>` do not require escaping and will continue to
work.
Also fix up documentation to be clearer. The original docs are slightly
misleading in how it discusses triple slashes for 'tags'.
closes: vim/vim#13303
related: vim/vim#1330154844857fd
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: test: undofile left behind
Solution: cleanup undofile
fix: tmp file not deleted when running make test_undo
Temporary file `.Xtestfile.txt.un~` was left running `make test_undo`
and vim was configured with:
```
./configure --with-features=normal --enable-gui=no --enable-terminal
```
closes: vim/vim#13304b07b9dc4da
Co-authored-by: Dominique Pellé <dominique.pelle@tomtom.com>
This adds the checks in https://neovim.io/doc/reports/clang/ when using
clang-tidy. The strategy is to enable all clang-analyzer checks, and
disable only the checks for the warnings that exist currently. This
allows us to eliminate each warning type without blocking ongoing work,
but also without adding bugs for already eliminated warnings.
The plan is to eventually eliminate https://neovim.io/doc/reports/clang/
by completely integrating it into the clang-tidy check.
Also add make and cmake targets `clang-analyzer` to run this check.
*** CID 466056: Control flow issues (DEADCODE)
/src/nvim/window.c: 6951 in file_name_in_line()
6945 // Search backward for first char of the file name.
6946 // Go one char back to ":" before "//", or to the drive letter before ":\" (even if ":"
6947 // is not in 'isfname').
6948 while (ptr > line) {
6949 if ((len = (size_t)(utf_head_off(line, ptr - 1))) > 0) {
6950 ptr -= len + 1;
>>> CID 466056: Control flow issues (DEADCODE)
>>> Execution cannot reach the expression "path_has_drive_letter(ptr - 2)" inside this statement: "if (vim_isfilec((uint8_t)pt...".
6951 } else if (vim_isfilec((uint8_t)ptr[-1])
6952 || (len >= 2 && path_has_drive_letter(ptr - 2))
6953 || ((options & FNAME_HYP) && path_is_url(ptr - 1))) {
6954 ptr--;
6955 } else {
6956 break;
"VimEnter foo" was accepted as a valid event name for "VimEnter".
Events delimited with commas, eg. "VimEnter,BufRead", were also
accepted, even though only the first event was actually parsed.
Co-authored-by: ii14 <ii14@users.noreply.github.com>
long is 32 bits on windows, while it is 64 bits on other architectures.
This makes the type suboptimal for a codebase meant to be
cross-platform. Replace it with more appropriate integer types.
runtime: make command name for &iskeywordprg more unique (vim/vim#13297)
See https://github.com/vim/vim/pull/13213/commits by @dkearns:
Rename 'keywordprg' user command to ShKeywordPrg as this is just a
leaking implementation detail.
1e33cd72b6
Co-authored-by: Enno <Konfekt@users.noreply.github.com>
The 'arabicshape' feature of vim is a transformation of unicode text to
make arabic and some related scripts look better at display time. In
particular the content of a cell will be adjusted depending on the
(original) content of the cells just before and after it.
This is implemented by the arabic_shape() function in nvim. Before this
commit, shaping was invoked in four different contexts:
- when rendering buffer text in win_line()
- in line_putchar() for rendering virtual text
- as part of grid_line_puts, used by messages and statuslines and
similar
- as part of draw_cmdline() for drawing the cmdline
This replaces all these with a post-processing step in grid_put_linebuf(),
which has become the entry point for all text rendering after recent
refactors.
An aim of this is to make the handling of multibyte text yet simpler.
One of the main reasons multibyte chars needs to be "parsed" into
codepoint arrays of composing chars is so that these could be inspected
for the purpose of shaping. This can likely be vastly simplified in many
contexts where only the total length (in bytes) and width of composed
char is needed.
