From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams 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 08:37:28 -0700 (PDT) Message-ID: 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>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1411054723 21606 80.91.229.3 (18 Sep 2014 15:38:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Sep 2014 15:38:43 +0000 (UTC) Cc: 18493@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 18 17:38:35 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 1XUdn0-0001n0-RK for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Sep 2014 17:38:35 +0200 Original-Received: from localhost ([::1]:51833 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUdn0-0002B2-FJ for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Sep 2014 11:38:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUdmj-00022y-AO for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 11:38:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUdmZ-0003XH-UT for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 11:38:17 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUdmZ-0003WW-S7 for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 11:38:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XUdmU-0005n0-FW for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 11:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 18 Sep 2014 15:38: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.141105465422207 (code B ref 18493); Thu, 18 Sep 2014 15:38:02 +0000 Original-Received: (at 18493) by debbugs.gnu.org; 18 Sep 2014 15:37:34 +0000 Original-Received: from localhost ([127.0.0.1]:44660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XUdm1-0005m6-05 for submit@debbugs.gnu.org; Thu, 18 Sep 2014 11:37:33 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:49546) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XUdlz-0005lx-L3 for 18493@debbugs.gnu.org; Thu, 18 Sep 2014 11:37:32 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8IFbUFL028679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Sep 2014 15:37:30 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8IFbTJW028884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2014 15:37:29 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8IFbT21022643; Thu, 18 Sep 2014 15:37:29 GMT In-Reply-To: <<831tr92cuq.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:93472 Archived-At: > > 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. >=20 > 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) > > > Does it have explicit support for text scaling? > > > > No, my code does not. From what I understand now, I guess it > > needs to worry about that now. Seems nuts that it should have to, > > but my understanding is limited... >=20 > Welcome to the brave new world of variable-size characters and other > Emacs display features that break the "normal" interpretation of > "columns" and "rows". The only reliable way of expressing screen > coordinates in the general case is with pixel values. =20 OK, I can understand that. > posn-col-row just converts that to the frame's canonical > character units, that's all. =20 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? > We have other functions which map that to buffer position or > to other objects if the click event is not on buffer text. OK. And I see that Martin pointed to `posn-actual-col-row'. So I guess I will need to use something like this: (if (fboundp 'posn-actual-col-row) (posn-actual-col-row ...) (posn-col-row ...)) That's not a problem for me. But why? Why wouldn't it be TRT to have `posn-col-row' return the visual column, i.e., compensate for text scaling? Is there an advantage in using frame char size for it instead? > The question is what you do with what posn-col-row returns. See above. I return the mouse pointer to the clicked position. I do some stuff, redisplay the (updated list of) candidates in=20 *Completions*, raise the frame showing *Completions*, optionally move that frame to the display edge (if one-window-p, and respecting a user option), and reposition the mouse pointer where it was when clicked. I do the last part because user actions on individual candidates can intentionally call `select-frame-set-input-focus', which can position the mouse pointer on a standalone minibuffer frame. (And that is very unhandy.) > Given the answer, it should be possible to tell you how to > get at the information even when such advanced display > features are in use, or maybe identify some missing Emacs > functionality. I guess the answer to that is the workaround code above. I have no problem with doing that. I still ask the question: Why? What is the advantage of disregarding text scaling here? =20 Why/when would anyone who wants the column and row not want the column and row wrt the apparent char size (e.g. due to text scaling)? Why/when would s?he instead want the column and row as determined by the frame default char size? Just asking. Maybe there is a good reason (e.g. a use case). So far, I don't see it.