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: Thu, 04 Jun 2020 19:52:42 +0000
> 
> > As for script and language, for now adding them would just waste
> > memory, since we don't yet have any meaningful support for
> > buffer-local, let-alone paragraph-local, scripts and languages.  When
> > we added HarfBuzz support, I considered adding some functionality to
> > determine language and/or script from the codepoints, but decided that
> > it made little sense, since HarfBuzz already does exactly that in
> > hb_buffer_guess_segment_properties.  So I think we should add to the
> > FIXME in hbfont.c the fact that when we do support those internally in
> > Emacs, we should add these attributes to cached gstrings, but not yet
> > actually add them for now.
> 
> 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.

> Could we maybe get away with just doing so once? My suggestion would be
> to add a single field to gstrings which would currently be L2R or R2L
> but might become an alist or something when we get around to adding
> those features?

We could add an element that would currently be a symbol or an
integer, but could later become a vector of several elements.  Is that
what you had in mind?  (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.)

> > Here's the patch I propose for emacs-27:
> 
> Let's try that.

Pushed to the emacs-27 branch.