Chong Yidong <cyd@stupidchicken.com> writes:
>>> As it turns out, it doesn't work right with word-wrapping because
>>> posn-at-point returns funny X positions.  Probably the same underlying
>>> bug causes sometimes mouse-clicks to place point elsewhere than under
>>> the mouse.
>>
>> Perhaps the word-wrap changes to display_line and move_it_* are not
>> entirely consistent.
>
> That's a good guess.  Unfortunately, I can't seem to reproduce it.
> Maybe it's the font I'm using.  Could someone try to set up a detailed
> recipe?

The following text seems to illustrate it for me (I've added it as an
attachment as well, juuust in case).  Put the following long line in a
buffer, and do with (setq word-wrap t), and have Stefan's
line-mode-visual patch enabled:

12:25 *** TOPIC openssl vulnerability: /msg dpkg dsa1571 | 4.0r3 released /msg dpkg etch | /msg dpkg etch->lenny | Offtopic: #debian-offtopic | PUBLIC KEY NOT AVAILABLE? /msg dpkg no public key | THIS IS NOT #ubuntu | FAQ: 

With point at the start of the buffer, you can move with C-n to the next
visual line with no problem, but if you do C-n again at that point, it
acts screwy.

(posn-at-point) does indeed seem to return incorrect results:  after the
first C-n, with the cursor visually located at the start of the 2nd
"visual line", (posn-at-point) returns results with very large  X
coordinates, as if it thinks the cursor is still at the end of the
previous line:

   (#<window 62 on lkasjdf> 81 (640 . 0) 0 nil 81 (80 . 0) nil (0 . 0) (0 . 17))

-Miles