GNU bug report logs - #18107
emacsclient: maximization and size hints

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18107 in the body.
You can then email your comments to 18107 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: emacsclient: maximization and size hints
Date: Fri, 25 Jul 2014 12:52:05 -0300

When you call emacsclient like this:

   emacsclient -c  -F "((fullscreen . maximized))"

the maximization ignores the size hints and some residual area could
be left behind, looking like a phantom modeline below the real one.
This doesn't happen when you manually or programatically maximize
emacs after launch. Extra space could be reserved at the east and
south edges, of course, because of the multiple-of-char-size
restriction, but this extra space is correctly painted with the
background color. It seems to me like some issue with the order of the
initialization sequence.

Nevertheless, I believe this is mostly irrelevant for 24.4 as the
multiple-of-char-size restriction would be no more binding.

Message #8 received at 18107 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Carlos Pita <carlosjosepita <at> gmail.com>, 18107 <at> debbugs.gnu.org
Subject: Re: bug#18107: emacsclient: maximization and size hints
Date: Sat, 26 Jul 2014 11:00:29 +0200

> When you call emacsclient like this:
>
>     emacsclient -c  -F "((fullscreen . maximized))"
>
> the maximization ignores the size hints and some residual area could
> be left behind, looking like a phantom modeline below the real one.
> This doesn't happen when you manually or programatically maximize
> emacs after launch. Extra space could be reserved at the east and
> south edges, of course, because of the multiple-of-char-size
> restriction, but this extra space is correctly painted with the
> background color. It seems to me like some issue with the order of the
> initialization sequence.
>
> Nevertheless, I believe this is mostly irrelevant for 24.4 as the
> multiple-of-char-size restriction would be no more binding.

Sorry, I completely fail to understand what you did.  What is a "phantom
modeline below the real one"?  Which version did you use on which build?

Thanks, martin

Message #11 received at 18107 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Carlos Pita <carlosjosepita <at> gmail.com>, 18107 <at> debbugs.gnu.org
Subject: Re: bug#18107: emacsclient: maximization and size hints
Date: Sat, 26 Jul 2014 11:32:16 +0200

> this is a problem I've seen many times with terminals running inside tiling
> window managers that doesn't honor size hints. Sometimes the client gets
> resized and a previously rendered area (usually at the bottom) is not
> cleared, because the client itself asumes it's not in charge of that area
> (because of the size hints it exposes, requiring to be resized at char size
> multiples). Well, that's happening in latest 24.3 when launched the way I
> described. I guess that, in order to reoroduce the issue, you will have to
> set an initial geometry heigher than you screen, so that maximization turns
> the window shorter. The phantom modeline will be then just a residual copy
> of the modeline in an area outside of the geometry hinted by emacs, at the
> very bottom of the frame. Hope it's clear now. Also, I tested this with the
> latest pretest and it's not happening anymore because of the new resizing
> policy. Cheers, Carlos.

So can we close this bug?

martin

Message #16 received at 18107-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Carlos Pita <carlosjosepita <at> gmail.com>, 18107-done <at> debbugs.gnu.org
Subject: Re: bug#18107: emacsclient: maximization and size hints
Date: Sat, 26 Jul 2014 11:43:13 +0200

> If 24.3 gets no fixes of its own,

It won't.

> then I guess 24.4 closes this issue, yes.
> I reported it just in case and because I 'm not fully aware of the
> maintenance schedule and policy. Cheers.

Closed.

Thanks, martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.