[Lazarus] automatic code unfolding, on edit (inside fold)

[Martin Friebe]

Mattias Gaertner wrote:
> On Thu, 31 Jul 2008 14:21:03 +0100
> Martin Friebe <lazarus at mfriebe.de> wrote:
>
>   
>> While working on http://bugs.freepascal.org/view.php?id=7773, there a
>> a few behavioural decisions:.
>>
>> The basic of the bug is (| = cursor):
>> [ some comment is not needed,, but refers to later, to point out
>> special situations ]
>>  
>>   [+]  If a=b then begin {some comment} |
>>          //Line after  end of above block
>>
>> The code is folded as above. If you press return a new line is
>> inserted. It is inserted into the block, not after the block.
>> Currently this leads to a (partial) unfold of the block.
>>
>> Similar issues can arise if:
>> - a multi line text is inserted from clipboard
>> - a multi line pattern replace occurs inside a fold
>> - text is inserted elsewhere in a block (using other bugs, such as 
>> move-cursor-word-left does jump into folds)
>>
>> The fact that the code unfolds at all, seems more result of a bug,
>> than intention (so that can be seen either way) => The same code
>> unfolds are valid folded block, if you insert a new "begin" in the
>> text above it.
>>
>> ----
>> In any case, I need to define a new valid behaviour. May intentions 
>> would be:
>> - inserting a new "begin" above a valid, unchanged folded block, will 
>> keep this block folded
>> - doing changes in the middle of a folded block, will keep it folded.
>>   This should only occur with "replace-all".
>>     
>
> And many codetools. For example rename identifier or class completion.
>   
True, I will end up more with something like: If the caret ends up
inside the fold => unfold it.

However there are (may be?) operations which may temporarily point the
caret inside the fold, and then leave it again.

I will fix this in 2 steps.
1a) Make sure that if an unfold occurs, it is always complete, and
redraws all relevant parts.
1b) Fix a good deal of the "need unfold - caret inside fold" situations
  for now, I am *not* going to trigger this inside the SetCarretXY,
because I first need to make sure that doesn't break anything else.
2) Fix the remaining "need to open fold" issues. this will unfortunately
be deferred

1b and 2 are not the original bug, and while 1b can be archived with
little extra work; 2 may take a goo deal more work.

>   
>>   Any other operation needs to be fixed, and prevented to go into a 
>> folded block. Or additional behaviour needs/can be defined later
>>     
>
> Can you explain how?
>   
Example: word-left, or word-right can currently find words inside the
fold. I am fixing that.
>   
>>    ( I am thinking of a temporarily (maybe even intended partial)
>> unfold during search/replace inside a folded block. => this would
>> automatically fold again. However this is not part of the current
>> work-item)
>> - There should be no other "in folded block changes" So there is no
>> need to provide "open-fold" behaviour for them (As long as the fold
>> either opens correct (completely) or does not open at all)
>>
>> - ===> The only operation that will require to open a folded block is
>> a return at the end or in the middle of the fold-start line
>> (fcCollapsed / the line with the begin).
>>  Alternatively this could insert  the new line after the block => I 
>> don't think that would be intuitive, especially if the cursor was 
>> between the "begin" and {comment} => then the comment would have to
>> stay in the block, and an unfold was needed.
>>     
>
> True.
>
>  
>   
>>  If the cursor was in front of the begin, the fold could be
>> preserved. But I do not know if I will do that now. (since a/many new
>> line(s) could also be inserted from clipboard or replace.
>>
>> I may base the condition as follow. If a line is inserted exclty
>> below the cfCollapsed line, then an unfold occurs.
>>     
>
> Mattias
> _______________________________________________
> Lazarus mailing list
> Lazarus at lazarus.freepascal.org
> http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
>