unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* MPS: composition
@ 2024-04-28 12:49 Gerd Möllmann
  2024-04-28 13:21 ` Helmut Eller
  0 siblings, 1 reply; 7+ messages in thread
From: Gerd Möllmann @ 2024-04-28 12:49 UTC (permalink / raw)
  To: Eli Zaretskii, Helmut Eller; +Cc: emacs-devel

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?



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: MPS: composition
  2024-04-28 12:49 MPS: composition Gerd Möllmann
@ 2024-04-28 13:21 ` Helmut Eller
  2024-04-28 14:03   ` Eli Zaretskii
  2024-04-28 14:07   ` Gerd Möllmann
  0 siblings, 2 replies; 7+ messages in thread
From: Helmut Eller @ 2024-04-28 13:21 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel

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?



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: MPS: composition
  2024-04-28 13:21 ` Helmut Eller
@ 2024-04-28 14:03   ` Eli Zaretskii
  2024-04-28 18:55     ` Helmut Eller
  2024-04-28 14:07   ` Gerd Möllmann
  1 sibling, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2024-04-28 14:03 UTC (permalink / raw)
  To: Helmut Eller; +Cc: gerd.moellmann, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: MPS: composition
  2024-04-28 13:21 ` Helmut Eller
  2024-04-28 14:03   ` Eli Zaretskii
@ 2024-04-28 14:07   ` Gerd Möllmann
  1 sibling, 0 replies; 7+ messages in thread
From: Gerd Möllmann @ 2024-04-28 14:07 UTC (permalink / raw)
  To: Helmut Eller; +Cc: Eli Zaretskii, emacs-devel

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...



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: MPS: composition
  2024-04-28 14:03   ` Eli Zaretskii
@ 2024-04-28 18:55     ` Helmut Eller
  2024-04-29  6:21       ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Helmut Eller @ 2024-04-28 18:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gerd.moellmann, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: MPS: composition
  2024-04-28 18:55     ` Helmut Eller
@ 2024-04-29  6:21       ` Eli Zaretskii
  2024-04-29  7:21         ` Helmut Eller
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2024-04-29  6:21 UTC (permalink / raw)
  To: Helmut Eller; +Cc: gerd.moellmann, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: MPS: composition
  2024-04-29  6:21       ` Eli Zaretskii
@ 2024-04-29  7:21         ` Helmut Eller
  0 siblings, 0 replies; 7+ messages in thread
From: Helmut Eller @ 2024-04-29  7:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gerd.moellmann, emacs-devel

>> 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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-04-29  7:21 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-28 12:49 MPS: composition Gerd Möllmann
2024-04-28 13:21 ` Helmut Eller
2024-04-28 14:03   ` Eli Zaretskii
2024-04-28 18:55     ` Helmut Eller
2024-04-29  6:21       ` Eli Zaretskii
2024-04-29  7:21         ` Helmut Eller
2024-04-28 14:07   ` Gerd Möllmann

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).