| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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#12230
closes: vim/vim#12971
https://github.com/vim/vim/commit/69fb5afb3bc9da24c2fb0eafb0027ba9c6502fc2
Co-authored-by: LemonBoy <thatlemon@gmail.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
(#25605)
Problem: Vim9: in script cannot set item in uninitialized list.
Solution: When a list is NULL allocate an empty one. (closes vim/vim#8461)
https://github.com/vim/vim/commit/e65081d1b591f16dc6e380a830d87565c5eb7b03
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#13228
closes: vim/vim#13243
https://github.com/vim/vim/commit/dd75fcfbdff1934c6e531b5a89ebc636318bf4a2
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Co-authored-by: Wansmer <wansmer@gmail.com>
Co-authored-by: Andrew Voynov <andrewvoynov.b@gmail.com>
Co-authored-by: David Moberg <david.moberg@mediatek.com>
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
feat(float): add fclose command
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
(#25569)
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#13301
https://github.com/vim/vim/commit/54844857fd6933fa4f6678e47610c4b9c9f7a091
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
|
| | | | | | | |
| | | | | | |
| | | | | | | |
Removing this behavior causes more inconsistencies and bugs.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | | |
Co-authored-by: dundargoc <gocdundar@gmail.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.
|
| | | | | | | | |
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
refactor(grid): do arabic shaping in one place
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |
