[Top][All Lists]

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

Re: GNU Emacs raison d'etre

From: martin rudalics
Subject: Re: GNU Emacs raison d'etre
Date: Mon, 18 May 2020 10:32:49 +0200

> 1. It's trivial to move a minibuffer-only frame
> off screen (and bring it back on screen).

Not in my experience.  Not even for arbitrary frames.

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

Only on systems that do support that.

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

On every GUI I've seen so far

(make-frame-invisible (window-frame (minibuffer-window)))

works as intended.  I call it thousands of times daily whenever a
minibuffer becomes empty.

> As I said, my impression is
> that use of minibuffer frames doesn't get
> tested much when features are introduced.]

I use a minibuffer child frame all the time.  It is invisible whenever I
don't need it, promptly shows up on any window where I want to interact
with it and resizes just like any normal minibuffer window.

I do not use the echo area for ElDoc though and occasionally the echo
area noisily pops up to tell me that I'm at the beginning or end of a
buffer.  I've been told that I have to live with the latter.

In either case I can assure you that minibuffer frames are tested by me
intensively whenever features are introduced.


reply via email to

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