bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44521: 27.1; ivy.el breaks harfbuzz Arabic shaping


From: Eli Zaretskii
Subject: bug#44521: 27.1; ivy.el breaks harfbuzz Arabic shaping
Date: Mon, 09 Nov 2020 17:25:09 +0200

> Date: Sun, 08 Nov 2020 19:20:35 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 44521@debbugs.gnu.org
> 
> > From: Thamer Mahmoud <thamer.mahmoud@gmail.com>
> > Date: Sun, 08 Nov 2020 19:15:37 +0300
> > 
> > (progn
> >   (load-library "~/.emacs.d/elpa/ivy-0.13.0/ivy-overlay.el")
> >   (load-library "~/.emacs.d/elpa/ivy-0.13.0/colir.el")
> >   (load-library "~/.emacs.d/elpa/ivy-0.13.0/ivy.el")
> >   (ivy-mode t)
> >   (run-with-timer .5 nil 'set-input-method "arabic")
> >   (run-with-timer .5 nil 'insert "السلام عليكم")
> >   (execute-extended-command nil))
> > 
> > 2. While still in the minibuffer, type any Arabic letter. Note the
> >    AIN(ع) in "عليكم" changes shape from initial to final.
> > 
> > This bug breaks shaping in most buffers, especially after using
> > swiper.el (ivy-based isearch).
> 
> I'm not familiar with ivy, but if it writes the text in the minibuffer
> in several overlays, then the Arabic text will indeed become
> disconnected and generally shaped incorrectly.
> 
> I'll try to look into this, but to make this easier and more efficient
> I'd appreciate a test case that is less complicated, preferably not
> using ivy at all.

Actually, it turned out that the reason is very clear, thanks for the
recipe which made it so easy.  So I've now fixed this on the emacs-27
branch for the upcoming Emacs 27.2.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]