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#18493: 24.3.93; posn-col-row should take text-scale-mode into account Date: Thu, 18 Sep 2014 19:39:20 +0300 Message-ID: <83sijo2893.fsf@gnu.org> References: <864mw529bx.fsf@yandex.ru> <38e6b538-3e76-472a-b371-2e74f9a14bf7@default> <541A1693.4090009@yandex.ru> <30fb9ae4-3781-4bc7-a1cf-45bf2a195929@default> <831tr92cuq.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1411059693 27550 80.91.229.3 (18 Sep 2014 17:01:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Sep 2014 17:01:33 +0000 (UTC) Cc: 18493@debbugs.gnu.org, dgutov@yandex.ru To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 18 19:01:26 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 1XUf58-0001Cr-Fw for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Sep 2014 19:01:22 +0200 Original-Received: from localhost ([::1]:52287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUf58-0006OF-0o for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Sep 2014 13:01:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUf4z-0006M4-KY for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 13:01:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUf4u-0000S2-6z for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 13:01:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUf4u-0000Qi-4H for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 13:01:08 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XUekV-0007PT-1z for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 12:40:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 18 Sep 2014 16:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18493 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18493-submit@debbugs.gnu.org id=B18493.141105836728426 (code B ref 18493); Thu, 18 Sep 2014 16:40:02 +0000 Original-Received: (at 18493) by debbugs.gnu.org; 18 Sep 2014 16:39:27 +0000 Original-Received: from localhost ([127.0.0.1]:44702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XUeju-0007OQ-Cs for submit@debbugs.gnu.org; Thu, 18 Sep 2014 12:39:26 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:42055) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XUejo-0007Nn-4B for 18493@debbugs.gnu.org; Thu, 18 Sep 2014 12:39:22 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NC300500UW6W400@mtaout24.012.net.il> for 18493@debbugs.gnu.org; Thu, 18 Sep 2014 19:33:56 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NC300NH5VCK9K90@mtaout24.012.net.il>; Thu, 18 Sep 2014 19:33:56 +0300 (IDT) In-reply-to: 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:93476 Archived-At: > Date: Thu, 18 Sep 2014 08:37:28 -0700 (PDT) > From: Drew Adams > Cc: dgutov@yandex.ru, 18493@debbugs.gnu.org > > > > getting the column of a mouse click, using: > > > (car (posn-col-row (event-start event))) > > > And I guess that code must be broken wrt text scaling. > > > I didn't realize that. > > > > As I wrote elsewhere, whether it is broken depends on what you do > > with the results. E.g., if you deal with mouse clicks, the > > natural value to use is the underlying buffer position, not > > column/row. What do you need the column for? > > I pass the column and row to `icicle-raise-Completions-frame', > which calls (set-mouse-position (selected-frame) col row) Then you should be fine, because set-mouse-position expects _exactly_ the "column" and "row" that posn-col-row returns. (Its doc string could tell that more clearly, but I looked at the implementation.) > > posn-col-row just converts [pixels] to the frame's canonical > > character units, that's all. > > That's precisely the question raised in this thread (at least > by me, and I think maybe by Dmitry). Why? Why doesn't > (shouldn't) it take text scaling into account? What's the > value of using the frame char size for calculating visual > columns in the presence of text scaling? Because in many use cases this is exactly what you want to pass to other functions, which expect that. > So I guess I will need to use something like this: > > (if (fboundp 'posn-actual-col-row) > (posn-actual-col-row ...) > (posn-col-row ...)) Not necessarily: posn-actual-col-row has its own quirks, see its doc string and the discussions in bug #18384. > But why? Why wouldn't it be TRT to have `posn-col-row' return > the visual column, i.e., compensate for text scaling? Because in most cases you will not be able to do anything useful with such a "column" that you cannot do with the buffer position that is already available in the click event and in some other posn-* functions. > Is there an advantage in using frame char size for it instead? The advantage, as I see it, is that many Emacs APIs expect such units. Of course, this is just a guess: I didn't design that function and didn't write its first versions. But after hacking display-related code for some time, it makes perfect sense to me.