That is reverting the change made in [4f6cd7] . The document's fold levels could potentially not match the contraction state if the application makes a mistake in responding to fold level changes. Using contraction state guarantees that there will be no contracted lines and acts as a reset to safety. If performance was important then contraction state could offer a set-all-expanded (or ...range...) since it has access to the underlying RunStyles and could just reset it.
I think delta could be deleted, and change the code to returns changed, means visibility of some line are changed, technically it's different from delta (changed screen line count).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The change to SetVisible() can be used to optimize Editor::ExpandLine():
Maybe it's better to open a new ticket to discuss improvements for code folding.
That is better than the one after. Recursive functions start as more complex and adding an optional pointer argument makes it worse. The question for the previous version is whether there is sufficient benefit to batch up SetVisible calls. The data structure manipulation will often take little time compared to the GUI-level costs of performing redraws and similar so I want to see that the added code will produce a user-noticeable improvement. Its always worthwhile measuring before / after performance - sometimes the results don't match expectations.
There seems to be difference in attitudes between us here. You want even small performance improvements, perhaps because they have potential benefits. I'm just a grumbly grey-beard who has seen too many projects exceed their complexity budget and become unmaintainable.
Low level optimizations can make it more difficult to discover and apply higher-level optimizations. The fold structure is an implicit tree that gets partially rediscovered then discarded on each action. Perhaps the tree should be made concrete and persistent albeit incomplete.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While the current behaviour of FoldAll(FoldAction::Contract) is good, since applications want to fold every header, there could be a FoldAction::ContractRecursive to do that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
for FoldAll, what about adding second parameter to tell whether to contract all headers (default is false to keep current behavior), so it works also for FoldAction::Toggle.
fun void FoldAll=2662(FoldAction action, bool allLevel)
Last edit: Zufu Liu 2022-07-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First part of the changes (ExpandAll, ExpandLine and SetVisible).
Not intended to add ExpandTopLevel, implement this is complex, rough equivalent to call FoldLine() on all top level header.
I just want contract recursive works for FoldAction::Contract and FoldAction::Toggle, how about change the second parameter to bool contractRecursive or bool contractAll? it's easy to handle than treat FoldAction::ContractRecursive as a flag.
I think expanding the scope of Toggle may be counterproductive causing more complexity in the future. The criteria it uses to determine the current state (is the first fold header expanded?) isn't great and applications may want to use something else. Majority expanded, for example. It may be better to have apps determine which state they think the folds are in (possibly with helpers in Scintilla) then call the action they want.
it's easy to handle than treat FoldAction::ContractRecursive as a flag.
Bundling up the options, either inside an enum or as a struct, makes it easier to pass them around. Treating enums as flags isn't that bad. bool parameters have their own problems.
Though it's invalid Python, however I thing toggle folds should still works.
A simple fix:
FoldLeveltopLevel=FoldLevel::NumberMask;for(;line<maxLine;line++){if(LevelIsHeader(level)){constFoldLevellevelLine=LevelNumberPart(level);if(topLevel>=levelLine){topLevel=levelLine;// top level fold without parentconstSci::LinelineMaxSubord=pdoc->GetLastChild(line,level);
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Acting as intended.
Simple change to make
Editor::FoldAll()working as expected, very faster for both contracting and expanding.merged as following:
Last edit: Zufu Liu 2022-07-04
That is reverting the change made in [4f6cd7] . The document's fold levels could potentially not match the contraction state if the application makes a mistake in responding to fold level changes. Using contraction state guarantees that there will be no contracted lines and acts as a reset to safety. If performance was important then contraction state could offer a set-all-expanded (or ...range...) since it has access to the underlying RunStyles and could just reset it.
Related
Commit: [4f6cd7]
OK, added
ExpandAll().ContractionState<LINE>::SetVisible()is also changed to useFillRange(), which makes code folding even faster.Why is the
changedvariable needed inContractionState<LINE>::SetVisible? Isn't that equivalent todelta != 0?I think
deltacould be deleted, and change the code to returnschanged, means visibility of some line are changed, technically it's different fromdelta(changed screen line count).This may have returned the delta in an early version. Its fine to just track if there have been any changes.
The change to
SetVisible()can be used to optimizeEditor::ExpandLine():Maybe it's better to open a new ticket to discuss improvements for code folding.
final version of
Editor::ExpandLine():The added complexity doesn't seem worth it.
What about previous version (the one without
parentLine) ?That is better than the one after. Recursive functions start as more complex and adding an optional pointer argument makes it worse. The question for the previous version is whether there is sufficient benefit to batch up
SetVisiblecalls. The data structure manipulation will often take little time compared to the GUI-level costs of performing redraws and similar so I want to see that the added code will produce a user-noticeable improvement. Its always worthwhile measuring before / after performance - sometimes the results don't match expectations.There seems to be difference in attitudes between us here. You want even small performance improvements, perhaps because they have potential benefits. I'm just a grumbly grey-beard who has seen too many projects exceed their complexity budget and become unmaintainable.
Low level optimizations can make it more difficult to discover and apply higher-level optimizations. The fold structure is an implicit tree that gets partially rediscovered then discarded on each action. Perhaps the tree should be made concrete and persistent albeit incomplete.
Since
SetExpandedreturns abool,ExpandAllshould as well.There should be a test for
ExpandAll:While the current behaviour of
FoldAll(FoldAction::Contract)is good, since applications want to fold every header, there could be aFoldAction::ContractRecursiveto do that.for
FoldAll, what about adding second parameter to tell whether to contract all headers (default is false to keep current behavior), so it works also forFoldAction::Toggle.Last edit: Zufu Liu 2022-07-19
Extending this to
Togglemakes it more complex to evolve. Will there be 4 toggle command variants if anExpandTopLevelwas added?First part of the changes (
ExpandAll,ExpandLineandSetVisible).Not intended to add
ExpandTopLevel, implement this is complex, rough equivalent to callFoldLine()on all top level header.I just want contract recursive works for
FoldAction::ContractandFoldAction::Toggle, how about change the second parameter tobool contractRecursiveorbool contractAll? it's easy to handle than treatFoldAction::ContractRecursiveas a flag.Last edit: Zufu Liu 2022-07-19
Minor change for
SetVisible, changedstatic_cast<char>(isVisible)in above patch to(isVisible ? 1 : 0).The condition
GetVisible(line) != isVisiblecan be simplified to callvisible->ValueAt(static_cast<LINE>(line))directly (not in the patch).Last edit: Zufu Liu 2022-07-20
Committed as [fe4bf2].
I think expanding the scope of
Togglemay be counterproductive causing more complexity in the future. The criteria it uses to determine the current state (is the first fold header expanded?) isn't great and applications may want to use something else. Majority expanded, for example. It may be better to have apps determine which state they think the folds are in (possibly with helpers in Scintilla) then call the action they want.Bundling up the options, either inside an enum or as a struct, makes it easier to pass them around. Treating enums as flags isn't that bad.
boolparameters have their own problems.Related
Commit: [fe4bf2]
Implement
FoldAction::ContractRecursiveas a flag.SciTEBase::FoldAll()can be changed toFoldAction::ContractAllseems better thanFoldAction::ContractRecursiveas there is no recursive.for contacting,
FoldLevel::Base == LevelNumberPart(level)will fails for top level fold without parent in Python like indentation based folding, e.g.for toggling,
Discover current statemay fails for fold without child.ContractAllsounds redundant to aFoldAllfunction. PerhapsContractEachorContractEveryHeader.Indenting the top level is unlikely for Python or similar languages.
Headers should have children.
The actual difference is that
Contract...contracts every level.Though it's invalid Python, however I thing toggle folds should still works.
A simple fix: