`vertical-motion' broken

[Le Wang]

This bug report will be sent to the Free Software
Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers
do not have
translators to read other languages for them.

Your bug report will be posted to the
bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (sparc-sun-solaris2.8, Motif
Version 2.1.0)
 of 2002-06-05 on kawi
configured using `configure 
--prefix=/home/lewang/usr/local --with-xpm
--with-x-toolkit=motif
--libdir=/home/lewang/usr:/home/lewang/usr/local
--includedir=/home/lewang/usr:/home/lewang/usr/local'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_CA.ISO8859-1
  value of $LC_CTYPE: en_CA.ISO8859-1
  value of $LC_MESSAGES: C
  value of $LC_MONETARY: en_CA.ISO8859-1
  value of $LC_NUMERIC: en_CA.ISO8859-1
  value of $LC_TIME: en_CA.ISO8859-1
  value of $LANG: nil
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

While debugging screen-lines.el with GNU Emacs
21.3.50.2, I noticed that 
vertical-motion behaviour is completely unpredictable
under certain 
circumstances.  The problem exists in version 21.2.1
as well.  I don't know 
why it works most of the time, but it's very difficult
to recreate this 
problem ... so here goes:


1. emacs -q

2. evaluate: (new-frame '((name . "test") (width .
30)))

3. open the attached file in the new frame

4. evaluate (in the file buffer): (goto-char 52)

5. evaluate: (vertical-motion 0)

6. note that the curor is not at the beginning of the
screen line.

7. evaluate (in the file buffer): (goto-char 56)

8. evaluate: (vertical-motion 1)

9. note that the curor just skipped a screen-line


This bug breaks screen-lines.


On a related note, if a screen-line ends in a tab,
vertical-motion right now
considers that tab to be a part of the next line. 
E.g. If I go to the second
line, and evaluate (vertical-motion 0), the point will
end up at the end of
the first line.  This bevaviour is surprising.  The
documentation does not
explicitly say what the correct behaviour should be in
this case, but I think
the least surprising behaviour would be to move to the
beginning of the
current line, as far to the left as possible.



Recent input:
M-x r e p o r t - e m a c s - b u <tab> <return>

Recent messages:
(emacs-21.2 -q)
Loading disp-table...done
Loading tool-bar...done
Loading image...done
Loading tooltip...done
For information about the GNU Project and its goals,
type C-h C-p.
Loading emacsbug...done



______________________________________________________________________ 
Post your ad for free now! http://personals.yahoo.ca

---

reply via email to

---