bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width

bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width

[Phil Sainty]

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.

This behaviour seems to be consistent, such that with :width the
current-column result comes from the (rounded) number of real columns
over which the specified space(s) stretch; whereas with :relative-width
the current-column is the same as it would have been without the text
property.

I'm confused because the manual doesn't seem to suggest that there
should be a difference between the two specifications, other than which
character is used as the basis for the visual appearance of the space:

(elisp) Specified Space:

‘:width WIDTH’
      If WIDTH is a number, it specifies that the space width should be
      WIDTH times the normal character width.  WIDTH can also be a "pixel
      width" specification (*note Pixel Specification::).

‘:relative-width FACTOR’
      Specifies that the width of the stretch should be computed from the
      first character in the group of consecutive characters that have
      the same ‘display’ property.  The space width is the width of that
      character, multiplied by FACTOR.


What I was hoping for was the control of being able to specify a precise
:width (because the resulting width of tabs when using :relative-width
gets rather tricky in practice when it comes to tabs which are not
tab-width wide), but with the (current-column) behaviour of
:relative-width.

(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.)


-Phil

bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width

[Eli Zaretskii]

> 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.

bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width

[Phil Sainty]

Hi Eli,

On 23/09/15 04:57, Eli Zaretskii wrote:
>> 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.

Ah. Well this is quite unfortunate for me.

I've recompiled, and can confirm the change. Unfortunately the
revised behaviour is actually the opposite to what I was hoping for.
(A version of :width with the (now old) column behaviour of
:relative-width would have been perfect.)

In order for me to manipulate the *apparent* size of indentation
without having any *practical* effect on the buffer, it's important
that the current-column value for any given character of indentation
does not change.

If the current-column for a character can change, then simply
re-indenting a line/region may cause the number of characters
of indentation to change, even if the user had not edited the
text since it was originally indented. (calculate-lisp-indent
is dependent on current-column, for example.)

Is there a way forward for me here?

My library is/was *mostly* working how I wanted (I think the
cases where using :relative-width had actually caused problems
were probably edge cases), and I was intending to propose it as
a GNU ELPA package.

Assuming the new change is definitely how the existing properties
should work, would you consider adding new alternative properties
which provide the "specified space widths do not affect column
numbers" behaviour?


-Phil

p.s. Please let me know if you'd like to see examples and/or code?

bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width

[Eli Zaretskii]

> Date: Thu, 24 Sep 2015 00:32:15 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
> 
> On 23/09/15 04:57, Eli Zaretskii wrote:
> >> 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.
> 
> Ah. Well this is quite unfortunate for me.
> 
> I've recompiled, and can confirm the change. Unfortunately the
> revised behaviour is actually the opposite to what I was hoping for.
> (A version of :width with the (now old) column behaviour of
> :relative-width would have been perfect.)

Then I don't really understand your bug report.  Can you explain what
was problematic for you in the old behavior?  I could easily revert
the change I made, if you convince me the previous behavior was
correct.

> In order for me to manipulate the *apparent* size of indentation
> without having any *practical* effect on the buffer, it's important
> that the current-column value for any given character of indentation
> does not change.
> 
> If the current-column for a character can change, then simply
> re-indenting a line/region may cause the number of characters
> of indentation to change, even if the user had not edited the
> text since it was originally indented. (calculate-lisp-indent
> is dependent on current-column, for example.)

I don't understand what you are trying to accomplish, on a higher
level.  Why does it make sense for the apparent size of the
indentation to change without affecting the value returned by
current-column?  And if it does, why can't you override the default
behavior of current-column instead of using fancy display properties?

> Is there a way forward for me here?

Does this do what you want:

  (insert (propertize " " 'display '(space :width (100))))

(The number 100 is in pixels; see the node "Pixel Specification" in
the ELisp manual.)

I'm not sure this is not a bug, though.  Perhaps we should fix the
code in current-column that handles pixel values as well.  Or maybe
space specs in pixels should always count as one column, I don't know.

> My library is/was *mostly* working how I wanted (I think the
> cases where using :relative-width had actually caused problems
> were probably edge cases), and I was intending to propose it as
> a GNU ELPA package.

Can you describe those edge cases?

> Assuming the new change is definitely how the existing properties
> should work, would you consider adding new alternative properties
> which provide the "specified space widths do not affect column
> numbers" behaviour?

See above.

And I'm no longer sure the new change is definitely how
:relative-width should behave, as it sounds like any space
specification in pixels, or actually any value that is not in units of
the default character width, seems to be counted as a single character
regardless of its actual width.