On 2023-09-09 07:58, Bruno Haible wrote:
* Commit b93de66735cd6f935ee0970f8cb26908d113e09d introduced mcel.h. Summarize, in comments, the discussion we had regarding SEE and MEE. Basically, MEE is good in all circumstances, whereas SEE is only good if the surrounding applications does only specific things with the strings. Also needs to mention for which encodings it makes a difference, cf.https://lists.gnu.org/archive/html/bug-gnulib/2023-07/msg00131.html
Not sure I agree that "MEE is good in all circumstances". It's not good for applications that have a strong SEE tradition (Emacs, diffutils, grep, etc.); these apps typically do not lose information about the encoding error bytes and SEE's relative simplicity makes this easier.
As I understand it, MEE is good for applications that typically replace a sequence of two or more bytes containing an encoding error, with a single replacement character, thus losing some information. MEE makes this easier since it coalesces the error byte sequences for you - or at least it will, once the problem mentioned in <https://lists.gnu.org/archive/html/bug-gnulib/2023-08/msg00047.html> is fixed.
gnulib/doc/strings.texi currently discusses the SEE vs MEE distinction, but only very briefly and without saying "SEE" or "MEE"; look for "sequences of two or more bytes as a single encoding error" and for "single encoding error can contain two or more bytes". No doubt the discussion could be expanded. Among other things SEE makes things simpler, and that'd be worth mentioning in any extended comparison.
