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

Previous Next

Package: emacs;

Reported by: Dmitry <dgutov <at> yandex.ru>

Date: Mon, 1 Sep 2014 21:54:01 UTC

Severity: normal

Found in version 24.3.93

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #19 received at 18385 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18385 <at> debbugs.gnu.org
Subject: Re: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width
Date: Thu, 04 Sep 2014 02:10:42 +0400
On 09/03/2014 08:12 PM, Eli Zaretskii wrote:

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

Thank you.

>> 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!

Looks like yet another reason not to use this from Lisp code. :)

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

Ah, indeed. It's a different application from what I had in mind.

> But every complex data structure should have accessor functions to its
> parts, and the event structure is no exception.

I guess its docstring was that tripped me up. "Actual column" sounds too 
close to the name of `current-column', which does count character widths.

Do you think something like this change would make sense?

Or, also, instead of "contain", maybe use "correspond to" (unrelated to 
the present discussion).

=== modified file 'lisp/subr.el'
--- lisp/subr.el	2014-09-02 15:16:42 +0000
+++ lisp/subr.el	2014-09-03 22:09:02 +0000
@@ -1149,10 +1149,13 @@
 	      (/ (cdr pair) (+ (frame-char-height frame) spacing))))))))

 (defun posn-actual-col-row (position)
-  "Return the actual column and row in POSITION, measured in characters.
-These are the actual row number in the window and character number in 
that row.
-Return nil if POSITION does not contain the actual position; in that case
+  "Return the actual row character number and row number in POSITION.
+Return nil if POSITION does not contain an actual position; in that case
 `posn-col-row' can be used to get approximate values.
+
+Consider using `posn-col-row' instead either way, because this
+function doesn't take character widths into account.
+
 POSITION should be a list of the form returned by the `event-start'
 and `event-end' functions."
   (nth 6 position))






This bug report was last modified 10 years and 344 days ago.

Previous Next


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