> Much better would be to just pass
> any non recognized arguments to the
> open call prior to the filename.
Yeah, that makes sense, thanks for a hint.
However, about these possibile "non recognized arguments": this way, we'll have a case with no arguments at all (the usual `:open`) and a case with whatever is going after `:open` to be passed to open/xdg-open -- so, when to show help for :open then? Should we also introduce something like `:open --help`? No other commands seem to support that...
> However, about these possibile "non recognized arguments": this way,
> we'll have a case with no arguments at all (the usual `:open`) and a
> case with whatever is going after `:open` to be passed to open/xdg-open
> -- so, when to show help for :open then? Should we also introduce
What do you mean by help? The command completion?
> something like `:open --help`? No other commands seem to support
No, I mean that little informational hint it prints out now if used inappropriately, `return errors.New("Usage: open")`. Now, if we either use :open without any arguments, or pass all the provided arguments to the system opener, there will be no opportunity to provide this help message (only if requested specifically, like with `-h` / `--help`).
Differently from xdg-open, macOS's /usr/bin/open can also use non-default
applications to open files. This patch adds -A parameter to aerc's :open
command, which allows to open message parts with custom programs. E.g. to
open a HTML part in a non-default browser, use :open -A Safari. Or even
:open -A MacVim to open it in an editor instead of a browser.
DISCLAIMER: again, I'm not a programmer, and this probably can be done in
a way better manner (if someone needs this functionality at all :)
That's a very strange approach and doesn't really scale well.
You really don't need to do platform specific stuff here.
Much better would be to just pass any non recognized arguments to the open call
prior to the filename.
With that, the UX would look like:
`:open -a App` for you and `:open --funkyFlagBecauseICan` on my special snowflake™
patched system running a custom xdg-open wrapper, all without any of the build time
complexity and code duplication you introduced.
Yes you are wrong, exit status 1 is not guaranteed. You could get any non zero exit status (some applications may associate meaning with the exit status).
Other than that, we'd do what we always do, bubble up the error to the user and let them handle it, after all it's their fault ;)
For example, `xdg-open` supports parameters such as `--version`. Now, if in aerc, we do something like `:open --version`, it will report `Opened` but for a user, nothing will happen. Of course, this is some sort of a farcorner-fetched corner case but still, should we do something here?