search

railwaycat / homebrew-emacsmacport

Emacs mac port formulae for the Homebrew package manager
BSD 2-Clause "Simplified" License
1.65k stars 125 forks source link

emacs-mac on big sur 11.3.1 doesn't redraw correctly in search mode #253

Open totalbanal opened 3 years ago

totalbanal commented 3 years ago

after updating to big sur 11.3.1 emacs is not rendering correctly depending on mode

how to reproduce

used version:

the functionality fails on the brew emacs-mac package, but works on the brew emacs installation

jianfenglu commented 3 years ago

same problem here.

minminfu commented 3 years ago

A workaround I figured out: add these two lines to the ~/.emacs file.

(add-hook 'isearch-update-post-hook 'redraw-display) (add-hook 'isearch-mode-end-hook 'redraw-display)

lefterov commented 3 years ago

Works!

TwentyFourD commented 2 years ago

I avoided the problem by using the formula instead of the cask:

brew uninstall emacs-mac # Remove cask brew install emacs-mac # Install formula ln -s /usr/local/opt/emacs-mac/Emacs.app /Applications/ # Link to Application (as per the guidance at the end of the formula installation)

ylluminarious commented 2 years ago

Has anyone else found any other solutions to this problem? I've run into the same issue, except that when I type M-x redraw-display, nothing happens - it stays frozen. I'm unable to close the frame or open any new GUI frames without crashing Emacs.

For me, the bug isn't occurring occurring reliably either. It happens at random with no warning at all. Also, it occurs when I exit the minibuffer in general, not just in isearch.

The only thing I can do is use Emacs via emacsclient -t, but that doesn't work well for me since I rely on several GUI features.

So currently my only recourse is to force-quit Emacs and restart it. Has anyone come up with any better solutions?

TwentyFourD commented 2 years ago

Did you try using the formula instead of the cask as per my previous comment? Then you don't need the redraw-display workaround.

ylluminarious commented 2 years ago

@TwentyFourD Unfortunately, I can't use the Homebrew formula, because I apply a few minor patches to my own build. The problem, however, seems uncannily similar in its symptoms, so I'm curious what the underlying cause is that makes the formula work properly, whereas the cask does not.

TwentyFourD commented 2 years ago

I think your patch might be included in the formula. See https://github.com/railwaycat/homebrew-emacsmacport/blob/master/Formula/emacs-mac.rb and https://github.com/railwaycat/homebrew-emacsmacport/blob/master/patches/multi-tty-27.diff

ylluminarious commented 2 years ago

@TwentyFourD Thanks a lot for your advice! I finally tried running the railwaycat Homebrew tap, and you're correct, my patch is included in the formula here. I've been running for over 9 and a half days now, with no crashes from C-g anymore. This was a stark contrast to previously on my own build, where I couldn't run usually more than a day or two without crashing from C-g.

However, I did have an odd crash occur during my first day of usage which made me wary for a while. My error message was remarkably similar to the issues reported in https://github.com/railwaycat/homebrew-emacsmacport/issues/206, https://github.com/railwaycat/homebrew-emacsmacport/issues/169, https://github.com/hlissner/doom-emacs/issues/1340, and https://github.com/railwaycat/homebrew-emacsmacport/issues/179. It occurred right as I was typing, not from using any special commands. My paragraph was getting kind of long, but it just simply crashed right as I was in the middle of typing. No warnings signs at all.

Again, no special commands or anything, just simply typing. It probably crashed just after or during a self-insert-command. I have no idea what caused this crash to occur. My Emacs uptime was about 1 or 2 days when this happened, but I haven't had this problem recur for over 9 and a half days now, so I hope it was just a random fluke.

In any case, your advice seems to have at least resolved my problems with the C-g bug. I'm probably going to use the railwaycat formula as my main build from now on. This has greatly helped to restore my sanity. I still can't help but feeling nervous every time I run C-g (after dealing with months of crashes), but at least now I'm pleasantly relieved when I realize Emacs is still running 😸

TwentyFourD commented 2 years ago

Good to hear that it has helped. I haven't had any crashes but my sessions are usually short and I probably don't drive emacs as hard as you do :). Just a bit of light code editing for me.

ylluminarious commented 2 years ago

Darn, it seems like I might have spoken too soon.

A day after I posted my above comment, I decided to reboot my machine. That night, I ran into this GUI-frame-freeze bug again. Before it occurred, I accidentally typed C-x C-c which normally runs save-buffers-kill-terminal, but thanks to a package I use called mac-pseudo-daemon, Emacs did not quit and instead simply closed my frame. However, once I opened a new frame shortly afterwards, this freeze happened again when I typed C-g while isearching for something in Dired.

Today, it happened again when I typed C-g in a an ido-switch-buffer minibuffer prompt. I also happened to be writing a long paragraph shortly before it occurred, but I doubt whether that had any bearing on it at all. It seems to have no correlation with the previous incident, so I'm inclined to think that unfortunately the railwaycat build is not immune to this problem either.

My only idea to try and circumvent the problem again is to upgrade my Xcode and Xcode Tools installation (from 13.1 to 13.2.1), and rebuild Emacs, perhaps with some different options this time (like --with-mac-metal), due to a remark in the changelog about the SDK. I'm also going to try --HEAD this time, instead using of the standard release. However, I have no idea whether this will actually fix the bug and prevent the freeze from happening again. This is extremely frustrating and disappointing to have to deal with again... if anyone has any further advice, it would be greatly appreciated.