bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18493: 24.3.93; posn-col-row should take text-scale-mode into accoun


From: Eli Zaretskii
Subject: bug#18493: 24.3.93; posn-col-row should take text-scale-mode into account
Date: Thu, 18 Sep 2014 19:50:05 +0300

> Date: Thu, 18 Sep 2014 08:37:21 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> > > I don't understand why the value changing helps, instead of hurts,
> > > in that context.  I would think that the column should not change
> > > just because the text is scaled.  But I'm probably missing
> > something.
> > 
> > Take a look at the implementation. The function takes pixel
> > coordinates and divides them by the frame-default character dimensions.
> > text-scale-mode is buffer-local, so it doesn't change the latter.
> 
> Yes, I guessed that.  That sounds like the wrong behavior, to me.
> The frame char size is not useful here, I would think.  What counts,
> for visual _columns_ is the visual char size, i.e., from text scaling.

Perhaps in the case of text scaling, it does (and even then there are
reasons for the current behavior, see my other mail).

But text scaling is just one particular feature that Emacs display
supports; there are many more where it is meaningless to talk about
"columns".  E.g., how do you measure an inline image in columns? what
would be the "column" of the first character displayed after such an
image?  What about stretches of whitespace created by the likes of
':align-to' display properties -- how do you measure them in
"columns" in some useful and predictable manner?

Either we want a general solution, or something for "simple" use
cases.  The former is not possible, as I hope you will agree; the only
general solution is to use pixel coordinates.  The "simple" solution
we already have, it just doesn't go far enough to cover text scaling,
and it will take some serious arguments and real-life use cases to
convince me that we should go farther or introduce a new API for those
use cases.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]