bug-gnu-emacs
[Top][All Lists]
Advanced

[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 <address@hidden> 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
                                address@hidden






reply via email to

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