[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bashbug's default editor

From: Ángel
Subject: Re: bashbug's default editor
Date: Sat, 01 Aug 2020 01:15:28 +0200

On 2020-07-31 at 11:26 -0400, Eli Schwartz wrote:
> In the sentence in the bashbug manpage, does the word "default" refer to
> the probing or what happens when probing fails?
> My belief is that people reading the manpage will understand it to mean
> the former (more natural reading).
> Your belief seems to be that people will understand it to mean the
> latter (I don't feel the sentence conveys this).
> ...
> The OP here seems to have interpreted it the way I did. So clearly it's
> confusing to at least 2 people out of millions.

I agree with the OP and Eli.
This is not a bug against the code, but against the documentation, and I
do think there is an issue here.

We are in the context of a software program and its configuration. A
phrase following the pattern
> If <configuration option> is not set (...) defaults to <valid value>.

is commonly used to mean that the program will act as if <configuration
option> was set to <valid value>

Here it gets a bit odd, since the part about "bashbug attempting to
locate a number of alternative editors, including emacs" adds no value.
In fact, the whole thing about emacs and vi there seems of little use
(maybe it was added to please members of both cults?), unless you
document the actual algorithm the user just knows that it will open a
random editor.

I suggest the following wording:
> EDITOR Specifies the preferred editor. If EDITOR is not set, bashbug
> will attempt to locate some common editors on the system and choose
> one for you.

It's still a black box, but at least doesn't distract about emacs or vi.
If you don't like what bashbug choose, you should have picked one
yourself. :)

While poking at $EDITOR defaults, vim should probably be added to the
list, somewhere.

For those interested, here is the actual guessing code:

I'm a bit surprised by the hardcoded paths, actually. I understand it
may not want to use something like Debian's which may not be generally
available, but I was expecting a loop trying to exec alternatives would
work, even in the sh mode. I wasn't expecting exec to finish the parent
script rather than a function. :/

Best regards

reply via email to

[Prev in Thread] Current Thread [Next in Thread]