Re: search-default-mode char-fold-to-regexp and Greek Extended block characters

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Fri, 26 Jul 2019 21:38:30 +0300, Juri Linkov <juri@linkov.net> said:

    Juri> If there are many such cases, then better to handle them automatically indeed
    Juri> (if this doesn't cause slowdown too much) instead of adding them one by one
    Juri> to the default values.  Does this handle ß as well?
    >> 
    >> There are 74, and I donʼt want to maintain such a list by hand :-).

    Juri> Yes, 74 is too tedious to maintain by hand, so better to install your
    Juri> previous patch (if it doesn't have the problem mentioned below) since

The only difference between v2 and v1 of the patch is that v2 handles
ß, so v1 is probably better.

    Juri> there are only 3 such complex characters (handled by your newer patch)
    Juri> that is easy to add by hand:

    Juri>   '((?ß "ss")
    Juri>     (?ΐ "ΐ")
    Juri>     (?ΰ "ΰ"))

I donʼt understand this comment. With v1 of the patch, ß is the only
one that would need to be added by hand to char-fold--default-include

    >> ß is not a complex character, so is never looked at here. But if we
    >> hoist the checking out of the loop over complex characters, we can
    >> make that work as well (this supersedes my previous patch).
    >> 
    >> I have no idea of the performance impact of all this.
    >> [...]
    >> +                   (aset equiv (aref roundtrip 0)
    >> +                         (cons str (aref equiv (aref roundtrip 0))))))

    Juri> It seems this adds a symmetric decomposition from the first character of "ss",
    Juri> i.e. from ?s to "ß".  Shouldn't this rather update 'equiv-multi' instead?

Yes, thinko on my part.

    Juri> OTOH, I see no reason to add symmetric decompositions by default since
    Juri> they are handled by the option 'char-fold-symmetric'.

OK. Sounds like v1 is the winner. Iʼll clean it up and commit when ready.

Robert