How to make the start command suggest relative paths?

[iboB]

I often use start with a filename argument to open it with the default associated program (as in > start my-text-file.txt to open notepad with this file)

With clink for some reason the suggestions for paths relative to the current dir after start are disabled. So I often resort to:

1. type x my
2. press tab to get x my-text-file.txt
3. press home to get to the beginning of the line
4. delete x and type start

How can I enable relative path suggestions for start?

[chrisant996]

The same occurs when completing the first word of any command line. And the first word after start is the first word of a new command line.

The bash, zsh, fish, and etc shells all have similar specialized completion for the first word of a command line. Clink has settings to control how completion works for the first word.

See Executable Completion.

[iboB]

Instead of changing first word completion globally, can't I do something for start specifically?

[chrisant996]

No.

[garoto]

ctrl+space perhaps? https://chrisant996.github.io/clink/clink.html#rlcmd-clink-select-complete

[iboB]

No, this just gives the same suggestions as tab but the list is interactive

[chrisant996]

Typing start .\ would work, of course, but I think you don't want that.

[chrisant996]

Also, the start argmatcher is coming from the cmd_commands.lua script in the clink-completions repo -- it isn't coming from Clink itself.

The part that's coming from Clink is that the start argmatcher tells Clink that the next word after start begins a new executable command line (because it does), and then Clink treats it as such. It sounds like you want Clink to not treat it like a new executable command line.

So maybe what you want is to not use the start argmatcher from clink-completions. But I also don't want to start adding configuration settings to enable/disable specific argmatchers from clink-completions.

Maybe it would be useful to have a way to un-register an argmatcher? So that you could add a script that runs after the clink-completions scripts, and it could un-register the start argmatcher (and maybe also register a different version of a start argmatcher that doesn't support the executable completion capability)?

[iboB]

Actually I had completely forgotten that start is not needed. I was used to xdg-open on Linux and just naturally started using something on Windows.

I hadn't thought about %PATHEXT% too but I'd rather use the existing defaults, than manually adding everything in a whitelist.

What I am going to do is just create my own start batch file: mystart (or more likely simply x) that just executes start with all of its arguments.

Sorry for the fuss, but there's nothing to be done here. It can all be worked around on my end.

[chrisant996]

Interesting.

Maybe name it xdg-open.bat so you don't even need to change what you type?

But it still sounds like you'd ideally also like a setting that includes documents with file associations. Right? (e.g. something like exec.documents.)

The only reason I haven't yet made such a setting is there isn't a good way to make it high-performance. But I can at least do some optimizations to minimize the delay while it looks up file extensions to include/exclude them from the list of completions.

[iboB]

At first I thought I wanted that, but now that I'm thinking this through, I don't think it's s such a good idea. xdg-open.bat is the best solution. It shows clear intent and doesn't pollute the first word suggestions otherwise.

[chrisant996]

Ok, I'm glad you found a solution you like.

I've added an exec.associations setting which defaults to false (off), but can be enabled to include launchable documents as matches. I.e. files with registered file associations such as ".pdf". (I was surprised at how effective the optimizations I mentioned turned out; on my computer there is zero perceivable speed difference when exec.associations is enabled.)

I've also fixed input line coloring so that it accurately applies the color.executable color to launchable documents found along the system PATH. E.g. if the PATH includes C:\Tools and there's a Documentation.PDF file in that directory and you type "Documentation.PDF" at the command prompt even while the current directory is something other than C:\Tools. Windows will launch that document file, so Clink is meant to color it accordingly.

Those will be included in the next Clink release (probably this weekend).

So, you'll be able to try it out and see which way you prefer.

(If you set match.coloring_rules to color executables and documents differently, then the completion commands will clearly differentiate between them when displaying matches.)

[chrisant996]

Clink v1.6.13 has been published, and includes an exec.associations setting.