On Tue, 2024-09-03 at 19:18 +0300, Konstantin Kharlamov wrote: > On Tue, 2024-09-03 at 18:30 +0300, Eli Zaretskii wrote: > > > Cc: da_...@orange.fr > > > From: Konstantin Kharlamov <hi-an...@yandex.ru> > > > Date: Tue, 03 Sep 2024 17:46:09 +0300 > > > > > > CCing the commit author. > > > > > > Sorry for using external plugin, but master has two separate > > > unrelated > > > critical regressions (the other one is going via link in *Help* > > > buffer > > > and getting Emacs locked up with 100% CPU and quickly increasing > > > memory > > > usage, which complicates reducing the steps), and since there's a > > > clear > > > commit that introduced the problem I decided to report it as is. > > > > > > # Steps to reproduce > > > > > > 1. Make sure you're in the Emacs repository and > > > `./build/src/emacs` > > > is > > > the built binary > > > 2. Execute `git clone --depth 1 > > > https://github.com/emacs-evil/evil > > > /tmp/evil` > > > 3. Execute `PATH="$(pwd)/build/src/:$PATH" make -C /tmp/evil > > > emacs` > > > (Emacs with Evil loaded will start) > > > 4. Press `n` to refuse running tests > > > 5. Turn line numbers on by evaluating: (setq-default display- > > > line- > > > numbers 'visual) > > > 6. Press `df` > > > > What does "df" do? > > "df" is triggering the action "delete text up to" and it will wait > for > the third key, the symbol to "delete text up to". But for the problem > to appear pressing the third key is not required. > > As a matter of fact, sometimes it gets reproduced by just pressing > "f" > which stands for "go to next symbol" (and it would similarly wait a > keypress to define a symbol to go to), but for some reason it happens > much less compared to pressing "df". > > > Does it somehow end up calling string-pixel-width? > > It seems it doesn't. I used a `M-x debug-on-entry string-pixel-width` > and then pressed "df" which made line numbers disappear, but debugger > wasn't triggered. > > > IOW, please show how string-pixel-width is related to the above. > > Offhand I don't know. I would reduce steps, but I can't use *Help* > for > reasons mentioned in my 1st email, and I still didn't find a commit > which does not hang upon following *Help* buffer, because 1000 > commits > before dffdbc1f1fd6 Emacs fails to compile with some native- > compilation > errors and `make clean` doesn't help. I presume finding the culprit > for > this problem will take some time. > > I don't know if it's of any help, but upon pressing "df" the caret > turns from a rectangle to a square (half the rectangle size). This is > indicating that Emacs is waiting for the next keypress, perhaps this > indication somehow triggers the problem…
So FWIW, I'm not really clear how to debug it further. The problem seems to only reproduce interactively. I tried calling manually various functions like `(evil-find-char 1 ?f)`, `(evil-operator-range)`, `(evil-delete 1 3)` but it didn't trigger the problem. In particular, `(evil-operator-range)` is the one that makes caret turn to a square waiting for input, but problem doesn't reproduce like this. However, I found an alternative way to reproduce it, unfortunately still requiring Evil: 1. Press f (it will wait for next character) 2. Press C-g to cancel the action 3. Press M-: Result: line numbers disappear along with minibuffer popping up. Another interesting point: after line numbers disappeared, if I evaluate `display-line-numbers` (i.e. just to see its value), line numbers immediately appear back. ---------- Regarding the unrelated hang, I more or less figured that out. It turned out to be in another plugin, but it didn't look like a plugin bug because usually when ELisp hangs you can stop a loop with C-g or even just quit emacs with ^C or killall, but for some reason occasionally only SIGKILL worked, which made me think it's a hang in C code. But it wasn't.
