cbuffer/cad doesn't take visual selection as range '<,'>cad

[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

[vim-ml]

Hi, 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

This looks weird and ugly (that's not your fault!). 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

…

[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 agree it can be improved :)

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.

[chrisbra]

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?

[vim-ml]

Hi Christian,

On Fri, Apr 26, 2024 at 9:02 AM Christian Brabandt < ***@***.***> wrote: Hm, even the mentioned <#2955 (comment)> '<,'>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 <https://github.com/yegappan> what do you think?

Yes. The above change looks good to me. The change to ADDR_OTHER was introduced by Patch 8.1.1241 (b731689). 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

[chrisbra]

I created #14657 for this.