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

From: Phil Sainty <[email-masked]>
Date: Thu, 24 Sep 2015 00:32:15 +1200

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?