[QUESTION] [CHANGE IN BEHAVIOUR] New semantics of the + key command

[schragge]

I wouldn't call this a regression, but there is a change in behavior I'd like to discuss. 6942a4c changed the + command in two ways.

Changed semantics of +

First, as described in the changelog and in the commit description, pressing + multiple times doesn't multiply the number of selections anymore. I don't think the old behavior was of practical use in any real life situation, but it could have come useful in the context of some VimGolf challenges. See more details in mawww/golf#39.

The 7th rule of VimGolf states:

Refrain from copy/paste, reading in the solution (:read), or using external tools [emphasis mine—@schragge].

A number of challenges require doing some mathematical calculations. While Vim has its expression register, Kakoune relies on using external tools for doing stuff like this (a correct decision IMO). Nevertheless, some such challenges could be solved with Kakoune alone. I could come up with two techniques for doing this.

The first of them is using a lookup table. But it consumes many keystrokes, and so is mostly non-competitive (re. VimGolf). As it usually has nothing to do with +, I won't describe it in detail here.

The second one is less obvious, let's call it "Counting rods". It repurposes the sequential numbering register (#) as an abacus of sorts and often involves using + to bring the number of selections to the desired value, then numbering them with either "#R or "#P, and finally, retaining only the last selection (or, equivalently, removing all selections but the last one), which would be the result of calculation.

Of course, such solutions wouldn't be as efficient as using a proper command line calculator (bc, dc, etc). But at least in one case, the pure Kakoune solution would be comparable in terms of keystrokes used to the best Vim solutions. With the recent change described above some such solutions either stop to work completely or require more keystrokes.

Changed order of selections after +

Beside the new semantics, the order of selections has also changed. Previously, the main selection was the first one. Now, it is the last one of the selections made by +. Again, see some details in mawww/golf#39.

Examples

Some examples follow.

• The D a n k side of the Moon
  • The "Counting Rods" solution using the old + semantics as of v2023-08-05 (40 keystrokes)
    6lrnQf(l"qd"qq++"#P(<a-,>dQ9q%<a-s>3b<a-b>hy<a-h><a-W>S.<ret>P<space>q
  • The "Counting Rods" solution using the Kakoune git head (42 keystrokes)
    6lrnQf(la+<esc>"qd2"qq+"#P<a-,>dQ9q%<a-s>3b<a-b>hy<a-h><a-W>S.<ret>P<space>q
  • External tool solution using dc (31 keystrokes)
    6lrn%<a-s>3b<a-b>hy<a-h><a-W>S.<ret>Pf:had+p<esc>|dc<ret><space>q
• Complete the circuit grid!
  • Old + selection order as of v2023-08-05, the main selection is above (51 keystrokes)
    %3+yP<a-,>C<a-O><a-s><a-m>ha0.7 1.4 2.1 <esc>QS<space><ret>10+d<a-d>lRQ2<a-b>haB C D <esc>q<space>q
  • New + selection order, the main selection is below (52 keystrokes)
    %3+yP1<a-,>C<a-O><a-s><a-m>ha0.7 1.4 2.1 <esc>QS<space><ret>10+d<a-d>lRQ2<a-b>haB C D <esc>q<space>q
  • External tools solution using awk and tr (39 keystrokes)
    Q<a-i>pyp<a-O>|tr ABC BCD<ret><a-s><a-m>L|awk \$1+=.7<ret>Qqq<space>q
• Simple addition
  • Old + selection order as of v2023-08-05, the main selection is on the left (14 keystrokes)
    +yPr15pr-<a-,>r=<space>q
  • New + selection order, the main selection is on the right (again 14 keystrokes, no worsening)
    +yPr15pr-,r=<space>q

Questions

• In your opinion, does the old + semantics still have some merits/uses, or should it be abandoned for good?
• What selection order is more preferable, the old or the new one?

[arrufat]

Maybe just like * and <a-*>, we could have + and <a-+>?

[schragge]

But <a-+> is already used to reduce multiple selections to one.

[arrufat]

Right, forgot to check before posting. I am on the fence on the behavior of +

• right now it's more consistent: +++ is the same as 3+
• before +++ was giving you 8 selections, 3+, just tree. So you had both behaviors. And it enabled some nice tricks for vim golfs, which I am not sure were useful anywhere else.