I was looking at a bug report and I spent a bunch of time switching between 3 different IDs. I had to copy & paste repeatedly and it's a big hassle. I really wanted all three searches active at the same time and wanted to associate a descriptive name with each. I also wanted to see the search ranges in the timeline (I ended up using tags to do that).
I thought about putting each ID into an environment variable, but that has a bunch of issues (it's not easy to use vars in searches/filters).
Thinking about it more, it seems like you should be able to start simple with a search and then progress to something more fancy. If we allow the user to convert the current search to a "named" one. Then we can build on that. The named search can be turned into a filter, shown in the timeline, highlighted with a different color, added to a vtab column, and so on.
So, maybe a command like :create-named-search <name> [pattern]. Without the pattern argument, it creates the named search from the currently active search and clears the active search. With the pattern it does as you would expect. There should also be a :delete-named-search <name>.
After creating the search, the matching text in the view should be changed to a different color. The existing n / N / < / > hotkeys should work for all searches, named or otherwise. In the timeline, named searches should show up as their own row and the preview should show matching messages. Probably add a log_named_searches column to the log vtabs where it's a JSON array with the names of the matching searches. A lnav_view_searches table similar to lnav_view_filters would also be good.
To start, this should just work for the LOG view.
I was looking at a bug report and I spent a bunch of time switching between 3 different IDs. I had to copy & paste repeatedly and it's a big hassle. I really wanted all three searches active at the same time and wanted to associate a descriptive name with each. I also wanted to see the search ranges in the timeline (I ended up using tags to do that).
I thought about putting each ID into an environment variable, but that has a bunch of issues (it's not easy to use vars in searches/filters).
Thinking about it more, it seems like you should be able to start simple with a search and then progress to something more fancy. If we allow the user to convert the current search to a "named" one. Then we can build on that. The named search can be turned into a filter, shown in the timeline, highlighted with a different color, added to a vtab column, and so on.
So, maybe a command like
:create-named-search <name> [pattern]. Without thepatternargument, it creates the named search from the currently active search and clears the active search. With the pattern it does as you would expect. There should also be a:delete-named-search <name>.After creating the search, the matching text in the view should be changed to a different color. The existing
n/N/</>hotkeys should work for all searches, named or otherwise. In the timeline, named searches should show up as their own row and the preview should show matching messages. Probably add alog_named_searchescolumn to the log vtabs where it's a JSON array with the names of the matching searches. Alnav_view_searchestable similar tolnav_view_filterswould also be good.To start, this should just work for the LOG view.