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

Search from .robot and .resource files by default #70

Open
pekkaklarck opened this issue Sep 25, 2022 · 9 comments
Open

Search from .robot and .resource files by default #70

pekkaklarck opened this issue Sep 25, 2022 · 9 comments

Comments

@pekkaklarck
Copy link
Contributor

I've been using pss for years mostly when developing Robot Framework. It would be convenient if our custom extensions .robot and .resource were recognized by pss automatically. If you consider this ok, I'm happy to provide a PR.

@eliben
Copy link
Owner

eliben commented Sep 27, 2022

To be honest, I'm not sure about this. In the limit, there are probably thousands of extensions a tool could support built-in, but adding more also adds cognitive burden to all users, in a way.

Working around such limitations is typically pretty simple with shell aliases e.g. with the --include-pattern option. I have several shell aliases for pss myself that do various things I like by default, and I see this as a perfectly acceptable usage scenario.

@eliben
Copy link
Owner

eliben commented Sep 27, 2022

Oh I was just digging in issues history and found #23 :-)

@pekkaklarck
Copy link
Contributor Author

pekkaklarck commented Sep 27, 2022

I agree there are lot of other file file types that could be supported and it's hard to draw a line somewhere.

Personally I'd say it would be best if pss would search all text files by default. IIRC, this wasn't done initially because detecting is a file text if binary can be a bit slow. Is that a valid concern nowadays? If it is, could there be a list of files that aren't searched by default (.jpg, .out, .exe, ...) instead of a list of files that are?

Alternatively, simply searching from all files by default could be fine as well. It's unlikely that's so slow or that there would be too many false positives.

@pekkaklarck
Copy link
Contributor Author

Fat fingers accidentally pressed close in this small screen...

I had forgotten about #23. Easier way to limit searching to one extension still sounds good to me. I often use --py which basically works that way.

@pekkaklarck
Copy link
Contributor Author

This would actually be a pretty convenient default workflow:

# 1. Search from all (text) files by default:
pss xyz
# 2. Limit searching if there are too many matches: 
pss xyz some/dir    # Limit by path. Works already now.
pss xyz -Eext       # Limit by extension `ext`. 

@eliben
Copy link
Owner

eliben commented Sep 27, 2022

pss is old and very stable by now; it's not likely that I'm going to change the way it works fundamentally, changing defaults etc.

I still think that the "custom add extension" functionality discussed in #23 is the way to go, and happy to accept PRs that implement that.

@pekkaklarck
Copy link
Contributor Author

Searching from all (text) files could cause would require an easy opt-out and a major version change. I understand if you consider that too much work. It's easy to alias pss for pss -a as well.

I fail to see how adding custom extensions would be better than using -E ext when needed. I pretty often use pss --py to limit searching and similar functionality with all file types would be convenient.

@eliben
Copy link
Owner

eliben commented Oct 7, 2022

Ultimately -E doesn't cover all uses cases, because pss doesn't only search by extension. In many cases, it searches by filename pattern like in --docker, --cmake, --gomod and several others. Singling out just extensions for -E doesn't feel right to me, so I think a regex would be unavoidable.

Let's say we extend the -E idea to take a full regexp/pattern; ignoring the fact that it's a bit more verbose for a moment - is it worth it instead of pss -aG? That could be, because it composes better; say you want to search "Python and Robot" files -- doing this with -aG may be somewhat cumbersome (unless I'm missing something obvious).

As for -E (with a full regexp/pattern) vs. config options, I'm willing to accept that by this time maybe config options are an overkill for pss since no one really needs them and -E can be sufficient.

@aaltat
Copy link

aaltat commented Jun 15, 2023

I have many times to need to limit search in to certain file type, because it will limit the found results. Example repository might have mixed code from different languages, but not all those file extension are supported by pss (like with pss --py). So if I do pss xyz there is just too many results found and it is not useful. But I know that data is in files having .abc extension, so currently typing pss -iaG ".*\.abc" xyz is actually quite lot of typing to do. Therefore having simple pss -E abc xyz would be really handy for my use case.

What ever you decide to do, I am an happy user for the pss tool and it is certainly better than using find/xargs/grep combo.

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

No branches or pull requests

3 participants