-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why does xterm--report-background-handler
and version-handler
take 2 seconds to return on at least iterm2 and alacritty? Investigate emacs-bug. (was Doesn't detect pause when starting "emacsclient -nw")
#57
Comments
Yes, that is the intended use case. But not all the file IO code or the buffer init code OR the xterm init code is captured yet. Also, there’s a lot of native frames that are currently hidden because I don’t have a good way to display them, and probably your 2 secs might be found there IF it’s covered. Undocumented feature exists where you can grab the event steam live and that might help. Do
Before doing that, somewhere else in bash, run
This will print a live stream of every command that your Emacs is running, even before executing the command. If you can’t find the time there, it must be somewhere where I haven’t captured yet. I too get slow file opens sometimes and I really want this use case to work so I’m happy to investigate w you if you’re game! |
Ran "socat -u UNIX-RECV:/tmp/sock STDOUT | ts | tee ~/slow.log" in one terminal, and "emacsclient -e '(explain-pause-log-to-socket "/tmp/sock")'; e customize.el ; killall socat", then did a C-x C-c as fast as I could once the file showed up.
Nothing jumps out at me. |
Check it out, you spent two seconds in
1999ms exactly, that's the timeout firing.
Conclusion: somewhere in someone's code, it's literally waiting for some kind of input for 2 seconds. It might be trying to read keyboard input, or it might be trying to read mouse input, or maybe - and this is my suspicion - it is the That happens here-ish, at least in emacs HEAD: https://github.com/emacs-mirror/emacs/blob/master/lisp/term/xterm.el#L764 Check out that the default value of But certainly, for this package, there needs to be some way to see "native frames" somehow, and especially "native frames that timeout". I'm not sure yet how to show that :( I suspect I need to implement #48 or something similar so I can generate a tree view in But I should also productionalize this secret feature (which I intend to do) by providing a way for a separate emacs process to read it and highlight things and stuff. You can see I intended to do that since it spits out elisp that is parseable. |
GNU Emacs 26.1 |
This commit in 27+ decreases the Before 27, there was a hardcoded wait of 2 seconds, and it was not controllable. Suggestion:
|
|
It's either It's also possible |
OK, I lied, both are timing out:
|
on 26.1:
on emacs mainline:
|
xterm is very quick. |
That's crazy. I get that too. Does this PR even work?! emacs-mirror/emacs@c67befd#diff-89047cdd70633a563eda4e02a5fb2e13L674 Very strange:
I conclude there is probably an emacs-lisp bug in that PR above. This is on 28 HEAD. However, I think you can set both values very low and see what happens. I believe it will fix it assuming that PR even half works. Also, I was thinking how annoying it is to recompile emacs for 28+, if you want to stay on 26 I'd honestly just define I am very curious what exactly it is querying for, though, and I will take a look after finishing #56 ... |
Wait, I understand that code now. The total time it waits is the combination of both values. So the PR does work. Just set both values to 0.01. But still doesn't explain what the hell it's querying for...and why all these modern term emulators don't reply to it. |
|
This comment is highly suggestive: |
I saw that too. And this has been hitting me too, but I've been thinking that I've been doing some GC during startup and I was going to get "to it" once I did #27 and track GC pauses. LOL. Well thank you because it has been also frustrating me. I am probably gonna see if I can figure out what the root cause is, and try to report a bug to emacs core... I suspect this is likely hitting lots and lots of people and it wouldn't count as part of Maybe make a post in reddit about this and help the community? There are at least dozens of us still using |
xterm--report-background-handler
and version-handler
take 2 seconds to return on at least iterm2 and alacritty? Investigate emacs-bug. (was xterm--iDoesn't detect pause when starting "emacsclient -nw"
xterm--report-background-handler
and version-handler
take 2 seconds to return on at least iterm2 and alacritty? Investigate emacs-bug. (was xterm--iDoesn't detect pause when starting "emacsclient -nw"xterm--report-background-handler
and version-handler
take 2 seconds to return on at least iterm2 and alacritty? Investigate emacs-bug. (was Doesn't detect pause when starting "emacsclient -nw")
I'm going to open new enhancement issues for the two things I outlined so it makes it easier to find and debug these issues. They were things I wanted to do already, but it's good to get affirmation they are useful features. Thank you for trying explain-pause out and let me know if you find other bugs! I'm going to leave this open until I get time to discover with upstream what's going on.... |
Awesome, thanks again for the debugging help and for making explain-pause-mode! |
I'm trying to track down a 2 second pause where running "emacsclient -nw SOMEFILE" shows emacs immediately (either on the scratch buffer or whatever buffer I was last interacting with in another window/tty) before it shows SOMEFILE.
I start explain-pause-mode in init.el at "emacs --daemon" start time. I tried to open a file 6 times in a row, but explain-pause-top just showed some normal ~70ms GC pauses, nothing close to 2000ms.
Dunno if this use-case is intended or even possible...
The text was updated successfully, but these errors were encountered: