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