Re: master 49e243c0c85: Avoid resizing mutation in subst-char-in-string, take two

[Eli Zaretskii]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Wed, 15 May 2024 19:29:04 +0200
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> 15 maj 2024 kl. 14.40 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > One important use case where this is not rare at all is when replacing
> > characters from the same Unicode block (= "script").
> 
> It is very rare to see replacement exclusively confined to single block, 
> except for block 0 (ASCII). Scripts, even Latin, generally transcend blocks 
> and even planes. 

"Rare" is in the eye of the beholder.  Imagine processing of Arabic or
Greek or Cyrillic text -- these replacements are natural there.

> Text written in one script also tends to include characters from blocks not 
> related to that script, such as symbols, spaces, combining marks, numerals 
> etc.

That's true, but replacing punctuation and symbols by letters is
_really_ rare, at least IME.

> The usefulness of equal-length multibyte `aset` is very small,

I guess we'll have to agree to disagree about this.

> One reason why single-character multibyte replacement (`aset`, 
> `subst-char-in-string`, `store-substring`, most of the cl-lib functions etc) 
> is so rare is that in the world of Unicode, a 'character' can be a sequence 
> of scalar values (combining chars, modifiers etc) so a one-for-one value 
> replacement is just too inflexible and limiting.

But Emacs doesn't (yet) support such "characters", except in the
display engine.  If you search for such sequences with Emacs commands,
you will generally not find the corresponding precomposed characters
and other equivalents (we have "character-folding" in search commands,
but that's a trick, really, not a fundamental support of character
equivalence).

So I think these last aspects are not really relevant to the issue at
hand.