Shortcomings of "Mark occurrences"

[ghost]

Description

Please see the attached video.

Bug 1 (at 00′17″ in the video): All occurrences of the search term "555" are marked, although "Mark occurrences" has been disabled.

Bug 2 (at 00′26″ in the video): After typing "AAA" (so that the first occurrence of "555" gets replaced by "AAA"), the space after "AAA" will be marked.

Shortcoming (at 00′29″ in the video): It is not possible to make the orange marks go away (e.g. by moving the cursor) when they are no longer needed/wanted.

Demo.webm

Java version Runtime version: 23-internal VM name: OpenJDK 64-Bit Server VM VM version: 23-internal-ahadas-0081ac197a656cdc0d88d5a5e2a0f399ee023654 VM vendor: Oracle Corporation

Additional context I'm a muCommander user and have originally reported this issue here: https://github.com/mucommander/mucommander/issues/1208

FYI @pskowronek

Operating System type and version: Name: Mac OS X Version: 14.5 Architecture: aarch64

[pskowronek]

ad Bug 2, can be reproduced in FindAndReplaceDemo demo app:

[pskowronek]

Ad bug 1 - as discussed here is not a bug per se (imho). However, how should RSyntaxTextArea behave when RSyntaxTextArea#setMarkAllOnOccurrenceSearches is set to false, what it does exactly? While checking in FindAndReplaceDemo I see that only context.setMarkAll(false); can disable marking of search occurrences.

[bobbylight]

Yep, like you mentioned in the thread you linked to, RSTA's behavior is derived from Eclipse and IntelliJ (the IDEs I used to use, and use today) :)

I appreciate some of these behaviors are unexpected, and would like to support different behaviors, as long as the tradeoffs around code complexity/support don't get too large.

To recap, RSTA has two concepts being discussed:

1. "mark occurrences" - this currently renders a different background for all instances of the same lexical token (per programming language) in the editor. It requires no selection (any selected text and nothing is marked), and occurs after a timer to debounce this operation. The latter was done for better support of large documents, but the debounce timer can be set to 0 if you want this to happen immediately. However, there's not currently a way for it to run on e.g. what's selected, vs. per token (as determined by the current TokenMaker).
2. "mark all" - this is a property of searches and is on the SearchContext. This marks all instances of the searched-for text (regardless of whether it's the same token) with a specific background/highlight color. I think I'm mimicking Eclipse's behavior, at least its behavior from 10+ years ago, currently :) It appears IJ behaves the same way, but uses a more subtle background color (which would be configurable with RSTA). Note the RSTAUI project provides find and replace dialogs that allow the user to toggle whether to have "mark all" enabled.

I think there are a few items to consider here:

1. Per your question:

However, how should RSyntaxTextArea behave when RSyntaxTextArea#setMarkAllOnOccurrenceSearches is set to false, what it does exactly?

That option is a little confusingly-named, but it only is used when the user uses Ctrl+K / Ctrl+Shit+K (or Cmd+K / Cmd+Shift+K), which is a shortcut to search for the current selection without any Find/Replace UI.

2. "Bug 1" is not a bug as it's "Mark All" being shown in the video at that timestamp
3. Agreed that "bug 2" is clearly aa bug. We do some shenanigans to get Swing Highlights to behave a little better, but this is a remaining bug to tackle
4. The "shortcoming" of the orange Mark All highlights not being removaable - I agree here. I like that they stick around even if you move the caret (though I know some folks don't agree on that point) but it's also nice to have a way to clear them. In the RSTAUI project's modals. What would a good behavior here be? a. Hitting Escape in the editor clears them? b. Automatically hiding them if the search UI is hidden/closed? (I imagine this would be up to the application to do via a call to RTextArea#clearMarkAllHighlights() since we don't provide the modals to use OOTB in the RSyntaxTextArea project) c. Something else?
5. Should the "mark occurrences" behavior be modified somehow to be more "modern"? Some ideas: a. Still work even if the user selects text. IJ does this, but always just highlights the token under the selection start. Alternatively, we could not be token-based, but just mark all occurrences of the selection, no matter what it is, similar to VS Code. IMO this behavior only makes sense if it isn't debounced, since not seeing it immediately is weird. b. Actually, VS Code also seems to do RSTA's "mark occurrences" (debounced highlight of all instances of the token) but only if there's no selection. So it's just a different implementation of "mark occurrences" behavior when there's a selection

Any other thoughts?

[pskowronek]

Thanks for detailed analysis!

ad bug 1 - is it more the consequence of misunderstanding and how muC name things. I can modify muC to have another option for enabling the marking of "all instances of the same lexical token" - or I could make them under one setting in muC under "mark occurrences" (to be discussed in muC). The problem is that I don't know how to control (enable/disable) "all instances of the same lexical token" in RSTA. Any advise from your side?

ad bug 2 - it would be nice to be addressed.

4. The "shortcoming" of the orange Mark All highlights not being removaable - I agree here. I like that they stick around even if you move the caret (though I know some folks don't agree on that point) but it's also nice to have a way to clear them. In the RSTAUI project's modals. What would a good behavior here be? a. Hitting Escape in the editor clears them? b. Automatically hiding them if the search UI is hidden/closed? (I imagine this would be up to the application to do via a call to RTextArea#clearMarkAllHighlights() since we don't provide the modals to use OOTB in the RSyntaxTextArea project) c. Something else?

From muC perspective:

• ad a) is problematic - Escape closes the viewer/editor window in muC.
• ad b) also problematic - it complicates things in UX imho
• ad c) a configurable option what to do when caret is moved?

5. Should the "mark occurrences" behavior be modified somehow to be more "modern"? Some ideas:

For me it is still "modern" - it is how IJ works. I don't have much experience with VS Code. @Andreas0602 ?

[ghost]

5. Should the "mark occurrences" behavior be modified somehow to be more "modern"? Some ideas:

For me it is still "modern" - it is how IJ works. I don't have much experience with VS Code. @Andreas0602 ?

In my opinion, it would be much more important to first fix the bugs and shortcomings I reported, rather than making "mark occurrences" more "modern".

After that, it would be nice (but not top priority) to make "mark occurrences" available also for txt files, just like in Notepad++.