From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: andrea.rossetti@gmail.com, 17768@debbugs.gnu.org
Subject: bug#17768: 24.3; problem with two ruler-mode windows
Date: Sun, 15 Jun 2014 17:09:26 +0200 [thread overview]
Message-ID: <539DB726.1080908@gmx.at> (raw)
In-Reply-To: <83zjhfv3r9.fsf@gnu.org>
> 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-row'
>> 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 the
>> 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 the
>> 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 ´does "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
next prev parent reply other threads:[~2014-06-15 15:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-12 23:57 bug#17768: 24.3; problem with two ruler-mode windows Andrea Rossetti
2014-06-13 7:29 ` martin rudalics
2014-06-14 16:45 ` Eli Zaretskii
2014-06-15 15:09 ` martin rudalics [this message]
2014-06-15 16:17 ` Eli Zaretskii
2014-06-16 21:05 ` Stefan Monnier
2014-06-14 17:22 ` Andrea Rossetti
2014-06-15 15:09 ` martin rudalics
2014-06-15 18:06 ` Andrea Rossetti
2014-06-15 23:22 ` Andrea Rossetti
2014-06-16 7:10 ` martin rudalics
2014-06-16 7:10 ` martin rudalics
2014-06-16 8:45 ` bug#17768: Andrea Rossetti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539DB726.1080908@gmx.at \
--to=rudalics@gmx.at \
--cc=17768@debbugs.gnu.org \
--cc=andrea.rossetti@gmail.com \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.