[kobayays@otsukakj.co.jp: vertical-motion]

[kobayays@otsukakj.co.jp: vertical-motion]

[Richard Stallman]

Would someone please DTRT and ack?

------- Start of forwarded message -------
From: KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>
To: emacs-pretest-bug@gnu.org
Date: Thu, 24 Aug 2006 14:13:30 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: vertical-motion
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

It seems that vertical-motion is not right in the case which
some propertized texts are included in the line.


- - Test function:

(defun test-case (n)
  ;; Preparate the test buffer.
  (switch-to-buffer (get-buffer-create "test"))
  (erase-buffer)
  (let ((pos (point-min)))
    (dotimes (i 3) (insert "\t\t\t\t\t\n"))
    (while (< pos (point-max))
      (and (= (char-after pos) ?\t)
	   (put-text-property pos (1+ pos) 'display (propertize "   >")))
      (setq pos (1+ pos))))
  ;; The following is the test case.
  (goto-char (point-min))
  (while (< (point) (point-max))
    (beginning-of-line)
    (forward-char n)
    ;; If POINT is not on the edge of the line,
    ;; POINT move to the beginning of the save line.
    (vertical-motion 1)))


- - Correct actions.
(test-case 0)
(test-case 5)

- - Strange actions.
(test-case 1)
(test-case 2)
(test-case 3)
(test-case 4)

- -- 
KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [kobayays@otsukakj.co.jp: vertical-motion]

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Would someone please DTRT and ack?
>
> From: KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>
> Subject: vertical-motion
> To: emacs-pretest-bug@gnu.org
> Date: Thu, 24 Aug 2006 14:13:30 +0900
>
> It seems that vertical-motion is not right in the case which
> some propertized texts are included in the line.

I want to add that navigating across large images has become a
completely unworking mess in the last year.  No combination of
forward-line and scroll-down by now makes it possible to reliably move
across such an item (either direction), and it is very unpredictable
what will happen at all.  A year ago, Emacs 22 was on a good track.

The last bug reports I sent in were basically met with "this is not
going to get fixed before the release".

Very frustrating, since we had stuff that worked almost perfectly in
that regard one year ago.  Now the situation appears at least as bad
as in Emacs 21.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [kobayays@otsukakj.co.jp: vertical-motion]

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Would someone please DTRT and ack?
>>
>> From: KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>
>> Subject: vertical-motion
>> To: emacs-pretest-bug@gnu.org
>> Date: Thu, 24 Aug 2006 14:13:30 +0900
>>
>> It seems that vertical-motion is not right in the case which
>> some propertized texts are included in the line.
>
> I want to add that navigating across large images has become a
> completely unworking mess in the last year.  No combination of
> forward-line and scroll-down by now makes it possible to reliably move
> across such an item (either direction), and it is very unpredictable
> what will happen at all.  A year ago, Emacs 22 was on a good track.

Can you point to some changes which made things worse?

> The last bug reports I sent in were basically met with "this is not
> going to get fixed before the release".

I would like to fix it ... but this is not trivial, and I've yet to 
find a good way to do it (which doesn't break a lot of other code).

> Very frustrating, since we had stuff that worked almost perfectly in
> that regard one year ago.  Now the situation appears at least as bad
> as in Emacs 21.

I share your frustration.

Do forward-char / backward-char work better in these cases??

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

Re: [kobayays@otsukakj.co.jp: vertical-motion]

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> Would someone please DTRT and ack?
>>>
>>> From: KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>
>>> Subject: vertical-motion
>>> To: emacs-pretest-bug@gnu.org
>>> Date: Thu, 24 Aug 2006 14:13:30 +0900
>>>
>>> It seems that vertical-motion is not right in the case which
>>> some propertized texts are included in the line.
>>
>> I want to add that navigating across large images has become a
>> completely unworking mess in the last year.  No combination of
>> forward-line and scroll-down by now makes it possible to reliably move
>> across such an item (either direction), and it is very unpredictable
>> what will happen at all.  A year ago, Emacs 22 was on a good track.
>
> Can you point to some changes which made things worse?

There have been so many changes in that area that it would be hard to
point to any particular one.  There was progressive deterioration.
There was even a time where the screen display and the behavior could
get out of sync (the cursor displays at a different point than it
behaves) and I am not sure this has not occured recently.

Since you said no fixes where intended before the release, I stopped
actively checking for things like that since it would only annoy me to
no good cause.

And there are things where clicking on some highlighted line (probably
not fully visible) will cause the line to jump away in some manner of
recentering, thus evading the click action, and jump back afterwards.
Sort of click-avoidance-mode.

I just don't understand how stuff like that tests as an improvement.

>> The last bug reports I sent in were basically met with "this is not
>> going to get fixed before the release".
>
> I would like to fix it ... but this is not trivial, and I've yet to
> find a good way to do it (which doesn't break a lot of other code).
>
>> Very frustrating, since we had stuff that worked almost perfectly in
>> that regard one year ago.  Now the situation appears at least as bad
>> as in Emacs 21.
>
> I share your frustration.
>
> Do forward-char / backward-char work better in these cases??

Irrelevant.  I use the equivalent of auto-reveal-mode on
forward-char/backward-char.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [kobayays@otsukakj.co.jp: vertical-motion]

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> There have been so many changes in that area that it would be hard to
> point to any particular one.  There was progressive deterioration.
> There was even a time where the screen display and the behavior could
> get out of sync (the cursor displays at a different point than it
> behaves) and I am not sure this has not occured recently.
>
> Since you said no fixes where intended before the release, I stopped
> actively checking for things like that since it would only annoy me to
> no good cause.

.. unless I can find some way to fix it which isn't too complex ..

If you can provide more test cases that I can look at, maybe I can
find the right fix.

> And there are things where clicking on some highlighted line (probably
> not fully visible) will cause the line to jump away in some manner of
> recentering, thus evading the click action, and jump back afterwards.
> Sort of click-avoidance-mode.

This is news to me.  So examples please!

I have fixed a few redisplay issues with "cursors outside visible part
of window" -- one of those might have broken image display or behaviour
with highlighting.

> I just don't understand how stuff like that tests as an improvement.

Fixing one bug often leads to another bug -- so please report problems
that you think are related to _recent_ changes.

  It's a bit annoying for the to be told that fixes I might have made
a year ago broke something else, and I wasn't told at the time -- now
I have to use a lot of time to find out what changes may have broken
things.

>>> The last bug reports I sent in were basically met with "this is not
>>> going to get fixed before the release".
>>
>> I would like to fix it ... but this is not trivial, and I've yet to
>> find a good way to do it (which doesn't break a lot of other code).

And now you tell me, that things degraded gradually, so there are
probably several things that influences the current bad behaviour.
Which is actually also my experience with trying to solve it. :-(

>> Do forward-char / backward-char work better in these cases??
>
> Irrelevant.  I use the equivalent of auto-reveal-mode on
> forward-char/backward-char.

Too bad -- as I have found that using those keys typically
do scroll images in cases where the scrolling commands don't.

So far, I've found that it is primarily the scrolling commands which
are broken -- often they make false decisions when chosing a new
window start in the presense of a partially visible image.

I'll give fixing it another shot this week.

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

Re: [kobayays@otsukakj.co.jp: vertical-motion]

[Richard Stallman]

    Since you said no fixes where intended before the release, I stopped
    actively checking for things like that since it would only annoy me to
    no good cause.

Please start again.

    And there are things where clicking on some highlighted line (probably
    not fully visible) will cause the line to jump away in some manner of
    recentering, thus evading the click action, and jump back afterwards.
    Sort of click-avoidance-mode.

    I just don't understand how stuff like that tests as an improvement.

I know you are upset, but please don't accuse us of trying to hurt
things.  Each change that was installed was intended to fix a bug.
You know this.

Re: [kobayays@otsukakj.co.jp: vertical-motion]

[Richard Stallman]

    I want to add that navigating across large images has become a
    completely unworking mess in the last year.  No combination of
    forward-line and scroll-down by now makes it possible to reliably move
    across such an item (either direction), and it is very unpredictable
    what will happen at all.  A year ago, Emacs 22 was on a good track.

    The last bug reports I sent in were basically met with "this is not
    going to get fixed before the release".

I would like to reconsider this.  If we have made it worse than it
was, we should make one more attempt to find a good fix.  Perhaps
conditionalizing some of the changes that made it worse would be a
sufficient fix.

Could you please resend the report that described this problem?

Re: [kobayays@otsukakj.co.jp: vertical-motion]

[Chong Yidong]

> From: KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>
> Subject: vertical-motion
>
> It seems that vertical-motion is not right in the case which
> some propertized texts are included in the line.
>
> (defun test-case (n)
>   ;; Preparate the test buffer.
>   (switch-to-buffer (get-buffer-create "test"))
>   (erase-buffer)
>   (let ((pos (point-min)))
>     (dotimes (i 3) (insert "\t\t\t\t\t\n"))
>     (while (< pos (point-max))
>       (and (= (char-after pos) ?\t)
> 	   (put-text-property pos (1+ pos) 'display (propertize "   >")))
>       (setq pos (1+ pos))))
>   ;; The following is the test case.
>   (goto-char (point-min))
>   (while (< (point) (point-max))
>     (beginning-of-line)
>     (forward-char n)
>     ;; If POINT is not on the edge of the line,
>     ;; POINT move to the beginning of the save line.
>     (vertical-motion 1)))
>
> - - Strange actions.
> (test-case 1)

The problem is that when the iterator method at PT is GET_FROM_STRING,
the value of it.current after calling move_it_to is PT + 1.  This is
because the call to set_iterator_to_next in xdisp.c:6607 (inside
move_it_in_display_line_to), upon reaching the end of the display
string at PT, sees that there are no more strings to display at PT and
calls pop_it, which automagically advances the iterator to PT + 1.
The code in Fvertical_motion then misfires:

      /* Move back if we got too far.  This may happen if
	 truncate-lines is on and PT is beyond right margin.
	 It may also happen if it_start is on an image or a stretch
	 glyph -- in that case, don't go back.  */
      if (IT_CHARPOS (it) > it_start && XINT (lines) > 0
	  && !start_on_image_or_stretch_p)
	move_it_by_lines (&it, -1, 0);

I propose the following fix.  It fixes the bug described in the above
bug report.

*** emacs/src/indent.c.~1.183.~	2006-02-25 13:07:18.000000000 -0500
--- emacs/src/indent.c	2006-08-28 17:54:41.000000000 -0400
***************
*** 2074,2080 ****
      {
        int it_start;
        int oselective;
!       int start_on_image_or_stretch_p;
  
        SET_TEXT_POS (pt, PT, PT_BYTE);
        start_display (&it, w, pt);
--- 2074,2080 ----
      {
        int it_start;
        int oselective;
!       int start_on_image_or_stretch_or_string_p;
  
        SET_TEXT_POS (pt, PT, PT_BYTE);
        start_display (&it, w, pt);
***************
*** 2086,2093 ****
  	 while the end position is really at some X > 0, the same X that
  	 PT had.  */
        it_start = IT_CHARPOS (it);
!       start_on_image_or_stretch_p = (it.method == GET_FROM_IMAGE
! 				     || it.method == GET_FROM_STRETCH);
        reseat_at_previous_visible_line_start (&it);
        it.current_x = it.hpos = 0;
        /* Temporarily disable selective display so we don't move too far */
--- 2086,2094 ----
  	 while the end position is really at some X > 0, the same X that
  	 PT had.  */
        it_start = IT_CHARPOS (it);
!       start_on_image_or_stretch_or_string_p = (it.method == GET_FROM_IMAGE
! 					       || it.method == GET_FROM_STRETCH
! 					       || it.method == GET_FROM_STRING);
        reseat_at_previous_visible_line_start (&it);
        it.current_x = it.hpos = 0;
        /* Temporarily disable selective display so we don't move too far */
***************
*** 2098,2107 ****
  
        /* Move back if we got too far.  This may happen if
  	 truncate-lines is on and PT is beyond right margin.
! 	 It may also happen if it_start is on an image or a stretch
! 	 glyph -- in that case, don't go back.  */
        if (IT_CHARPOS (it) > it_start && XINT (lines) > 0
! 	  && !start_on_image_or_stretch_p)
  	move_it_by_lines (&it, -1, 0);
  
        it.vpos = 0;
--- 2099,2108 ----
  
        /* Move back if we got too far.  This may happen if
  	 truncate-lines is on and PT is beyond right margin.
! 	 It may also happen if it_start is on an image, stretch
! 	 glyph, or string -- in that case, don't go back.  */
        if (IT_CHARPOS (it) > it_start && XINT (lines) > 0
! 	  && !start_on_image_or_stretch_or_string_p)
  	move_it_by_lines (&it, -1, 0);
  
        it.vpos = 0;

Re: [kobayays@otsukakj.co.jp: vertical-motion]

[Chong Yidong]

> The problem is that when the iterator method at PT is GET_FROM_STRING,
> the value of it.current after calling move_it_to is PT + 1.  This is
> because the call to set_iterator_to_next in xdisp.c:6607 (inside
> move_it_in_display_line_to), upon reaching the end of the display
> string at PT, sees that there are no more strings to display at PT and
> calls pop_it, which automagically advances the iterator to PT + 1.
> The code in Fvertical_motion then misfires.
>
> I propose the following fix.  It fixes the bug described in the above
> bug report.

I have checked in the fix.