|
From: | Milan Zimmermann |
Subject: | bug#59469: Adding a simpler duplication of the issue |
Date: | Tue, 22 Nov 2022 02:18:00 -0500 |
On 11/21/2022 6:50 PM, Milan Zimmermann wrote:
> A simpler duplication shows the issue is below.
[snip]
> Same bug: After the call to non-elisp program, /usr/bin/gzip, a
> previously exported variable bbb (exported inside the block) is nullified.
I'm not entirely sure, but I have a suspicion that this is due to
Eshell's deferred commands. Deferred commands tell Eshell to stop
processing synchronously and yield to the rest of Emacs. It's a way of
keeping long-running commands (e.g. external processes) from hanging the
rest of Emacs.
Unfortunately, the logic to do this (see 'eshell-do-eval') was written
before lexical binding was added to Emacs Lisp, and I think this is the
cause of quite a few subtle bugs with Eshell command evaluation. Fixing
that is bug#57635, which would leverage the generator.el internals to do
this.
Of course, I could be wrong. This is reaching well past my comfort zone
for Emacs Lisp, but this sure seems like an issue with 'eshell-do-eval'.
I'd certainly like to fix this one day, since it's blocking a few other
things I want to do in Eshell, but I think it'll be a pretty big project.
[Prev in Thread] | Current Thread | [Next in Thread] |