set-frame-width (and interactive resizing) lie about actual width

set-frame-width (and interactive resizing) lie about actual width

[Ronan Waide]

In GNU Emacs 21.2.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-04-08 on porky.devel.redhat.com
configured using `configure  i386-redhat-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --with-gcc --with-pop --with-sound'
Important settings:
  value of $LC_ALL: nil
  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: en_IE@euro
  locale-coding-system: iso-latin-9
  default-enable-multibyte-characters: nil

I've done a little searching on Google and can't find if this bug is,
in fact, a known bug. My current version of Emacs appears to be
confused about the width of the frame in characters; if I try an
interactive resize (i.e. grab frame with pointer, drag), the window
manager's helper box in the top right showing me the current
dimensions claims that the window is 80 characters wide when in fact
it is 102. Likewise, if I do (set-frame-width (selected-frame) 80) I
get a 102-char wide window. I've traced the problem to my X Resources
file, attached here:

*Background: Black
*Foreground: White
*pointerColor: White
*cursorColor: White
*bitmapIcon: on
*font: -misc-fixed-medium-r-normal--14-140-75-*-c-*-iso8859-15

I guess the font setting is causing the problem. However, I don't
understand WHY it's causing the problem.

Any suggestions?

Cheers,
Waider.
-- 
waider@waider.ie / Yes, it /is/ very personal of me.

"I always thought of Reality as Diplomacy without the board, rules or
 consistent players." - Dalton.

Re: set-frame-width (and interactive resizing) lie about actual width

[Richard Stallman]

This bug is known, and a few years ago I tried making changes
to try to fix it--but each change that fixed one case just made
another case fail.

What we really need is for someone with a thorough understanding of X
programming to redo that part of Emacs.  I never understood X well enough
myself to do it.