| Commit message (Collapse) | Author | Age |
... | |
| | | |
| | | |
| | | | |
This was removed from Vim in patch 8.1.0681.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
It is less error-prone than manually defining header guards. Pretty much
all compilers support it even if it's not part of the C standard.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Note: The crash happens in the second test case when using uninitialized
memory, and therefore doesn't happen with ASAN.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
When the given length is exactly the number of bytes to copy, xmemdupz()
makes the intention clearer.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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: vim/vim#13394
See: https://huntr.com/bounties/b0a2eda1-459c-4e36-98e6-0cc7d7faccfe/
https://github.com/vim/vim/commit/6b89dd6a7257a1e2e9c7ea070b407bc4674a5118
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Uncrustify is the source of truth where possible.
Remove any redundant checks from clint.py.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
(#25715)
Problem: Vim9: crash with deferred function call and exception
Solution: Save and restore exception state
Crash when a deferred function is called after an exception and another
exception is thrown
closes: vim/vim#13376
closes: vim/vim#13377
https://github.com/vim/vim/commit/c59c1e0d88651a71ece7366e418f1253abbe2a28
The change in check_due_timer() is N/A as Nvim calls timer callbacks on
the main loop.
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: Vim9: exceptions confuse defered functions
Solution: save and restore exception state when calling defered
functions
closes: vim/vim#13364
closes: vim/vim#13372
https://github.com/vim/vim/commit/0672595fd50e9ae668676a40e28ebf66d7f52392
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
BREAKING CHANGE: This breaks the OptionSet autocommand, as the `v:` values associated with it (`v:option_new`, `v:option_old`, `v:option_oldlocal` and `v:option_oldglobal`) are now the same type as the option, instead of all option values being converted to strings.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: gcc overflow-warning for f_resolve
Solution: use pointer p instead of pointer q[-1]
Suppress the following warning:
```
filepath.c: In function ‘f_resolve’:
filepath.c:2162:27: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2162 | q[-1] = NUL;
```
Closes: vim/vim#13352
closes: vim/vim#13353
https://github.com/vim/vim/commit/215c3261a25f7a99e8711a3b3c6158119c6aea9e
Co-authored-by: Ken Takata <kentkt@csc.jp>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
(#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: 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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This finalizes the long running refactor from the old TUI-focused grid
implementation where text-drawing cursor was not separated from the
visible cursor.
Still, the pattern of setting cursor position together with updating a
line was convenient. Introduce grid_line_cursor_goto() to still allow
this but now being explicit about it.
Only having batched drawing functions makes code involving drawing
a bit longer. But it is better to be explicit, and this highlights
cases where multiple small redraws can be grouped together. This was the
case for most of the changed places (messages, lastline, and :intro)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem:
The swapfile "E325: ATTENTION" dialog is displayed when editing a file
already open in another (running) Nvim. Usually this behavior is
annoying and irrelevant:
- "Recover" and the other options ("Open readonly", "Quit", "Abort") are
almost never wanted.
- swapfiles are less relevant for "multi-Nvim" since 'autoread' is
enabled by default.
- Even less relevant if user enables 'autowrite'.
Solution:
Define a default SwapExists handler which does the following:
1. If the swapfile is owned by a running Nvim process, automatically
chooses "(E)dit anyway" (caveat: this creates a new, extra swapfile,
which is mostly harmless and ignored except by `:recover` or `nvim -r`.
2. Shows a 1-line "ignoring swapfile..." message.
3. Users can disable the default SwapExists handler via `autocmd! nvim_swapfile`.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: No support for writing extended attributes
Solution: Add extended attribute support for linux
It's been a long standing issue, that if you write a file with extended
attributes and backupcopy is set to no, the file will loose the extended
attributes.
So this patch adds support for retrieving the extended attributes and
copying it to the new file. It currently only works on linux, mainly
because I don't know the different APIs for other systems (BSD, MacOSX and
Solaris). On linux, this should be supported since Kernel 2.4 or
something, so this should be pretty safe to use now.
Enable the extended attribute support with normal builds.
I also added it explicitly to the :version output as well as make it
able to check using `:echo has("xattr")`, to have users easily check
that this is available.
In contrast to the similar support for SELINUX and SMACK support (which
also internally uses extended attributes), I have made this a FEAT_XATTR
define, instead of the similar HAVE_XATTR.
Add a test and change CI to include relevant packages so that CI can
test that extended attributes are correctly written.
closes: vim/vim#306
closes: vim/vim#13203
https://github.com/vim/vim/commit/e085dfda5d8dde064b0332464040959479696d1c
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Move vimoption_T to option.h
- option_defs.h is for option-related types
- option_vars.h corresponds to Vim's option.h
- option_defs.h and option_vars.h don't include each other
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
long is 32-bits even on 64-bit windows which makes the type suboptimal
for a codebase meant to be cross-platform.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
problem: there are too many different functions in message.c
solution: fold some of the functions into themselves
|
| | | |
| | | |
| | | |
| | | |
| | | | |
problem: there are too many different functions in message.c
solution: fold some of the functions into themselves
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Co-authored-by: nuid64 <lvkuzvesov@proton.me>
Co-authored-by: Mike Smith <10135646+mikesmithgh@users.noreply.github.com>
Co-authored-by: XTY <xty@xty.io>
Co-authored-by: Empa <emanuel@empa.xyz>
Co-authored-by: kyu08 <49891479+kyu08@users.noreply.github.com>
|
| | | |
| | | |
| | | |
| | | | |
Clang 14 now reports sprintf as deprecated.
|
| |\ \ \
| | | | |
| | | | | |
feat(msgpack_rpc): add a new `msgpack-rpc` client type to fix behavior with MessagePack-RPC compliant clients
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Added to support MessagePack-RPC fully compliant clients that do
not return responses in request order.
Although it is currently not an efficient implementation for full
compliance and full compliance cannot be guaranteed, the addition
of the new client type `msgpack-rpc` creates a situation where "if
the client type is `msgpack-rpc`, then backward compatibility is
ignored and full compliance with MessagePack- RPC compliance is
justified even if backward compatibility is ignored if the client
type is `msgpack-rpc`.
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Most of the messy things when changing a non-current buffer is
not about the buffer, it is about windows. In particular, it is about
`curwin`.
When editing a non-current buffer which is displayed in some other
window in the current tabpage, one such window will be "borrowed" as the
curwin. But this means if two or more non-current windows displayed the buffers,
one of them will be treated differenty. this is not desirable.
In particular, with nvim_buf_set_text, cursor _column_ position was only
corrected for one single window. Two new tests are added: the test
with just one non-current window passes, but the one with two didn't.
Two corresponding such tests were also added for nvim_buf_set_lines.
This already worked correctly on master, but make sure this is
well-tested for future refactors.
Also, nvim_create_buf no longer invokes autocmds just because you happened
to use `scratch=true`. No option value was changed, therefore OptionSet
must not be fired.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
ml_get_buf() takes a third parameters to indicate whether the
caller wants to mutate the memline data in place. However
the vast majority of the call sites is using this function
just to specify a buffer but without any mutation. This makes
it harder to grep for the places which actually perform mutation.
Solution: Remove the bool param from ml_get_buf(). it now works
like ml_get() except for a non-current buffer. Add a new
ml_get_buf_mut() function for the mutating use-case, which can
be grepped along with the other ml_replace() etc functions which
can modify the memline.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: append() reports failure when not appending anything.
Solution: Only report failure when appending something. (closes vim/vim#11498)
https://github.com/vim/vim/commit/cd9c8d400c1eb9cbb4ff6a33be02f91a30ab13b2
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
$COLORTERM is set in the terminal emulator based on the value of
'termguicolors' ("truecolor" if &tgc is set, 256 otherwise), but ONLY if
$COLORTERM is also set in the parent terminal emulator.
This is an unnecessary restriction that can cause issues in some cases.
For instance, $COLORTERM is stripped by default by OpenSSH, so is not
present in an SSH session. The terminal emulator still supports 24 bit
color, so the lack of $COLORTERM is not a reliable indicator. When an
application runs in Nvim's :terminal it thus has no way to know whether
or not true color is supported.
Instead, setting it unconditionally based on 'termguicolors' uses the
user's own preferences to infer if 24-bit color is supported, rather
than depending on the (unreliable) presence of $COLORTERM. If
'termguicolors' is set in a terminal that does not support true color
then the colors in Nvim will already look bad. Enabling them for
applications in the terminal emulator will not make it any worse.
If 'termguicolors' is not set then the value of $COLORTERM from the
parent terminal (if any) is forwarded to Nvim's :terminal.
Fixes: https://github.com/neovim/neovim/issues/24717
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: The mouse code is spread out.
Solution: Move all the mouse code to mouse.c. (Yegappan Lakshmanan,
closes vim/vim#4959)
https://github.com/vim/vim/commit/b20b9e14ddd8db111e886ad0494e15b955159426
Also move getmousepos() there.
N/A patches for version.c:
vim-patch:8.1.2070: mouse code is spread out
Problem: Mouse code is spread out.
Solution: Move mouse terminal code parsing to mouse.c. (Yegappan Lakshmanan,
closes vim/vim#4966)
https://github.com/vim/vim/commit/b8ff5c271ee5dcef6f63436b77e228e062ff9a0e
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: No tests for state().
Solution: Add tests. Clean up some feature checks. Make "a" flag work.
https://github.com/vim/vim/commit/c2585490321854ca3df115efcf0b40986901d96c
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: SafeStateAgain not triggered if callback uses feedkeys().
Solution: Check for safe state in the input loop. Make log messages easier
to find. Add 'S' flag to state().
https://github.com/vim/vim/commit/d103ee78432f9036d243b18dd5aac1263d3b7dc9
Include misc1.c change from patch 8.1.2062.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: Cannot check the current state.
Solution: Add the state() function.
https://github.com/vim/vim/commit/0e57dd859ecb1e8a3b91509d2f4343e839340eb8
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: reverse() on string doesn't work in compiled function.
Solution: Accept string in argument type check. (Yegappan Lakshmanan,
closes vim/vim#12377)
https://github.com/vim/vim/commit/f9dc278946d52235a0025fd347bd9ff571258470
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: reverse() does not work for a String.
Solution: Implement reverse() for a String. (Yegappan Lakshmanan,
closes vim/vim#12179)
https://github.com/vim/vim/commit/03ff1c2dde7f15eca5c9baa6dafbda9b49bedc3b
vim-patch:9.0.1738: Duplicate code to reverse a string
Problem: Duplicate code to reverse a string
Solution: Move reverse_text() to strings.c and remove string_reverse().
closes: vim/vim#12847
https://github.com/vim/vim/commit/4dd266cb66d901cf5324f09405cfea3f004bd29f
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: missing winid argument for virtcol()
Solution: Add a {winid} argument to virtcol()
Other functions col(), charcol() and virtcol2col() support a {winid}
argument, so it makes sense for virtcol() to also support than.
Also add test for virtcol2col() with 'showbreak' and {winid}.
closes: vim/vim#12633
https://github.com/vim/vim/commit/825cf813fa0fddf085fcbd3194781e875320ff63
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: Fix regression in {func} argument of reduce()
Solution: pass function name as string again
Before patch 9.0.0548, passing a string as {func} argument of reduce()
is treated as a function name, but after patch 9.0.0548 it is treated as
an expression instead, which is useless as reduce() doesn't set any v:
variables. This PR restores the behavior of {func} before that patch.
Also correct an emsg() call, as e_string_list_or_blob_required doesn't
contain format specifiers.
closes: vim/vim#12824
https://github.com/vim/vim/commit/ad0c442f1fcc6fe9c433777ee3e5b9e6addc6d69
|