From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GnuTLS for W32 Date: Tue, 03 Jan 2012 09:02:17 -0500 Message-ID: References: <87ty4fbje8.fsf@lifelogs.com> <83ehvjs8t5.fsf@gnu.org> <87pqf3bcom.fsf@lifelogs.com> <83boqns68o.fsf@gnu.org> <87liprazr1.fsf@lifelogs.com> <83wr9bqez3.fsf@gnu.org> <87y5tr9dwv.fsf_-_@lifelogs.com> <87k45alwgb.fsf@wanadoo.es> <87fwfyltm1.fsf@wanadoo.es> <87boqmlrma.fsf@wanadoo.es> <87ty4e9j19.fsf@lifelogs.com> <83obumqa0v.fsf@gnu.org> <87ipktag2e.fsf@lifelogs.com> <87aa659bpw.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1325599356 5445 80.91.229.12 (3 Jan 2012 14:02:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2012 14:02:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 03 15:02:32 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ri4wf-0007nT-FF for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2012 15:02:29 +0100 Original-Received: from localhost ([::1]:39113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri4we-0006Hm-Vp for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2012 09:02:28 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri4wY-0006Gz-Au for emacs-devel@gnu.org; Tue, 03 Jan 2012 09:02:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ri4wT-00007I-99 for emacs-devel@gnu.org; Tue, 03 Jan 2012 09:02:22 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:52049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri4wT-000074-7a for emacs-devel@gnu.org; Tue, 03 Jan 2012 09:02:17 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Ri4wT-0003Ev-1y for emacs-devel@gnu.org; Tue, 03 Jan 2012 09:02:17 -0500 In-reply-to: <87aa659bpw.fsf@lifelogs.com> (message from Ted Zlatanov on Tue, 03 Jan 2012 08:06:51 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147209 Archived-At: > From: Ted Zlatanov > Date: Tue, 03 Jan 2012 08:06:51 -0500 > > On Tue, 03 Jan 2012 02:14:19 -0500 Eli Zaretskii wrote: > > OK, so let's do a restart after a DLL package install or upgrade. It's > better than nothing. Can this process be reused for other DLLs like the > libxpm DLL? Can we activate the new DLL after Emacs restarts, so the > old one will remain active as long as Emacs is using it and the user is > not forced to restart immediately? We can, although it'd probably still need some code changes. E.g., displaying the splash image at startup will automatically load an image library, and we will have to defer that until after the DLL is replaced. (Assuming I understand you correctly that you propose to run package.el in the new, restarted instance of Emacs and replace the DLL before it is first used.) > I'm not sure if multiple Emacs processes are an important use case. I > would guess it's an edge case on W32 Happens to me all the time when I'm working on some bug and have the "regular" Emacs running alongside. Also, I understand that some people who use Gnus have it run in a separate session. > I'm not sure what you and Juanma want to say. That because we don't > have salaried positions for tracking GnuTLS updates to Emacs, it's a > burden? Or that we shouldn't even do it? Or that we need more people > to run the Emacs infrastructure? What's the problem and how can we > solve it? What I want to say is this: > EZ> Bottom line, I feel that letting users download and unzip DLLs is by > EZ> far more practical for this purpose than what you suggest. It also > EZ> has the advantage of already working. What you propose is a laudable goal, but I think it has practical complications that make its gain not worth the effort. Please keep in mind that Windows users of Emacs already know how to download and unzip a distribution, because that's how they install Emacs in the first place. That said, if someone is motivated enough to invest the effort, I'll applaud them.