Fold-related bug and pointer to fix

[Efraim Yawitz]

I had the following problem and I think it is a bug in some fold-related code:

I was trying to use the NarrowRegion plugin to do diffs between two functions in the same file by creating narrowed buffers for each function and calling :diffthis on them.  When I tried to do this using folds, i.e. :.,+2NarrowRegion to create a buffer for a folded-up function which looked like this:

int FuncName() {

.....folded........
}

I got everything but the final brace in the narrowed buffer.  Eventually I discovered that this has nothing to do with NarrowRegion, but just a yank such as:

:.,+2y

over a fold gives only the folded lines but not the line after the fold.

A normal command of y2j works just fine and gets the line after the fold.  Similarly, in a file where multiple folds are right after one another (a nice example is in fold.c of the vim code), a normal command of y2j yanks two folds, but :.,+2y yanks only one.

A little debugging led me to believe that the problem is in this code in ex_docmd.c, lines 2548-2549 in the latest git code:

    /* Put the first line at the start of a closed fold, put the last line
     * at the end of a closed fold. */
    (void)hasFolding(ea.line1, &ea.line1, NULL);
    (void)hasFolding(ea.line2, NULL, &ea.line2);

This seems to use the side effect of the hasFolding call to set the value of ea.line2 which is passed to the actual yank command.

I hope this will be helpful to fix the bug.

Ephraim

[Ben Fritz]

On Wednesday, November 23, 2016 at 4:39:24 AM UTC-6, Efraim Yawitz wrote:
> I had the following problem and I think it is a bug in some fold-related code:
>
> I was trying to use the NarrowRegion plugin to do diffs between two functions in the same file by creating narrowed buffers for each function and calling :diffthis on them.  When I tried to do this using folds, i.e. :.,+2NarrowRegion to create a buffer for a folded-up function which looked like this:
>
> int FuncName() {
> .....folded........
> }
>
> I got everything but the final brace in the narrowed buffer.  Eventually I discovered that this has nothing to do with NarrowRegion, but just a yank such as:
>
> :.,+2y
>
> over a fold gives only the folded lines but not the line after the fold.
>
> A normal command of y2j works just fine and gets the line after the fold. 

I can confirm this looks like a bug, seeing the same behavior in 64-bit Vim 8.0.95 on Windows 7.

It gets worse actually. I tried several yanks from code that looks like this in Vim:

else
{ ---3 lines folded--- }
#endif

if ( ---2 lines folded--- )

With the cursor on the top "else" line:

:.,+2y yanks only the "else" and the folded lines beneath, when I expect to also get the #endif

:.,+3y yanks the exact same thing (omitting the #endif *and* the empty line)

:.,+4y finally includes the #endif (with nothing after it) but I expected it to yank everything from "else" to the content of the second folded section.

The :d command acts in the same way.

It appears something is wrong with handling of folded lines in the ranges specified for ex commands.

Forwarding to vim_dev as this appears to be a bug.

[Efraim Yawitz]

Thanks.  As I wrote before, the handling of folds in do_one_cmd just has one call to hasFolding() for the end of the fold while in cursor_down() in edit.c, there is the following code which seems to take care of all folds:

#ifdef FEAT_FOLDING
    if (hasAnyFolding(curwin))
    {
        linenr_T    last;

        /* count each sequence of folded lines as one logical line */
        while (n--)
        {
        if (hasFolding(lnum, NULL, &last))
            lnum = last + 1;
        else
            ++lnum;
        if (lnum >= curbuf->b_ml.ml_line_count)
            break;
        }
        if (lnum > curbuf->b_ml.ml_line_count)
        lnum = curbuf->b_ml.ml_line_count;
    }
    else
#endif
 

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Efraim Yawitz]

Has any fix been made for this?  I'm not subscribed to vim_dev, and there are a lot of messages to look through in the archives.

Thanks,

Ephraim

On Tue, Nov 29, 2016 at 7:02 PM, Ben Fritz <fritzo...@gmail.com> wrote:

[Ben Fritz]

On Tuesday, December 13, 2016 at 6:37:54 AM UTC-6, Efraim Yawitz wrote:
> Has any fix been made for this?  I'm not subscribed to vim_dev, and there are a lot of messages to look through in the archives.
>
> Thanks,
>
> Ephraim
>
>

I don't see it in the todo list nor do I see it in the recent patches.

[Efraim Yawitz]

--

What happens next?  Does Bram know about it?

This is not particularly urgent, especially since there is a simple workaround to just use explicit line numbers, i.e. :.,778y instead of .,+5y, but it certainly is incorrect.

[Christian Brabandt]

Am 2016-12-14 15:35, schrieb Efraim Yawitz:
> On Wed, Dec 14, 2016 at 7:26 AM, Ben Fritz <fritzo...@gmail.com>
> wrote:
>
>> On Tuesday, December 13, 2016 at 6:37:54 AM UTC-6, Efraim Yawitz
>> wrote:
>>> Has any fix been made for this? I'm not subscribed to vim_dev,
>> and there are a lot of messages to look through in the archives.
>>>
>>> Thanks,
>>>
>>> Ephraim
>>>
>>>
>>
>> I don't see it in the todo list nor do I see it in the recent
>> patches.
>>
>> --
>
> What happens next? Does Bram know about it?
>
> This is not particularly urgent, especially since there is a simple
> workaround to just use explicit line numbers, i.e. :.,778y instead of
> .,+5y, but it certainly is incorrect.

We need a proper patch with a test to make sure, this fix works
correctly.

I might look into it and submit a patch.

Best,
Christian

[Christian Brabandt]

Bram,
attached is a patch, that changes slightly how addresses are being
calculated when on a folded line and using an relative offset.

Best,
Christian
--
Mißtrauen ist eine schlechte Rüstung, die mehr hindern als schirmen
kann.
-- George Gordon

[Bram Moolenaar]

Christian Brabandt wrote:

> Bram,
> attached is a patch, that changes slightly how addresses are being
> calculated when on a folded line and using an relative offset.

Thanks! I'm afraid the list of patches to include is getting longer,
and I don't have much time, thus it might take a while.

--
The difference between theory and practice, is that in theory, there
is no difference between theory and practice.

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

[Efraim Yawitz]

On Fri, Dec 16, 2016 at 12:58 PM, Christian Brabandt <cbl...@256bit.org> wrote:

Bram,
attached is a patch, that changes slightly how addresses are being
calculated when on a folded line and using an relative offset.

I couldn't manage to run the patch. patch -p0 gave me errors.  What am I doing wrong?