From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width Date: Wed, 03 Sep 2014 19:12:42 +0300 Message-ID: <8338c8fzt1.fsf@gnu.org> References: <86ppffuhx3.fsf@yandex.ru> <83k35mf3kz.fsf@gnu.org> <86ha0plhx9.fsf@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1409760807 5329 80.91.229.3 (3 Sep 2014 16:13:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Sep 2014 16:13:27 +0000 (UTC) Cc: 18385@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 03 18:13:20 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XPDBM-0002ma-Hw for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Sep 2014 18:13:16 +0200 Original-Received: from localhost ([::1]:46477 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPDBM-0001Kv-04 for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Sep 2014 12:13:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPDBD-0001KX-NG for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 12:13:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPDB8-0002qO-Br for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 12:13:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38187) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPDB8-0002pW-8Y for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 12:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XPDB7-000713-KO for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 12:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2014 16:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18385 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18385-submit@debbugs.gnu.org id=B18385.140976076926945 (code B ref 18385); Wed, 03 Sep 2014 16:13:01 +0000 Original-Received: (at 18385) by debbugs.gnu.org; 3 Sep 2014 16:12:49 +0000 Original-Received: from localhost ([127.0.0.1]:57984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPDAu-00070W-Mo for submit@debbugs.gnu.org; Wed, 03 Sep 2014 12:12:49 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:60002) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPDAr-00070E-G9 for 18385@debbugs.gnu.org; Wed, 03 Sep 2014 12:12:47 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NBC002001V5DY00@mtaout25.012.net.il> for 18385@debbugs.gnu.org; Wed, 03 Sep 2014 19:07:13 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NBC00J29241D390@mtaout25.012.net.il>; Wed, 03 Sep 2014 19:07:13 +0300 (IDT) In-reply-to: <86ha0plhx9.fsf@yandex.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:92992 Archived-At: > From: Dmitry Gutov > 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.