Patch 9.0.0858

[Bram Moolenaar]

Patch 9.0.0858
Problem: "!!sort" in a closed fold sorts too many lines.
Solution: Round to end of fold after adding the line count. (closes #11487)
Files: src/ex_docmd.c, src/testdir/test_fold.vim


*** ../vim-9.0.0857/src/ex_docmd.c 2022-10-09 18:53:29.024591198 +0100
--- src/ex_docmd.c 2022-11-11 01:09:27.686314567 +0000
***************
*** 4308,4313 ****
--- 4308,4315 ----
lnum = MAXLNUM;
do
{
+ int base_char = *cmd;
+
switch (*cmd)
{
case '.': // '.' - Cursor position
***************
*** 4602,4611 ****
i = '+'; // "number" is same as "+number"
else
i = *cmd++;
! if (!VIM_ISDIGIT(*cmd)) // '+' is '+1', but '+0' is not '+1'
n = 1;
else
{
n = getdigits(&cmd);
if (n == MAXLNUM)
{
--- 4604,4614 ----
i = '+'; // "number" is same as "+number"
else
i = *cmd++;
! if (!VIM_ISDIGIT(*cmd)) // '+' is '+1'
n = 1;
else
{
+ // "number", "+number" or "-number"
n = getdigits(&cmd);
if (n == MAXLNUM)
{
***************
*** 4627,4636 ****
else
{
#ifdef FEAT_FOLDING
! // Relative line addressing, need to adjust for folded lines
! // now, but only do it after the first address.
! if (addr_type == ADDR_LINES && (i == '-' || i == '+')
! && address_count >= 2)
(void)hasFolding(lnum, NULL, &lnum);
#endif
if (i == '-')
--- 4630,4645 ----
else
{
#ifdef FEAT_FOLDING
! // Relative line addressing: need to adjust for closed folds
! // after the first address.
! // Subtle difference: "number,+number" and "number,-number"
! // adjusts to end of closed fold before adding/subtracting,
! // while "number,.+number" adjusts to end of closed fold after
! // adding to make "!!" expanded into ".,.+N" work correctly.
! int adjust_for_folding = addr_type == ADDR_LINES
! && (i == '-' || i == '+')
! && address_count >= 2;
! if (adjust_for_folding && (i == '-' || base_char != '.'))
(void)hasFolding(lnum, NULL, &lnum);
#endif
if (i == '-')
***************
*** 4643,4648 ****
--- 4652,4663 ----
goto error;
}
lnum += n;
+ #ifdef FEAT_FOLDING
+ // ".+number" rounds up to the end of a closed fold after
+ // adding, so that ":!!sort" sorts one closed fold.
+ if (adjust_for_folding && base_char == '.')
+ (void)hasFolding(lnum, NULL, &lnum);
+ #endif
}
}
}
*** ../vim-9.0.0857/src/testdir/test_fold.vim 2022-11-02 13:30:37.542314565 +0000
--- src/testdir/test_fold.vim 2022-11-11 00:58:09.322153933 +0000
***************
*** 1570,1573 ****
--- 1570,1609 ----
bw!
endfunc

+ func Test_sort_closed_fold()
+ CheckExecutable sort
+
+ call setline(1, [
+ \ 'Section 1',
+ \ ' how',
+ \ ' now',
+ \ ' brown',
+ \ ' cow',
+ \ 'Section 2',
+ \ ' how',
+ \ ' now',
+ \ ' brown',
+ \ ' cow',
+ \])
+ setlocal foldmethod=indent sw=3
+ normal 2G
+
+ " The "!!" expands to ".,.+3" and must only sort four lines
+ call feedkeys("!!sort\<CR>", 'xt')
+ call assert_equal([
+ \ 'Section 1',
+ \ ' brown',
+ \ ' cow',
+ \ ' how',
+ \ ' now',
+ \ 'Section 2',
+ \ ' how',
+ \ ' now',
+ \ ' brown',
+ \ ' cow',
+ \ ], getline(1, 10))
+
+ bwipe!
+ endfunc
+
" vim: shiftwidth=2 sts=2 expandtab
*** ../vim-9.0.0857/src/version.c 2022-11-10 23:17:15.863670823 +0000
--- src/version.c 2022-11-11 00:50:22.930095852 +0000
***************
*** 697,698 ****
--- 697,700 ----
{ /* Add new patch number below this line */
+ /**/
+ 858,
/**/

--
A fine is a tax for doing wrong. A tax is a fine for doing well.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Bram Moolenaar]

I wrote:

> Patch 9.0.0858
> Problem: "!!sort" in a closed fold sorts too many lines.
> Solution: Round to end of fold after adding the line count. (closes #11487)
> Files: src/ex_docmd.c, src/testdir/test_fold.vim

I had been working on this and decided to finish it, but looking back
I'm not happy with this solution. As I mentioned before, there are two
options:
- Expanding "!!" and then handling the expanded range - this seemed like
the most user-friendly way, because you can see a range of lines is
going to be operated upon before you hit Enter.
- Not expanding "!!" and including the whole fold when turning it into
line numbers. This doesn't give any hint about including the whole
fold, thus it seemed not the best choice.

However, it turns out that we have an existing behavior that interferes:
Adding an offset to a range with a fold allowed for excluding or
including some lines above/below the end of the fold. The second line
number is adjusted to the end of the closed fold before
adding/subtracting the offset. Not sure if this is being actively used,
but at least there is a test for it.

I worked around it by checking for a dot before the offset. That's what
we get when expanding "!!" and the tests didn't have the dot, so it
works, the tests pass. But it's a very subtle difference that most
likely confuses users, it requires reading the help to find out the
details.

This is really a choice between the two options that are neither good.
At this moment I think not expanding "!!" would be slightly better than
the presence of a dot making a difference. Unless someone objects, I'm
going for the other choice.

--
Everybody lies, but it doesn't matter since nobody listens.
-- Lieberman's Law