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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Dmitry <dgutov <at> yandex.ru>
Subject: bug#18385: closed (Re: bug#18385: 24.3.93; posn-at-point doesn't
 account for tab-width)
Date: Tue, 02 Sep 2014 15:25:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 18385 <at> debbugs.gnu.org.

-- 
18385: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18385
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry <dgutov <at> yandex.ru>
Cc: 18385-done <at> debbugs.gnu.org
Subject: Re: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width
Date: Tue, 02 Sep 2014 18:24:12 +0300

> From: Dmitry <dgutov <at> yandex.ru>
> Date: Tue, 02 Sep 2014 01:53:12 +0400
> 
> 1. New, empty buffer.
> 2. (insert "a\tb")
> 3. (posn-actual-col-row (posn-at-point))
> => (3 . 0)
> 
> It should probably return (9 . 0).

No, it should return (3 . 0), as it does.  You misunderstand the
contract of this function (which is not surprising, since the issue is
a subtle one, and the documentation, while it tries to be accurate,
has a hard time communicating its intent due to inherent ambiguity of
the related terminology).

This sentence from the doc string of posn-actual-col-row says it all:

  These are the actual row number in the window and character number
  in that row.

"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.

So this is not a bug, but intended, if obscure, behavior.

> I'm not 100% this is actually a bug, but (posn-actual-col-row
> (posn-at-point)) returns the "visually" correct column values in the
> more complex cases (after text with `display' or `compose-region' called
> on it), so not accounting for tab-width looks surprising.

As long as posn-actual-col-row deals with characters of the same
dimensions (i.e. the same font), it will always produce seemingly
accurate "column" counts, no matter whether these characters come from
a buffer, a display property, or an overlay string.  (It counts
characters on display, so the source from which they came is
irrelevant.)  But as soon as you have something in the line whose
glyph is larger or smaller than the other characters in that line, the
"column" produced by the function will be skewed, because it's
actually not a visual column, but a count of "display elements" from
the beginning of the screen line.  E.g., try insert-image or put a
display property which uses ':align-to' or ':width', and you will see
that the image and the stretch of whitespace produced by those are
counted as a single "column", no matter what are their actual
dimensions.

IOW, posn-actual-col-row is not reliable when you want screen
coordinates in row/column units.

> Originally: https://github.com/company-mode/company-mode/issues/175

And you were right to resolve that by using posn-col-row instead.
That function translates pixel coordinates into row/column units,
which is much closer to what you want.

(Yes, it's not easy to do the job of the display engine.)

[Message part 3 (message/rfc822, inline)]

From: Dmitry <dgutov <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.93; posn-at-point doesn't account for tab-width
Date: Tue, 02 Sep 2014 01:53:12 +0400

1. New, empty buffer.
2. (insert "a\tb")
3. (posn-actual-col-row (posn-at-point))
=> (3 . 0)

It should probably return (9 . 0).

I'm not 100% this is actually a bug, but (posn-actual-col-row
(posn-at-point)) returns the "visually" correct column values in the
more complex cases (after text with `display' or `compose-region' called
on it), so not accounting for tab-width looks surprising.

Originally: https://github.com/company-mode/company-mode/issues/175

In GNU Emacs 24.3.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-08-18 on axl
Repository revision: 117447 eliz <at> gnu.org-20140817144850-xgexz1n2z8s4aiur
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.