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:52:55 -0700 (PDT) Message-ID: <955c9f56-902e-4e21-8cfe-e2b8d2a37ead@default> References: <<864mw529bx.fsf@yandex.ru>> <<8338bp2cwf.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 1411056682 17145 80.91.229.3 (18 Sep 2014 16:11:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Sep 2014 16:11:22 +0000 (UTC) Cc: 18493@debbugs.gnu.org To: Eli Zaretskii , Dmitry Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 18 18:11:14 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 1XUeIb-0001Cx-S4 for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Sep 2014 18:11:14 +0200 Original-Received: from localhost ([::1]:52045 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUeIb-0002Mb-9C for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Sep 2014 12:11:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUeIP-0002MC-C5 for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 12:11:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUeIG-0003jy-Lx for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 12:11:01 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53128) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUeIG-0003jG-J5 for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 12:10:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XUe1y-0006Ce-4p for bug-gnu-emacs@gnu.org; Thu, 18 Sep 2014 11:54: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:54: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.141105558523765 (code B ref 18493); Thu, 18 Sep 2014 15:54:02 +0000 Original-Received: (at 18493) by debbugs.gnu.org; 18 Sep 2014 15:53:05 +0000 Original-Received: from localhost ([127.0.0.1]:44681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XUe12-0006BC-Fl for submit@debbugs.gnu.org; Thu, 18 Sep 2014 11:53:05 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:32416) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XUe0z-0006Am-DD for 18493@debbugs.gnu.org; Thu, 18 Sep 2014 11:53:02 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8IFqvhn008390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Sep 2014 15:52:58 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8IFqufa025202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2014 15:52:57 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 s8IFquhA013934; Thu, 18 Sep 2014 15:52:56 GMT In-Reply-To: <<8338bp2cwf.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: acsinet22.oracle.com [141.146.126.238] 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:93473 Archived-At: > That's the intended behavior: posn-col-row is documented to return > the coordinates of its argument in canonical character units. And > that is what it does here. Yes, but why? > There's no bug here. > But once variable-size fonts, stretch glyphs, images, and > other display atrocities come into play, there's no meaningful way of > talking about "columns" and "rows" that can be used as indices into > the text. If there is no meaningful way to talk about columns and rows then a function that returns the column and row might as well run around the block and then take a nap. I understand your argument, I think. But there is a difference between saying (a) that we cannot know just what visual column/row is involved in the general case, in the presence of the many possible display considerations and saying (b) that we cannot do that in any cases. The case of text scaling seems to me to be a case where we can meaningfully return the visual column and row. No? So that general give-up argument disappears in this case. Granted, there is another possible question: Why not have both, as separate functions - IOW, what we apparently have now, with the=20 presence of function `posn-actual-col-row'. But why? Is there really a use case for obtaining what `posn-col-row' currently returns in a text-scaling context? And if `posn-actual-col-row' really does return the actual, visual column and row, then what does that say about your general can't-do argument above? And if it does not really do that, then why does it have that name "actual", and why does its doc give the impression that it does really do that? > So the answer to your question depends on what you intend to do with > the value. >=20 > > > I don't even understand why the value should change with text > > > scale. > > > > It would solve the problem of text-scale-mode being enabled in > > buffers, where I'm getting inaccurate results from `posn-col-row' > > because of that. And by "inaccurate", I mean different from the > > ones I'd like. >=20 > Then perhaps you want posn-col-row-as-dgutov-likes-it, not posn-col- > row ;-) >=20 > Seriously, though: it all depends on what you do with the results > returned by this function. And you didn't explain what that is, so > it is hard to tell whether there is a problem, and if so, where. >=20 > IOW, please explain what is it that "you'd like". I agree that the whole question of this design depends on the answer to your question: what do you intend to do with the return values. So let me ask you that same question: what is the use case that the current design supports? What do you imagine might be a use for obtaining the frame-char column and row and not wanting the "actual" column and row? I am generally in favor of allowing for such differences, as users are pretty clever at coming up with uses for them. But here I don't (yet) see it. And presumably the designers had something in mind, when they chose to return the column & row based on frame char size even in the presence of scaling. IOW, why have two separate functions, `posn-col-row' and `posn-actual-col-row'? It's just a question. Knowing the design is as it is can help users put the various functions to best use.