Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 16.05.2020 16:57, Sergey Organov wrote:

> > 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.

Yes. I _have_ had problems reading the minibuffer's contents, however, 
on a few occasions.

> 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
> unreliable.

Fair enough. But in the end, you're probably asking for something that 
doesn't exist in Emacs yet. Like, no graphical switches for buffers 
that's equal in power to the minibuffer-based one.

I agree that the prompts could be positioned better, and the result 
could be better readability. After all, if one uses the minibuffer a 
lot, isn't it a shame that it resides somewhere down below, and uses the 
same font as the rest of Emacs?

In that, I think VS Code, Atom, etc, have a better idea by positioning 
their input area somewhere near the top of the window, in an easy-to-see 
dropdown. Somewhere in the middle of the frame could also work.

If you like, try out https://github.com/honmaple/emacs-maple-minibuffer/ 
with (setq maple-minibuffer:position-type 'frame-top-center) or 
'frame-center.

I'd like to see Emacs something like this by default someday.

> 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.

I see where you're coming from, but I think the minibuffer is too large 
a part of Emacs UI to shield the newbies from it like that.

Or at least, the above would be a better solution, by improving 
minibuffer's usability for both newbies and existing users.