bug#41005: problem with rendering Persian text in Emacs 27

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Cc: valizadeh.ho@gmail.com,  41005@debbugs.gnu.org,  nicholasdrozd@gmail.com
> Date: Fri, 05 Jun 2020 08:41:19 +0000
> 
> >> We're going to have to change the lgstring structure, though, right?
> >
> > I think so.  We should probably add one more element to the vector in
> > LGSTRING_HEADER, because the header is the hash key of the composition
> > cache.
> 
> Do we have to maintain compatibility? If so, I suggest we change
> 
> [FONT-OBJECT CHAR ...]
> 
> to
> 
> [FONT-OBJECT [CHAR ...] DIRECTION], and use ARRAYP (AREF (..., 2)) to
> decide whether the new format is in effect.  I actually thought about
> suggesting the format be [FONT-OBJECT STRING DIRECTION], but that would
> make debugging harder when pretty-printing the string in a failed
> composition re-attempts that composition.
> 
> But of course it would be easier not to maintain compatibility, and then
> we could order the elements any way we choose.

We don't have to be backward-compatible here, I think, as the
structure of the header is an internal implementation detail.  So
something like [FONT-OBJECT DIRECTION CHAR ...] is also a possibility.

We could also put DIRECTION elsewhere and just modify the code that
passes the hash key to the hash function.

> > (I think we should prefer vectors to lists in
> > this case, because consing them is slightly faster, and the number of
> > elements is known in advance and fixed.)
> 
> No argument there, though harfbuzz features, if we ever add them,
> probably should be added as a list inside the vector. I'm talking about
> things like "kern=0" passed to hb_feature_from_string, then to hb_shape,
> to disable kerning.

Maybe.  Something to consider when we actually support those features.