Michael Albinus <michael.albi...@gmx.de> writes: > Tramp used a non-zero timeout in the past. This was removed some years > ago, I don't remember the reason.
The timeout in tramp-accept-process-output was disabled in commit 54ef338ba3670415cf47fabc33a92d4904707c7e . The commit mentions bug#61350 , however, it's not clear (based on briefly skimming the discussion there) that this change was ever necessary. If not, should the timeout be reintroduced? > I've added (sit-for 0.005) in the loop calling > tramp-accept-process-output. It decreases the CPU load from 100% to > something between 45..50%, when waiting for a response from remote. I am trying to better understand what's going on, so the following is simply for my understanding. Use your discretion when responding. IIUC, we're still actively waiting for the output from the remote host, but simple not _exclusively_ doing so thanks to the `sit-for'. Is my understanding correct? If so, isn't there some mechanism to specify a continuation that's run once the TRAMP process produces output? Such a mechanism shouldn't require a `sit-for' to yield control. In other words, isn't it possible to do both font-locking and getting the response over ssh concurrently (of the main thread, as well wrt each other)? If not, are there technical challenges in doing so, or simply that it's not been implemented (and thus, possibly, we may not know what the challenges are)? > Pushed to master Thank you. I can test this (applied onto 29.4) later in the week along with the `dired-font-lock-keywords' patch and report back. -- Suhail
