GNU bug report logs - #18493
24.3.93; posn-col-row should take text-scale-mode into account

Previous Next

Full log

Message #47 received at 18493 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 18493 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#18493: 24.3.93;
 posn-col-row should take text-scale-mode into account
Date: Thu, 18 Sep 2014 20:00:29 +0300

> Date: Thu, 18 Sep 2014 08:52:55 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 18493 <at> debbugs.gnu.org
> 
> > 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.

You are being carried away, and probably also influenced by the
"usual" meaning of "column" and "row".  What posn-col-row returns are
not arbitrary random values it finds around the block.  It returns
precise coordinates in units of canonical character size.  These
values are useful because there are functions in Emacs that expect
them.

So, while it is meaningless to talk about "columns" and "rows" in
their usual meanings, it is still meaningful to talk about coordinates
measured in canonical character cell units.

> The case of text scaling seems to me to be a case where we can
> meaningfully return the visual column and row.

In my other mail I wrote that the buffer position is all you need for
that, and you already have it.  So I see no general problem here,
unless someone shows a particular use case where that is not enough
for some reason.  Then we can reason whether what's needed is
"scalable" variant of posn-col-row or something else.

> And if `posn-actual-col-row' really does return the actual, visual
> column and row

It doesn't.  posn-actual-col-row is just an accessor function to some
of the data in the click event.  See the discussions I pointed to.

> So let me ask you that same question: what is the use case that the
> current design supports?

Just grep the Lisp files for that function, there are several dozens
of its uses throughout Emacs (and a few more in C).

> IOW, why have two separate functions, `posn-col-row' and
> `posn-actual-col-row'?

They do 2 very different things.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.