Re: GNU Emacs raison d'etre

[Arthur Miller]

Drew Adams <address@hidden> writes:

>> "autohide" (similar as windows taskbar) could be a way? But it is
>> hardcoded in c-code that minibuffer cannot be hidden.
>
> That's not true (depending on what you mean,
> I guess).
>
> 1. It's trivial to move a minibuffer-only frame
> off screen (and bring it back on screen).
>
> 2. Alternatively, it's possible to make a frame
> invisible (and visible again).
>
> (modify-frame-parameters 1on1-minibuffer-frame
>                          '((alpha . 0)))
> (modify-frame-parameters 1on1-minibuffer-frame
>                          '((alpha . 100)))
> ___
>
> [No, alpha is not a satisfactory solution for
> trying to get real invisibility.  Zero doesn't
> make a frame completely invisible.  And the
> frame is still present, at the same location,
> which can be bothersome in terms of interaction.

Indeed, setting alpha is not enough, the frame will still be visible,
and it will also still take space. Believe me I tried, and I traced the
problem to C code (I think in buffer.c, I don't remember). I think there
was even an explicit comment saying minibuffer can not be hidden.By the
way, I wasn't thinking of having it in separate frame. I prefer to have
just one single frame so I minimize frame switching (alt-tabbing). So I
ment for the "usual" minibuffer as on the bottom of the visible Emacs
frame. So that put out of the question to set minibuffer away from the
screen and then show it back. Albeit it might be a solution if
minibuffer would be used in a pop-up manner.
>
> Presumably, frame parameter `visibility' would
> also be usable for this, but it doesn't seem
> to have an effect on a minibuffer-only frame,
> at least on MS Windows.  Same with parameter
> `minibuffer-exit', and same with functions
> `make-frame-(in)visible'.  Dunno whether those
> are just bugs.  As I said, my impression is
> that use of minibuffer frames doesn't get
> tested much when features are introduced.]
>
>> What I learned some decades ago when I took my driving license is that
>> human eye is trained to register motion, better then static objects. So
>> if minibuffer poped/raised/lowered (like a quake console :-)) when
>> needed, that motion could draw attention more then just some text
>> prompting in a tatic minibuffer. Same effect is probably achieved by
>> flushing minibuffers background/foreground colors or similar.
>
> One person's helpful attention attracter is
> another person's annoyance.  So yes, but such
> things need to be optional - user preferences.
It might be; but annoyance or not, it is an attention drawer. It is not
about preferance here, but more about what draws peoples attention.

When they are new to Emacs and dont' notice that minibuffer asks them
something, I recognize myself when I was new, something moving on the
screen might draw the attention. Once they get more experienced with
Emacs they can choose to have it always visible as it is now, place it
somewhere etc.

Just as analogy if it helps, when one drive, the brain automatically
focus on thing that moves, not on things that are static. Don't know if
it is because of evolution or not since bears and tigers were our
neighbours, but obviously that is how we are wired as humans.

Personally I prefer less distraction, that is why I use simple window
manager instead of a desktop, but in this case, I would prefer
minibuffer as autohide. Also because vertical screen estate is a scarce
resource since we evolved into wide-screen age :-).