GNU bug report logs -
#64724
30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment
Previous Next
Full log
View this message in rfc822 format
> Let me describe the full sequence how I arrived to that manual page:
>
> 1. We had a situation where `backward-word' moved further than expected:
>
> <invisible>=</invisible>word<point>
> M-b
> <point>=word
>
> This was despite "=" not considered to be a word constituent in
> syntax table.
>
> 2. I noticed that this behavior is related to point movement and
> invisible text and searched manual index for "point", "invisible".
> The only match was "22.6 Adjusting Point After Commands"
> I assumed that it is describing all the cases related to interaction
> between point and invisible text.
>
> 3. I've read that section of the manual and did not find anything about
> point ending up not inside, but at the boundary of invisible text.
The boundary is usually considered as "inside" for this specific case.
More specifically, in your above example, at the end of the command
point ends up being *displayed* at a position that could correspond to
various buffer positions, and the 22.6 point-adjustment will thus try
and choose which of those buffer positions to use (based on the
stickiness, as well as the direction of movement).
> 4. I reached to sources and tried to track down the cause, eventually
> arriving to `set_point_both'.
Hmm... I'd be very surprised if `set_point_both` is the cause:
`inhibit-point-motion-hooks` should be non-nil, so that code will simply
be skipped.
If `inhibit-point-motion-hooks` is nil, please send me the recipe so
I can try and change the caller that set this var.
Stefan
This bug report was last modified 1 year and 328 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.