Re: GNU Emacs raison d'etre

[Arthur Miller <arthur.miller@live.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> 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.
Situation with minibuffer as you describe, being on the bottom and not
being looked is getting even more exaggarated since screens are getting
bigger (I talk about desktop), so one has to explicitly look down to the
bottom of the screen which has some consequence for my neck. I know I
can reposition minibuffer and so on, but I am kind-a used to have it on
the bottom and am not sure where to put it otherwise.

Btw, maybe if minibuffer was hidden away and poped-up only when it is
needed, it might be more attention attracting for new users. Or maybe it
could be flashed with different background color or something similar
that draws attention and eye to minibuffer when it asks for something.