emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Async rebuild package-quickstart after packages update? was Re: 28.0


From: Arthur Miller
Subject: Re: Async rebuild package-quickstart after packages update? was Re: 28.0.50; Proposal: slightly more efficient package-quickstart.el
Date: Sat, 07 Aug 2021 07:45:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

chad <yandros@gmail.com> writes:

> As near as I can tell, the moderate-sized potential problem with "just start 
> another full interactive session, and communicate with
> it" is the near-certainty that some people's interactive startup isn't 
> (effectively) reentrant. There are lots of ways this can happen
> -- package auto-loading and refreshing, cache files like 
> desktop/places/recent/history/etc, configurations that automatically open
> dedicated frames in various places, multiple servers confusing emacsclient, 
> and the like. (Back in the 90's and early 00's, I used to
> see user configurations like this all the time.)

I thought that emacs does not open frames in daemon mode (more than one
invisible or how it works).


> There is some mitigation for this effect in that it overlaps with daemon-mode 
> non-rerentrancy, and also some in that only a subset
> of users will use package-quickstart. That's probably enough to put together 
> an experiment, but I would expect some (solvable!)
> problems to crop up.
>
> On the other hand, if I understand T.V Raman's suggestion to put together a 
> package that learns which parts of the environment
> are necessary to share between a configured emacs and a subsequent emacs 
> batch process, it sounds like a reasonable approach
> toward a similar middle ground, but starting from the cleaner -Q state. If 
> I'm reading async.el correctly, it already has machinery
> for this in, for example, async-inject-variable.
>
>  (defun async-inject-variables
>
>      (include-regexp &optional predicate exclude-regexp noprops)  "Return a 
> `setq' form that replicates part of the calling
>  environment.
>  It sets the value for every variable matching INCLUDE-REGEXP and
>  also PREDICATE.  It will not perform injection for any variable
>  matching EXCLUDE-REGEXP (if present) or representing a `syntax-table'
>  i.e. ending by \"-syntax-table\".
>  When NOPROPS is non nil it tries to strip out text properties of each
>  variable's value with `async-variables-noprops-function'.
>  It is intended to be used as follows:
>      (async-start
>         \\=`(lambda ()
>            (require \\='smtpmail)
>            (with-temp-buffer
>              (insert ,(buffer-substring-no-properties (point-min) 
> (point-max)))
>              ;; Pass in the variable environment for smtpmail
>              ,(async-inject-variables 
> \"\\\\=`\\(smtpmail\\|\\(user-\\)?mail\\)-\")
>              (smtpmail-send-it)))
>         \\='ignore)"  
>
> It also has this option, which suggests that this issue comes up at least 
> some of the time, and is worked around in situ rather than
> solved at the package level:
>
>  (defvar async-quiet-switch "-Q"
>    "The Emacs parameter to use to call emacs without config.
>  Can be one of \"-Q\" or \"-q\".
>  Default is \"-Q\" but it is sometimes useful to use \"-q\" to have a
>  enhanced config or some more variables loaded.") 
>
> I think there's an interesting area to explore here, especially given the 
> relatively low utility of make-thread, the way cores are
> multiplying, and the extra crunching-power desired by potential changes like 
> native-comp, json, lsp, and tree-sitter (which I
> assume, perhaps wrongly, will end up with loadable binary objects for 
> some/most languages), this seems like a good problem to
> look at.

I agree that it is an interesting problem, it seems like a lot of work.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]