support the`helix` editor

[Byron]

Required features

• [x] apply filters to individual files based on the attribute stack (for linefeed conversions of diff base)
• [x] support for reading an up-to-date version of the index/staging area
• [x] git-status (HEAD and worktree + untracked files)
• grammars.rs
  • [x] clone a repo with --depth=1 (grammars are fetched that way), currently git is shelled out
    • [x] checkout simple worktree
    • [x] add remotes after configuring their urls
    • [x] get revision hash of HEAD
• optional
  • [ ] replace filetime usage in gix-index with gix::fs::FileTime, a clone of what this crate offers which should be reproducible without too much effort.

[pascalkuthe]

• [ ] support for the stage (to potentially display gutters against that instead of head and stage/unstage changes? Ideally we could even indicate if a hunk is staged or not with a different color but I am not sure if that is possible without running a second diff)

[pascalkuthe]

Another thing that comes to mind:

I want to cache repositories in some manner which requires some sort of file -> repo lookup. The simplest solution is to simply build a repo root -> worktree hashmap. Helix already detect the git root anyway by searching for the nearest .git folder. However this does not work for:

• bare repos
• detached worktrees/repos (.git is a file in that case`)

However gitoxide can detect these cases. Do you think the discovery logic can be spun out into a seperate function that helix could use.

I hope/think the overhead is not that large helix also frequently scans for the .git folder right now. I have a rough implementation locally that implements a custom in-memory tree that keeps track of which directories a git repo has been resolved. It was really clever but really compilcated and probably quite fragil. I think it's overkill and would prefer a simple hashmap solution. What are your thaughts?

[Byron]

[ ] support for the stage (to potentially display gutters against that instead of head and stage/unstage changes? Ideally we could even indicate if a hunk is staged or not with a different color but I am not sure if that is possible without running a second diff)

It's already possible to get an up-to-date copy of the index with worktree().index(), and from one can get entries at a given path even though doing so is probably less convenient than it could be as all of it is still quite new. It is, however, possible to do already, despite that.

Doing two diffs seems like something that could be attainable given diffs are already much faster than pretty much anywhere else. Can't diffs be done in parallel as well so the only added serial overhead is to correctly draw the index diff in a different color?

[pascalkuthe]

[ ] support for the stage (to potentially display gutters against that instead of head and stage/unstage changes? Ideally we could even indicate if a hunk is staged or not with a different color but I am not sure if that is possible without running a second diff)

It's already possible to get an up-to-date copy of the index with worktree().index(), and from one can get entries at a given path even though doing so is probably less convenient than it could be as all of it is still quite new. It is, however, possible to do already, despite that.

Doing two diffs seems like something that could be attainable given diffs are already much faster than pretty much anywhere else. Can't diffs be done in parallel as well so the only added serial overhead is to correctly draw the index diff in a different color?

Thinking about it more I think showing hunks are staged doesn't actually work well. I think the stage is not guaranteed to be "in-between" head and worktree. So we could have three totally distinct files in HEAD, the index and the worktree. At which point you can either display two seperate diffs or need to choose one of them but displaying both doesn't make sense

[Byron]

Another thing that comes to mind:

I want to cache repositories in some manner which requires some sort of file -> repo lookup. The simplest solution is to simply build a repo root -> worktree hashmap. Helix already detect the git root anyway by searching for the nearest .git folder. However this does not work for:

• bare repos
• detached worktrees/repos (.git is a file in that case`)

However gitoxide can detect these cases. Do you think the discovery logic can be spun out into a seperate function that helix could use.

I hope/think the overhead is not that large helix also frequently scans for the .git folder right now. I have a rough implementation locally that implements a custom in-memory tree that keeps track of which directories a git repo has been resolved. It was really clever but really compilcated and probably quite fragil. I think it's overkill and would prefer a simple hashmap solution. What are your thaughts?

The git-discover crate should have you covered for detecting everything there is to know about the presence of a git repo in a given directory (or .git file for that matter), without being forced to open the repository right away.

I hope/think the overhead is not that large helix also frequently scans for the .git folder right now.

Doing it 'properly' is slow enough to have forced me to implement a less correct but faster version in one of the ein subcommands.

I think it's overkill and would prefer a simple hashmap solution. What are your thaughts?

I'd use a hashmap too, as any IO should outweigh the cost for the few queries it probably sees. Only one suggestion, in case it's not done yet: ThreadSafeRepository is the one intended to be kept in such a structure, keeping only the data that is shared across Repository instances. Thus thread-local caches won't be held by it, reducing the memory consumption to the bare minimum. Something that would have to be monitored is the overhead in system resources that are held by these instances, and when it would be time to release them.