Subject: Re: bug#78898: Make read/readevalloop reentrant

From: Eli Zaretskii <[email-masked]>
Date: Sat, 28 Jun 2025 13:08:44 +0300

> From: Lynn Winebarger <[email-masked]>
> Date: Wed, 25 Jun 2025 17:59:53 -0400
> 
> In the recursive sense, not the "safe for concurrency" sense.
> 
> I want to use readevalloop to process command-line arguments, and my
> initial attempts failed to handle '"(load "loadup.el") (princ
> "Done")'.  So I took a stab at making all the entry points synchronize
> with an explicit stack of continuation frames shared between read0 and
> readevalloop.
> 
> The attached diff is against master from a couple of days ago.  For
> me, a configure/build (from scratch) completes *almost* everything
> (including the standard AOT native-compiled bits) - it chokes on
> lisp/leim/ja-dic.el due to a failure in a compiled function in
> bytecomp.elc.  There are clearly still some issues where the new code
> is not dealing with unibyte/multibyte correctly.  For example, running
> emacs -Q shows the initial scratch buffer contents as:
> 
> ;; This buffer is for text that is not saved, and for Lisp evaluation.
> ;; To create a file, visit it with â€˜C-x C-fâ€™ and enter text in its buffer.
> 
> This is definitely not ready for committing, but I'm hoping someone
> else finds this of interest and maybe can spot where I'm going wrong
> with the unibyte/multibyte handling.  Or what is going on with
> ja-dic.el.  The error I'm seeing there is in the execution of some
> byte-code, where some bit-wise operator gets a non-numeric argument.
> My only idea at present is to diff the byte-compiled libraries and see
> what's going on there - theoretically, there shouldn't be any change
> in the results of the byte-compiler.

Stefan and Mattias, any comments to this proposal?

Do we really want readevalloop be recursive this way?  What does this
gain us?