#1796 Deleting line break drops fold state of next line

Bug
open
5
2017-01-10
2015-12-23
No

Deleting the line break drops the fold state of next line as you can see in the two attached images (before.png and after.png).

Funnily enough, the fold state is preserved if the previous line is completely blank (i.e. e.g. no indentation).

The bug can be reproduced with Scite 3.6.2, though it must be Scintilla related as we're facing the same issue in our Scintilla based editor.

2 Attachments

Related

Bugs: #1896

Discussion

  • Neil Hodgson

    Neil Hodgson - 2015-12-30
    • labels: --> scintilla, folding
    • status: open --> open-accepted
     
  • Neil Hodgson

    Neil Hodgson - 2015-12-30

    This example worked OK before [bc4e97] which was discussed at Last (sub)-line in document displayed repetitively with word wrap.

    Probably should open the fold on line 6 before joining onto 5 since it isn't known at that point that 5 will become a fold header.

     

    Related

    Commit: [bc4e97]


    Last edit: Neil Hodgson 2015-12-31
    • Markus Nißl

      Markus Nißl - 2016-01-04

      Your fix always open the fold now, even if the previous line is completely blank ...

      As of Scintilla 3.6.2, we fixed the bug with a workaround: we already used a copy of SciteBase::FoldChanged() in our code and changed its start to:

      if (levelNow & SC_FOLDLEVELHEADERFLAG) {
      if (levelPrev & SC_FOLDLEVELHEADERFLAG)) {
      // Preserving the fold state when deleting the line before a collapsed block
      wEditor.Call(SCI_SETFOLDEXPANDED, line, wEditor.Call(SCI_GETLINEVISIBLE, line + 1));
      } else {
      // Adding a fold point...

      This preserves the fold state. I didn't want to submit this patch when I saw that the bug didn't pop-up when the previous line was completely empty.

      You might want to apply the above patch to both SciteBase::FoldChanged() (in Scite) and Editor::FoldChanged() (in Scintilla), so all Scintilla users that opt for SCI_SETAUTOMATICFOLD and all Scite users benefit from the fix.

       
      • Neil Hodgson

        Neil Hodgson - 2016-01-09

        The fold change notification occurs asynchronously at some later point and it is not safe to depend on it as the document may have changed in more complex ways by this point. Expanding the fold when the line is deleted should ensure that the dependent lines will not be orphaned.

         
        • Markus Nißl

          Markus Nißl - 2016-01-13

          Do you see a way how to preserve the fold state?

          I have just tested that scenario in Visual Studio (just to see how other editors behave) and it works there.

           
          • Neil Hodgson

            Neil Hodgson - 2016-01-16

            I don't see a safe way to preserve the fold.

            Visual Studio uses an approach which appears to defer changes for around 1 second. It may be fully lexing and running fold discovery over the whole document before fixing up added and removed fold points. You could try to emulate this with Scintilla but that may require taking over fold state completely instead of letting lexers perform fold discovery.

             
  • Neil Hodgson

    Neil Hodgson - 2015-12-31
    • status: open-accepted --> open-fixed
    • assigned_to: Neil Hodgson
     
  • Neil Hodgson

    Neil Hodgson - 2016-01-18
    • status: open-fixed --> closed-fixed
     
  • Neil Hodgson

    Neil Hodgson - 2017-01-10
    • status: closed-fixed --> open
     
  • Neil Hodgson

    Neil Hodgson - 2017-01-10

    Problem with this change in [#1896].

     

    Related

    Bugs: #1896


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks