3 ms·

I would have gone with an out-of-band way to signal that the application supports a completion mechanism; One way would be to add a new section to the binary (

I would have gone with an out-of-band way to signal that the application supports a completion mechanism; One way would be to add a new section to the binary (though that would only work with binaries), that could contain standardized data, such as a json tree of the possible completions, or the proper syntax to use the executable as a "completion server" as in your proposal. In shell scripts, it could be one of the header lines starting with a magic comment such as "#!completion: shellac_v0.1 IMO having the shell detect that the executable supports a standardized completion format gets you halfway there ;)

chubot 7y ago
Yes, the detection is definitely an important part of it that I've idly thought about, but haven't written anything about. The proposal is still very early, and not implemented anywhere. The Github wiki is open to edit if you want to write up a proposal (on a new page) and discuss it on https://oilshell.zulipchat.com/ https://oilshell.zulipchat.com/ . A prototype is even better. Although I think that perhaps running the binary with `-h` or `--help` and an env variable like SHELLAC_FEATURE_DETECT=1 might be a more backward compatible detection mechanism. If the binary doesn't support shellac, then it will probably exit quickly with help, or an error message. (And shells could cache this detection info.) If it does support Shellac, then it will print some kind of "spec" to stdout describing where the completion is. Is it in the binary itself written in Rust/Python/etc., or is it in a separate completion script ? The conversation has been dormant lately, but like I said I think there are a few groups of people motivated to do this (e.g. alternative shell users who don't want to rewrite completions themselves).
- MayeulC 7y ago
  > running the binary with `-h` or `--help` These shouldn't be taken for granted, I think the feature should be opt-in (and quite easy to contribute). I would have executed the binary if there is a segment saying that it supports Shellac. The binary then detects the environment variable that's in the current spec, and prints completion information to stdout.

chubot 7y ago

Yes, the detection is definitely an important part of it that I've idly thought about, but haven't written anything about. The proposal is still very early, and not implemented anywhere. The Github wiki is open to edit if you want to write up a proposal (on a new page) and discuss it on https://oilshell.zulipchat.com/ https://oilshell.zulipchat.com/ . A prototype is even better. Although I think that perhaps running the binary with `-h` or `--help` and an env variable like SHELLAC_FEATURE_DETECT=1 might be a more backward compatible detection mechanism. If the binary doesn't support shellac, then it will probably exit quickly with help, or an error message. (And shells could cache this detection info.) If it does support Shellac, then it will print some kind of "spec" to stdout describing where the completion is. Is it in the binary itself written in Rust/Python/etc., or is it in a separate completion script ? The conversation has been dormant lately, but like I said I think there are a few groups of people motivated to do this (e.g. alternative shell users who don't want to rewrite completions themselves).

MayeulC 7y ago
> running the binary with `-h` or `--help` These shouldn't be taken for granted, I think the feature should be opt-in (and quite easy to contribute). I would have executed the binary if there is a segment saying that it supports Shellac. The binary then detects the environment variable that's in the current spec, and prints completion information to stdout.