:open should support globbing / wildcards

[LeoniePhiline]

I haven't found a bug report for this yet - sorry if I missed one!

I had just now wanted to open a whole range of files via :open ~/path/to/prefix_*.

Helix created a new buffer with that name instead of expanding the * and opening all matching files. It would be real neat if globbing was supported!

[mslot]

Should we have an upper recursive and directory limit that can be overridden? Imagine opening /**/*, or just a directory with one million files in it.

[askreet]

The behavior in (n)vim seems to be:

• If something looks like a glob pattern, try to match it into a file list.
• If that works, check to see if there are "too many" files and error out.
• If that doesn't work, open a buffer with the filename including glob-like characters.

Would we want the mirror that behavior? Seems generally OK to me. The alternative to #3 would be something like error out if no files match and provide a way to escape the glob pattern should you want to edit a file called "file*".

[mslot]

The behavior in (n)vim seems to be:

* If something looks like a glob pattern, try to match it into a file list.

* If that works, check to see if there are "too many" files and error out.

* If that doesn't work, open a buffer with the filename including glob-like characters.

Would we want the mirror that behavior? Seems generally OK to me. The alternative to #3 would be something like error out if no files match and provide a way to escape the glob pattern should you want to edit a file called "file*".

I think that is a good algorithm. I can accept that.

[Pablu23]

Hi I would like to try and implement this. Its my first time collaborating, so I was curious if it is allowed to use crates, I would try to implement this with the glob crate.

[the-mikedavis]

I'm not sure we need globbing support. IMO this overlaps with the file picker and I would rather see multiple selections in the file-picker (#4837) than extending :open. We try to keep the dependency count small so pulling in a new crate just for this would not be ideal.

[mslot]

I'm not sure we need globbing support. IMO this overlaps with the file picker and I would rather see multiple selections in the file-picker (#4837) than extending :open. We try to keep the dependency count small so pulling in a new crate just for this would not be ideal.

I can't see why this shouldn't be supported with :open, because this is one of those things where you would want to quickly point out what to open, and globbing is perfect for that.

I do agree that pulling in another crate is not what we want.

How should globbing be supported? Basic: ** for "all directories under parent" and * for all files in current?

[mo8it]

A manual implementation would be a waste of dev time and confusing for users in the best case because it won't meet every expectation. I think that we should use a well known implementation. glob is one crate without any dependencies. I would like to implement this if you agree and @Pablu23 doesn't have time (because he asked first).

[the-mikedavis]

Actually we recently added globs for file-types using glob globset: #8006

Yeah on second thought I think this would be a reasonable improvement. This is right around where we should expand globs:

helix/helix-term/src/commands/typed.rs

Line 113 in 98ebeee

let path = helix_stdx::path::expand_tilde(&path);

[pascalkuthe]

(We should be using globset and not the glob crate tough)

[mo8it]

This is not closed 😅 The merged PR is just slightly related.

BTW, globset doesn't offer a recursive iterator. Should I implement it myself or should we add glob?

[pascalkuthe]

You may be able to tell ignore directly to o ly whitelist paths that match a certain glob. If not you should implement an ignore filter that checks a globset glov. You should not be pulling any new libraries in or writing significant amounts of code