pos-visible-in-window-p at ellipsis

pos-visible-in-window-p at ellipsis

[David Reitter]

Start an emacs -Q , presumably in as non-TTY  (tested with the Carbon  
port)

M-x latex-mode
M-x outline-minor-mode

Enter the following text into the buffer

\section{heading}
this is a sentence.

M-x hide-subtree
You should now see this:

\section{heading}...

Place the point at the ellipsis (...) and enter

M-: (pos-visible-in-window-p (point) nil 'partial) RET

Now hit C-f to place the point right after the ellipsis, and enter

M-: (pos-visible-in-window-p (point) nil 'partial) RET


The bug is that both `pos-visible-in-window-p' returns the same pixel  
coordinates at both positions.  According to the doc, " X and Y are  
the pixel coordinates relative to the top left corner of the window.",  
and I presume this refers to the coordinates of whatever the point is  
on.

This is practically relevant because I'm using that function to  
position the point in just the right place (i.e. maintain horizontal  
pixel position) when a user goes up or down a line (and C-n etc  
doesn't do that.)



In GNU Emacs 22.1.50.1 (i386-apple-darwin9.1.0, Carbon Version 1.6.0)
  of 2007-12-21 on scarlett
Windowing system distributor `Apple Inc.', version 10.5.1
configured using `configure  '--without-x' '--prefix=/usr/local''

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: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: LaTeX

Minor modes in effect:
   shell-dirtrack-mode: t
   outline-minor-mode: t
   encoded-kbd-mode: t
   tooltip-mode: t
   tool-bar-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
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: identity

Recent input:
<help-echo> <down-mouse-1> <mouse-1> <help-echo> <down-mouse-1>
<mouse-1> q M-a <up> C-k C-k C-k C-k C-k C-k <return>
<return> <return> t h i s SPC i s SPC a SPC <backspace>
n <backspace> <backspace> c o l l a p s e d SPC s e
n t e n c e <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> n o
t SPC a SPC s e n t e n c e . <up> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<S-right> <S-right> <left> <left> <escape> x o u t
l i <tab> e <tab> - m o <tab> <backspace> <backspace>
<backspace> i n <tab> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> m o d e <return> <help-echo>
<down-mouse-1> <mouse-1> <down-mouse-1> <mouse-movement>
<mouse-1> <double-down-mouse-1> <double-mouse-1> <help-echo>
<menu-bar> <hide> <hide-entry> <help-echo> <help-echo>
<help-echo> <down-mouse-1> <mouse-1> <up> <escape>
x l a t e x - m o d e <return> \ s e c i o n <backspace>
<backspace> <backspace> t i o n { h a d i n g <backspace>
<backspace> <backspace> <backspace> <backspace> e a
d i n g { <backspace> { <backspace> } <return> <help-echo>
<help-echo> <escape> x o u t l i n e - m i n o r -
m o d e <return> <help-echo> <menu-bar> <outline> <hide-subtree>
<right> <left> <escape> : M-v C-y <return> <right>
<escape> : C-y <return> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
Loading outline...done
outline-back-to-heading: before first heading
Loading tex-mode...
Loading regexp-opt...done
Loading tex-mode...done
Loading skeleton...done
Outline minor mode enabled
call-interactively: Beginning of buffer
(133 48) [2 times]
Loading emacsbug...done

Re: pos-visible-in-window-p at ellipsis

[Richard Stallman]

Would someone please DTRT then ack?


Message-Id: <B6295587-ED43-480F-8840-285E7BB09AA8@gmail.com>
From: David Reitter <david.reitter@gmail.com>
To: emacs-pretest-bug@gnu.org
Date: Sun, 23 Dec 2007 19:19:03 +0000
Cc: 
Subject: pos-visible-in-window-p at ellipsis

Start an emacs -Q , presumably in as non-TTY  (tested with the Carbon  
port)

M-x latex-mode
M-x outline-minor-mode

Enter the following text into the buffer

\section{heading}
this is a sentence.

M-x hide-subtree
You should now see this:

\section{heading}...

Place the point at the ellipsis (...) and enter

M-: (pos-visible-in-window-p (point) nil 'partial) RET

Now hit C-f to place the point right after the ellipsis, and enter

M-: (pos-visible-in-window-p (point) nil 'partial) RET


The bug is that both `pos-visible-in-window-p' returns the same pixel  
coordinates at both positions.  According to the doc, " X and Y are  
the pixel coordinates relative to the top left corner of the window.",  
and I presume this refers to the coordinates of whatever the point is  
on.

This is practically relevant because I'm using that function to  
position the point in just the right place (i.e. maintain horizontal  
pixel position) when a user goes up or down a line (and C-n etc  
doesn't do that.)



In GNU Emacs 22.1.50.1 (i386-apple-darwin9.1.0, Carbon Version 1.6.0)
  of 2007-12-21 on scarlett
Windowing system distributor `Apple Inc.', version 10.5.1
configured using `configure  '--without-x' '--prefix=/usr/local''

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: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: LaTeX

Minor modes in effect:
   shell-dirtrack-mode: t
   outline-minor-mode: t
   encoded-kbd-mode: t
   tooltip-mode: t
   tool-bar-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
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: identity

Recent input:
<help-echo> <down-mouse-1> <mouse-1> <help-echo> <down-mouse-1>
<mouse-1> q M-a <up> C-k C-k C-k C-k C-k C-k <return>
<return> <return> t h i s SPC i s SPC a SPC <backspace>
n <backspace> <backspace> c o l l a p s e d SPC s e
n t e n c e <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> n o
t SPC a SPC s e n t e n c e . <up> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<S-right> <S-right> <left> <left> <escape> x o u t
l i <tab> e <tab> - m o <tab> <backspace> <backspace>
<backspace> i n <tab> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> m o d e <return> <help-echo>
<down-mouse-1> <mouse-1> <down-mouse-1> <mouse-movement>
<mouse-1> <double-down-mouse-1> <double-mouse-1> <help-echo>
<menu-bar> <hide> <hide-entry> <help-echo> <help-echo>
<help-echo> <down-mouse-1> <mouse-1> <up> <escape>
x l a t e x - m o d e <return> \ s e c i o n <backspace>
<backspace> <backspace> t i o n { h a d i n g <backspace>
<backspace> <backspace> <backspace> <backspace> e a
d i n g { <backspace> { <backspace> } <return> <help-echo>
<help-echo> <escape> x o u t l i n e - m i n o r -
m o d e <return> <help-echo> <menu-bar> <outline> <hide-subtree>
<right> <left> <escape> : M-v C-y <return> <right>
<escape> : C-y <return> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
Loading outline...done
outline-back-to-heading: before first heading
Loading tex-mode...
Loading regexp-opt...done
Loading tex-mode...done
Loading skeleton...done
Outline minor mode enabled
call-interactively: Beginning of buffer
(133 48) [2 times]
Loading emacsbug...done



_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: pos-visible-in-window-p at ellipsis

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Start an emacs -Q , presumably in as non-TTY  (tested with the Carbon  
> port)
>
> M-x latex-mode
> M-x outline-minor-mode
>
> Enter the following text into the buffer
>
> \section{heading}
> this is a sentence.
>
> M-x hide-subtree
> You should now see this:
>
> \section{heading}...
>
> Place the point at the ellipsis (...) and enter
>
> M-: (pos-visible-in-window-p (point) nil 'partial) RET
>
> Now hit C-f to place the point right after the ellipsis, and enter
>
> M-: (pos-visible-in-window-p (point) nil 'partial) RET
>
> The bug is that both `pos-visible-in-window-p' returns the same pixel  
> coordinates at both positions.  According to the doc, " X and Y are  
> the pixel coordinates relative to the top left corner of the window.",  
> and I presume this refers to the coordinates of whatever the point is  
> on.

This happens because the pixel position reported by pos_visible_p can
overshoot when there is invisible text (see the comment in
xdisp.c:1321).  It would be rather complicated to compensate for this
(and potentially buggy since pos_visible_p is used by many other
functions).  I think we should simply change the documentation of
pos-visible-in-window-p to say that the pixel positions may not be
accurate when there is invisible text at the specified position.

Re: pos-visible-in-window-p at ellipsis

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

>  I think we should simply change the documentation of
> pos-visible-in-window-p to say that the pixel positions may not be
> accurate when there is invisible text at the specified position.

I agree.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: pos-visible-in-window-p at ellipsis

[Richard Stallman]

    This happens because the pixel position reported by pos_visible_p can
    overshoot when there is invisible text (see the comment in
    xdisp.c:1321).  It would be rather complicated to compensate for this
    (and potentially buggy since pos_visible_p is used by many other
    functions).

Why is invisible text difficult?  Can't it just skip to the
next visible character?  (The comment doesn't say what is hard.)

      I think we should simply change the documentation of
    pos-visible-in-window-p to say that the pixel positions may not be
    accurate when there is invisible text at the specified position.

That is ok if this really is hard.  I just wonder why it is hard,
since it seems like it ought to be easy.

Re: pos-visible-in-window-p at ellipsis

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     This happens because the pixel position reported by pos_visible_p can
>     overshoot when there is invisible text (see the comment in
>     xdisp.c:1321).  It would be rather complicated to compensate for this
>     (and potentially buggy since pos_visible_p is used by many other
>     functions).
>
> Why is invisible text difficult?  Can't it just skip to the
> next visible character?  (The comment doesn't say what is hard.)

It *does* skip, and that's the problem.  That means that to determine
the actual upper-left pixel position, you need to backtrack to
compensate for the skipping.  That's why invisible text is difficult.

Re: pos-visible-in-window-p at ellipsis

[Chong Yidong]

> M-x latex-mode
> M-x outline-minor-mode
>
> Enter the following text into the buffer
>
> \section{heading}
> this is a sentence.
>
> M-x hide-subtree
> You should now see this:
>
> \section{heading}...
>
> Place the point at the ellipsis (...) and enter
>
> M-: (pos-visible-in-window-p (point) nil 'partial) RET
>
> Now hit C-f to place the point right after the ellipsis, and enter
>
> M-: (pos-visible-in-window-p (point) nil 'partial) RET
>
> The bug is that both `pos-visible-in-window-p' returns the same pixel  
> coordinates at both positions.  According to the doc, " X and Y are  
> the pixel coordinates relative to the top left corner of the window.",  
> and I presume this refers to the coordinates of whatever the point is  
> on.
>
> This is practically relevant because I'm using that function to  
> position the point in just the right place (i.e. maintain horizontal  
> pixel position) when a user goes up or down a line (and C-n etc  
> doesn't do that.)

I've checked in a fix for this into the trunk; please see if it works
for you there.

(I've asked to wait till after 22.2 to backport this fix into the
branch, and RMS has agreed.)