From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel 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 08:26:39 +0300 Message-ID: <83czqpj04w.fsf@gnu.org> References: <24842.41537.969310.87574@retriever.mtv.corp.google.com> <83tuk4jusd.fsf@gnu.org> <83pmurhy9s.fsf@gnu.org> <83h7g2itxx.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8421"; mail-complaints-to="usenet@ciao.gmane.io" Cc: raman@google.com, monnier@iro.umontreal.ca, arthur.miller@live.com, emacs-devel@gnu.org To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 07 07:27:28 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mCEro-000216-5i for ged-emacs-devel@m.gmane-mx.org; Sat, 07 Aug 2021 07:27:28 +0200 Original-Received: from localhost ([::1]:39938 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mCErn-0001g2-1f for ged-emacs-devel@m.gmane-mx.org; Sat, 07 Aug 2021 01:27:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36100) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCEr2-00010R-MO for emacs-devel@gnu.org; Sat, 07 Aug 2021 01:26:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46084) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mCEr1-0003dJ-C5; Sat, 07 Aug 2021 01:26:39 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4483 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCEr0-0006Pd-Lw; Sat, 07 Aug 2021 01:26:39 -0400 In-Reply-To: (message from chad on Fri, 6 Aug 2021 17:46:43 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:272155 Archived-At: > From: chad > Date: Fri, 6 Aug 2021 17:46:43 -0700 > Cc: Eli Zaretskii , EMACS development team , > Stefan Monnier , raman > > 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. I agree. > If I'm reading async.el correctly, it already has machinery for this in, for example, > async-inject-variable. The machinery exists, but we'd still need to decide which variables should be "injected". Once we make that decision, do we really need all the heavy lifting that Async lets us use? Because adding --eval to the command line for each variable is not really rocket science, is it? Bottom line: I don't think we need to wait for Async being in core to solve this issue in a very satisfactory manner.