Re: Question about composite.c

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerry Agbobada <gagbobada@gmail.com>
> Date: Mon, 20 Jan 2020 23:17:19 +0100
> 
> (defvar composition-ligature-table (make-char-table nil))
> (require 'composite)
> 
> (let ((alist
>        '(
>          (?* . ".\\(?:\\(\\*\\*\\|[*>]\\)[*>]?\\)")
>          )))
>   (dolist (char-regexp alist)
>     (set-char-table-range composition-ligature-table (car char-regexp)
>                           `([,(cdr char-regexp) 0 font-shape-gstring]))))
> 
> (set-char-table-parent composition-ligature-table composition-function-table)
> 
> (setq-local composition-function-table composition-ligature-table)

Can you tell what kind of ligatures you wanted to support that
required such a non-trivial regexp?

Also, why did you need to use a separate char-table instead of
composition-function-table?

> I think my error may come from having a composition-table where a replacement
> triggered by =prettify-symbols= occurs before the regex for
> =composition-ligature-table= happens, so there's only an empty string for
> replacement and there's an error because it doesn't pass the test.

It's not just an empty string, it's a _unibyte_ string.  How did that
happen?

More importantly, please don't use prettify-symbols-mode, which are
based on static compositions, together with automatic compositions.
Static compositions are an obsolete feature, it lacks support for some
modern Emacs features (e.g., bidirectional text), and we should remove
it from Emacs at some future point -- but not before we implement a
replacement for it using composition-function-table and related
machinery.  Mixing these two incompatible compositions is asking for
trouble.  If you turn off prettify-symbols-mode, does the problem go
away?

> diff --git a/src/composite.c b/src/composite.c
> index 53e6930b5f..1151721d61 100644
> --- a/src/composite.c
> +++ b/src/composite.c
> @@ -1735,7 +1735,7 @@ Otherwise (for terminal display), FONT-OBJECT
> must be a terminal ID, a
>    if (NILP (string))
>      {
>        if (NILP (BVAR (current_buffer, enable_multibyte_characters)))
> -       error ("Attempt to shape unibyte text");
> +       error ("Attempt to shape unibyte text \"%s\" in non multibyte
> buffer", string);
>        validate_region (&from, &to);
>        frompos = XFIXNAT (from);
>        topos = XFIXNAT (to);
> @@ -1745,8 +1745,8 @@ Otherwise (for terminal display), FONT-OBJECT
> must be a terminal ID, a
>      {
>        CHECK_STRING (string);
>        validate_subarray (string, from, to, SCHARS (string), &frompos, &topos);
> -      if (! STRING_MULTIBYTE (string))
> -       error ("Attempt to shape unibyte text");
> +      if (strlen(string) != 0 && ! STRING_MULTIBYTE (string))
> +       error ("Attempt to shape unibyte text \"%s\"", string);
>        frombyte = string_char_to_byte (string, frompos);

This cannot be right.  We cannot meaningfully compose unibyte text,
because it is not made of characters, it is made of raw bytes, and
therefore you cannot meaningfully reference composition-function-table
by such raw bytes.  The errors are correct, and must stay that way.
You need to debug this further to understand how come you ended up in
this condition, and then fix whatever root cause caused that.

> * Question
> I guess the only question is : what's supposed to happen when =string= is an
> empty lisp string in this condition ?

There's no problem with empty strings here, as long as they are
multibyte.