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

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

[Ted Phelps]

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)

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

[Chong Yidong]

Hi Jan,

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


Ted Phelps <phelps@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.

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

[Jan Djärv]

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)
>
>
>
>
>

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

[Jan Djärv]

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.

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

[Jan Djärv]

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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 06 Apr 2010 20:54:24 +0200, Jan Djärv <jan.h.d@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@math.s.chiba-u.ac.jp

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

[Ted Phelps]

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

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

[Ted Phelps]

=?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

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

[Ted Phelps]

=?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

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

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-04-07 02.16:
>>>>>> On Tue, 06 Apr 2010 20:54:24 +0200, Jan Djärv<jan.h.d@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.

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

[Ted Phelps]

=?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

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

[Jan Djärv]

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.

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

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-04-07 02.16:
>>>>>> On Tue, 06 Apr 2010 20:54:24 +0200, Jan Djärv<jan.h.d@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.

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

[Jan Djärv]

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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 07 Apr 2010 11:18:25 +0200, Jan Djärv <jan.h.d@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@math.s.chiba-u.ac.jp

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

[Ted Phelps]

=?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

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

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]



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.

[-- Attachment #2: iwb1.png --]
[-- Type: image/png, Size: 46013 bytes --]

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

[Jan Djärv]

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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 07 Apr 2010 12:03:58 +0200, Jan Djärv <jan.h.d@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@math.s.chiba-u.ac.jp

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

[Jan Djärv]

Hi.

A correction has been made in the trunk.

	Jan D.

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

[Jan Djärv]

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.
> 

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

[Chong Yidong]

Jan Djärv <jan.h.d@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.

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

[Jan Djärv]

Chong Yidong skrev:
> Jan Djärv <jan.h.d@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.

bug#5848: closed by Jan Djärv <jan.h.d@swipnet.se> (Re: bug#5848: 23.1.95; bands of background after font change if --with-x-toolkit=no)

[Ted Phelps]

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@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