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".
Any other operation needs to be fixed, and prevented to go into a folded block. Or additional behaviour needs/can be defined later ( 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.

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.

Regards
Martin

And many codetools. For example rename identifier or class completion.

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?

True.

Mattias

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.

Example: word-left, or word-right can currently find words inside the fold. I am fixing that.