[vim/vim] cbuffer/cad doesn't take visual selection as range '<,'>cad (Issue #14638)
Ilan Schemoul
Steps to reproduce
select something
type '<,'>cad
=> E16: Invalid range
Expected behaviour
Should take visual range (like it takes regular range such as 1cad).
Btw in the issue #2955 you can see it's advised by someone to do such things as '<,'>cgetbuffer (very useful because as explained in the issue when you have a terminal running inside vim you regularly want to take the output of the command and put it in the fixlist)
Version of Vim
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 14 2024 09:05:11) Included patches: 1-579, 1969, 580-1848, 4975, 5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859, 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108, 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840, 1846-1847, 2110-2112, 2121
Environment
xterm-256color
WSL 2 ubuntu 22.04
windows terminal
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christ van Willegen
Version of Vim
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 14 2024 09:05:11) Included patches: 1-579, 1969, 580-1848, 4975, 5016, 5023, 5072, 2068, 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859, 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108, 2107-2109, 2109-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840, 1846-1847, 2110-2112, 2121
vim-dev ML
Op vr 26 apr. 2024 00:37 schreef Ilan Schemoul ***@***.***>:
> Version of Vim
>
> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 14 2024 09:05:11)
> Included patches: 1-579, 1969, 580-1848, 4975, 5016, 5023, 5072, 2068,
> 1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859, 1873, 1860-1969, 1992,
> 1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108, 2107-2109, 2109-3995,
> 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840, 1846-1847, 2110-2112,
> 2121
>
213 is listed twice, once on it's own, and in the 1-579. 1858 is in there
twice, as well. Ranges are not merged, patch numbers are not sorted.
Does this list depend on the order of the patches list at the end of
version.c ? Shouldn't this be made more readable? I'll try to look into
it...
Oh, I just realized: this is an old version (8.2, from 2019). Is there a
newer version you can try?
Christ van Willegen
>
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Ilan Schemoul
Hey,
Version of Vim
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 14 2024 09:05:11)
Included patches: 1-579, 1969, 580-1848, 4975, 5016, 5023, 5072, 2068,
1849-1854, 1857, 1855-1857, 1331, 1858, 1858-1859, 1873, 1860-1969, 1992,
1970-1992, 2010, 1993-2068, 2106, 2069-2106, 2108, 2107-2109, 2109-3995,
4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840, 1846-1847, 2110-2112,
2121
This looks weird and ugly (that's not your fault!).
I do not know why it's like this. I believe I kept the default vim as packaged by default on ubuntu 22.04 on WSL 2. I can reinstall with sudo apt-get if you want when I'll have access again to this computer
Oh, I just realized: this is an old version (8.2, from 2019). Is there a
newer version you can try?
I just compiled the latest version on master on another computer with Ubuntu 22.04 and I can confirm I have the same error with configuration disabled (-u none) and selecting something and executing the command :'<,'>cad (or cgetbuffer)
I am surprised you confirm it seems like a bug (present already in my version from 2019 and still here in 2024) and not a misunderstanding on my side as visual range selecting is very common and I can't believe I can be the only one trying to use quickfix lists with visual selection.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
Hm, even the mentioned '<,'>cgetbuffer does no longer work. It seems at least the following two commands would need to use ADDR_LINES instead of ADDR_OTHER.
Something like this:
diff --git a/src/ex_cmds.h b/src/ex_cmds.h index 70e57708f..bd195a72f 100644 --- a/src/ex_cmds.h +++ b/src/ex_cmds.h @@ -271,7 +271,7 @@ EXCMD(CMD_cabove, "cabove", ex_cbelow, ADDR_UNSIGNED), EXCMD(CMD_caddbuffer, "caddbuffer", ex_cbuffer, EX_RANGE|EX_WORD1|EX_TRLBAR, - ADDR_OTHER), + ADDR_LINES), EXCMD(CMD_caddexpr, "caddexpr", ex_cexpr, EX_NEEDARG|EX_WORD1|EX_NOTRLCOM|EX_EXPR_ARG, ADDR_NONE), @@ -331,7 +331,7 @@ EXCMD(CMD_cgetfile, "cgetfile", ex_cfile, ADDR_NONE), EXCMD(CMD_cgetbuffer, "cgetbuffer", ex_cbuffer, EX_RANGE|EX_WORD1|EX_TRLBAR, - ADDR_OTHER), + ADDR_LINES), EXCMD(CMD_cgetexpr, "cgetexpr", ex_cexpr, EX_NEEDARG|EX_WORD1|EX_NOTRLCOM|EX_EXPR_ARG, ADDR_NONE),
It seems ADDR_OTHER doesn't make sense here. @yegappan what do you think?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yegappan Lakshmanan
vim-dev ML
On Fri, Apr 26, 2024 at 9:02 AM Christian Brabandt <
***@***.***> wrote:
> Hm, even the mentioned
> commands would need to use ADDR_LINES instead of ADDR_OTHER.
>
> Something like this:
>
> diff --git a/src/ex_cmds.h b/src/ex_cmds.h
> EXCMD(CMD_caddbuffer, "caddbuffer", ex_cbuffer,
> EX_NEEDARG|EX_WORD1|EX_NOTRLCOM|EX_EXPR_ARG,
> EXCMD(CMD_cgetbuffer, "cgetbuffer", ex_cbuffer,
> EX_NEEDARG|EX_WORD1|EX_NOTRLCOM|EX_EXPR_ARG,
> ADDR_NONE),
>
> It seems ADDR_OTHER doesn't make sense here. @yegappan
>
>
Yes. The above change looks good to me.
The change to ADDR_OTHER was introduced by Patch 8.1.1241
(b731689e85b4153af7edc8f0a6b9f99d36d8b011).
Currently there is no test for using a range with the caddbuffer and
cgetbuffer commands. That is why this regression
was not caught earlier. We should add a few tests for using a range with
these commands.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I created #14657 for this.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
Closed #14638 as completed via 652c821.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.