search the directory hierarchy for indentation heuristics

[ashkitten]

sleuth.vim's README says:

Searching for other files of the same type continues up the directory hierarchy until a match is found. This means, for example, the indent for the first file in a brand new Ruby project might very well be derived from your .irbrc. I consider this a feature.

when creating new files in an existing project, it's quite nice to have the editor automatically pick up the indentation format from the files around it instead of making the user copy it themselves.

[cessen]

I think we'll want this be a fallback when there isn't e.g. a .editorconfig file or similar. That way the (machine readable) standard dictated by the project is followed when it exists, but things still Just Work™ when that's absent.

Also, I'm sure this goes without saying (and imagine is how sleuth works), but just to be explicit: this should be per-file-type, probably based on file extension. Don't want C++ files interfering with the indentation style of Python files in the same project, or vice-versa.

[ashkitten]

we may also want to limit it to a project directory if we can detect that (git root or similar), though i can definitely see a benefit in globally traversing until we find a match

[cessen]

Yeah, I think deciding what files should be searched is the only tricky part of the feature. Ideally we want this to be instant, so there will need to be some heuristics to keep the search from exploding in a project with tons of files.

I definitely agree it should be limited to the current project, though! Maybe do a search for VCS root, and if it's not found then only search below the current directory.

[ashkitten]

ideally it stops searching on the first match, so projects with tons of files should not be an issue anyway

[cessen]

I think collecting two or three example files would be a good idea. But in any case, it's certainly bounded in that sense, yes.

However, I was thinking of cases like:

1. You're working in a huge project, and create a new file of a new type that's not in the project yet. Helix now has to traverse the entire project tree just to discover that there are no matching files.
2. You're working in a huge project, and create a new file, and only a handful of files of that type already exist in the project. Due to their locations, Helix ends up traversing a substantial portion of the project tree to find one of them.

Both cases are uncommon, but probably come up occasionally.

Having said that, we could also index the project tree in the background to make it fast to query files by file extension. In fact, I think Helix might already have something along those lines, but for the navigate-to-file fuzzy searching. So maybe it's a non-issue. Worst case, we just make some changes to that indexing code to also serve this purpose.