bug#42562: Problem with rendering Persian text still exists in minibuffer and dired

[Sineau Gh]

Thank you for clearing things up Eli. You are correct. As I remember it
was like this before emacs 27 too.

I have one more question. You have hinted in a previous email that
setting the font for emacs may cause it to use a font that doesn't
support arabic shaping. Are you suggesting that I can't use commands
like `set-frame-font` or `default-aframe-list` like before? Or is
there something else in my config that messes up the ligatures?
Because my config is working fine with previous versions of emacs and
also emacs 27 compiled "without-harfbuzz".ses up the ligatures? Because my
config is working fine with previous versions of emacs and also emacs
27 compiled "without-harfbuzz".

On Fri, 31 Jul 2020 at 17:26, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Sineau Gh <sineaugh@gmail.com>
> Date: Fri, 31 Jul 2020 11:02:44 +0430
> Cc: 42562@debbugs.gnu.org
>

> تحقیق
> تست
> مدرن.txt
> تحقیق.org

> - visit a file using C-x C-f.
> - use TAB for *Completion Buffer*.
> - first character of all file names are disjointed.
> - type ت to filter the filenames, now the second characters are
>   disjointed.
> - now open one of the files. in modeline first and last characters of
>   the filename are disjointed.

Thanks.  Now everything is clear: this is due to the basic limitation
of how Emacs displays text with different faces: we render each run of
character in the same face separately from characters in a different
face.  So if the face changes in the middle of a word, we render the
two parts of the word separately, and that breaks Arabic shaping.

Fixing this would need significant changes in the low-level code that
handles text layout, which is one of the basics of the current display
engine.  Patches are welcome.