[Top][All Lists]

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

Re: GNU Emacs raison d'etre

From: Sergey Organov
Subject: Re: GNU Emacs raison d'etre
Date: Sat, 16 May 2020 16:57:42 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Dmitry Gutov <address@hidden> writes:

> On 16.05.2020 15:34, Sergey Organov wrote:
>>>>>> And here there are 2 more problems for newbies. They usually expect
>>>>>> pop-up/modal/  dialog to be thrown on them for anything but text input
>>>>>> or moving around.
>>>>> That happens in Emacs for some/many commands invoked via the menu bar.
>>>> Then this must be rather easy to achieve for keyboard induced commands
>>>> as well.
>>> Not really.  When the user invokes a command from the menu, we have a
>>> clear signal that the mouse is being used, and therefore can display a
>>> GUI dialog without fear.  But when the user types "C-x C-f", how can
>>> we know that he/she expects a dialog box and not a minibuffer prompt?
>> My argument was that newbie never wants minibuffer prompt, so this is
>> not an issue. I mean it'd always be dialog unless "newbie-mode" is
>> turned off.
> My anecdata shows otherwise: it's never been a problem personally.

What exactly? Failure to notice Emacs suddenly asking you for something
in the minibuffer? I see it very often.

Rarely newbies look at the bottom of the screen/frame when cursor is
suddenly gone, even after some training. The most frequent instinct I
see is clicking with the mouse at the position on the screen where they
want cursor to be.

Here is an example:

1. Type C-x b (imitation of accident keystroke)
2. Click with the mouse _here_
3. In the menu click "Edit | Go To | Goto Line"

Result? For me it's:

completing-read-default: Command attempted to use minibuffer while in minibuffer

error message that, besides, is again being output into minibuffer
place, that for me even was immediately overwritten by a help string on
a lisp variable as I was doing it in the *scratch*.

Will any newbie be able to tell why this menu item suddenly didn't work
as expected? I'd rather afraid they may think Emacs is buggy and

> As for the newbies who want modal dialogs, surely they will use the
> mouse and the toolbar to invoke the corresponding commands?

This is unrelated to the context of the suggestion.

Please recall that the problem being discussed is /accidental/
invocation of a command by a keystroke that brings newbie to minibuffer
that she often doesn't even notice! If Emacs rather threw big shiny
dialog into his face (even if only displaying this same minibuffer in
it), it'd leave the newbie little chances to remain ignorant.

In fact, many "expert" commands already do something like this, asking
to be explicitly enabled. This is not that helpful for complete newbies
though as the prompt still uses the minibuffer that newbies often forget
to pay attention to in the first place.

-- Sergey

reply via email to

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