Re: `aset` on strings, changing the size in bytes

[Stefan Monnier <monnier@iro.umontreal.ca>]

> What's the justification for such an incompatible change, though?
> This feature _is_ used, e.g. see ruler-mode.el.

Indeed, ruler-mode is the main user I know of this feature.

> I understand that the effect of the change will be that whenever one
> wants to mutate a string by replacing a character, they would need to
> cons a new string, with the likes of
>
>   (setq str (concat (substring str ...) new-char (substring str ...)))
>
> is that right?

There are several alternatives.  The ones I'm familiar with are:
- the `concat` option you mention
- use a unibyte string
- use a vector rather than a string
- use a (temp)buffer rather than a string
For ruler-mode, I've found the temp-buffer to be the better option.

> Which means in practice that 'aset' will need to generally disappear
> from string-processing code, because in practice it is impossible to
> know when the byte length will change without complicated
> calculations, so robust code will need to drop use of 'aset' for
> strings, except in a small set of specialized situations.

In the general case, indeed.  But in my experience, `aset` is used very
rarely on strings and many of those cases are known to only involve
ASCII chars or to work on unibyte strings.

> Or maybe the proposal is to modify 'aset' to do the above under the
> hood?

No, "'aset' do the above under the hood?" is what we have now.


        Stefan