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
Ihor Radchenko [2023-07-20 09:57:02] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Indeed, the `set_point_both` adjustment is an obsolete (mis-)feature
>> that has been deprecated since Emacs-25, when
>> `inhibit-point-motion-hooks`s default has been changed to t (and
>> replaced with `cursor-sensor-mode` and
>> `cursor-intangible-mode`).
>
> Will it ever be removed though?
That's the plan, yes. In Emacs-29, I removed all the places where we
defensively let-bound it to non-nil, in preparation for the
actual removal.
> It appears to affect outline mode a lot.
>
> We just recently received a somewhat related report with yet another
> point adjustment subtlety:
>
> * Short heading...
> * Very very very very long heading<point>...
>
> C-p will move after hidden text above:
>
> * Short heading...<point>
> * Very very very very long heading...
I suspect this has nothing to do with `inhibit-point-motion-hooks` nor
`set-point-both` but with the post-command point-adjustment, instead.
> And I am pretty sure that there are many edge cases like this, which
> rely on the implementation details with point adjustment.
point-adjustment cannot get all cases right, because (like in the above
example), the "right" thing to do depends on the specific semantics of
the last command (e.g. was the last command supposed to move by one
logical line or one screen line?).
IIRC, `C-p` has ad-hoc code to try and handle cases like the above, but
apparently it doesn't handle this specific case.
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.