Fix issue with opening a relative directory with hx <dir> introduced in #8498

[bjorn-ove]

When opening the editor using hx <dir> where <dir> is relative it would either open the wrong directory in the picker, or a new file.

This was introduced by #8498

My solution is to replace the first argument by "." when it is a directory and override args.working_directory. This should effectively leave the original logic in place while still solve the config issue.

[woojiq]

Does this fix #8515?

[bjorn-ove]

Does this fix #8515?

Yes, it should

[bjorn-ove]

The new solution should work well together with working_directory. I have also rebased against master.

[the-mikedavis]

I'd like to avoid passing around a flag like this, it seems leaky / ad-hoc to me. I think it should work to turn all relative paths we get in the args to absolute, relative to the current working directory at start-up time (before we switch the working directory to the one specified with -w). That should also have less confusing behavior when using the -w flag: hx -w path/to/helix Cargo.toml should open the Cargo.toml in the current directory rather than Helix's Cargo.toml IMO

[bjorn-ove]

I also didn't like that flag, but it was the cleanest I could come up with while keeping the original behaviour. Since that was to be relative from -w <dir>, I tried to keep it.

This is also how all other tools I know work. If you run tar -C <dir> hello.txy it changes the directory before opening hello.txt. Usually it is basically an alias for (cd <dir> && tool arg1 arg2 arg3)

I also thought about joining working_directory and files[0], but to make that behave correctly on all platforms is complex.

[bjorn-ove]

Another issue with your suggestion is non existing paths. As canonicalize needs the path to exist.

[the-mikedavis]

Hmm yeah, let's follow other tools then and keep those files relative to the working path rather than cwd at invocation.

The behavior here seems ok then but I'd still like to clean up that rogue flag - it seems like that's leaking out of args. Let's make it a part of the Args struct, something like open_cwd

[bjorn-ove]

it seems like that's leaking out of args. Let's make it a part of the Args struct, something like open_cwd

The reason I didn't do this is that I wanted to leave the args parsing without side-effects. And since I depend on setting the working directory before I check if it is a directory, that wouldn't work. I could make it mutable in main() and set it there, if you think that is acceptable?

[the-mikedavis]

Yeah that's what I had in mind - making it let mut args = .. in main and updating the flag where you set the boolean now

[bjorn-ove]

Hmm yeah, let's follow other tools then and keep those files relative to the working path rather than cwd at invocation.

I may have unintentionally lied about other tools. At least for tar, it will open the file from -f from the current directory, then change, and create all files in the new location.

So it might actually make sense to iterate trough all files in main() and resolve to full path before altering the directory.

Should I look into this, or just leave it as it is now?

[the-mikedavis]

Hmm yeah, let's resolve the paths before altering the directory. IMO that behavior is more intuitive and I believe shell completion should help with that approach (it should assume files are relative to the shell's cwd)