From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r100117: Run kill-emacs when exiting for display closed or SIGTERM/HUP. Date: Wed, 05 May 2010 10:00:26 -0400 Message-ID: References: <3D94147C-CA80-4DB1-AD11-4707C3077275@swipnet.se> <4BDE87A4.5060701@swipnet.se> <4BDF1106.7060200@swipnet.se> <87633474hd.fsf@uwakimon.sk.tsukuba.ac.jp> <4BDFD57A.3050808@swipnet.se> <87d3xb7vge.fsf@uwakimon.sk.tsukuba.ac.jp> <4BE0184C.1090902@swipnet.se> <4BE02EA7.2070102@swipnet.se> <4BE11C88.2080705@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1273088657 32444 80.91.229.12 (5 May 2010 19:44:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 5 May 2010 19:44:17 +0000 (UTC) Cc: "emacs-devel@gnu.org" To: Jan =?iso-8859-1?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 05 21:44:15 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O9kVx-00080c-7v for ged-emacs-devel@m.gmane.org; Wed, 05 May 2010 21:44:13 +0200 Original-Received: from localhost ([127.0.0.1]:41940 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9kVw-0003a2-KW for ged-emacs-devel@m.gmane.org; Wed, 05 May 2010 15:44:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9f9P-0007Oy-NL for emacs-devel@gnu.org; Wed, 05 May 2010 10:00:35 -0400 Original-Received: from [140.186.70.92] (port=53303 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9f9L-0007IZ-6p for emacs-devel@gnu.org; Wed, 05 May 2010 10:00:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9f9I-0000oS-Fo for emacs-devel@gnu.org; Wed, 05 May 2010 10:00:31 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:7427 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O9f9I-0000oF-BI for emacs-devel@gnu.org; Wed, 05 May 2010 10:00:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEcW4UvO+IB1/2dsb2JhbACdRHK+HYJcEgiCHQSMLg X-IronPort-AV: E=Sophos;i="4.52,333,1270440000"; d="scan'208";a="63451919" Original-Received: from 206-248-128-117.dsl.teksavvy.com (HELO alfajor.home) ([206.248.128.117]) by ironport2-out.pppoe.ca with ESMTP; 05 May 2010 10:00:27 -0400 Original-Received: by alfajor.home (Postfix, from userid 20848) id 8CE5DAF29E; Wed, 5 May 2010 10:00:26 -0400 (EDT) In-Reply-To: <4BE11C88.2080705@swipnet.se> ("Jan =?iso-8859-1?Q?Dj=E4rv=22?= =?iso-8859-1?Q?'s?= message of "Wed, 05 May 2010 09:21:44 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:124545 Archived-At: > Some directory trees I work with are very deep, 7 to 8 layers of > subdirectories are not uncommon. But they are part of the same project. > I save the desktop at the top of that tree, because I do a svn up there > before I start Emacs. When I am at the deepest part of the tree and want to > open a file that is in another directory, I have to either > C-x C-f > or > C-x b *s C-x C-f > I find the latter to be much faster. [ Reminds me that we should add special support for "get back to root of project" in the read-file-name minibuffer. I don't use the same setup as you do, but the same needs show up. One way I imagine it working is that the completion uses the union of files at cwd and at the project's root so that it "just works" as long as the file name is not ambiguous. It could even work regardless of project root: just automatically try to move up the directory hierarchy until we find a file name that matches. ] >> BTW, why use --chdir rather than save the default-directories in the >> session file if you think that it should work even without desktop.el? > I doesn't work with desktop. desktop adds itself to after-init-hook, and > that is run before session restore. So desktop will load my desktop in > $HOME before default-directories are restored. I don't understand what you're saying here. For one, I was talking about the "no desktop" case, and second I don't understand if you're talking about some accidental problem in the current way desktop works or a fundamental limitation in the way desktop can work. >>> I'd like desktop.el to be more modular so we could save desktop >>> automatically in the session specific restore data file. I tried >>> once, but it was so hard coded to use just one file, so I gave up. >> >> Ah, now you're starting to talk. Can you give some details of what you >> tried and where the "hardcoding" was showing its ugly head? > desktop-save can't save to an arbitrary buffer. When desktop isn't used and > Emacs is to be killed by the session manager, it would be good to save the > desktop in the session-specific file. Yes. And when desktop is used, either the desktop data should also be saved into the session file (rather than the desktop file), or at least the location of the desktop file should be saved in the session file. > But desktop-read can't read just part of a file, so restore may become > an issue. You lost me here. > Ideally we would just load the session specific file on restart, but > desktop has some cleanups it does in desktop-read after load. I don't know what you're talking about. > You never know if desktop-save is going to ask questions or not (well, > except duplicating the logic behind ask-if-new and so on). When called from the session management, I think desktop should be forced to not ask questions. > This makes it unsuitable for use when the session manager says "save > state". Note that in those cases, we may not be stopped at all, and > user interaction should not take place. Exactly, so desktop needs to be changed to account for that situation. > And there is the possibility that the desktop file is locked, > so it will ask a question anyway. There shouldn't be any such problem with the session file (which is one reason I suggest desktop should save to the session file, even if the user is using a desktop file). >>> If I start emacs in /some/dir without a desktop file and have desktop-mode >>> enabled, there will be no desktop saved when I log out. >>> When the session manager then restarts Emacs in $HOME it will read my >>> desktop file in $HOME. That is a bug also. >> OK, let's try and fix it right, then. > My first attemt was to let desktop save its state if desktop is > enabled, otherwise save it in the session specific file. But I now > think that we must save in the session specific files always, due to > the locking and stuff in desktop. Agreed. > Desktop may also choose to save in its file, so we save desktop > in two places (just one if desktop-save-mode isn't enabled). Not sure what desktop users would prefer. > On restore, you should somehow tell desktop not to load its file, because if > it does, it might be the wrong thing to do. We wan't to restore to the > state we had when stopped, and we don't know what has happend to that > desktop file while we weren't running (some other Emacs may have modified > it). But now session restore kicks in after desktop has already read its > file. We need to change this ordering so session restore takes place before (or "at the same time as") desktop-load, so it can prevent desktop from loading another desktop. > After we have restored from the session file, we must then tell > desktop that it is now okay to save to its file again. Of course. Stefan