MPS: composition

MPS: composition

[Gerd Möllmann]

AFAICS, all struct compositions (malloc'd) are kept in composition_table
(composite.c), so we could

- alloc struct composition from MPS
- add a fix_compositon 
- make composition_table an exact root

I think that would be nicest approach. WDYT?

Re: MPS: composition

[Helmut Eller]

On Sun, Apr 28 2024, Gerd Möllmann wrote:

> AFAICS, all struct compositions (malloc'd) are kept in composition_table
> (composite.c), so we could
>
> - alloc struct composition from MPS
> - add a fix_compositon 
> - make composition_table an exact root
>
> I think that would be nicest approach. WDYT?

It's the nicest approach.  But it's a lot of code just for this one key
field.  Does this key really have to be a Lisp_Object can't it be
something simple like an integer?

Re: MPS: composition

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel <emacs-devel@gnu.org>
> Date: Sun, 28 Apr 2024 15:21:20 +0200
> 
> On Sun, Apr 28 2024, Gerd Möllmann wrote:
> 
> > AFAICS, all struct compositions (malloc'd) are kept in composition_table
> > (composite.c), so we could
> >
> > - alloc struct composition from MPS
> > - add a fix_compositon 
> > - make composition_table an exact root
> >
> > I think that would be nicest approach. WDYT?
> 
> It's the nicest approach.  But it's a lot of code just for this one key
> field.  Does this key really have to be a Lisp_Object can't it be
> something simple like an integer?

The key is constructed from the composition data itself, which comes
from Lisp:

  if (FIXNUMP (components))
    key = make_vector (1, components);
  else if (STRINGP (components) || CONSP (components))
    key = Fvconcat (1, &components);
  else if (VECTORP (components))
    key = components;
  else if (NILP (components))
    {
      key = make_uninit_vector (nchars);
      if (STRINGP (string))
	for (ptrdiff_t i = 0; i < nchars; i++)
	  {
	    ch = fetch_string_char_advance (string, &charpos, &bytepos);
	    ASET (key, i, make_fixnum (ch));
	  }
      else
	for (ptrdiff_t i = 0; i < nchars; i++)
	  {
	    ch = fetch_char_advance (&charpos, &bytepos);
	    ASET (key, i, make_fixnum (ch));
	  }
    }

Replacing that with an integer would be somewhat tricky.  The
requirement here is that if any part of the composition changes, the
key should be different, or else the results of the composition will
not follow the changes.

Re: MPS: composition

[Helmut Eller]

> Replacing that with an integer would be somewhat tricky.  The
> requirement here is that if any part of the composition changes, the
> key should be different, or else the results of the composition will
> not follow the changes.

You mean, it is explicitly allowed to change part of the key while it is
in the hash table?  This is indeed tricky.  I wouldn't even know how
that could work.

Re: MPS: composition

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: gerd.moellmann@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 28 Apr 2024 20:55:20 +0200
> 
> > Replacing that with an integer would be somewhat tricky.  The
> > requirement here is that if any part of the composition changes, the
> > key should be different, or else the results of the composition will
> > not follow the changes.
> 
> You mean, it is explicitly allowed to change part of the key while it is
> in the hash table?

The composable character sequences and the rules to compose them are
defined by Lisp data structures, and those can be modified by Lisp
programs, yes.

As a simple example, consider automatic compositions, produced by
auto-composition-mode.  These compositions are defined by
composition-function-table.  It is a char-table, where each composable
character has a non-nil entry.  We have such rules defined by default
for several languages which require that, but a Lisp program or the
user are allowed to add or modify those rules as they see fit, and
Emacs should not reuse stale cached compositions when the rules
change.  A simple practical example is to define rules for ligatures,
when certain sequences of ASCII characters, like "-->", are displayed
as corresponding font ligatures.  The rules for ligation, encoded in
composition-function-table, can easily change during an Emacs session.

We have clear-composition-cache to make sure stale cached compositions
don't get in the way, but that is a drastic measure, so we use it very
sparingly.

Re: MPS: composition

[Helmut Eller]

>> You mean, it is explicitly allowed to change part of the key while it is
>> in the hash table?
>
> The composable character sequences and the rules to compose them are
> defined by Lisp data structures, and those can be modified by Lisp
> programs, yes.

What's confusing me is that if the key changes, then so would the
hash-code.  But maybe symbols with plists are used, then it would work
again.  Anyway, it would be too much trouble not to use Lisp_Object here.

Re: MPS: composition

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Sun, Apr 28 2024, Gerd Möllmann wrote:
>
>> AFAICS, all struct compositions (malloc'd) are kept in composition_table
>> (composite.c), so we could
>>
>> - alloc struct composition from MPS
>> - add a fix_compositon 
>> - make composition_table an exact root
>>
>> I think that would be nicest approach. WDYT?
>
> It's the nicest approach.  But it's a lot of code just for this one key
> field.  Does this key really have to be a Lisp_Object can't it be
> something simple like an integer?

Good question...