From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: Updating Elisp files while Emacs is running Date: Tue, 15 Mar 2016 09:01:05 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1458046910 11973 80.91.229.3 (15 Mar 2016 13:01:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Mar 2016 13:01:50 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Mar 15 14:01:42 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1afobV-0002X6-0M for geh-help-gnu-emacs@m.gmane.org; Tue, 15 Mar 2016 14:01:41 +0100 Original-Received: from localhost ([::1]:48075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afobU-0006Kk-8r for geh-help-gnu-emacs@m.gmane.org; Tue, 15 Mar 2016 09:01:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afobI-0006KO-Ud for help-gnu-emacs@gnu.org; Tue, 15 Mar 2016 09:01:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afobD-0003zS-6o for help-gnu-emacs@gnu.org; Tue, 15 Mar 2016 09:01:28 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:33132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afobD-0003yn-0b for help-gnu-emacs@gnu.org; Tue, 15 Mar 2016 09:01:23 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1afob6-0002Et-CJ for help-gnu-emacs@gnu.org; Tue, 15 Mar 2016 14:01:16 +0100 Original-Received: from 75-119-244-10.dsl.teksavvy.com ([75.119.244.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Mar 2016 14:01:16 +0100 Original-Received: from monnier by 75-119-244-10.dsl.teksavvy.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Mar 2016 14:01:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 58 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 75-119-244-10.dsl.teksavvy.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:OKIiwxaJIRZrhBBJEls+/DsLdgE= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:109583 Archived-At: > OS-level package managers such as Debian's dpkg generally replace files > unconditionally when upgrading. I think we'd be better off discussing it with concrete cases at hand. Let's try a few cases: - You have Emacs-24.5 running and upgrade to Emacs-25.1. In this case, making your Emacs process load files from the 25.1 version is risky, because there can be (and there are) incompatibilities. You might still want to do it, since the incompatibilities won't always bite you, and it can be better than failing right away. Note that the files have to be elsewhere, because Debian lets you have both Emacs-24.5 and Emacs-25.1 installed at the same time. - You have Emacs-24.4 running and upgrade to Emacs-24.5. In this case, there should be very few incompatibilities, so it might make sense to try and redirect the running process to use the new 24.5 files. One possible solution here is for the Debian package to use directory names like /usr/share/emacs/24/... instead of /usr/share/emacs/24.4/... since Debian doesn't let you have both 24.4 and 24.5 installed at the same time (contrary to the default Emacs build's presumption). - You have ELPA package sm-c-mode-3.4 installed (and an Emacs is running with its load-path pointing to it) and upgrade it to sm-c-mode-4.0. This can happen if you upgrade from a separate process. Here, there are 2 subcases: - you've already used sm-c-mode in this process, so most/all the files are already loaded. In that case you should be fine and there's most likely nothing to do. - you haven't used sm-c-mode yet in this process, so it would be both desirable and likely safe to reload the new sm-c-mode-autoloads.el so as to redirect future uses of sm-c-mode to load from the new 4.0 version. I'm not sure how best to handle this, but maybe one way to accommodate this is to add some hook to `load' to handle the situation of a directory having gone missing. E.g. one easy/safe hook could be a load-file-not-found-hook called when load fails to find the file, so you could add ad-hoc code to it that tries to detect the above situations, updates the load-path accordingly, and tries again. A slightly more intrusive attempt might be a load-path-directory-not-found-hook called when a dir in load-path doesn't exist. This would try to solve the main problem I see with the previous hook: when /usr/share/emacs/24.4 is missing, Emacs may erroneously find some old/unrelated file with the same name further down the load-path and would hence fail to run load-file-not-found-hook. But the problem with load-path-directory-not-found-hook would then be that it's currently considered perfectly normal for load-path to contain non-existing directories, so it could break some setups if not done carefully enough. Stefan