PreviousNextTracker indexSee it online !

(196/212) 505 - Keyboard shortcuts to go to the beginning/end of the fold

prev/next - exist
beginning/end - also should be

Submitted bdimych - 2016-03-02 04:43:21.771000 Assigned
Priority 5 Labels
Status open Group none
Resolution None

Comments

2017-10-31 11:21:14.463000
ngc

Here you have 2 macros to achieve that:

GoToBeginning of fold

os=textArea.getSelection();
om=textArea.isMultipleSelectionEnabled();
if (om) {
textArea.toggleMultipleSelectionEnabled();
}
textArea.selectFold();
textArea.goToPrevCharacter(false);
if (om) {
textArea.toggleMultipleSelectionEnabled();
}
textArea.setSelection(os);

GoToEnd of fold

os=textArea.getSelection();
om=textArea.isMultipleSelectionEnabled();
if (om) {
textArea.toggleMultipleSelectionEnabled();
}
textArea.selectFold();
textArea.goToNextCharacter(false);
if (om) {
textArea.toggleMultipleSelectionEnabled();
}
textArea.setSelection(os);

2017-10-31 11:21:54.181000
ngc

- **status**: open --> closed-fixed
- **assigned_to**: Skeeve

2017-11-02 23:31:12.101000
tsourick

Since folding features are part of the core this one should also be implemented in there, I suppose.

2017-11-02 23:35:25.122000
tsourick

And the macro looks much like a workaround. With all this in mind, I would not close the ticket as fixed.

2017-11-02 23:58:47.055000
ngc

You have more experience with jEdit I assume, but I see that the feature request is older than a year and no one took care.

I also do not think that it's a good idea to put features into the core which can

1. easily be achieved with a small macro
2. seem of not too much interest. After all: Folding is in for more than 10 years and only last yoear one person asked.

I do not think the macros are workarounds. They use the existing fold-related functionality to select a fold. So no need to reinvent how to find the fold's start and end.

The part about the selection is just there because selectFold will remove all current selections.

2017-11-04 01:07:26.818000
tsourick

I don't think it is a matter of experience with jEdit.

The macro you provided looks like a hack/workaround. Even if you open the source of other folding related actions you will see totally different approach. I am not against the macro, i'm just saying that ticket should not be closed as fixed until a proper solution is given.

There are a lot of tickets since years ago, I can not say should we skip unresolved ones just because they're old or not. But having them open there is a chance that someone can make a new useful thing. Is there another reason why they are still open for so long?

And again, folding features are part of the core and having it all in one place is a good idea, similar tools in the same toolbox, under Folding menu. Think of new users also, if they ever come to jEdit. Spreading of similar tools around also complicates the support increasing a mess. Just a common sence.

Bottom line is
- macro is ok
- ticket unresolved
- those who need the feature now can use macro as workaround until it is implemented by someone in core and put under Folding menu

2017-11-06 07:45:03.461000
ngc

- **status**: closed-fixed --> open
- **assigned_to**: Skeeve --> Roman Tsourick

2017-11-07 00:15:31.858000
tsourick

- **assigned_to**: Roman Tsourick --> nobody