From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#17768: 24.3; problem with two ruler-mode windows Date: Sun, 15 Jun 2014 17:09:26 +0200 Message-ID: <539DB726.1080908@gmx.at> References: <84sin9n0kf.fsf@gmail.com> <539AA853.3050202@gmx.at> <83zjhfv3r9.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1402845037 6915 80.91.229.3 (15 Jun 2014 15:10:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Jun 2014 15:10:37 +0000 (UTC) Cc: andrea.rossetti@gmail.com, 17768@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 15 17:10:29 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 1WwC4g-0001z3-5y for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jun 2014 17:10:26 +0200 Original-Received: from localhost ([::1]:38937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwC4d-0008VY-Cj for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jun 2014 11:10:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwC4T-0008VP-4m for bug-gnu-emacs@gnu.org; Sun, 15 Jun 2014 11:10:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WwC4L-0002Ns-KB for bug-gnu-emacs@gnu.org; Sun, 15 Jun 2014 11:10:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwC4L-0002MZ-HI for bug-gnu-emacs@gnu.org; Sun, 15 Jun 2014 11:10:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WwC4K-0000e6-1L for bug-gnu-emacs@gnu.org; Sun, 15 Jun 2014 11:10:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2014 15:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17768 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17768-submit@debbugs.gnu.org id=B17768.14028449852440 (code B ref 17768); Sun, 15 Jun 2014 15:10:03 +0000 Original-Received: (at 17768) by debbugs.gnu.org; 15 Jun 2014 15:09:45 +0000 Original-Received: from localhost ([127.0.0.1]:48427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WwC40-0000dH-3o for submit@debbugs.gnu.org; Sun, 15 Jun 2014 11:09:44 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:60745) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WwC3x-0000d2-35 for 17768@debbugs.gnu.org; Sun, 15 Jun 2014 11:09:42 -0400 Original-Received: from [194.166.85.236] ([194.166.85.236]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MN604-1WpaM53MBk-006cIi; Sun, 15 Jun 2014 17:09:30 +0200 In-Reply-To: <83zjhfv3r9.fsf@gnu.org> X-Provags-ID: V03:K0:I8O7lzOeMkSf6Y4mMi4vwWE8wT/zRV8sSI5LdmyQdK6XUjQpSuB xq2c+GtbNczy3PCeIsksF8IT+EPNCR3t4Sr6wuQdSPMjMwq4xcoOQtBt1W4Yu28TpTNntZ9 i4A3FY+4TUGb0VeaeRNwkaIExZHLU9P4lw1xgzsEEUFbhH5yEZ4aHh0YTokNaw3McaOf6Tb PItS0WNpPyxeEwHlTC/NA== 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:90399 Archived-At: > How else can column and row be measured, except from the window edge? From the left upper edge of the frame, just as the x-y-coordinates. At least that's apparently what the author of ruler mode thought. And if you compare it with the description of `posn-actual-col-row', such interpretation sounds quite reasonable to me. What is the difference between `posn-col-row' and `posn-actual-col-row' for a position within the text area of a window? If there's none, then why does the latter explicitly talk about windows and the former not? If there's one, what is it? >> Could someone look into the doc-string and info entry of `posn-col-ro= w' >> and maybe improve them to avoid such confusion. > > I don't understand the confusion, but I went out and made it more > clear anyway (r117242 on the emacs-24 branch). Thank you. But IIUC the reference to "window edge" is still missing from the manual entry. Someone who reads "given in units of the frame's default character width and default line height" might still conclude that we count from the frame edge. The only implict reference to "window" comes from the term "text area" and I'm not sure how familiar people are with that and whether they connect it to windows at all. >> For example: >> >> This function returns a cons cell `(COL . ROW)', containing t= he >> estimated column and row corresponding to buffer position >> >> ... what does "buffer position" mean here ... > > The meaning of the word "position" is overloaded here: the POSITION > argument of the function includes a reference to a buffer position. A= > better way to say that is "... corresponding to the buffer position > given by POSITION." > >> Note that ROW is counted from the top of the text area. If th= e >> window >> >> ... which window is meant here ... > > The window given by POSITION, of course. Perhaps you misremember that= > the POSITION argument is a complex data structure, not just a number. > It includes a reference to the window where the event took place. I know. But the phrase "corresponding to buffer position POSITION" was surely misleading. And do we even care about "buffer positions" here? I doubt that. All we do is returning coordinates in terms of frame lines and columns (as opposed to coordinates in terms of pixels as returned by `posn-x-y'). >> possesses a header line (*note Header Lines::), it is _not_ >> counted as the first line. >> >> ... this sounds obvious but what =C2=B4does "not counting" stand for?= > > It stands for "not counting". IOW, the header line is not included in= > the row count, and the first text line is still row number zero, not > number 1. Earlier we say "Row 0 is taken to be the header line if the window has one, or the topmost row of the text area otherwise." which I would interpret as "The header line, if present, is counted as line 0. If no header line is present the first text line is counted as line 0.", that is, the header line _is_ counted. I'm too silly to grok that. >> > into >> > >> > (setq col (- (car (posn-col-row start)) >> > (scroll-bar-columns 'left)) >> > ... >> >> This sounds like the correct solution to me. > > In general, one should stay away of columns when dealing with > coordinates, since columns are measured in logical order, i.e. in a > R2L line they are measured from the right edge of the window. But > since in this case columns are just x coordinates measured in other > units (and therefore calling them "columns" is a misnomer), I think > it's OK in this case. This means that we shouldn't provide `posn-col-row' in the first place which I'd consider the best solution. In any case, ruler mode deals with columns, so it has to either access them somehow or provide an abstraction based on pixel values. martin