Changes in "Search Results" window

[JuhaManninen]

I applied a patch from issue :
 https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40286
The "Search Results" window appearance changed quite much. Please test with development branch "main" and comment.

[Martin_fr]

The bold highlight of the search term was much better.

I didn't note the change on the images of the issue. The color there is (as I inspected now) a very dark blue, always unnoticeable. And I didn't reflect that the HL is missing.
But on my Win10 machine it is a light blue. Really bad.

----

The path needs to be in front of the filename (is it used to be).

The font toggle box does remember it's state, but if I do another search, even if it is on, the path is not there.

Also, it currently needs to be enabled for every result. I do need an option that makes it on for all (including future) searches.

-- EDIT:
Path is there / my fault

[n7800]

Please, before commenting, read the discussion on the bug tracker - there are answers to many questions.

[JuhaManninen]

The bold highlight of the search term was much better.

I must agree with Martin. Logically a matching text should pop up visually somehow. Now with a light color it actually gets diminished. Making the light colored text bold makes it pop up again, but not too much.
I would like to have opinions from other people, too, before changing it.

My ideas for the future: Such things for the search results should be configurable. It means :

• Font attributes for a matching text.
• Showing filenames with full path, relative path or no path.
• Other visual properties...

Now the new button for removing the relative path seems odd. A relative path of a matching file is desired by most people.
There really should be a button to show the options for "Search Results" pane in the global options window.

The "Find in Files" feature is very important in my personal work flow.
I use the editor's code completion, jumping to definitions with Ctrl-Click, bookmarks and then "Find in Files".
The "Search Results" should be as configurable as the editor and the Codetools features.
This was for future development. The patch in issue #40286 was applied and (with minor changes) will be part of the new major release that will be forked soon.

[Martin_fr]

My ideas for the future: Such things for the search results should be configurable. It means :

My whish list.

- Display found lines with the same highlight as the source editor (Needs SynEdit refactored, so the painter can be used)
  (This then allows fully customizable attributes for the "found term"
-- Ability to select a different Highlight scheme for that. So one could configure a subset of HL.
-- Toggle user defined markup on/off in search results

- Display context: E.g. the previous function header/name for each found line (only once, if several entries in the same function)

- change/toggle tree to have one level for each folder

Code: Text  [Select][+][-]

1.    + components
2.          file
3.          file
4.          + codetools
5.                 file
6.          + synedit
7.                 file

- Allow drag/drop reorder of tabs.
- Allow drag/drop merging of tabs.
   E.g. ctrl or shift drag a tab onto another, and have both search result in that drag

Code: Text  [Select][+][-]

1.    + "search term 1"
2.          + path
3.              file
4.          + path
5.              file
6.    + "search term 2"
7.          + path
8.              file

   Or (optional) merging the 2 results, sorting them into a single list.


- Quick refresh button / repeat search -> but skipping the dialog (and don't change its current remembered values)
  (actually, not needed, if the next item is done)

- Automatic tracking of changes in editor / adjust line numbers
   Indicate if a line has been edited since it was found

[BrunoK]

Moving the close current tab to the right is nice.

Boldening the search term in the found window would be a good idea. Anyway in  the standard (I think) color scheme with the selected highlight color, it looks OK.

The main problem is not seeing the full path to the found items. It was visible in 2.2.2 but with the new presentation and searching in different folder trees (maybe searching in the 3.2.2 and then trunk fpc, or the laz 2.2.2 and trunk laz folder) in separate searches, it disappears.
With the new proposed solution, missing the full path to files mean it is not possible to differentiate what full path root directory is concerned.
Example : search for FindInFilesDlg in your 2.2.x folder and then in your 2.3 (trunk) folder. One gets no clue of where the search string was found. Annoying.

With the new code, backup folder becomes quite visible. It is an improvement to help prevent  loading a backup.

[JuhaManninen]

Boldening the search term in the found window would be a good idea. Anyway in  the standard (I think) color scheme with the selected highlight color, it looks OK.

Depends on OS, widgetset, desktop system (KDE here) and maybe other variables.

The main problem is not seeing the full path to the found items. It was visible in 2.2.2 but with the new presentation and searching in different folder trees (maybe searching in the 3.2.2 and then trunk fpc, or the laz 2.2.2 and trunk laz folder) in separate searches, it disappears.
With the new proposed solution, missing the full path to files mean it is not possible to differentiate what full path root directory is concerned.
Example : search for FindInFilesDlg in your 2.2.x folder and then in your 2.3 (trunk) folder. One gets no clue of where the search string was found. Annoying.

That is very true!
I admit I tested only searching Lazarus trunk directories. Then a relative path is nice and does not duplicate information.
The button that now strips out paths completely, should show the full path. I wonder more and more what is the use case for n7800 to hide paths completely. When is it beneficial? It makes sense only when all files reside in one directory, but then a relative path gives the same result.
Maybe n7800 could comment on this.
Anyway it must be changed to enable full path. Maybe relative path could still be the default because the most common use case is to search from one project and version.

[n7800]

Now the new button for removing the relative path seems odd.

I believe that options should be located as close as possible to the point of use. Now you can switch the display of paths with this button or by pressing [Ctrl+P] which is very convenient. I would not want to go into the IDE options for this (even if they can be called through the context menu). One tab needs paths, the other doesn't. This is not a global option. Although, you can set the default for it.

By the way, the tab control buttons really look very strange to me. As many as five buttons to close tabs! Are they really needed there? The tab is easily closed by pressing the middle mouse button or [Ctrl+F4]. This window can have many tabs, but not so much that you need a whole panel with buttons to close them. Although, of course, they do not interfere with anyone.

[n7800]

- Display found lines with the same highlight as the source editor (Needs SynEdit refactored, so the painter can be used)
  (This then allows fully customizable attributes for the "found term"

If that means using a monospaced font, then I tried it and didn't like it. In addition, search results with the current font look more compact, which is good. After all, this is only an overview function - you will still view the code in the editor.

[n7800]

- Quick refresh button / repeat search -> but skipping the dialog (and don't change its current remembered values)

I even know the hotkey for this function - [F5]. Maybe I'll add it one of these days.

Although for now you can press [Ctrl + N] (to open a search dialog with the same conditions) and immediately [Enter]. However, the results will open in a new tab, and not in the same one.

[n7800]

- Allow drag/drop merging of tabs.
  E.g. ctrl or shift drag a tab onto another, and have both search result in that drag

I think that for such purposes, you just need to improve the search box itself, and add the ability to search in the list of folders to it. This is actually easy to add.

[n7800]

The main problem is not seeing the full path to the found items.

Looks like we'll need another "absolute/relative path" switcher...

Maybe n7800 could comment on this.

I already answered on the bugtracker:

1) Usually units have a unique name, often well recognizable.
For example, it is already clear that the files "desktop_options.pas" and "editor_color_options.pas" are options window frames. I know they are in "lazarus\ide\frames".
"findinfilesdlg.pas" and "procedurelist.pas" are the windows that are in "lazarus\ide".
"stdctrls.pp", "grids.pas" and "colorbox.pas" - in "lazarus\lcl"...

2) In this case, all names are aligned, they appear as if in a list. Especially useful if the names are composed of "parts":
lcl\customdrawn_common.pas
lcl\customdrawn_mac.pas
lcl\customdrawndrawers.pas
lcl\interfaces\customdrawn\customdrawnthemes.pas
lcl\interfaces\customdrawn\customdrawnwinapi_win.inc
lcl\interfaces\customdrawn\customdrawnsforms_x11.inc
lcl\interfaces\customdrawn\customdrawn_winextra.pas

I often use such names in my projects. In this case, the units are in the appropriate folders. The names seem to "duplicate" the path.

3) In addition, the user can search in any folders (maybe not even in the project folder, in documents, some xml-files), and the nesting can be very large.

4) Sometimes paths are simply not required. When you're looking for places where a variable is used, you still need to open the file wherever it is. And it doesn't even matter the name of the file. And after opening the file, the path can be seen in the status bar of the code editor.

10) After all, it's just an option that's disabled by default. If you don't need this feature, just don't use it.

I am not saying that the path is not needed at all. I also use it often. But sometimes it even gets in the way.

[n7800]

Example : search for FindInFilesDlg in your 2.2.x folder and then in your 2.3 (trunk) folder. One gets no clue of where the search string was found. Annoying.

We can add another checkbox that will display not only the search text but also the path in the tab caption.

By the way, for now, you can click on "New search with the same criteria" (Ctrl+N) to see the terms of this search. Previously, only text was substituted there, but now all conditions are indicated there.
Or you can click on any search result - it will open in the code editor, in the status bar of which you will see the full path.

[n7800]

Personally, I most of all want to delete unnecessary results. To do this, I will also improve the filter - it will be possible to filter not only text, but also files and paths. But I'll deal with that a bit later.

[JuhaManninen]

By the way, the tab control buttons really look very strange to me. As many as five buttons to close tabs! Are they really needed there? The tab is easily closed by pressing the middle mouse button or [Ctrl+F4]. This window can have many tabs, but not so much that you need a whole panel with buttons to close them. Although, of course, they do not interfere with anyone.

They are from December 2019 by BrunoK.
I admit I don't personally use them but they don't bother me either.

- Quick refresh button / repeat search -> but skipping the dialog (and don't change its current remembered values)

I even know the hotkey for this function - [F5]. Maybe I'll add it one of these days.

There is a ToolButton "RefreshButton" for the purpose but it has Visible=False and a ToDo note. Yes, it should be implemented.

We can add another checkbox that will display not only the search text but also the path in the tab caption.

What if the path is long?
An ideal solution would be a 3-state RadioButton but it does not fit here.
Somehow the full path must be supported as there are use cases that require it.
An easy solution for now would be to switch between full path and relative path with the current button, instead of between relative path and no path. Then the "no path" option would be left out.
@n7800, will you look at this issue?