arrufat
commented
8 months ago Maybe just like and <a->, we could have + and <a-+>?
Open schragge opened 8 months ago
arrufat
commented
8 months ago Maybe just like and <a->, we could have + and <a-+>?
schragge
commented
8 months ago But <a-+> is already used to reduce multiple selections to one.
arrufat
commented
8 months ago Right, forgot to check before posting. I am on the fence on the behavior of +
I wouldn't call this a regression, but there is a change in behavior I'd like to discuss. https://github.com/mawww/kakoune/commit/6942a4c0c9428a9e2ddb65de3969d2dcb5c5eb2f 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 https://github.com/mawww/golf/pull/39.The 7th rule of VimGolf states:
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"#Ror"#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 https://github.com/mawww/golf/pull/39.Examples
Some examples follow.
+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>q6lrnQf(la+<esc>"qd2"qq+"#P<a-,>dQ9q%<a-s>3b<a-b>hy<a-h><a-W>S.<ret>P<space>qdc(31 keystrokes)6lrn%<a-s>3b<a-b>hy<a-h><a-W>S.<ret>Pf:had+p<esc>|dc<ret><space>q+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+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>qawkandtr(39 keystrokes)Q<a-i>pyp<a-O>|tr ABC BCD<ret><a-s><a-m>L|awk \$1+=.7<ret>Qqq<space>q+selection order as of v2023-08-05, the main selection is on the left (14 keystrokes)+yPr15pr-<a-,>r=<space>q+selection order, the main selection is on the right (again 14 keystrokes, no worsening)+yPr15pr-,r=<space>qQuestions
+semantics still have some merits/uses, or should it be abandoned for good?