[Top][All Lists]

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

RE: GNU Emacs raison d'etre

From: Drew Adams
Subject: RE: GNU Emacs raison d'etre
Date: Sun, 17 May 2020 11:57:56 -0700 (PDT)

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

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.

reply via email to

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