Problem: To goto or delete a bookmark, one needs to prefix a count
for the bookmark number (e.g., "2gb" to open bookmark#2).
As the bookmark list gets or deletes entries, the numbers
keep changing, requiring listing the bookmarks with qb to
discover the desired bookmark number. Typing gb or mB
without a count targets g:netrw_bookmarklist[-1].
Solution: If no count is given to gb or mB, list all bookmarks and
prompt for a number using inputlist(), similar to tag jump
with g].
closes: vim/vim#2021135b767a090
Co-authored-by: J. Paulo Seibt <jpseibt@gmail.com>
Problem: runtime(netrw): command injection possible via crafted
directory names in NetrwMaps() (Christopher Lusk)
Solution: Temporarily remove B flag in NetrwMaps() to prevent command
injection
8e41c34aba
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
Using the `DiffTool` plugin (e.g. through `nvim -d ...` or `:DiffTool
<file1> <file2>` fails if a space is in one of the paths. This occurs
because the `diff` wraps the paths with quotes (`'`) if space
characters are present, which the line diff regex fails to parse.
Solution:
Update regex to handle quoted paths by matching the string within the
quotes, if it exists.
Problem: the bookmarks list can have duplicate entries, more often
in win32 (due to mixed slashes and capitalization) and when
g:netrw_keepdir=0 (which could introduce relative paths).
Duplicate entries could be: C:\foo\BAR\baz.file
c:\foo\bar\baz.file
c:/foo\BAR/baz.file
BAR/baz.file
Solution: Normalize the paths and make sure they are always absolute
(J. Paulo Seibt).
closes: vim/vim#2019474019bea8c
Co-authored-by: J. Paulo Seibt <jpseibt@gmail.com>
Problem: runtime(netrw): bookmarking directory uses current dir
Solution: Correctly handle netrw actual directory (J. Paulo Seibt)
fixes: vim/vim#10481closes: vim/vim#20169ec76ac620b
Co-authored-by: J. Paulo Seibt <jpseibt@gmail.com>
Problem: off-by-one bug in s:NetrwUnMarkFile()
Solution: Correctly loop through all buffers to unlet all variables
(J. Paulo Seibt)
When the function loops through buffers to clear s:netrwmarkfilelist_#
and s:netrwmarkfilemtch_#, it skips the last one at bufnr('$'), messing
up mark highlights and causing other functions that operate on those
arrays (like delete or rename) to target stale marked files.
The bufnr() help page says that bufnr("$") returns the highest buffer
number of existing buffers, so while ibuf < bufnr("$") does not clear
the last buffer-local arrays.
To reproduce:
Just opening a fresh Vim and running :Ex opens a netrw buffer at the
highest number. Then, typing mu after marking some files triggers the
mark highlight bug, and finally typing D would act like calling the
delete function against the previous marked files, as the buffer-local
arrays where not touched by s:NetrwUnMarkFile.
closes: vim/vim#201297ccc273a4c
Co-authored-by: J. Paulo Seibt <jpseibt@gmail.com>
Problem: termdebug: Need a few more user commands
Solution: Add the :RunOrContinue and the :ToggleBreak user commands
(bennyyip)
closes: vim/vim#18283c975d62473
Co-authored-by: bennyyip <yebenmy@gmail.com>
Problem:
- Various `TermRequest` handlers which all do similar things.
- `tty.query` is specific to `XTGETTCAP DCS`, can't be reused for other kinds of terminal queries.
Solution:
Provide `tty.request()`.
Calling `set print pretty on` in GDB will:
> Cause GDB to print structures in an indented format with one member
per line
However, `termdebug` just renders the newlines as raw `\n` characters.
This is a regression of[1]. Glancing through the history it looks to
have been caused by cd1b14f027 which
removed the output splitting when displaying the eval results, so this
changes adds that behaviour back.
As a quick reproduction/test, compile the following C program:
```c
struct Foo {
char *name;
};
int main(void) {
struct Foo f = {"hello"};
printf("%s\n", f.name);
return 0;
}
```
Then launch `nvim` and run:
:Termdebug main
:Gdb
(gdb) set print pretty on
(gdb) break main
(gdb) run
:Source
Place the cursor on the `f` variable and call `:Evaluate`. Before this change:
With this change:
Link: https://github.com/neovim/neovim/issues/10020 [1]
Problem:
Cannot remove a `@conceal` highlight when defined in highlights.scm.
Solution:
Support a `@noconceal` highlight that works similarly to `@nospell` where it
overrides the conceal set on the range to remove it. Additionally, can
set the conceal metadata field to false for the same behavior.
Problem: runtime(netrw): ~ note expanded on MS Windows
(Tom Vamvanij)
Solution: Expand ~ on MS Windows (Yasuhiro Matsumoto)
On Windows, ":Explore ~" did nothing because the tilde expansion was
gated to Unix/Cygwin only. Additionally, substitute() interprets
backslashes in the replacement string specially (e.g. \U as a case
modifier), which would corrupt $HOME values like C:\Users\name even
if the branch were taken.
Include has("win32") in the guard, anchor the pattern to the start of
the string, and escape backslashes, ampersands and tildes in $HOME
before substituting.
fixes: vim/vim#20003closes: vim/vim#20014723c0acf25
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Problem: runtime(netrw): RFC2396 decoding double escaping spaces
(lilydjwg, after 3e60f03d942d6bb0f7eac)
Solution: Remove escape() call, since we are using fnameescape() anyhow
fixes: vim/vim#19913ab4ebb62ee
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: netrw: does not take port into account in hostname validation
(after v9.2.0073)
Solution: Update hostname validation check and test for an optional port
number (Miguel Barro)
closes: vim/vim#19533a6198523fb
Co-authored-by: Miguel Barro <miguel.barro@live.com>
Problem: [security]: Insufficient validation of hostname and port in
netrw URIs allows command injection via shell metacharacters
(ehdgks0627, un3xploitable).
Solution: Implement stricter RFC1123 hostname and IP validation.
Use shellescape() for the provided hostname and port.
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-m3xh-9434-g33679348dbbc0
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: netrw: need better tests for absolute paths
Solution: Use absolutepath(), instead of regex test (Miguel Barro).
closes: vim/vim#19477bd1dc5b1a6
Cherry-pick a typo fix from latest Vim.
Co-authored-by: Miguel Barro <miguel.barro@live.com>
Problem:
Non-trivial to write output of vim.net.request to buffer. Requires extra
code in plugin/net.lua which can't be reused by other plugin authors.
```
vim.net.request('https://neovim.io', {}, function(err, res)
if not err then
local buf = vim.api.nvim_create_buf(true, false)
if res then
local lines = vim.split(res.body, '\n', { plain = true })
vim.api.nvim_buf_set_lines(buf, 0, -1, true, lines)
end
end
end)
```
Solution:
Accept an optional `outbuf` argument to indicate the buffer to write output
to, similar to `outpath`.
vim.net.request('https://neovim.io', { outbuf = buf })
Other fixes / followups:
- Make plugin/net.lua smaller
- Return objection with close() method
- vim.net.request.Opts class
- vim.validate single calls
- Use (''):format(...) instead of `..`
Problem:
The "tohtml" plugin is loaded by default.
Solution:
- Move it to `pack/dist/opt/nvim.tohtml/`, it is an "opt-in" plugin now.
- Document guidelines.
- Also revert the `plugin/` locations of `spellfile.lua` and `net.lua`.
That idea was not worth the trouble, it will be too much re-education
for too little gain.
that was an internal note which somehow slipped in months ago and even
survived the change to Vimscript9
closes: vim/vim#18305049c76f0e8
Co-authored-by: Simon Sobisch <simonsobisch@web.de>
Problem: termdebug :Break does not support `thread` and `if` arguments
Solution: extend :Break and :Tbreak to accept optional location, thread
{nr}, and if {expr} arguments (Yinzuo Jiang).
closes: vim/vim#196135890ea5397
AI-assisted: Codex
Problem: tests: termdebug test may fail and leave temp file around
(Dominique Pellé)
Solution: only run balloon_show() if the function exists, validate
termdebug is running using the g: termdebug_is_running var,
use defer to delete temporary files
Only include:
- guard balloon_show() in the termdebug plugin
- wait for g:termdebug_is_running in Test_termdebug_basic()
The remaining upstream test cleanups do not apply here.
fixes: vim/vim#153342979cfc262
Co-authored-by: Christian Brabandt <cb@256bit.org>
AI-assisted: Codex
- Functions are way too long. Readability and maintainability should
be slightly improved.
- Some variables are re-assigned to their initial value at teardown.
This should not be needed since all internal variables are
re-initialized at startup of every Termdebug session.
Only include:
- prompt-mode buffer tracking changes around `promptbufnr`
- prompt buffer cleanup in `CloseBuffers()` and `EndDebugCommon()`
- related `BufUnload` and gdb startup failure cleanup adjustments
The remaining upstream `StartDebug_term()` refactor and helper extraction
do not apply here.
closes: vim/vim#15086225d4d9212
Co-authored-by: Ubaldo Tiberi <ubaldo.tiberi@gmail.com>
AI-assisted: Codex
For ASM and Variables buffer, check were done to make sure they existed
before attempting to close them, but not for debugged program or gdb
communication. The debugged program window is a user-facing one and
user might close it manually, so it's better to check if it exists.
fce324f557
Co-authored-by: Damien Riegel <damien@riegel.io>
AI-assisted: Codex
Problem:
In autocmd examples, using "args" as the event-object name is vague and
may be confused with a user-command.
Solution:
Use "ev" as the conventional event-object name.
Closing the quickfix window previously triggered a WinClosed autocmd
that deleted all difftool autocmds and pushed an empty quickfix list,
making the difftool non-functional. Users who close the quickfix window
to gain screen real estate for viewing diffs had no way to continue
navigating entries.
Remove the qf_win tracking and its associated WinClosed autocmd so that
closing the quickfix window no longer tears down the difftool state.
Closing either diff window still performs full cleanup as before.
The BufWinEnter handler no longer passes with_qf to diff_files, so
navigating entries while the quickfix window is closed reuses the
existing diff layout without forcing a layout rebuild.
Fixes#37388
Problem:
- Nvim supports multi-line input in prompt buffer, so line(`$`) is not
always the prompt line.
Solution:
- Use `line("':")` to get the prompt line.
Problem: When using netrw to navigate directories, vim immediately
creates, then deletes a swap file in the entered directory,
causing the lastModifiedTime of that directory to change.
Solution: Use the :noswapfile command modifier in s:NetrwEditFile()
fixes: vim/vim#188544e2aafddbb
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: When Vim is launched with a UNC directory, netrw treats it as a
relative path and compose it again.
Solution: This is due to `exists("g:netrw_cygwin")` always being true.
We can directly use `g:netrw_cygwin`.
closes: vim/vim#19015538da34ad3
Co-authored-by: tao <2471314@gmail.com>
Problem: runtime(netrw): LocalBrowseCheck() wipes unnamed buffers when
g:netrw_fastbrowse=0 (Carlos Falgueras García)
Solution: Check that bufname() is not empty
fixes: vim/vim#18740closes: vim/vim#18741384685fade
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: confusing that there is the tag `undo-tree` (the Vim
implementation) and `undotree` (the Lua plugin for visualization).
Solution: rename tag to undotree-plugin. Mention the plugin in the docs of
|undotree|.
Problem: Changing permissions fail when using `gp` if the file under
the cursor is not in the current working directory.
Solution: Use the already available `a:curdir` argument and prepend it
to the `<cfile>`, so that the path of the file is correct.
This commit also refactors some leftover `netrw#ErrorMsg` to
`netrw#msg#Notify` (the main refactoring was done in
f5e3b5c04f85b0f69cd2aae81e4938cfb191a790).
closes: vim/vim#18674fe71c56d8f
Co-authored-by: Mohammad Reza Karimi <m.r.karimi.j@gmail.com>
Problem: username parsing bug in netrw plugin when using remote adding
feature
Solution: Allow any characters except for "@" (Václav Kobera), add a
test for the netrw plugin
closes: vim/vim#18611f17f78c557
Co-authored-by: Václav Kobera <vasekobera@gmail.com>
