bug#47556: "really open? (y)es or (n)o or (l)iterally" vs. emacsclient -n

bug#47556: "really open? (y)es or (n)o or (l)iterally" vs. emacsclient -n

[積丹尼 Dan Jacobson]

$ emacs -Q --maximized -eval '(server-start)'&
$ emacsclient -n big.jpg
big.jpg is large (14.5 MiB), really open? (y)es or (n)o or (l)iterally
Alas in this case our y, n, or l's are not being read by the mini-buffer!

And if we indeed switch to emacs and type "n", the question doesn't go
away yet, until we type something into the *scratch* buffer.

If we instead use --fullscreen, we can't even see the mini-buffer (at
least in icewm.)

emacs-version "27.1"

bug#47556: "really open? (y)es or (n)o or (l)iterally" vs. emacsclient -n

[Jean Louis]

* 積丹尼 Dan Jacobson <jidanni@jidanni.org> [2021-04-02 03:00]:
> $ emacs -Q --maximized -eval '(server-start)'&

I like when Emacs starts maximized. That is why I have put this in
~/.emacs.d/early-init.el:

(add-to-list 'default-frame-alist '(fullscreen . maximized))

That way each time it starts maximized.

> $ emacsclient -n big.jpg
> big.jpg is large (14.5 MiB), really open? (y)es or (n)o or (l)iterally
> Alas in this case our y, n, or l's are not being read by the
> mini-buffer!

I do not observe this in Emacs development version. I have tested this
in Emacs development version and when I do that, I am shown the frame
that I have started and the minibuffer and question in the minibuffer,
and I could answer with "y" and see the large file.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

bug#47556: "really open? (y)es or (n)o or (l)iterally" vs. emacsclient -n

[Jean Louis]

* 積丹尼 Dan Jacobson <jidanni@jidanni.org> [2021-04-02 03:00]:
> $ emacs -Q --maximized -eval '(server-start)'&
> $ emacsclient -n big.jpg
> big.jpg is large (14.5 MiB), really open? (y)es or (n)o or (l)iterally
> Alas in this case our y, n, or l's are not being read by the mini-buffer!
> 
> And if we indeed switch to emacs and type "n", the question doesn't go
> away yet, until we type something into the *scratch* buffer.
> 
> If we instead use --fullscreen, we can't even see the mini-buffer (at
> least in icewm.)
> 
> emacs-version "27.1"

I am also using IceWM. I have tested in Emacs development version more
of this, as you said --fullscreen, and I did not observe that
behavior. I have tried answering Y and N and all is fine.

So it is read by minibuffer in Emacs development version.

It is true that message remains longer in minibuffer, this disturbs me
sometimes.

My hope is that my IceWm settings do not interfere with this testing,
as I have in ~/.icewm/window this below inhibiting the title bar, I
don't think it interferes.

emacs.dTitleBar: 0
emacsclient.dTitleBar: 0


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

bug#47556: "really open? (y)es or (n)o or (l)iterally" vs. emacsclient -n

[積丹尼 Dan Jacobson]

>>>>> "JL" == Jean Louis <bugs@gnu.support> writes:
JL> It is true that message remains longer in minibuffer, this disturbs me
JL> sometimes.

OK then just somebody fix that only please,
as all the icemw stuff might be due to our icewm init files,
and newer fixes with icewm upstream with various versions.