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

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

bug#21533: 24.5; current-column result varies between specified spaces u


From: Eli Zaretskii
Subject: bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width
Date: Tue, 22 Sep 2015 19:57:23 +0300

> Date: Wed, 23 Sep 2015 02:29:25 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
> 
> I can't tell whether this is expected behaviour or not?
> 
> Starting from emacs -Q, in the *scratch* buffer, I get the following
> results from evaluating these forms with C-j:
> 
> (progn (insert (propertize " " 'display '(space :width 2)))
>         (current-column))
>   2
> 
> (progn (insert (propertize " " 'display '(space :relative-width 2)))
>         (current-column))
>   1
> 
> Which is to say that a specified space of :width 2 occupies 2 columns,
> while a specified space of :relative-width 2 occupies only 1 column.

Simply put, current-column did not support :relative-width.  Now it
does, so your example should work as expected with the development
sources.

But beware: current-column is not guaranteed to always produce the
exact results you'd expect on GUI displays when wider-than-normal
characters are involved.  That's because character width in column
units is always an integer: 0, 1, or 2, whereas the actual pixel width
of those characters depends on the font and is in general not an
integral multiple of the "normal character width".  For example, try
your test case with the (double-width) character ᄀ instead of the
space.  Or try ^A (Ctrl-A).

If you want accurate screen coordinates, use pixel coordinates
returned by functions like posn-at-point instead.  You can convert the
pixel coordinates into units of canonical character width
(a.k.a. "columns") if you divide the pixel coordinates by the value
returned by the function default-font-width.

Also note that :relative-width is only supported on GUI frames.  The
documentation omitted this crucial fact; I fixed that as well.

> (What I'm actually *doing* is scaling indentation, and so if the column
> numbers vary with the scaling, then re-indenting the buffer causes
> changes; and I want the effect to be purely visual.)

If you only ever need to scale TAB and SPC characters, then the above
restrictions don't apply, I think.  But it is still useful to keep
them in mind.





reply via email to

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