Eli Zaretskii writes: >> Cc: Michael Albinus , 62194@debbugs.gnu.org >> Date: Fri, 17 Mar 2023 17:45:43 +0100 >> From: miha--- via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> Though I do think that if a function that calls a-p-o with >> JUST-THIS-ONE=nil isn't internal, it should mention that it can run >> timers in its doc string. > > I don't see why: timers can run in Emacs almost anywhere, so > mentioning that in doc strings of every function makes little sense. I'm not completely sure how timers work, but >> But here we are talking about 'expand-file-name' and other functions >> from tramp-sh-file-name-handler. For these, I disagree that we want them >> to accept output from other processes and call their filters. >> 'expand-file-name' and others are used often and, for most of the >> existence of Emacs, they did not call proc filters. I think it's >> dangerous to have them do it now. > > Process filters can be also called at any time, because they basically > depend on when the output from a subprocess arrives. Why would you > want that to stop while Emacs processes expand-file-name? From '(elisp) Output from Processes': Output from a subprocess can arrive only while Emacs is waiting: when reading terminal input, in ‘sit-for’ and ‘sleep-for’, in ‘accept-process-output’, and in functions which send data to processes. From my understanding of process.c, wait_reading_process_output normally needs to be in the call stack in order for process filters to run. >> 'expand-file-name' is synchronous, therefore tramp has to make it use >> accept-process-filter (tell me if there's another way). It can use it in >> roughly two ways: with JUST-THIS-ONE=t or JUST-THIS-ONE=nil. In the >> first case, we hit the eglot-over-ssh freeze problem and in the second >> case, we'll have 'expand-file-name' call timers and process filters, >> which I explained above why I don't like. > > I think you should teach yourself to like that.