bug#17768: 24.3; problem with two ruler-mode windows

[martin rudalics]

> 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