coord conversion: frame->column_width set wrong?

coord conversion: frame->column_width set wrong?

[jbyler+emacs-lists]

I'd like to reopen discussion on an apparent problem with the conversion
from canonical coordinates to pixel coordinates.  I believe that the
frame->column_width value is being set up incorrectly in X Windows on my
Red Hat 9 system.  The symptom is that windmove doesn't work well, but
the problem can be observed by running some tests I will describe below.
 My results:

        5/14/2003 build from CVS   6/~12/04 build from CVS

-nw        good                        good

X/11       good                        *bug*

Setup: emacs -q &
M-x scroll-bar-mode
M-x fringe-mode (none)
M-x tool-bar-mode
M-x menu-bar-mode
... to get a bare-bones frame.

Tests:
(coordinates-in-window-p '( 0 . 0) (selected-window))
should return: (0 . 0)
bug condition returns: nil

(window-at 0 0)
should return: #<window 3 on *scratch*> (or similar)
bug condition returns: nil

(coordinates-in-window-p '( 1 . 1) (selected-window))
should return: (1 . 1)
bug condition returns: (0.8571428571428571 . 0.9230769230769231)



Looking through the changes made to the functions in question, I came
across only one significant change that I think could have caused this:

Name changes:
coordinates-in-window-p uses the macro
PIXEL_X_FROM_CANON_X -> FRAME_PIXEL_X_FROM_CANON_X
which calls 
CANON_X_UNIT -> FRAME_COLUMN_WIDTH

On a window system, CANON_X_UNIT was a wrapper for
FRAME_DEFAULT_FONT_WIDTH, defined in xterm.h, macterm.h, and w32term.h. 
FRAME_DEFAULT_FONT_WIDTH no longer exists, and in its place,
FRAME_COLUMN_WIDTH simply reads the field column_width from the frame
data structure.  This value gets initialized to 1 in make_frame, but I
couldn't find a place where it gets set based on the font.  Perhaps it
isn't being set at all?




Some clips from prior discussion:

Robert J. Chassell, Re: windmove and the minibuffer
http://lists.gnu.org/archive/html/emacs-devel/2003-05/msg00952.html

Luc Teirlinck, Re: windmove and the minibuffer
http://lists.gnu.org/archive/html/emacs-devel/2003-06/msg00007.html

Luc Teirlinck, Re: ruler-mode is broken
http://lists.gnu.org/archive/html/emacs-pretest-bug/2003-10/msg00142.html


Thanks,
Jesse Byler
-----

The information contained in this electronic mail
and any attached document is the confidential and
proprietary business information of Forum Systems,
Inc. It is intended solely for the addressed
recipient listed above. It may not be distributed
in any manner without the express written consent
of Forum Systems, Inc.

Re: coord conversion: frame->column_width set wrong?

[Jan D.]

jbyler+emacs-lists@anon41.eml.cc wrote:

> Tests:
> (coordinates-in-window-p '( 0 . 0) (selected-window))
> should return: (0 . 0)
> bug condition returns: nil
> 
> (window-at 0 0)
> should return: #<window 3 on *scratch*> (or similar)
> bug condition returns: nil
> 
> (coordinates-in-window-p '( 1 . 1) (selected-window))
> should return: (1 . 1)
> bug condition returns: (0.8571428571428571 . 0.9230769230769231)
> 


> Name changes:
> coordinates-in-window-p uses the macro
> PIXEL_X_FROM_CANON_X -> FRAME_PIXEL_X_FROM_CANON_X
> which calls 
> CANON_X_UNIT -> FRAME_COLUMN_WIDTH
> 
> On a window system, CANON_X_UNIT was a wrapper for
> FRAME_DEFAULT_FONT_WIDTH, defined in xterm.h, macterm.h, and w32term.h. 
> FRAME_DEFAULT_FONT_WIDTH no longer exists, and in its place,
> FRAME_COLUMN_WIDTH simply reads the field column_width from the frame
> data structure.  This value gets initialized to 1 in make_frame, but I
> couldn't find a place where it gets set based on the font.  Perhaps it
> isn't being set at all?

It is being set in xterm.c, x_new_font:
   FRAME_COLUMN_WIDTH (f) = FONT_WIDTH (FRAME_FONT (f));

The inconsistency seems to have another cause, see the thread
"Fix `window-at' and `coordinates-in-window-p'"

	Jan D.

Re: coord conversion: frame->column_width set wrong?

[jbyler+emacs-lists]

On Sun, 25 Jul 2004 12:49:14 +0200, "Jan D." <jan.h.d@swipnet.se> said:
> jbyler+emacs-lists@anon41.eml.cc wrote:
> 
> > Tests:
> > (coordinates-in-window-p '( 0 . 0) (selected-window))
> > should return: (0 . 0)
> > bug condition returns: nil
> > 
> > (window-at 0 0)
> > should return: #<window 3 on *scratch*> (or similar)
> > bug condition returns: nil
> > 
> > (coordinates-in-window-p '( 1 . 1) (selected-window))
> > should return: (1 . 1)
> > bug condition returns: (0.8571428571428571 . 0.9230769230769231)
> > 
> 
> 
> > Name changes:
> > coordinates-in-window-p uses the macro
> > PIXEL_X_FROM_CANON_X -> FRAME_PIXEL_X_FROM_CANON_X
> > which calls 
> > CANON_X_UNIT -> FRAME_COLUMN_WIDTH
> > 
> > On a window system, CANON_X_UNIT was a wrapper for
> > FRAME_DEFAULT_FONT_WIDTH, defined in xterm.h, macterm.h, and w32term.h. 
> > FRAME_DEFAULT_FONT_WIDTH no longer exists, and in its place,
> > FRAME_COLUMN_WIDTH simply reads the field column_width from the frame
> > data structure.  This value gets initialized to 1 in make_frame, but I
> > couldn't find a place where it gets set based on the font.  Perhaps it
> > isn't being set at all?
> 
> It is being set in xterm.c, x_new_font:
>    FRAME_COLUMN_WIDTH (f) = FONT_WIDTH (FRAME_FONT (f));
> 
> The inconsistency seems to have another cause, see the thread
> "Fix `window-at' and `coordinates-in-window-p'"
> 
> 	Jan D.


Thanks!  This problem has been fixed in current CVS emacs, and all my
tests for coordinates-in-window-p and window-at on a "naked" frame now
work as expected.  I tested on RedHat 9 with the default toolkit, also
with GTK (--with-x-toolkit=gtk), and finally with -nw.

-Jesse
-----

The information contained in this electronic mail
and any attached document is the confidential and
proprietary business information of Forum Systems,
Inc. It is intended solely for the addressed
recipient listed above. It may not be distributed
in any manner without the express written consent
of Forum Systems, Inc.