[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#5268: 23.1.90; # of rows/columns not adjusted by change of internal-
From: |
YAMAMOTO Mitsuharu |
Subject: |
bug#5268: 23.1.90; # of rows/columns not adjusted by change of internal-border-width for fullscreen frames |
Date: |
Sun, 27 Dec 2009 13:09:47 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) |
>>>>> On Sat, 26 Dec 2009 09:55:36 +0100, martin rudalics <rudalics@gmx.at>
>>>>> said:
>> 1. emacs -Q
>> 2. (set-frame-parameter nil 'fullscreen 'fullboth) C-j
>> 3. (frame-parameter nil 'width) C-j [which gives 176 for me]
> Gives 156 here.
>> 4. (set-frame-parameter nil 'font "-*-courier-*--20-*") C-j
>> 5. (frame-parameter nil 'width) C-j [which gives 112 for me]
> Gives 102 here and the frame is still full size. But if I now do
> (set-frame-parameter nil 'font "-*-courier-*--12-*")
> the frame is sized down and
> (frame-parameter nil 'width)
> still evaluates to 102 (after doing that the frame sometimes misses its
> modeline, for whatever reason).
> With GNU Emacs 23.1.90.1 (i386-mingw-nt5.1.2600) of 2009-12-14 so any
> differences we see might be related to our ports.
On Ubuntu 9.10 (GTK+ build), it gives 176 again and the frame size is
kept in fullscreen and the modeline visible. FWIW, the Mac port I'm
distributing
(http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00466.html)
gives a similar result.
I think such adjustment of the number of rows/columns for a fullscreen
frame is the intended and expected behavior for operations that would
require the change of the frame size if the frame were an ordinary
one. That's why I thought the current behavior of the
`internal-border-width' case was not by intention.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp