bug#18385: 24.3.93; posn-at-point doesn't account for tab-width

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: eliz@gnu.org
> Date: Wed, 03 Sep 2014 03:30:10 +0400
> 
> > "Character number in that row".  IOW, it counts characters, not visual
> > columns.  This function, and the data in its POSITION argument which
> > it accesses, are designed to make it easy to find the glyph (or
> > "display element") in a screen line, so it simply provides the ordinal
> > number of the "thing at point" on its screen line, disregarding the
> > screen dimensions of that thing.
> 
> Okay, if character widths are "applied" after the glyphs to be displayed
> are collected, I guess this makes a certain amount of sense.

Technically, the width is "applied" during the same (single) pass the
display elements are collected.

If you want a more accurate description of what happens, it is this:
Glyphs collected for each display line are stored in an array of
structures which specify how to display each glyph (and that includes
the calculated pixel width of the glyphs).  What posn-actual-col-row
gives you is the _index_ of the corresponding glyph structure in that
array.

> Is this value useful, though? Since the visual buffer contents are
> inaccessible from Lisp

posn-actual-col-row is just an accessor function for the event data
structure.  The event data structure from which it extracts its output
is used not only from Lisp, it is also used by the display engine
itself, and there this information is very useful, because it allows
to easily find the glyph where the user clicks the mouse.  The glyph
holds a reference to the object from which it came and other useful
information required to process click events.

> I believe this value wouldn't be properly correct in most contexts,
> even in tty, where the major pitfalls you described can't happen.

First, ':align-to' display properties are supported on a TTY as well,
as are TABs (of course).  But this is actually one more subtle issue
with posn-actual-col-row, because if you try your recipe in a
text-mode frame, you will see that there posn-actual-col-row counts
the TAB as 7 columns, and your recipe works as you expected!

This is again a manifestation of how click events and posn-at-point
implement the "column" part: they count _glyphs_.  Now, on a TTY,
TABs, ':align-to', and the like are implemented by inserting a
suitable number of glyphs that display as a blank character '\032',
because a text-mode terminal cannot display variable-width characters
(well, there are double-width characters in CJK locales, but let's
ignore that for a moment).  So this is what you get in the "column" on
a TTY.

> AFAICS, this function is only called in two places in Emacs code:
> 
> - From `line-move-partial', where I don't understand what it does.

line-move-partial uses the "row" part of what posn-actual-col-row
returns, so the problems with "columns" don't happen there.

> - From `proced-sort-header', where the caller apparently just assumes
>   there are no multiple-width characters on that line.

And that's a valid assumption in that case, because these "columns"
are applied to the Proced's header line, which Proced itself
generates, so it knows what is there.  In addition, the "column"
returned by posn-actual-col-row is used there to index into the
header-line string, so again, a pure character count is TRT.

> So, was the decision not to return current-column-like value made due to
> performance considerations?

The event data structure is fundamentally pixel-based.  The basic
first-hand information in the event is the pixel-unit X and Y, from
which, given enough code, you can recompute everything else.  The
event data structure provides additional pre-computed attributes of
the event to make the job of its users easier; the glyph coordinates
COL and ROW are 2 of these pre-computed attributes, which some of the
users of the event structure find very useful.  Admittedly, Lisp
programs generally shouldn't use those, except in very special cases.
But every complex data structure should have accessor functions to its
parts, and the event structure is no exception.