bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Ihor Radchenko [2023-07-20 09:57:02] wrote:
> Stefan Monnier <monnier@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