I had to comment three lines in the provided workaround:
;; (45 . ".\\(?:\\(?:-[>-]\\|<<\\|>>\\)\\|[<>}~-]\\)")
;; (46 . ".\\(?:\\(?:\\.[.<]\\)\\|[.=]\\)")
;; (47 . ".\\(?:\\(?:\\*\\*\\|//\\|==\\)\\|[*/=>]\\)")
these get emacs stuck on some spacemacs UI elements, e.g. opening a project selection with projectile.
other regexps seem to be working
For me the line with 45 in the beginning breaks Gnus. When it is not commented out, gnus starts with the endless (seemingly) series of beepis and error messages "attempt to shape unibyte text"
I had the same issue, but (63 . ".\\(?:\\(\\?\\?\\)\\|[:=?]\\)") was the problem line for me; I seem to be able to run OK with all the other lines left in.
I've also triggered this in the past, I believe it's an Emacs bug, which makes Emacs freeze with the message "attempted to shape unibyte text". It also affected other modes such as the Ediff helper window which had a certain piece of text which I never looked into. Anyway, I ran an edebug session on a few functions invoked when running ediff, which gave me the message. I can't remember how I figured out it was the ligature code, but it was, since I edited it out and everything worked fine.
I also encounter this. Emacs freezes whenever I open a helm buffer.
I found another one: (58 . ".\\(?:::\\|[:=]\\)") crashes org-mode's org-set-tags-command for me.
on my side this is making emacs 25.1.0.3 to freeze (fedora 24):
;;(124 . ".\\(?:\\(?:|[=|]\\)\\|[=>|]\\)")
Hello! I'm afraid I'm experiencing very similar issue. I use spacemacs on Mac:
Spacemacs: 0.200.7
Emacs: 24.5.1
The problem looks like it's affecting helm integration (whatever I try M-x, or C-x C-f, then the helm should appear, but instead, Emacs hangs indefinitely).
For me, it looks like commenting the following fixes the problem:
(45 . ".\\(?:\\(?:-[>-]\\|<<\\|>>\\)\\|[<>}~-]\\)")
(46 . ".\\(?:\\(?:\\.[.<]\\)\\|[.=-]\\)")
(47 . ".\\(?:\\(?:\\*\\*\\|//\\|==\\)\\|[*/=>]\\)")
Unfortunately, within those there are the symbols I'd love to use, but I think they appear in helm buffer, thus, causing the problem...
Thank you for your help!
Had to uncomment 45, 46, 47 on GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.10) of 2017-04-22 on archlinux.
Does anyone know the root cause of this problem?
FWIW, and for people that are having problems with Helm, I simply disable ligatures altogether in the helm buffers:
(add-hook 'helm-major-mode-hook
(lambda ()
(setq auto-composition-mode nil)))
The ligatures also freezes my Emacs when I enter c++-mode. Disabling auto-composition-mode for c++-mode did not seem to help.
45 crashes eshell for me.
I had the same for a c++ mode. So I commented out line 43 and now it works properly. @mahaarbo I think this fix may help you.
Also where can I find out which line stands for which character? :D
The problem for me was
;; (46 . ".\\(?:\\(?:\\.[.<]\\)\\|[.=-]\\)") ;; This line forces emacs to lock up whenever HELM opens
It made emacs lock up whenever I opened the HELM menu
Freezes in mu4e-headers-mode for me so I had to add:
(add-hook 'mu4e-headers-mode-hook
(lambda () (setq-local auto-composition-mode nil)))
Happens when I start mu4e and use one of the built-in bookmarks: M-x mu4e, bw
For me, the ligatures workaround breaks ediff-mode, turned out the suggestion by @mpolden fixed it using:
(add-hook 'ediff-mode-hook
(lambda () (setq-local auto-composition-mode nil)))
Most helpful comment
FWIW, and for people that are having problems with Helm, I simply disable ligatures altogether in the helm buffers: