GNU bug report logs - #5848
23.1.95; bands of background after font change if --with-x-toolkit=no

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 5848 in the body.
You can then email your comments to 5848 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: Ted Phelps <phelps <at> pobox.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1.95; bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 00:25:35 +1000

After changing the default font via the options menu, my Emacs frame
exhibits bands of the background colour along the bottom and right
edges.  In my case these are 5 pixels wide.  Resizing the window removes
these bands, but changing the default font re-introduces them.
Emacs-23.1 does not exhibit this behavior.

I have bisected the revision history and determined that the change
occurred with v1.1048 of emacs/src/xterm.c:

    http://osdir.com/ml/emacs-diffs-gnu/2009-10/msg00381.html

To be precise, reverting the changes to pixelheight and pixelwidth at
the beginning of the "@@ -8833,16 +8884,24 @@" blob in
x_set_widnow_size_1 cause these bands to disappear.

The definitions of FRAME_TEXT_LINES_TO_PIXEL_HEIGHT and
FRAME_TEXT_COLS_TO_PIXEL_WIDTH already account for the frame's internal
border, so adding them in again seems superfluous.

I note that when the gtk toolkit is in use, the x_set_window_size_1
function isn't ordinarily called, so most folks won't have seen this
behavior.

Thanks,
-Ted


In GNU Emacs 23.1.95.1 (x86_64-unknown-linux-gnu)
 of 2010-04-06 on orpheus
Windowing system distributor `The X.Org Foundation', version 11.0.10800000
configured using `configure  'CFLAGS=-Wall -O3 -pipe' '--without-sound' '--enable-asserts' '--with-x-toolkit=no''

Important settings:
  value of $LC_ALL: en_AU.UTF-8
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: MH-Folder

Minor modes in effect:
  hl-line-mode: t
  delete-selection-mode: t
  global-quilt-mode: t
  quilt-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<tab> b <tab> <return> <switch-frame> F n C-SPC C-n 
C-e C-p <return> SPC C-a C-g J b <return> t J b x 5 
5 g t C-x o C-s p h e l p s C-a C-x o t d x 9 1 g <return> 
n t n <return> t n C-SPC C-e C-n C-n C-n C-n C-n C-n 
C-n C-n F c C-a C-n <return> n n n n t n n n n n n 
n n n n n n n n n n n p C-SPC C-e F c <return> n n 
t n n p <return> SPC SPC t n C-SPC C-n C-e C-n F c 
x F n C-v <switch-frame> C-h v i s <tab> <backspace> 
<backspace> v i s <tab> i <tab> b <backspace> b e <tab> 
<return> M-: ( s e t q SPC v i s i b l e - b e l l 
SPC t ) <return> C-g C-g C-g C-g C-g C-g C-g C-g C-g 
C-g C-g C-x o C-g C-g C-n C-p C-n C-x o C-x 1 C-g C-g 
C-g C-g C-g C-g C-g C-g C-g C-g M-> C-g C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-g C-g C-g C-g <switch-frame> 9 6 h 9 6 g p p n <return> 
d d d d d d C-p <return> n d t d x <switch-frame> <switch-frame> 
<switch-frame> M-: M-p C-g C-g C-g C-g C-g C-g C-g 
C-g C-g C-g C-g C-g C-g C-g C-g C-g C-g C-g C-g C-g 
C-g C-g C-g C-g C-g C-g C-g M-: M-p C-g C-g C-g C-g 
C-g C-g C-g C-g C-g C-g C-g <switch-frame> M-x b u 
g <tab> <M-backspace> r e p o <tab> r t <tab> e <tab> 
<backspace> <return>

Recent messages:
Making completion list... [2 times]
Type C-x 1 to delete the help window.
t
Quit [23 times]
Mark set
Quit [5 times]
No more undeleted messages
Processing deletes and refiles for +mhe-index/sequence/unseen...done
Quit [38 times]
Making completion list... [2 times]

Load-path shadows:
~/env/emacs/quilt hides /usr/local/share/emacs/site-lisp/quilt
~/env/emacs/m4-mode hides /usr/local/share/emacs/23.1.95/lisp/progmodes/m4-mode

Features:
(shadow sort emacsbug help-fns parse-time vc-cvs python-21 python comint
ring help-mode flow-fill mh-thread vc-rcs newcomment ispell mh-identity
mh-letter mh-comp cal-move mh-alias crm multi-isearch mail-extr mh-mime
mh-gnus mh-junk mule-util mh-search mh-show goto-addr thingatpt
gnus-cite gnus-art mm-uu mml2015 pgg pgg-parse pgg-def epg-config
mm-view smime dig gnus-sum nnoo gnus-group gnus-undo nnmail mail-source
format-spec gnus-start gnus-spec gnus-int message sendmail ecomplete
rfc822 mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap
mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums gmm-utils mailheader
canlock sha1 hex-util hashcash gnus-win gnus-range gnus gnus-ems
nnheader mail-utils mm-util mail-prsvr wid-edit mh-seq mh-inc hl-line
mh-tool-bar mh-xface mh-utils mh-folder which-func imenu gnus-util netrc
time-date mh-scan pp view cal-china lunar solar cal-dst cal-bahai
cal-islam cal-hebrew holidays hol-loaddefs appt diary-lib diary-loaddefs
cal-menu easymenu calendar cal-loaddefs browse-url delsel server mh-e
mh-compat mailabbrev mh-acros cl cl-19 mh-buffers mh-loaddefs cc-styles
cc-align cc-engine cc-vars cc-defs regexp-opt tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces
cus-face files text-properties overlay md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote
make-network-process dbusbind system-font-setting font-render-setting x
multi-tty emacs)

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Ted Phelps <phelps <at> pobox.com>, 5848 <at> debbugs.gnu.org
Subject: Re: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Tue, 06 Apr 2010 12:20:54 -0400

Hi Jan,

Could you doublecheck your change to xterm.c?  Thanks.


Ted Phelps <phelps <at> pobox.com> wrote:

> After changing the default font via the options menu, my Emacs frame
> exhibits bands of the background colour along the bottom and right
> edges.  In my case these are 5 pixels wide.  Resizing the window removes
> these bands, but changing the default font re-introduces them.
> Emacs-23.1 does not exhibit this behavior.
>
> I have bisected the revision history and determined that the change
> occurred with v1.1048 of emacs/src/xterm.c:
>
>     http://osdir.com/ml/emacs-diffs-gnu/2009-10/msg00381.html
>
> To be precise, reverting the changes to pixelheight and pixelwidth at
> the beginning of the "@@ -8833,16 +8884,24 @@" blob in
> x_set_widnow_size_1 cause these bands to disappear.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Ted Phelps <phelps <at> pobox.com>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Tue, 06 Apr 2010 19:49:32 +0200

Can you say what window manager you are running and which fonts you are 
changing to and from?

	Jan D.


Ted Phelps skrev 2010-04-06 16.25:
> After changing the default font via the options menu, my Emacs frame
> exhibits bands of the background colour along the bottom and right
> edges.  In my case these are 5 pixels wide.  Resizing the window removes
> these bands, but changing the default font re-introduces them.
> Emacs-23.1 does not exhibit this behavior.
>
> I have bisected the revision history and determined that the change
> occurred with v1.1048 of emacs/src/xterm.c:
>
>      http://osdir.com/ml/emacs-diffs-gnu/2009-10/msg00381.html
>
> To be precise, reverting the changes to pixelheight and pixelwidth at
> the beginning of the "@@ -8833,16 +8884,24 @@" blob in
> x_set_widnow_size_1 cause these bands to disappear.
>
> The definitions of FRAME_TEXT_LINES_TO_PIXEL_HEIGHT and
> FRAME_TEXT_COLS_TO_PIXEL_WIDTH already account for the frame's internal
> border, so adding them in again seems superfluous.
>
> I note that when the gtk toolkit is in use, the x_set_window_size_1
> function isn't ordinarily called, so most folks won't have seen this
> behavior.
>
> Thanks,
> -Ted
>
>
> In GNU Emacs 23.1.95.1 (x86_64-unknown-linux-gnu)
>   of 2010-04-06 on orpheus
> Windowing system distributor `The X.Org Foundation', version 11.0.10800000
> configured using `configure  'CFLAGS=-Wall -O3 -pipe' '--without-sound' '--enable-asserts' '--with-x-toolkit=no''
>
> Important settings:
>    value of $LC_ALL: en_AU.UTF-8
>    value of $LC_COLLATE: nil
>    value of $LC_CTYPE: nil
>    value of $LC_MESSAGES: nil
>    value of $LC_MONETARY: nil
>    value of $LC_NUMERIC: nil
>    value of $LC_TIME: nil
>    value of $LANG: nil
>    value of $XMODIFIERS: nil
>    locale-coding-system: utf-8-unix
>    default enable-multibyte-characters: t
>
> Major mode: MH-Folder
>
> Minor modes in effect:
>    hl-line-mode: t
>    delete-selection-mode: t
>    global-quilt-mode: t
>    quilt-mode: t
>    tooltip-mode: t
>    mouse-wheel-mode: t
>    menu-bar-mode: t
>    file-name-shadow-mode: t
>    global-font-lock-mode: t
>    font-lock-mode: t
>    blink-cursor-mode: t
>    auto-encryption-mode: t
>    auto-compression-mode: t
>    line-number-mode: t
>    transient-mark-mode: t
>
> Recent input:
> <tab>  b<tab>  <return>  <switch-frame>  F n C-SPC C-n
> C-e C-p<return>  SPC C-a C-g J b<return>  t J b x 5
> 5 g t C-x o C-s p h e l p s C-a C-x o t d x 9 1 g<return>
> n t n<return>  t n C-SPC C-e C-n C-n C-n C-n C-n C-n
> C-n C-n F c C-a C-n<return>  n n n n t n n n n n n
> n n n n n n n n n n n p C-SPC C-e F c<return>  n n
> t n n p<return>  SPC SPC t n C-SPC C-n C-e C-n F c
> x F n C-v<switch-frame>  C-h v i s<tab>  <backspace>
> <backspace>  v i s<tab>  i<tab>  b<backspace>  b e<tab>
> <return>  M-: ( s e t q SPC v i s i b l e - b e l l
> SPC t )<return>  C-g C-g C-g C-g C-g C-g C-g C-g C-g
> C-g C-g C-x o C-g C-g C-n C-p C-n C-x o C-x 1 C-g C-g
> C-g C-g C-g C-g C-g C-g C-g C-g M->  C-g C-p C-p C-p
> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p
> C-g C-g C-g C-g<switch-frame>  9 6 h 9 6 g p p n<return>
> d d d d d d C-p<return>  n d t d x<switch-frame>  <switch-frame>
> <switch-frame>  M-: M-p C-g C-g C-g C-g C-g C-g C-g
> C-g C-g C-g C-g C-g C-g C-g C-g C-g C-g C-g C-g C-g
> C-g C-g C-g C-g C-g C-g C-g M-: M-p C-g C-g C-g C-g
> C-g C-g C-g C-g C-g C-g C-g<switch-frame>  M-x b u
> g<tab>  <M-backspace>  r e p o<tab>  r t<tab>  e<tab>
> <backspace>  <return>
>
> Recent messages:
> Making completion list... [2 times]
> Type C-x 1 to delete the help window.
> t
> Quit [23 times]
> Mark set
> Quit [5 times]
> No more undeleted messages
> Processing deletes and refiles for +mhe-index/sequence/unseen...done
> Quit [38 times]
> Making completion list... [2 times]
>
> Load-path shadows:
> ~/env/emacs/quilt hides /usr/local/share/emacs/site-lisp/quilt
> ~/env/emacs/m4-mode hides /usr/local/share/emacs/23.1.95/lisp/progmodes/m4-mode
>
> Features:
> (shadow sort emacsbug help-fns parse-time vc-cvs python-21 python comint
> ring help-mode flow-fill mh-thread vc-rcs newcomment ispell mh-identity
> mh-letter mh-comp cal-move mh-alias crm multi-isearch mail-extr mh-mime
> mh-gnus mh-junk mule-util mh-search mh-show goto-addr thingatpt
> gnus-cite gnus-art mm-uu mml2015 pgg pgg-parse pgg-def epg-config
> mm-view smime dig gnus-sum nnoo gnus-group gnus-undo nnmail mail-source
> format-spec gnus-start gnus-spec gnus-int message sendmail ecomplete
> rfc822 mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap
> mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums gmm-utils mailheader
> canlock sha1 hex-util hashcash gnus-win gnus-range gnus gnus-ems
> nnheader mail-utils mm-util mail-prsvr wid-edit mh-seq mh-inc hl-line
> mh-tool-bar mh-xface mh-utils mh-folder which-func imenu gnus-util netrc
> time-date mh-scan pp view cal-china lunar solar cal-dst cal-bahai
> cal-islam cal-hebrew holidays hol-loaddefs appt diary-lib diary-loaddefs
> cal-menu easymenu calendar cal-loaddefs browse-url delsel server mh-e
> mh-compat mailabbrev mh-acros cl cl-19 mh-buffers mh-loaddefs cc-styles
> cc-align cc-engine cc-vars cc-defs regexp-opt tooltip ediff-hook
> vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd
> fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
> select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu
> font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
> thai tai-viet lao korean japanese hebrew greek romanian slovak czech
> european ethiopic indian cyrillic chinese case-table epa-hook
> jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces
> cus-face files text-properties overlay md5 base64 format env code-pages
> mule custom widget hashtable-print-readable backquote
> make-network-process dbusbind system-font-setting font-render-setting x
> multi-tty emacs)
>
>
>
>
>

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Ted Phelps <phelps <at> pobox.com>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Tue, 06 Apr 2010 19:57:49 +0200

Ted Phelps skrev 2010-04-06 16.25:
>
> The definitions of FRAME_TEXT_LINES_TO_PIXEL_HEIGHT and
> FRAME_TEXT_COLS_TO_PIXEL_WIDTH already account for the frame's internal
> border, so adding them in again seems superfluous.
>

It would be if the internal border width was added, but it isn't.  There is 
border_width and internal_border_width.  Internal border is what Emacs uses to 
indicate that a frame has focus.  Border width is what is sent to the X server 
when creating the window.  That border is on the outside of the window.

Can you run in gdb and check the values for f->border_width and 
f->internal_border_width?

	Jan D.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Ted Phelps <phelps <at> pobox.com>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Tue, 06 Apr 2010 20:54:24 +0200

Ted Phelps skrev 2010-04-06 16.25:
> After changing the default font via the options menu, my Emacs frame
> exhibits bands of the background colour along the bottom and right
> edges.  In my case these are 5 pixels wide.  Resizing the window removes
> these bands, but changing the default font re-introduces them.
> Emacs-23.1 does not exhibit this behavior.
>
> I have bisected the revision history and determined that the change
> occurred with v1.1048 of emacs/src/xterm.c:
>
>      http://osdir.com/ml/emacs-diffs-gnu/2009-10/msg00381.html
>
> To be precise, reverting the changes to pixelheight and pixelwidth at
> the beginning of the "@@ -8833,16 +8884,24 @@" blob in
> x_set_widnow_size_1 cause these bands to disappear.
>
> The definitions of FRAME_TEXT_LINES_TO_PIXEL_HEIGHT and
> FRAME_TEXT_COLS_TO_PIXEL_WIDTH already account for the frame's internal
> border, so adding them in again seems superfluous.
>

Cool, reverting those two lines makes metacity crash, over and over again. 
Oboy...

Anyhow, the external border width should not be part of pixelwidth/height, but 
there is ore to it.  Look:

/* Return the pixel width/height of frame F if it has
   COLS columns/LINES rows.  */

#define FRAME_TEXT_COLS_TO_PIXEL_WIDTH(f, cols) \
  (FRAME_COL_TO_PIXEL_X (f, cols) \
   + (f)->scroll_bar_actual_width \
   + FRAME_TOTAL_FRINGE_WIDTH (f)      \
   + FRAME_INTERNAL_BORDER_WIDTH (f))

#define FRAME_TEXT_LINES_TO_PIXEL_HEIGHT(f, lines) \
  (FRAME_LINE_TO_PIXEL_Y (f, lines) \
   + FRAME_INTERNAL_BORDER_WIDTH (f))


and

#define FRAME_INTERNAL_BORDER_WIDTH(F) ((F)->internal_border_width)

But the internal border is on two sides, so it should be 
2*FRAME_INTERNAL_BORDER_WIDTH (f).

I see that w32 also uses these macros.  Can there be trouble there if I change 
them?

I can't see the original problem though, the window manager is supposed to 
apply wm size hints so those 5 pixels disappears.

	Jan D.

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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Ted Phelps <phelps <at> pobox.com>, 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 09:16:05 +0900

>>>>> On Tue, 06 Apr 2010 20:54:24 +0200, Jan Djärv <jan.h.d <at> swipnet.se> said:

> /* Return the pixel width/height of frame F if it has
>     COLS columns/LINES rows.  */

> #define FRAME_TEXT_COLS_TO_PIXEL_WIDTH(f, cols) \
>    (FRAME_COL_TO_PIXEL_X (f, cols) \
>     + (f)->scroll_bar_actual_width \
>     + FRAME_TOTAL_FRINGE_WIDTH (f)      \
>     + FRAME_INTERNAL_BORDER_WIDTH (f))

> #define FRAME_TEXT_LINES_TO_PIXEL_HEIGHT(f, lines) \
>    (FRAME_LINE_TO_PIXEL_Y (f, lines) \
>     + FRAME_INTERNAL_BORDER_WIDTH (f))


> and

> #define FRAME_INTERNAL_BORDER_WIDTH(F) ((F)->internal_border_width)

> But the internal border is on two sides, so it should be 
> 2*FRAME_INTERNAL_BORDER_WIDTH (f).

FRAME_COL_TO_PIXEL_X and FRAME_LINE_TO_PIXEL_Y include the left and
top side internal border width, respectively.  So, the internal border
is already counted twice in FRAME_TEXT_COLS_TO_PIXEL_WIDTH and
FRAME_TEXT_LINES_TO_PIXEL_HEIGHT above.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

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

From: Ted Phelps <phelps <at> mantara.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 11:43:48 +1000

Thanks for the speedy response!

=?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
> Can you say what window manager you are running and which fonts you are 
> changing to and from?

I'm using Window Maker (both 0.92.0 as shipped with Ubuntu 9.10 and a
fairly recent snapshot of their development tree), though twm also
exhibits the behavior.

Thanks,
-Ted

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

From: Ted Phelps <phelps <at> mantara.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 11:44:43 +1000

=?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
> 
> Ted Phelps skrev 2010-04-06 16.25:
> >
> > The definitions of FRAME_TEXT_LINES_TO_PIXEL_HEIGHT and
> > FRAME_TEXT_COLS_TO_PIXEL_WIDTH already account for the frame's internal
> > border, so adding them in again seems superfluous.
> 
> It would be if the internal border width was added, but it isn't.
> There is border_width and internal_border_width.  Internal border is
> what Emacs uses to indicate that a frame has focus.  Border width is
> what is sent to the X server when creating the window.  That border is
> on the outside of the window.

Right.

> Can you run in gdb and check the values for f->border_width and 
> f->internal_border_width?

f->border_width is 2
f->internal_border_width is 1

Thanks,
-Ted

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

From: Ted Phelps <phelps <at> mantara.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 11:46:32 +1000

=?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
> Can you say what window manager you are running and which fonts you are 
> changing to and from?

All of the fonts I've tried have produced the behavior: fixed,
lucidasanstypewriter-12, sony 8x16, several others.

-Ted

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Ted Phelps <phelps <at> mantara.com>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 11:42:19 +0200

Jan Djärv skrev 2010-04-07 10.23:
>

>
> Does this pixel disappear if you set internal border width to 0?
> I.e:
>
> (set-frame-parameter nil 'internal-border-width 0)
>

or simpler:

% emacs -xrm '*internalBorder: 0'

	Jan D.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Ted Phelps <phelps <at> pobox.com>, 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 11:18:25 +0200

YAMAMOTO Mitsuharu skrev 2010-04-07 02.16:
>>>>>> On Tue, 06 Apr 2010 20:54:24 +0200, Jan Djärv<jan.h.d <at> swipnet.se>  said:
>
>> /* Return the pixel width/height of frame F if it has
>>      COLS columns/LINES rows.  */
>
>> #define FRAME_TEXT_COLS_TO_PIXEL_WIDTH(f, cols) \
>>     (FRAME_COL_TO_PIXEL_X (f, cols) \
>>      + (f)->scroll_bar_actual_width \
>>      + FRAME_TOTAL_FRINGE_WIDTH (f)      \
>>      + FRAME_INTERNAL_BORDER_WIDTH (f))
>
>> #define w(f, lines) \
>>     (FRAME_LINE_TO_PIXEL_Y (f, lines) \
>>      + FRAME_INTERNAL_BORDER_WIDTH (f))
>
>
>> and
>
>> #define FRAME_INTERNAL_BORDER_WIDTH(F) ((F)->internal_border_width)
>
>> But the internal border is on two sides, so it should be
>> 2*FRAME_INTERNAL_BORDER_WIDTH (f).
>
> FRAME_COL_TO_PIXEL_X and FRAME_LINE_TO_PIXEL_Y include the left and
> top side internal border width, respectively.  So, the internal border
> is already counted twice in FRAME_TEXT_COLS_TO_PIXEL_WIDTH and
> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT above.

Upon further investigation, this is true for cols, but not always for lines.
We have

#define FRAME_LINE_TO_PIXEL_Y(f, row) \
  ((row < FRAME_TOP_MARGIN (f) ? 0 : FRAME_INTERNAL_BORDER_WIDTH (f))	\
   + (row) * FRAME_LINE_HEIGHT (f))


So if row is less than FRAME_TOP_MARGIN (which is menu bar lines + tool bar 
lines), internal border width is not added.  That makes sense for 
FRAME_LINE_TO_PIXEL_Y as the internal border is below the tool bar.  But it is 
not correct for
FRAME_TEXT_LINES_TO_PIXEL_HEIGHT, which is supposed to return the total frame 
size.  When setting wm size hints, this call

    base_height = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, 0);

will return just one internal border.  Thus, a pixel is missing.
Thanks for pointing me in the right direction.

	Jan D.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Ted Phelps <phelps <at> mantara.com>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 10:23:54 +0200

Ted Phelps skrev 2010-04-07 08.52:
> =?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
>> YAMAMOTO Mitsuharu skrev 2010-04-07 02.16:
>>> FRAME_COL_TO_PIXEL_X and FRAME_LINE_TO_PIXEL_Y include the left and
>>> top side internal border width, respectively.  So, the internal border
>>> is already counted twice in FRAME_TEXT_COLS_TO_PIXEL_WIDTH and
>>> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT above.
>>
>> Thanks for the clarification.  One pixel is still missing though, I'll
>> keep looking.
>
> I've had a closer look and that last pixel is still there when:
>
>    pixelwidth = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, cols);
>    pixelheight = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, rows);
>
> In this case, there's a one pixel border around the left, bottom and
> right edges of the frame.  Hopefully this helps you with your search?
> Or maybe this is the intended behavior?  I'll see if I can upload a
> screenshot...
>

Does this pixel disappear if you set internal border width to 0?
I.e:

(set-frame-parameter nil 'internal-border-width 0)

Anyway, when toolkit-x is no, the wm size hints are off by one pixel, so there 
is actually (font height)-1 extra pixels.

	Jan D.

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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Ted Phelps <phelps <at> pobox.com>, 5848 <at> debbugs.gnu.org,
	YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 18:48:22 +0900

>>>>> On Wed, 07 Apr 2010 11:18:25 +0200, Jan Djärv <jan.h.d <at> swipnet.se> said:

>> FRAME_COL_TO_PIXEL_X and FRAME_LINE_TO_PIXEL_Y include the left and
>> top side internal border width, respectively.  So, the internal border
>> is already counted twice in FRAME_TEXT_COLS_TO_PIXEL_WIDTH and
>> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT above.

> Upon further investigation, this is true for cols, but not always for lines.
> We have

> #define FRAME_LINE_TO_PIXEL_Y(f, row) \
>    ((row < FRAME_TOP_MARGIN (f) ? 0 : FRAME_INTERNAL_BORDER_WIDTH (f))	\
>     + (row) * FRAME_LINE_HEIGHT (f))


> So if row is less than FRAME_TOP_MARGIN (which is menu bar lines + tool bar 
> lines), internal border width is not added.  That makes sense for 
> FRAME_LINE_TO_PIXEL_Y as the internal border is below the tool bar.  But it is 
> not correct for
> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT, which is supposed to return the total frame 
> size.  When setting wm size hints, this call

>      base_height = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, 0);

> will return just one internal border.  Thus, a pixel is missing.
> Thanks for pointing me in the right direction.

FRAME_LINE_TO_PIXEL_Y used to be 

#define FRAME_LINE_TO_PIXEL_Y(f, row) \
  (FRAME_INTERNAL_BORDER_WIDTH (f)  \
   + (row) * FRAME_LINE_HEIGHT (f))

and I changed the definition as you quoted so it takes account of the
`row < FRAME_TOP_MARGIN (f)' case in order to draw and handle events
for non-toolkit menu/tool bars correctly.  Actually I seem to have
overlooked the `base_height' calculation by specifying 0 as the number
of lines.  (Also, `row' should have been parenthesized.)

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

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

From: Ted Phelps <phelps <at> mantara.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>,
	YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 16:52:40 +1000

=?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
> YAMAMOTO Mitsuharu skrev 2010-04-07 02.16:
> > FRAME_COL_TO_PIXEL_X and FRAME_LINE_TO_PIXEL_Y include the left and
> > top side internal border width, respectively.  So, the internal border
> > is already counted twice in FRAME_TEXT_COLS_TO_PIXEL_WIDTH and
> > FRAME_TEXT_LINES_TO_PIXEL_HEIGHT above.
> 
> Thanks for the clarification.  One pixel is still missing though, I'll
> keep looking.

I've had a closer look and that last pixel is still there when:

  pixelwidth = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, cols);
  pixelheight = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, rows);

In this case, there's a one pixel border around the left, bottom and
right edges of the frame.  Hopefully this helps you with your search?
Or maybe this is the intended behavior?  I'll see if I can upload a
screenshot...

Thanks,
-Ted

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

From: Ted Phelps <phelps <at> mantara.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 19:54:59 +1000

=?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
> Ted Phelps skrev 2010-04-07 08.52:
> > =?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
> >> YAMAMOTO Mitsuharu skrev 2010-04-07 02.16:
> >>> FRAME_COL_TO_PIXEL_X and FRAME_LINE_TO_PIXEL_Y include the left and
> >>> top side internal border width, respectively.  So, the internal border
> >>> is already counted twice in FRAME_TEXT_COLS_TO_PIXEL_WIDTH and
> >>> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT above.
> >>
> >> Thanks for the clarification.  One pixel is still missing though, I'll
> >> keep looking.
> >
> > I've had a closer look and that last pixel is still there when:
> >
> >    pixelwidth = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, cols);
> >    pixelheight = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, rows);
> >
> > In this case, there's a one pixel border around the left, bottom and
> > right edges of the frame.  Hopefully this helps you with your search?
> > Or maybe this is the intended behavior?  I'll see if I can upload a
> > screenshot...
> >
> 
> Does this pixel disappear if you set internal border width to 0?
> I.e:
> 
> (set-frame-parameter nil 'internal-border-width 0)

Yes, it does.

> Anyway, when toolkit-x is no, the wm size hints are off by one pixel,
> so there is actually (font height)-1 extra pixels.

Ok.

Thanks,
-Ted

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Ted Phelps <phelps <at> pobox.com>, 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 12:03:58 +0200

[Message part 1 (text/plain, inline)]

YAMAMOTO Mitsuharu skrev 2010-04-07 11.48:
>
> FRAME_LINE_TO_PIXEL_Y used to be
>
> #define FRAME_LINE_TO_PIXEL_Y(f, row) \
>    (FRAME_INTERNAL_BORDER_WIDTH (f)  \
>     + (row) * FRAME_LINE_HEIGHT (f))
>
> and I changed the definition as you quoted so it takes account of the
> `row<  FRAME_TOP_MARGIN (f)' case in order to draw and handle events
> for non-toolkit menu/tool bars correctly.  Actually I seem to have
> overlooked the `base_height' calculation by specifying 0 as the number
> of lines.  (Also, `row' should have been parenthesized.)

Ah, that explains why I didn't see it at the time I made my changes.
I'll fix it by not using FRAME_LINE_TO_PIXEL_Y in 
FRAME_TEXT_LINES_TO_PIXEL_HEIGHT.

I don't know if the OSX port uses this macros, but something is wrong there.
(set-frame-parameter nil 'internal-border-width 6) shifts the scrollbar 
outside the window (see screen shot).  A value of 10 will hide the scroll bar 
entirely.  Do you think that is a separate bug?

	Jan D.

[iwb1.png (image/png, attachment)]

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Ted Phelps <phelps <at> mantara.com>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 12:08:06 +0200

Ted Phelps skrev 2010-04-07 11.54:
> =?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
>>
>> Does this pixel disappear if you set internal border width to 0?
>> I.e:
>>
>> (set-frame-parameter nil 'internal-border-width 0)
>
> Yes, it does.
>

Thanks for testing.  So that pixel is actually the internal-border-width.
I'm not a big fan of any internal-border-width that is greater than zero myself.

	Jan D.

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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Ted Phelps <phelps <at> pobox.com>, 5848 <at> debbugs.gnu.org,
	YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 19:25:29 +0900

>>>>> On Wed, 07 Apr 2010 12:03:58 +0200, Jan Djärv <jan.h.d <at> swipnet.se> said:

> Ah, that explains why I didn't see it at the time I made my changes.
> I'll fix it by not using FRAME_LINE_TO_PIXEL_Y in
> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT.

Thanks.

> I don't know if the OSX port uses this macros, but something is
> wrong there.  (set-frame-parameter nil 'internal-border-width 6)
> shifts the scrollbar outside the window (see screen shot).  A value
> of 10 will hide the scroll bar entirely.  Do you think that is a
> separate bug?

Yes.  The NS port seems to put some own interpretation on
internal-border-width as I pointed out in
http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00594.html .

The Mac port should behave just as in X11, even for fullscreen frames.
(Actually, I noticed the problem with FRAME_LINE_TO_PIXEL_Y when I was
testing fullscreen frames with large internal-border-width.  The
non-toolkit tool bars are used for such frames because the Cocoa tool
bars can't be used for title-bar-less windows on Mac
http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00066.html)

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Ted Phelps <phelps <at> pobox.com>, 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 08:35:48 +0200

YAMAMOTO Mitsuharu skrev 2010-04-07 02.16:
>>>>>> On Tue, 06 Apr 2010 20:54:24 +0200, Jan Djärv<jan.h.d <at> swipnet.se>  said:
>
>> /* Return the pixel width/height of frame F if it has
>>      COLS columns/LINES rows.  */
>
>> #define FRAME_TEXT_COLS_TO_PIXEL_WIDTH(f, cols) \
>>     (FRAME_COL_TO_PIXEL_X (f, cols) \
>>      + (f)->scroll_bar_actual_width \
>>      + FRAME_TOTAL_FRINGE_WIDTH (f)      \
>>      + FRAME_INTERNAL_BORDER_WIDTH (f))
>
>> #define FRAME_TEXT_LINES_TO_PIXEL_HEIGHT(f, lines) \
>>     (FRAME_LINE_TO_PIXEL_Y (f, lines) \
>>      + FRAME_INTERNAL_BORDER_WIDTH (f))
>
>
>> and
>
>> #define FRAME_INTERNAL_BORDER_WIDTH(F) ((F)->internal_border_width)
>
>> But the internal border is on two sides, so it should be
>> 2*FRAME_INTERNAL_BORDER_WIDTH (f).
>
> FRAME_COL_TO_PIXEL_X and FRAME_LINE_TO_PIXEL_Y include the left and
> top side internal border width, respectively.  So, the internal border
> is already counted twice in FRAME_TEXT_COLS_TO_PIXEL_WIDTH and
> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT above.

Thanks for the clarification.  One pixel is still missing though, I'll keep 
looking.

	Jan D.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Ted Phelps <phelps <at> mantara.com>
Cc: 5848-done <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 13:56:30 +0200

Hi.

A correction has been made in the trunk.

	Jan D.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 14:06:17 +0200

Hi.

The error is present in the 23-branch as well, Shall I fix it there?

	Jan D.

> 
> A correction has been made in the trunk.
> 
>     Jan D.
> 

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 11:21:54 -0400

Jan Djärv <jan.h.d <at> swipnet.se> writes:

> The error is present in the 23-branch as well, Shall I fix it there?
>
> 	Jan D.

Since this is a regression against 23.1, yes.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 18:35:15 +0200

Chong Yidong skrev:
> Jan Djärv <jan.h.d <at> swipnet.se> writes:
> 
>> The error is present in the 23-branch as well, Shall I fix it there?
>>
>> 	Jan D.
> 
> Since this is a regression against 23.1, yes.

Checked in in emacs-23 branch also.

	Jan D.

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

From: Ted Phelps <phelps <at> mantara.com>
To: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848 closed by Jan Djärv
	<jan.h.d <at> swipnet.se> (Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no)
Date: Thu, 08 Apr 2010 10:26:47 +1000

GNU bug Tracking System writes:
> #5848: 23.1.95; bands of background after font change if --with-x-toolkit=no
> 
> It has been closed by Jan Dj=C3=A4rv <jan.h.d <at> swipnet.se>.

I can confirm that Jan's patch resolves the issue I reported.

As a bonus, it also fixes an issue which I had not yet reported where
the size of the mini-buffer (or, more likely, the whole frame) was too
large after a resize operation.

Thanks for the speedy resolution!

-Ted

Previous Next

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