From unknown Tue Sep 09 22:00:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width Resent-From: Dmitry Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Sep 2014 21:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 18385 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 18385@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.140960842127802 (code B ref -1); Mon, 01 Sep 2014 21:54:01 +0000 Received: (at submit) by debbugs.gnu.org; 1 Sep 2014 21:53:41 +0000 Received: from localhost ([127.0.0.1]:55955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XOZXg-0007EM-N1 for submit@debbugs.gnu.org; Mon, 01 Sep 2014 17:53:41 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34799) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XOZXe-0007E6-7e for submit@debbugs.gnu.org; Mon, 01 Sep 2014 17:53:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOZXU-0003Pq-9r for submit@debbugs.gnu.org; Mon, 01 Sep 2014 17:53:32 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:48383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOZXU-0003Pm-6r for submit@debbugs.gnu.org; Mon, 01 Sep 2014 17:53:28 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOZXP-0004j3-ET for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2014 17:53:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOZXK-0003Nc-M2 for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2014 17:53:23 -0400 Received: from mail-lb0-x22e.google.com ([2a00:1450:4010:c04::22e]:51540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOZXK-0003NQ-Ac for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2014 17:53:18 -0400 Received: by mail-lb0-f174.google.com with SMTP id p9so6464678lbv.5 for ; Mon, 01 Sep 2014 14:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version:content-type; bh=iRSfHgwSrJ2M3V9vTD4sgT/5w2yXuJpM7lbH/aRhvjg=; b=Abg31z0/yl9Mb2S0fXAFDgQ+JArP8PyG186JX6ywZDSZVrupRDRcDLz7UPuCQcI0J0 ZLewtBb+JLGfuecBVqpYKfQAb+hTVrbh/uhOp3RYIVC6teICiGq+REsqpOEVdok5Af3K h7c7vHoQLT3bURx424Fjj4RE9WpWthtNBUe2D8/oxsTyXBDFH8L3pkaXaDHPw4Zj+SMb ncF5meHnbC1oU8P/77kM1XMkQfyUOH1RWiziiGGpGo7VLfKORgDvkA/Jx9mQhOMkQ0sE np1p2jyWn6CFDzd4OvV0rJiuLvDFRYSWVvbx6jq02mz5HYOexhNaDMkzPLVFXhcWcpTV 7zeg== X-Received: by 10.112.134.101 with SMTP id pj5mr29268657lbb.47.1409608396438; Mon, 01 Sep 2014 14:53:16 -0700 (PDT) Received: from axl ([178.252.98.87]) by mx.google.com with ESMTPSA id lf2sm1276124lac.27.2014.09.01.14.53.14 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 01 Sep 2014 14:53:15 -0700 (PDT) From: Dmitry Date: Tue, 02 Sep 2014 01:53:12 +0400 Message-ID: <86ppffuhx3.fsf@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) 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@gnu.org-20140817144850-xgexz1n2z8s4aiur Windowing system distributor `The X.Org Foundation', version 11.0.11501000 System Description: Ubuntu 14.04.1 LTS From unknown Tue Sep 09 22:00:07 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Dmitry Subject: bug#18385: closed (Re: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width) Message-ID: References: <83k35mf3kz.fsf@gnu.org> <86ppffuhx3.fsf@yandex.ru> X-Gnu-PR-Message: they-closed 18385 X-Gnu-PR-Package: emacs Reply-To: 18385@debbugs.gnu.org Date: Tue, 02 Sep 2014 15:25:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1409671502-8675-1" This is a multi-part message in MIME format... ------------=_1409671502-8675-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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@debbugs.gnu.org. --=20 18385: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18385 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1409671502-8675-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 18385-done) by debbugs.gnu.org; 2 Sep 2014 15:24:12 +0000 Received: from localhost ([127.0.0.1]:57029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XOpwJ-0002Em-VB for submit@debbugs.gnu.org; Tue, 02 Sep 2014 11:24:12 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:42820) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XOpwG-0002EX-NN for 18385-done@debbugs.gnu.org; Tue, 02 Sep 2014 11:24:09 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NBA0040050FK900@mtaout27.012.net.il> for 18385-done@debbugs.gnu.org; Tue, 02 Sep 2014 18:18:31 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NBA00O1256VHK60@mtaout27.012.net.il>; Tue, 02 Sep 2014 18:18:31 +0300 (IDT) Date: Tue, 02 Sep 2014 18:24:12 +0300 From: Eli Zaretskii Subject: Re: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width In-reply-to: <86ppffuhx3.fsf@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Message-id: <83k35mf3kz.fsf@gnu.org> References: <86ppffuhx3.fsf@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18385-done Cc: 18385-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Dmitry > 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.) ------------=_1409671502-8675-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 1 Sep 2014 21:53:41 +0000 Received: from localhost ([127.0.0.1]:55955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XOZXg-0007EM-N1 for submit@debbugs.gnu.org; Mon, 01 Sep 2014 17:53:41 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34799) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XOZXe-0007E6-7e for submit@debbugs.gnu.org; Mon, 01 Sep 2014 17:53:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOZXU-0003Pq-9r for submit@debbugs.gnu.org; Mon, 01 Sep 2014 17:53:32 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:48383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOZXU-0003Pm-6r for submit@debbugs.gnu.org; Mon, 01 Sep 2014 17:53:28 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOZXP-0004j3-ET for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2014 17:53:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOZXK-0003Nc-M2 for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2014 17:53:23 -0400 Received: from mail-lb0-x22e.google.com ([2a00:1450:4010:c04::22e]:51540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOZXK-0003NQ-Ac for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2014 17:53:18 -0400 Received: by mail-lb0-f174.google.com with SMTP id p9so6464678lbv.5 for ; Mon, 01 Sep 2014 14:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version:content-type; bh=iRSfHgwSrJ2M3V9vTD4sgT/5w2yXuJpM7lbH/aRhvjg=; b=Abg31z0/yl9Mb2S0fXAFDgQ+JArP8PyG186JX6ywZDSZVrupRDRcDLz7UPuCQcI0J0 ZLewtBb+JLGfuecBVqpYKfQAb+hTVrbh/uhOp3RYIVC6teICiGq+REsqpOEVdok5Af3K h7c7vHoQLT3bURx424Fjj4RE9WpWthtNBUe2D8/oxsTyXBDFH8L3pkaXaDHPw4Zj+SMb ncF5meHnbC1oU8P/77kM1XMkQfyUOH1RWiziiGGpGo7VLfKORgDvkA/Jx9mQhOMkQ0sE np1p2jyWn6CFDzd4OvV0rJiuLvDFRYSWVvbx6jq02mz5HYOexhNaDMkzPLVFXhcWcpTV 7zeg== X-Received: by 10.112.134.101 with SMTP id pj5mr29268657lbb.47.1409608396438; Mon, 01 Sep 2014 14:53:16 -0700 (PDT) Received: from axl ([178.252.98.87]) by mx.google.com with ESMTPSA id lf2sm1276124lac.27.2014.09.01.14.53.14 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 01 Sep 2014 14:53:15 -0700 (PDT) From: Dmitry To: bug-gnu-emacs@gnu.org Subject: 24.3.93; posn-at-point doesn't account for tab-width Date: Tue, 02 Sep 2014 01:53:12 +0400 Message-ID: <86ppffuhx3.fsf@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) 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@gnu.org-20140817144850-xgexz1n2z8s4aiur Windowing system distributor `The X.Org Foundation', version 11.0.11501000 System Description: Ubuntu 14.04.1 LTS ------------=_1409671502-8675-1-- From unknown Tue Sep 09 22:00:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2014 23:31: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: To: 18385@debbugs.gnu.org Cc: eliz@gnu.org Received: via spool by 18385-submit@debbugs.gnu.org id=B18385.140970062622494 (code B ref 18385); Tue, 02 Sep 2014 23:31:01 +0000 Received: (at 18385) by debbugs.gnu.org; 2 Sep 2014 23:30:26 +0000 Received: from localhost ([127.0.0.1]:57188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XOxWr-0005qj-TK for submit@debbugs.gnu.org; Tue, 02 Sep 2014 19:30:26 -0400 Received: from mail-lb0-f181.google.com ([209.85.217.181]:44629) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XOxWo-0005qS-6p for 18385@debbugs.gnu.org; Tue, 02 Sep 2014 19:30:23 -0400 Received: by mail-lb0-f181.google.com with SMTP id s7so199253lbd.40 for <18385@debbugs.gnu.org>; Tue, 02 Sep 2014 16:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=SHI7f81piVwgfBKpJdZ5joDNvOWzaON9Esk7iAo1ACA=; b=AEFg5q1teJ4dvBSqtbnvQ1cFdvEiN0E/M2ByTBxgv0aCcq7AdPJZmJRqAxC/c6ScT0 m/7UYWe+odavPj6HLT2nyIoAL3JJ3HwkoI3JcPiFCj9rM8cFPlfb79Fnr5mdgsAQIm+r zvwW7kNMCa91omciV0Z5lGTDF5zlRig4WoZhCP+s0mOUPLMpS2scCm8TePy6hbZqYSNB bFlj7GalMBSYhkK7HAxetqqQzKWnzPywF0BkszauuQRG1qYTu3IDH3ZBhpS0L44wBxps kMrlh5QeTpfe7M1ZZ6ADAkQ1Whj13OzPcNYxda1eaoje0moL+AuvzRn/+w53uSL56OTd tSXw== X-Received: by 10.152.3.35 with SMTP id 3mr28892969laz.5.1409700615937; Tue, 02 Sep 2014 16:30:15 -0700 (PDT) Received: from axl ([178.252.98.87]) by mx.google.com with ESMTPSA id sr4sm273561lac.39.2014.09.02.16.30.14 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 02 Sep 2014 16:30:14 -0700 (PDT) From: Dmitry Gutov References: <86ppffuhx3.fsf@yandex.ru> <83k35mf3kz.fsf@gnu.org> Date: Wed, 03 Sep 2014 03:30:10 +0400 In-Reply-To: <83k35mf3kz.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Sep 2014 18:24:12 +0300") Message-ID: <86ha0plhx9.fsf@yandex.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi Eli, Thanks for the detailed explanation. Eli Zaretskii writes: > "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. Is this value useful, though? Since the visual buffer contents are inaccessible from Lisp, I believe this value wouldn't be properly correct in most contexts, even in tty, where the major pitfalls you described can't happen. AFAICS, this function is only called in two places in Emacs code: - From `line-move-partial', where I don't understand what it does. - From `proced-sort-header', where the caller apparently just assumes there are no multiple-width characters on that line. So, was the decision not to return current-column-like value made due to performance considerations? > 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. Thanks, that's good to know. From unknown Tue Sep 09 22:00:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width 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: To: Dmitry Gutov Cc: 18385@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18385-submit@debbugs.gnu.org id=B18385.140976076926945 (code B ref 18385); Wed, 03 Sep 2014 16:13:01 +0000 Received: (at 18385) by debbugs.gnu.org; 3 Sep 2014 16:12:49 +0000 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 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 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) 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) Date: Wed, 03 Sep 2014 19:12:42 +0300 From: Eli Zaretskii In-reply-to: <86ha0plhx9.fsf@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <8338c8fzt1.fsf@gnu.org> References: <86ppffuhx3.fsf@yandex.ru> <83k35mf3kz.fsf@gnu.org> <86ha0plhx9.fsf@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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. From unknown Tue Sep 09 22:00:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2014 22:11: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: To: Eli Zaretskii Cc: 18385@debbugs.gnu.org Received: via spool by 18385-submit@debbugs.gnu.org id=B18385.14097822551325 (code B ref 18385); Wed, 03 Sep 2014 22:11:01 +0000 Received: (at 18385) by debbugs.gnu.org; 3 Sep 2014 22:10:55 +0000 Received: from localhost ([127.0.0.1]:58189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPIlS-0000LI-Pl for submit@debbugs.gnu.org; Wed, 03 Sep 2014 18:10:55 -0400 Received: from mail-la0-f54.google.com ([209.85.215.54]:35630) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPIlP-0000L2-Tk for 18385@debbugs.gnu.org; Wed, 03 Sep 2014 18:10:52 -0400 Received: by mail-la0-f54.google.com with SMTP id b17so10856867lan.27 for <18385@debbugs.gnu.org>; Wed, 03 Sep 2014 15:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Mhc+xHVOe0U0WgbeI1Y0VKcavkum9mFzHfYj7CITVJ4=; b=n9u+2fnYBRMgUX0ASs3mVF6WgFeRyuDl6M7zjtQCrEnxa5E2ZlFwZUMecqqYgVvwKO 9btvxInOvcBpswKbFRraVbJpOrfrNLDmgP60rqDK16WC+EBTaOQqaI0bnrBtwtBvVKTR japieUW7PCoS4f7Nt6DiIrLOz4g4FFsWYXGGN1ZUX45xnvhXhGbmQ0taKkXZMkSKhdsX QffG6d7DI15Iyfe8Jsp1JDOQVjvhpCUkhG40JYzT+ZT9fcINfCCYTlci2tQXPk0VyE0H YuOfXA1n2lZ1wJn6XPQdumKFwYF2AakNeBb5iDJSH/kg6Mr83aKVquuv9ulx1tRwlSuS kZ0w== X-Received: by 10.112.173.136 with SMTP id bk8mr244269lbc.88.1409782245845; Wed, 03 Sep 2014 15:10:45 -0700 (PDT) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id gn7sm9410009lbc.10.2014.09.03.15.10.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Sep 2014 15:10:44 -0700 (PDT) Message-ID: <540791E2.5070706@yandex.ru> Date: Thu, 04 Sep 2014 02:10:42 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 References: <86ppffuhx3.fsf@yandex.ru> <83k35mf3kz.fsf@gnu.org> <86ha0plhx9.fsf@yandex.ru> <8338c8fzt1.fsf@gnu.org> In-Reply-To: <8338c8fzt1.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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)) From unknown Tue Sep 09 22:00:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Sep 2014 15:23:02 +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: To: Dmitry Gutov Cc: 18385@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18385-submit@debbugs.gnu.org id=B18385.140984417610267 (code B ref 18385); Thu, 04 Sep 2014 15:23:02 +0000 Received: (at 18385) by debbugs.gnu.org; 4 Sep 2014 15:22:56 +0000 Received: from localhost ([127.0.0.1]:58910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPYsB-0002fW-B1 for submit@debbugs.gnu.org; Thu, 04 Sep 2014 11:22:55 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:40592) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPYs8-0002fG-TV for 18385@debbugs.gnu.org; Thu, 04 Sep 2014 11:22:53 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NBD00C00U8MA500@a-mtaout23.012.net.il> for 18385@debbugs.gnu.org; Thu, 04 Sep 2014 18:22:46 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NBD00C6MUPYAM10@a-mtaout23.012.net.il>; Thu, 04 Sep 2014 18:22:46 +0300 (IDT) Date: Thu, 04 Sep 2014 18:23:00 +0300 From: Eli Zaretskii In-reply-to: <540791E2.5070706@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83ppfbe7fv.fsf@gnu.org> References: <86ppffuhx3.fsf@yandex.ru> <83k35mf3kz.fsf@gnu.org> <86ha0plhx9.fsf@yandex.ru> <8338c8fzt1.fsf@gnu.org> <540791E2.5070706@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 04 Sep 2014 02:10:42 +0400 > From: Dmitry Gutov > CC: 18385@debbugs.gnu.org > > 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? Yes, I made a similar change (on the emacs-24 branch). Thanks.