From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Wed, 05 May 2010 11:19:36 +0200 Message-ID: <4BE13828.2030609@gmx.at> References: <4BB4CF6B.2000007@alice.it> <87vdbhgqgd.fsf@mail.jurta.org> <828BB36311A84C43B96D1F2A559DACAE@us.oracle.com> <87d3xo662u.fsf@mail.jurta.org> <69D40D69CC6F4982A8E91D8D8F0F494F@us.oracle.com> <87r5m4hz39.fsf@mail.jurta.org> <4BD40821.70808@gmx.at> <87zl0rtmqy.fsf@mail.jurta.org> <871vdu6qn5.fsf@mail.jurta.org> <87bpcv1wvt.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1273079598 27698 80.91.229.12 (5 May 2010 17:13:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 5 May 2010 17:13:18 +0000 (UTC) Cc: Ken Hori , Emacs To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 05 19:13:17 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 1O9i9s-0002xV-D3 for ged-emacs-devel@m.gmane.org; Wed, 05 May 2010 19:13:16 +0200 Original-Received: from localhost ([127.0.0.1]:52065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9i9r-0008HQ-Q0 for ged-emacs-devel@m.gmane.org; Wed, 05 May 2010 13:13:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9all-0003cT-Dv for emacs-devel@gnu.org; Wed, 05 May 2010 05:19:53 -0400 Original-Received: from [140.186.70.92] (port=45078 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9alh-0003bg-EK for emacs-devel@gnu.org; Wed, 05 May 2010 05:19:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9alf-0004mI-MA for emacs-devel@gnu.org; Wed, 05 May 2010 05:19:49 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:40257) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1O9alf-0004lR-8p for emacs-devel@gnu.org; Wed, 05 May 2010 05:19:47 -0400 Original-Received: (qmail invoked by alias); 05 May 2010 09:19:43 -0000 Original-Received: from 62-47-58-170.adsl.highway.telekom.at (EHLO [62.47.58.170]) [62.47.58.170] by mail.gmx.net (mp068) with SMTP; 05 May 2010 11:19:43 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX192GdsVGmV2oU8S2CrsI3ISniVtJZmErgDgUFV+li +nZcqYiZwkUknv User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87bpcv1wvt.fsf@mail.jurta.org> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.69999999999999996 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:124537 Archived-At: > The point of set-window-configuration-from-sexp is to restore the > configuration of windows, not to duplicate the functionality of desktop.el. That's true from a theoretical point of view. It separates concerns in a clear way and gives clean semantics. Hence I fully agree with you. Unfortunately, in personal practice, I'm suffering from a quite similar problem. In particular, I display eldoc output on a per-window basis in a one-line window below the code window (I hate eldoc output in the echo area, I don't like it in the header line, and I very much hate tooltips. Ideally, there would be a bottom-line right above the mode-line where I could put it, but ...). Now I'm killing such an eldoc-buffer as soon as it is no more shown in its eldoc-window. But when (1) a `save-window-excursion' restores the saved configuration and (2) it has to restore a former eldoc-window that was deleted within the body of `save-window-excursion', I get the first buffer from `buffer-list' shown in that window which is downright silly. I solved my problem by killing such stale eldoc-windows after the configuration gets restored in a `window-configuration-change-hook'. This is, however, a slight redisplay pain, in particular with such niceties as (save-window-excursion (info)) in `info-lookup'. I maybe could come up with a satisfactory solution, but deleting and creating windows in `window-configuration-change-hook' is error-prone :-( So if we could hook into this in some way, for example by providing a window parameter that tells `set-window-configuration(-from-sexp)' what to do if the buffer no longer exists, that might not be a bad idea. If the buffer had a `buffer-file-name', we could try to regenerate it automatically from that name. If the file was deleted in the meantime (or is remote or hard to find), some warning message could be displayed in a temporary buffer in the restored window. Looking up a file via bookmarks could happen here as well. If the buffer was not associated with a file, we could try to regenerate it based on the old name stored in the parameter. For killed *info* and *help* buffers probably more information would be required. All this would happen independently from desktop.el in the session version and in the sexp version. And, as noted above, this idea is not based on clean semantics but on running into practical issues. martin