GNU bug report logs - #60527
30.0.50; Typing SPC in a minibuffer with completion

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60527 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#60527: 30.0.50; Typing SPC in a minibuffer with completion
Date: Wed, 4 Jan 2023 19:45:45 +0200

On 04/01/2023 19:16, Eli Zaretskii wrote:
>> Date: Wed, 4 Jan 2023 19:00:44 +0200
>> Cc:60527 <at> debbugs.gnu.org,monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>> On 04/01/2023 16:47, Eli Zaretskii wrote:
>>> I didn't say I'm against any change in this behavior.  Stefan proposed
>>> at least two alternatives that produce basically the same user-facing
>>> behavior when SPC is supposed to be interpreted verbatim, so they come
>>> very close to the alternative that you like better, but still stop
>>> short of breaking someone's muscle memory.
>> The first alternative provides sometimes the same, and sometimes
>> different behavior. In particular, when there are valid completions,
>> "SPC" would still perform completion -- something that I don't think
>> many users expect. Especially novices.
>>
>> The second alternative is even more involved, requiring
>> 'completing-read' callers to decide in advance whether the users will
>> want to have SPC insert SPC or perform completion. That's still odd and
>> seems like crossing the proper abstraction layers. The caller might not
>> know the collection contains spaces. And this approach can break
>> established muscle memory just the same, as soon as enough callers start
>> to make this choice.
> I understand that just rebinding SPC is much easier.  But we are
> supposed to consider other factors, not just the ease of
> implementation.  And I'm not afraid of code that is somewhat inelegant
> and even breaks abstractions, if we provide better, friendlier UI
> which breaks less habits.

Using proper abstractions is what can lead to predictable, better UI. 
And vice versa -- patching through special cases upon special cases 
leads to less predictable, worse UI.

I wasn't talking about the ease of implementation, really.

> Many Emacs's abstractions leak from many
> holes anyway.

That's more of a problem for a UI which is used in many, many places and 
in different contexts.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.