Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better support for multiple search terms #196

Closed
didib opened this issue Aug 31, 2021 · 9 comments
Closed

Better support for multiple search terms #196

didib opened this issue Aug 31, 2021 · 9 comments

Comments

@didib
Copy link

didib commented Aug 31, 2021

Hi Mark,

First, I'd like to say thanks. I've been using less since 1993 or so, and it's definitely one of the most important tools for me, used tens or hundreds of times a day. I actually find it quite amazing that you didn't loose interest after all these years. So, Thanks!

I've been thinking about this for quite some time now, but still do not have my thoughts clear. But now had another case where I wanted this feature, so decided it's a good time to create this "issue", as github calls it.

less already supports multiple search terms indirectly, by supporting "extended regexp" and the terms split with '|'. But AFAICT based on the manpage, the support is "implicit" - if the regexp library has it, you get it. That's fine, but I want more. specifically, at least two features, but perhaps others might make sense if/when work on this is started:

  1. Highlight different terms with different colors. Not much to say about this, I think it's obvious why it might be useful, and is probably not that hard to implement, if you agree to have slightly more reg-exp-library-specific code.

  2. Have a quick and simple way to jump to the next occurrence of a specific term. I still did not manage to come up with a good UI for this, as less already uses many/most keys/shortcuts and having to type long commands won't be "quick and simple", IMO. It might even make sense to introduce a new mode for searching, in which keys change their meaning - then, it can be useful to be able to type e.g. a single number or letter - e.g. pressing '3' or 'c' will jump to the next occurrence of the third term. Using a letter will also allow naturally to press 'C' for jumping to the previous occurrence. Alternatively, perhaps some new command (instead of a mode) can tell less what term number should 'n'/'N' jump to. That's less comfortable in some cases, probably, but requires a simpler and more natural change in the code/behavior, I guess. Why would this be useful? More and more, I find myself looking at some complex log file, having information about lots of different actions/tasks/items going on, and needing to search for both item-specific data (such as its ID/Name), often more than one (think a host name, a file name, etc.), and for more general terms (such as action names/IDs). I often want to see (highlight) all of them, but jump (n/N) to occurrences of a specific item (or items) - e.g. to the next occurrence of a host or file name but not the next one of a task name.

Best regards and thanks again!

@gwsw
Copy link
Owner

gwsw commented Jan 12, 2023

Although this doesn't address the second issue, as of b033a6f (less-620), you can get multiple color highlighting by using parenthesized subpatterns in your search pattern (only with posix and pcre regex libraries). Having multiple search terms active at the same time as you suggest would be substantially more difficult.

@piotr-dobrogost
Copy link

I find myself looking at some complex log file (…)

Have you tried lnav for this?

@didib
Copy link
Author

didib commented Jan 18, 2023

Although this doesn't address the second issue, as of b033a6f (less-620), you can get multiple color highlighting by using parenthesized subpatterns in your search pattern (only with posix and pcre regex libraries).

Thanks, sounds useful!

Having multiple search terms active at the same time as you suggest would be substantially more difficult.

OK. How about having a new variable/param - not sure how to call it, e.g. --search-subpattern-target=PATTNUM - defaulting to 0 (search for the entire pattern), where if it's set to some other number, pressing n/N will jump to the next occurrence of the respective subpattern?

@didib
Copy link
Author

didib commented Jan 18, 2023

I find myself looking at some complex log file (…)

Have you tried lnav for this?

Not yet. I might do soon - thanks. I realize there are specialized tools for such tasks, but IMO it's also useful to know that in a few years, once the changes done here propagate to the common distros, you'll have this available on more-or-less every server you happen to have to diagnose, right there - as less is everywhere :-).

@gwsw
Copy link
Owner

gwsw commented Jan 27, 2023

@didib, by definition every subpattern is part of every string that matches the search pattern. So pressing "n" will already jump to the next occurrence of every subpattern. Perhaps I'm not understanding correctly what you mean?

@ferdnyc
Copy link

ferdnyc commented Jan 30, 2023

@didib, by definition every subpattern is part of every string that matches the search pattern.

That's not quite accurate, technically.

If I have a pattern like /((Red)|(Blue))/, then for every occurrence of Red, groups 1 and 2 will have matched 'Red', whereas group 3 will not have participated in the match. For every occurrence of Blue, groups 1 and 3 will have matched 'Blue', whereas group 2 will not have participated in the match.

I'm not saying that it's possible to build a good/comfortable UI for interacting with that kind of sub-submatch. (In fact, I'll go in the opposite direction entirely: I think it's highly unlikely that simultaneous navigation of multiple sets of search matches can be represented in a sufficiently-comprehensible UI, where I define 'sufficiently-comprehensible' as "makes more sense than using vim". But I'd welcome being proved wrong.) But, technically not all (sub-)subgroups are included in all matches.

@didib
Copy link
Author

didib commented Jan 30, 2023

@didib, by definition every subpattern is part of every string that matches the search pattern. So pressing "n" will already jump to the next occurrence of every subpattern. Perhaps I'm not understanding correctly what you mean?

I admit I didn't think this out clearly. How about: Jump to the next line matching the pattern where the matching for group PATTNUM is not empty.

I think this is also a natural extension of less's behavior to say 'Pattern not found' when searching for the empty string (and not matching all lines, like e.g. grep does).

@gwsw
Copy link
Owner

gwsw commented Feb 2, 2023

In ac3ec3a there is a new ctrl-S search modifier, which lets you specify one or more subpatterns which must be nonempty in a valid match.

@buzain
Copy link

buzain commented Jan 16, 2024

In ac3ec3a there is a new ctrl-S search modifier, which lets you specify one or more subpatterns which must be nonempty in a valid match.

Is there an example/tutorial on how to use ctrl-S?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants