Missing line numbers in Quick Search viewer

[RedeemerSK]

• I verified latest Integration Build of Eclipse SDK doesn't provide the feature.

Suggestion

From a fresh installation and clean workspace: no setup steps are necessary

I reach state showing found occurrence in Quick Search dialog with

• pressing quick search key binding (CTRL+ALT+SHIFT+L)
• typing in some text that occurs in any file in workspace

And would like to be able to see line numbers and selected result/occurrence highlighted amongst other nearby occurrences in the viewer.

Concern

If searched text/pattern occurs multiple times near each other in a file, it's hard to tell which occurrence the viewer is currently showing / "focused on". Example:

It's hard to tell that viewer is showing last occurrence on line 106.

[RedeemerSK]

I would be willing to implement this enhancement if it would be accepted.

I currently have prototype working:

It's inspired by

• org.eclipse.compare.contentmergeviewer.TextMergeViewer.createPart(Composite)
• org.eclipse.compare.internal.MergeSourceViewer.MergeSourceViewer(SourceViewer, ResourceBundle, ICompareContainer)

therefore it uses SourceViewer for result viewer and shows line numbers vertical ruller + highlights current line (both if enabled by preferences) and for now it does not support any semantic highlighting for content. For comparison, current implementation of quick search dialog is using simple StyledText widget for viewer.

[humphreygao]

any possibility to have syntax color？

[RedeemerSK]

any possibility to have syntax color？

I definitely plan to look into that and I'm quite sure it's doable.

But I can imagine it's much harder to implement since even without investigating I'm quite sure it would require plugins/features (eg. Java development tools or Wild Web Developer) to be able to plug in custom viewer implementations doing their specific syntax coloring / semantic highlighting for specific content type (eg. java, xml, json ...).

So I think it makes sense to have 1st implementation delivered without syntax coloring asap and then build on that in later releases.

EDIT: but yeah, having syntax coloring is my end goal.

[merks]

I recall @iloveeclipse doing some fairly recent cool stuff to make syntax highlighting work in the compare editor. Maybe he has some pointers/suggestions.

[iloveeclipse]

It just happened to me to play with textmate & generic editor, but I'm not much of the help here. See #1786 and linked tickets / related code for further pointers.

Just an idea that if one would use generic editor contribution here (similar the one used in compare editor) and combine it with the content type / file name known, it should be possible to have full syntax support for many file types.

[RedeemerSK]

Sorry for long silence, life & laziness is a dangerous mix.

At first I would like to contribute version with no syntax coloring, since that can be made into PR very quickly. Afterwards I would look into using generic editor for syntax coloring and contribute that later if/once I can make it to work.
Eventually I want to also look into what would it take to use JDT default java editor's viewer since its java syntax highlighting is superior to generic editor (textmate) it seems.

Current version:

• current line highlighting same as in editor - based on caret position, disappears on multi-line selection
• additionally target line is always highlighted regardless of where the caret is located
• scrolls horizontally, if necessary, to reveal 1st occurrence of the searched text on the target line
• always shows line numbers vertical ruler (ignores preferences to display/hide it for editors)

Will create PR in upcoming days unless there will be feedback requiring more work.

[RedeemerSK]

PR: #2644
@HannesWell @fedejeanne would you mind taking a look at another PR with changes to QuickSearchDialog ? Thanks in advance

[fedejeanne]

PR: #2644 @HannesWell @fedejeanne would you mind taking a look at another PR with changes to QuickSearchDialog ? Thanks in advance

Sorry, I'm working on other stuff right now. But it seems you have a reviewer already :-)

[RedeemerSK]

Just an idea that if one would use generic editor contribution here (similar the one used in compare editor) and combine it with the content type / file name known, it should be possible to have full syntax support for many file types.

Turned out editor contribution specifically was not a good way to go. Editors are quite heavy and do many things that are not necessary for Quick Search use-case and are also implemented around IEditorPart / IEditorInput / IWorkbench abstractions and 'bending them' for use in Quick Search dialog would be unreasonable I think. But as you suggested by mentioning compare editor, for which there is unique extension point, I realized extension point is a way to go and went on and defined new one for source viewers used as presenters of text files & search matches inside Quick Search dialog.

So this is how WIP looks like at the moment with having 3 extensions implemented: default one (org.eclipse.text.quicksearch; fallback if no better is found for file/content type), one using GenericSourceViewer (org.eclipse.ui.genericeditor) and one using JavaSourceViewer (org.eclipse.jdt.ui), both doing their respective coloring (semantic highlighting). Like with compare viewer, quick search viewer contributed by plugin is considered if linked editor is registered to work with file / content type.

Like with 1st version, for which PR was already created, target match line is made to stand out with fixed 'current line' highlighting (regardless where caret is positioned).

Additionally I added highlighting of the target match line number in line numbers vertical ruler - like for example when QuickDiff is showing modified line. Other alternative is to show search result arrow (icon) annotation but that requires another vertical ruler to place the annotation into, thing I evaluated as wasted screen space just for single arrow.

I think I need to add some way to switch used source viewer used to present target match if the user wants something different than what was chosen by default. Something akin to compare editor, but maybe via some 'floating' button (eg. top right) to not have to dedicate some dialog area to the switcher combobox.

Any feedback is welcomed.

[RedeemerSK]

This is how it would look like with viewers selection menu.

In here located at bottom-right corner and icon used is one I found & consider as candidate in eclipse.platform.images.

Or at the top-right corner with other icon.

Now that I see how it looks like with overlay icon for selection menu, I'm not completely sold on that idea. Maybe it's just the icon/button background color.

Any suggestions ?

[BeckerWdf]

Just a remark from UX point of view. I am unsure about adding a "floating" icon on top of the source viewer. This is something that I didn't see up to now in the Eclipse IDE. What bout adding it into the already existing "..." menu? Or what about adding it between the list and the source view?