bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#31094: Code for second solution


From: Boruch Baum
Subject: bug#31094: Code for second solution
Date: Sun, 8 Apr 2018 10:13:30 -0400
User-agent: NeoMutt/20180223

On 2018-04-08 16:54, Eli Zaretskii wrote:
> > Date: Sun, 8 Apr 2018 09:17:01 -0400
> > From: Boruch Baum <boruch_baum@gmx.com>
> > Cc: 31094@debbugs.gnu.org
> >
> > The first code snippet already only changes behavior when the function
> > is called with either two or three universal prefix args.
>
> I was under the impression that the first variant was not what you were
> promoting.

Different strokes for different folks. Personally, I would end up using
the second variant, but I wouldn't begrudge anyone the first option and
they can co-exist peacefully in the code. Both are minor tweaks.

> > The second snippet is controlled by a boolean defcustom variable,
> > defaulting to the current long print-out behavior.
>
> That sounds sub-optimal to me: completely changing the behavior of a
> command given an option is not the best UI, IMO.  Two different
> commands are better.

You're over stating the behavior change of the second snippet; it
changes the detail level of the output. True, as written, it 'breaks'
the response to <RET> keybinding, but I consider that trivial, because
the same functionality is available with `C-h v` or `C-h f', and to the
benefit that the snippet is much leaner on memory. If you insist that
you absolutely need that <RET> key to display the symbol's complete
documentation, that can be done without rejecting the idea of the
snippet, but it's a minor coding hassle for no real reason; Everyone
knows `C-h v' and `C-h f' describe the symbol at point.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0





reply via email to

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