compiler messages suggestion/feature request

[paweld]

... to let users enable or disable the filter simply by clicking on the buttons or labels themselves, without having to open the context menu

That's exactly how it works—you can see it in the attached GIF (I know it's a little long :-) )

[n7800]

Please create a new topic for this so your improvement can be more visible and users can leave feedback (I'll do so right away). The current thread is more about sorting messages than filtering them.

[Martin_fr]

Nice idea.

Bit of an overlap with existing output and filters... None of that is really a problem... But maybe worth some thoughts. Maybe someone has some ideas (as I don't)

Each package (each green headerline) already has Warning, Hints (probably errors too, didn't test).
But indeed there is no "grand total". though personally, I don't want to loose vertical space for that.
I guess, since you added the same filters to the context menu, the "bottom toolbar" is optional?

There are filters "filter non urgent". The difference is
- yours: filter exactly one urgency 
- the existing: filter that urgency and all below

=> (you group all the lower urgencies into "other" => that is the same as "Notes and below"

I don't have any idea, but it feels like those 2 filters belong together. (both ways have there usecases)

E.g. if I filter "hints and below" => but then press "hints" in your module: Will I see hints, even though I filtered them?
Well that is both: useful and counter intuitive... So I don't know what is best here.

What if I chose those settings but do your "hints" first, and then filter "hints and below"?

[n7800]

Okay, let's not start a new thread, I'll just write here...

I've long planned to add something similar to the toolbar in other IDEs (see the example attached).

I think the standard toolbar is more suitable – it's traditionally located at the top and can have buttons with icons. It could also have other buttons accessible from the context menu.

Perhaps even a filter/search TEdit (for quickly searching by file or message) could be added directly to it (like in the Search Results View window), since the search is currently hidden in the context menu, creating a separate bottom panel.

[n7800]

There are filters "filter non urgent". The difference is
- yours: filter exactly one urgency 
- the existing: filter that urgency and all below

=> (you group all the lower urgencies into "other" => that is the same as "Notes and below"

I don't have any idea, but it feels like those 2 filters belong together. (both ways have there usecases)

E.g. if I filter "hints and below" => but then press "hints" in your module: Will I see hints, even though I filtered them?
Well that is both: useful and counter intuitive... So I don't know what is best here.

What if I chose those settings but do your "hints" first, and then filter "hints and below"?

I think that with the toolbar, context menu items are no longer necessary.

Each button should show/hide only its own message type. To show "current and below", the user simply selects a few. But for quick switching:
* Left-click - toggle display of the type
* Middle-click - toggle display of this and all below/above type messages

But this is just an example, without details. I won't even mention converting options from the old configuration...

[paweld]

I guess, since you added the same filters to the context menu, the "bottom toolbar" is optional?

That's true, but my main goal was actually the toolbar; I added the option to the context menu to maintain “compatibility” with the existing interface.

I don't have any idea, but it feels like those 2 filters belong together. (both ways have there usecases)

E.g. if I filter "hints and below" => but then press "hints" in your module: Will I see hints, even though I filtered them?
Well that is both: useful and counter intuitive... So I don't know what is best here.

What if I chose those settings but do your "hints" first, and then filter "hints and below"?

The existing filters “Filter non-urgent messages” and “Filter hints without source position” take precedence over this feature; in other words, if I select “Notes and below,” only information about warnings and errors will be collected (‘Hints’ and “Other” will be empty) - I did this to maintain compatibility with the existing filter settings.
The view is refreshed and messages are recalculated after changing the filter settings: “Filter non-urgent messages” and “Filter hints without source position”

[paweld]

I think the standard toolbar is more suitable – it's traditionally located at the top and can have buttons with icons. It could also have other buttons accessible from the context menu.

I'll try to add the option to set the location of the toolbar. As for the icons and additional buttons, I think I'll leave that for later.

Perhaps even a filter/search TEdit (for quickly searching by file or message) could be added directly to it (like in the Search Results View window), since the search is currently hidden in the context menu, creating a separate bottom panel.

Adding the ability to filter content is a great idea - I'll try to implement it.
You also reminded me that I need to add the option to disable the Ctrl+F shortcut for the message window, because it really annoys me.

[Martin_fr]

I think that with the toolbar, context menu items are no longer necessary.

- Yes, only one is *necessary* at the same time.
- No, see my comment. The menu may be preferable, if vertical space is limited.

[JuhaManninen]

The Messages GUI indeed needs cleanup.
Two competing filter GUIs is a very bad idea. Then Lazarus IDE would become more and more geeky and difficult to figure out.
I also like the idea of a Toolbar with buttons for those urgency filters and a FilterEdit for textual filtering like in Search Results.
The Toolbar buttons could even have popup menu quick selection for "Filter X and below" like is now in the Popup menu.
The current Ctrl+F incremental search can then be removed I guess. Filtering is more useful.

Note that the urgency filters and many other Popup menuitems now are specific to FPC. The Messages window can show output from external tools, too, and then the items are hidden.
Those buttons in a new Toolbar should be disabled accordingly. A text search can be applied to any message though.

[paweld]

1. I added content filtering (using “*” indicates a wildcard, and the order of the substrings does not matter), e.g.,
- for “aaa bbb” > filters all messages containing the string “aaa bbb”
- for “aaa*bbb” > filters all messages containing the strings “aaa” and ‘bbb’ in any order (both “aaa bbb” and “bbb aaa” are valid)
The unit name is also included in the search.

2. 3 visibility states for the filter bar: hidden, at the top, at the bottom

I still need to fix a few things and clean up the code.

[JuhaManninen]

1. I added content filtering (using “*” indicates a wildcard, and the order of the substrings does not matter), e.g.,
- for “aaa bbb” > filters all messages containing the string “aaa bbb”
- for “aaa*bbb” > filters all messages containing the strings “aaa” and ‘bbb’ in any order (both “aaa bbb” and “bbb aaa” are valid)
The unit name is also included in the search.

That is yet another syntax for filtering stuff. You should preferably use the FilterEdit components which are used around the IDE.
However this window uses a TCustomControl descendant for the messages. Maybe we should make a FilterEdit version for TCustomControl, where filtering happens only through the event handlers.

A configurable fancy syntax like “aaa*bbb” could be added to FilterEdit components. Then it could be used anywhere. However this one looks weird to me. Both normal wildcard and regular expression respect the order of search strings and '*' means any string.

I still need to fix a few things and clean up the code.

The menu contents should be cleaned accordingly.
How do you indicate a disabled state of the buttons? It should be distinctive.

[Martin_fr]

That is yet another syntax for filtering stuff. You should preferably use the FilterEdit components which are used around the IDE.
However this window uses a TCustomControl descendant for the messages. Maybe we should make a FilterEdit version for TCustomControl, where filtering happens only through the event handlers.

A configurable fancy syntax like “aaa*bbb” could be added to FilterEdit components. Then it could be used anywhere. However this one looks weird to me. Both normal wildcard and regular expression respect the order of search strings and '*' means any string.

If we look at this, we should break thinks down. Also for filter edit.

The matching itself should go into a (replaceable) TFooBarFilter class.

The class is
- given the filter
- can have settings (in the IDE global prefs could exist, either as options to a filter or to chose a filter class or both)
- has a virtual method: IsTextMatching(AText: String);

It may also have interface methods to get text by attributes. E.g. in the search results, a filter may only match filenames, or only line text. If a filter supports a syntax to allow such choice, then it needs an API to get the data by attribute.

For a filter edit, a list of such names could also be in a context menu, as selectable (radio or check menu) items. To limit what gets searched via menu.

In any case, such a TFilter class can then be used by all TFilterEdit, and any other filter implementation that we may have.

[paweld]

A configurable fancy syntax like “aaa*bbb” could be added to FilterEdit components. Then it could be used anywhere. However this one looks weird to me. Both normal wildcard and regular expression respect the order of search strings and '*' means any string.

I don't know if it's fancy? — similar to like 'aaa%bbb' in SQL, except that it’s more convenient (in my opinion) because the order of the substrings doesn’t matter. For example, if you search for “not found” and get a very long list, you can just add “*unit1” at the end and get a list from the selected unit - you don’t have to go back to the beginning of TEdit. Of course, I know this is a matter of personal preference, but ultimately, it’s no problem to change how this filter works.

How do you indicate a disabled state of the buttons? It should be distinctive.

are grayed out - see the attachment.

[Martin_fr]

"*" usually means "any char", but it keeps going forward. So in "Foo*Bar" bar must be after foo.

If order does not matter, then it should be "and" / "&" / "&&"

Also important is some form of "not", either
- show what is matched
- show what is not matched

[n7800]

A configurable fancy syntax like “aaa*bbb” could be added to FilterEdit components. Then it could be used anywhere.

Are you referring to a filtering mechanism built into the component itself? When I was considering the filtering syntax for the Search Results window, I also thought about embedding the algorithm directly into the component. However, filtering algorithms can be arbitrarily complex and involve a vast number of options (especially as they evolve over time).

It is best to avoid embedding such algorithms directly into the LCL or creating a dependency on a new package. Instead, it is better to simply allow the application to use events to assign any desired search algorithm.

The matching itself should go into a (replaceable) TFooBarFilter class.

The class is
- given the filter
- can have settings (in the IDE global prefs could exist, either as options to a filter or to chose a filter class or both)
- has a virtual method: IsTextMatching(AText: String);

It may also have interface methods to get text by attributes. E.g. in the search results, a filter may only match filenames, or only line text. If a filter supports a syntax to allow such choice, then it needs an API to get the data by attribute.

For a filter edit, a list of such names could also be in a context menu, as selectable (radio or check menu) items. To limit what gets searched via menu.

In any case, such a TFilter class can then be used by all TFilterEdit, and any other filter implementation that we may have.

We’ve already discussed something similar in the topic about the filter in the Search Results window. I have some unpublished work (including code for searching by "attributes") but ultimately, it all comes down to specific callbacks. This should make the filtering algorithm universal for any purpose (not just for LCL components, but in general).

Of course, whatever form it takes, I agree that it should be consistent across the entire IDE and support global settings. There is no need to make it part of the window itself - simply assigning handlers for the relevant events is sufficient.