Date: Tue, 29 Sep 2020 08:15:17 +0200
In-Reply-To: <C5ZLXP64FMPC.2Q0YDF9C4OLSV@Penelope.local>
References: <C5ZLXP64FMPC.2Q0YDF9C4OLSV@Penelope.local>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH] on macOS, :open now can use the specified application
To: JD <john1doe@ya.ru>
CC: ~sircmpwn/aerc@lists.sr.ht
From: Reto <reto@labrat.space>
Message-ID: <50D9C695-C911-4B7C-A521-DC88D2FCCDB9@labrat.space>

On 29 September 2020 07:35:20 CEST, JD <john1doe@ya=2Eru> wrote:

>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?
=20
>something like `:open --help`? No other commands seem to support
>that=2E=2E=2E

No, we'll simply document the behaviour and call it a day=2E `open [args=
=2E=2E=2E]` or some such=2E

>But then on a system wtih the standard xdg-open passing additional
>parameters to it (by mystake, let's say) will result in exit status 1,
>am I wrong? Should we do anything in this case?

Yes you are wrong, exit status 1 is not guaranteed=2E You could get any no=
n zero exit status (some applications may associate meaning with the exit s=
tatus)=2E

Other than that, we'd do what we always do, bubble up the error to the use=
r and let them handle it, after all it's their fault ;)

Cheers,
Reto