bug#65015: 29.1; align-to on wrapped line regression

[Eli Zaretskii]

> From: Axel Forsman <axelsfor@gmail.com>
> Date: Thu, 3 Aug 2023 12:48:26 +0200
> Cc: 65015@debbugs.gnu.org
> 
> > Well, it doesn't really say what HPOS is.  I have clarified it now,
> > thanks.
> 
> The docstring of compute-motion already uses HPOS to signify the
> horizontal position relative to the visual left edge of the text area.
> I have not read your change yet, but please use COL for the value
> of :align-to instead of HPOS to avoid overloading terminology.

That would be sub-optimal, since HPOS can also be a pixel-wise
specification.

> I read into the fact that HPOS is already defined elsewhere and that it
> takes millimeter-values, and took it as a pixel x-offset from the current
> left edge of the text area. Is that really so outlandish?

Not outlandish, no.  Just inconsistent with the rest of the behavior
when text alignment is required.  The :align-to alignment should work
as expected, i.e. align the text in the same manner, when the window
width changes, when lines are truncated or wrapped, and when truncated
lines are hscrolled.  If the :align-to argument is measured from the
visual beginning of a screen line, this can never work, don't you
agree?

> > The above just makes no sense in wrapped lines, that's all.
> 
> Why do you feel the need to paint me as an idiot?

Whatever made you say that, I wonder?  When I say "makes no sense", I
mean it makes no sense to me.

I guess we interpret the geometries of the Emacs lines very
differently if doing that in wrapped lines makes sense to you.

> Under the semantics imposed by HPOS being as described in the
> compute-motion docstring, the previous behavior is just what anyone
> would expect. Clearly it does make sense.

It does make sense in other contexts, but not in the context of
aligning text that should hold when the window dimensions change and
horizontal scrolling is used.  The idea of :align-to is to keep the
text aligned in those circumstances.  Think, for example, about
tabulated-list-mode which is used by quite a few Emacs features: it
uses :align-to to align columns in a table-like display, and that
display should not become messed up when the window is hscrolled or
changes its width.

This is the kind of applications that :align-to is used for, and they
must be supported correctly.

> Pardon my persistence, but would it be possible to reintroduce the old
> behavior under a new space spec property name, to give everyone (read:
> me) a clear upgrade path? Evidently it was useful.

A new display spec would be possible, especially if the problems the
pre-29 implementation caused are not considered important (e.g., what
do you expect to happen when the window is hscrolled?).  But someone
will have to write the code and document it.

> > AFAIU, to adapt to this change, your code will have to call
> > current-column to compute the adjustment of the value you pass to
> > :align-to.
> 
> Well yeah, but if that is now what the best implementation has to do, then
> that is clearly less than satisfactory.

Why is it not satisfactory?  The calculation is quite simple, IIUC.

> I think overlay popups are an important use case for everyone using
> Emacs text-frames.

FTR: I have nothing against overlay popups.