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: Tue, 02 Sep 2014 18:24:12 +0300 Message-ID: <83k35mf3kz.fsf@gnu.org> References: <86ppffuhx3.fsf@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1409671526 21405 80.91.229.3 (2 Sep 2014 15:25:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Sep 2014 15:25:26 +0000 (UTC) Cc: 18385-done@debbugs.gnu.org To: Dmitry Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 02 17:25:17 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 1XOpxN-000576-I4 for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Sep 2014 17:25:17 +0200 Original-Received: from localhost ([::1]:38787 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOpxN-0004XT-4m for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Sep 2014 11:25:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOpxF-0004Uz-4u for bug-gnu-emacs@gnu.org; Tue, 02 Sep 2014 11:25:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOpx8-000053-Me for bug-gnu-emacs@gnu.org; Tue, 02 Sep 2014 11:25:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOpx8-00004x-KK for bug-gnu-emacs@gnu.org; Tue, 02 Sep 2014 11:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XOpx8-0002G2-Bh for bug-gnu-emacs@gnu.org; Tue, 02 Sep 2014 11:25:02 -0400 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2014 15:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 18385 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 18385@debbugs.gnu.org, eliz@gnu.org, dgutov@yandex.ru Original-Received: via spool by 18385-done@debbugs.gnu.org id=D18385.14096714528608 (code D ref 18385); Tue, 02 Sep 2014 15:25:01 +0000 Original-Received: (at 18385-done) by debbugs.gnu.org; 2 Sep 2014 15:24:12 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <86ppffuhx3.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:92961 Archived-At: > 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.)