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.