From: Eli Zaretskii <eliz@gnu.org>
To: <miha@kamnitnik.top>
Cc: michael.albinus@gmx.de, joaotavora@gmail.com, 62194@debbugs.gnu.org
Subject: bug#62194: 30.0.50; Two Eglot-over-Tramp tests are failing on master, passing on emacs-29
Date: Fri, 17 Mar 2023 19:22:26 +0200 [thread overview]
Message-ID: <83v8izcmy5.fsf@gnu.org> (raw)
In-Reply-To: <87y1nvgunt.fsf@miha-pc>
> From: <miha@kamnitnik.top>
> Cc: michael.albinus@gmx.de, joaotavora@gmail.com, 62194@debbugs.gnu.org
> Date: Fri, 17 Mar 2023 18:22:14 +0100
>
> 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.
And it is, when Tramp calls expand-file-name and waits for the
response from the remote.
Moreover, there are situations in Emacs when we eventually call
wait_reading_process_output as result of Lisp code that doesn't
necessarily imagine something like that could happen, nor can control
that.
IOW, it is not easy to know from the Lisp level whether Emacs is going
to "wait for something" as part of running some Lisp program.
next prev parent reply other threads:[~2023-03-17 17:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 23:08 bug#62194: 30.0.50; Two Eglot-over-Tramp tests are failing on master, passing on emacs-29 João Távora
2023-03-15 9:40 ` Michael Albinus
2023-03-15 11:45 ` Michael Albinus
2023-03-15 20:24 ` João Távora
2023-03-15 20:36 ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-15 20:45 ` João Távora
2023-03-16 12:02 ` Michael Albinus
2023-03-16 12:20 ` João Távora
2023-03-16 14:57 ` Michael Albinus
2023-03-16 15:12 ` João Távora
2023-03-16 17:35 ` Michael Albinus
2023-03-16 17:59 ` João Távora
2023-03-16 21:18 ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-16 21:57 ` João Távora
2023-03-16 23:38 ` João Távora
2023-03-17 16:45 ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-17 16:47 ` Eli Zaretskii
2023-03-17 17:22 ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-17 17:22 ` Eli Zaretskii [this message]
2023-03-17 10:44 ` Michael Albinus
2023-03-17 11:19 ` João Távora
2023-03-18 9:38 ` Michael Albinus
2023-03-18 11:29 ` João Távora
2023-03-18 12:23 ` Michael Albinus
2023-03-18 12:33 ` João Távora
2023-03-19 12:19 ` Michael Albinus
2023-03-15 20:16 ` João Távora
2023-03-16 15:02 ` Michael Albinus
2023-03-28 10:51 ` Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83v8izcmy5.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=62194@debbugs.gnu.org \
--cc=joaotavora@gmail.com \
--cc=michael.albinus@gmx.de \
--cc=miha@kamnitnik.top \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).