From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: desktop-restore-frames Date: Sun, 28 Jul 2013 13:34:26 +0200 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1375011312 11328 80.91.229.3 (28 Jul 2013 11:35:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jul 2013 11:35:12 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 28 13:35:15 2013 Return-path: Envelope-to: ged-emacs-devel@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 1V3PFp-0001Jz-A5 for ged-emacs-devel@m.gmane.org; Sun, 28 Jul 2013 13:35:13 +0200 Original-Received: from localhost ([::1]:51807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3PFo-0001WA-SV for ged-emacs-devel@m.gmane.org; Sun, 28 Jul 2013 07:35:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3PFk-0001VZ-Vg for emacs-devel@gnu.org; Sun, 28 Jul 2013 07:35:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3PFj-0005gv-MU for emacs-devel@gnu.org; Sun, 28 Jul 2013 07:35:08 -0400 Original-Received: from mail-ea0-x22f.google.com ([2a00:1450:4013:c01::22f]:54598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3PFj-0005gb-Dh for emacs-devel@gnu.org; Sun, 28 Jul 2013 07:35:07 -0400 Original-Received: by mail-ea0-f175.google.com with SMTP id m14so442699eaj.34 for ; Sun, 28 Jul 2013 04:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=G7hxddIldOWQuynBAEpMrLtdh2hln41wkEW9JVYeRG0=; b=jRRZbSlldUhF91LqjAvyOyRIXAgFogIVBgBFTImfJgpPPQzQktjwnz0TZlHsOKPSJW UhbZGivyTbMJ0a9EWgIds29tJ0jJqhbTUq0q67053LgojJ4wUOeObada86uqNs8tg8MO xEVOFy/RGEZkxjGzPdh3MLPPupIeYaS3c4AdC71YOrTALd5oFOS1x645HeAE/bS5RBcK Rk/7nQMMILHJHwSrcySsM5cZX1hfWY0MW5SMycivkaryjZZdyxNwbUVG2u+ndpI3p9y4 ZTvDsveKXiWMwV+SaNHBtpiL9bBXNuI2Lkl3QSVVCmiJoRWZqFiWYnsTXyIknpyxPiiX cQRA== X-Received: by 10.14.219.6 with SMTP id l6mr53813520eep.152.1375011306586; Sun, 28 Jul 2013 04:35:06 -0700 (PDT) Original-Received: by 10.15.23.70 with HTTP; Sun, 28 Jul 2013 04:34:26 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22f 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:162218 Archived-At: Not that I received much feedback, but anyway, in case someone wants to add their thoughts... > * NOT ADDED / FOR DISCUSSION: > > - I have not made any attempt to detect off-screen frames and move > them back on-screen. As there are legitimate uses of off-screen > frames, we should discuss what is the expected UI before throwing code > at it. This is now implemented via a new option `desktop-restore-forces-onscreen', with three possibilities: - t means to force back onscreen any restored frame not visible at all in its display. - 'all means the same, but includes frames partially visible. - nil means do nothing. defaulting to t. Of course, checking whether a frame is offscreen or not is a bit fuzzy because of the impossibility of getting a precise pixel size, but the current implementation should err on the side of forcing back these frames that are on the fence, which seems more helpful anyway. > - Currently, desktop-restore-frames is enabled by customize. In some > cases, it seems it would be useful to be able to easily enable/disable > it, either as an argument to desktop-save-mode or as a new > pseudo-minor-mode. I'd still like to do that, if we can decide on the UI. > - M-x desktop-clear "cleans up" the desktop by removing buffers, etc. > Should that command also (directly or via an argument) remove windows > and/or frames? IMO both possibilities seem reasonable. I think the answer is yes, `desktop-clear' should delete frames too. The biggest issue to implement this is deciding about exclusions. For buffers there's `desktop-clear-preserve-buffers', which selects based on the buffer name; a sensible choice. But what is a good way to differentiate between frames? > - Other than desktop-filter-parameters-alist, I have not added any > low-level hook to allow tinkerers to piggyback into the save&restore > mechanics. I suppose the existing hooks and advice-add should suffice, > but if someone has anything specific in mind that would require other > entry points, I'm all ears. I added `desktop-before-saving-frames-functions'. It is not a filter, it is just called for each frame before saving its state. I also added a desktop-specific frame parameter `desktop-dont-save', which if non-nil precludes the frame from being saved (this can of course be set from a function in `desktop-before-saving-frames-functions'). I intend to add a few more to allow elisp programmers to control what is done with frames; examples of things that could be useful are `desktop-dont-clear', `desktop-keep-display', etc. Personally, I like doing this with frame parameters (over filter functions) for a few reasons: - This mechanism is easier to extend that adding more and more hooks or variables. - (Except in the obvious case of desktop-dont-save) they are automatically saved & restored along with the rest of frame parameters. - Are easy to set when creating the frame, via (initial|default|pop-up|minibuffer|special-display|window-system-default)-frame-alist or other methods. Is anyone opposed to doing things that way? NEW ITEMS: - Making sure that the selected frame at saving time is still selected at restore time (assuming the frame was saved, of course). - Drew asked me to modularize the desktop-restore-frames code so you can call it to save one frame or a set of frames, and also to modify `desktop-save-frames' to return the state (instead of modifying a global variable) and `desktop-restore-frames' to get the state from an arg (or better yet, I think, to extract from it a function that encapsulates the restoration of one frame), among other things. On one hand, I think that's a sensible request (certainly making the code depend a bit less on global variables is always good). On the other hand, saving & restoring frames is not the kind of operation that makes much sense in isolation. Being able to restore a frame/window config depends not only on the existing buffers, but also on minibuffer frames, etc, if it is minibufferless. Currently, saving frames changes (slightly) the state of all frames, because it necessarily detects minibufferless/minibuffer frame relationships and adds desktop--mini to all frames. I'm not really sure where to go from here. - On insight, I think I could have done all this in a new desktop-frames.el package, loaded by default from desktop.el. The advantage is that the current code works or could be easily made to work on Emacs 24.{1,2,3}, which has window-state-(get|put), so it could be added to ELPA as a back-compatible package. - With really little effort, it is possible to create a mini-package to save & restore a stack or queue of frame configurations dynamically, so you could do M-x save-frame-state ; pushes state M-x restore-frame-state ; pops state C-{N} M-x restore-frame-state ; restores state {N}, does not pop M-x next-frame-state etc. so you could, on one session, push, pop and cycle between frame states (it could even be made persistent). This does not offer too much of an advantage over the current frame-configuration-to-register stuff, but offers more flexibility: for example, with a bit of coding there could be commands to bring all frames in all displays to the current display, or to delete all frames in other displays. > * THINGS KNOWN NOT TO WORK: > > - Minibuffer(less|-only) frames do not survive the roundtrip to tty > and back. It could be made to work, but it is a bit complex and I'm > not sure how useful / necessary it really is. Not fixed. Very low priority. > - On Windows, invisible frames turn visible the second time they are > restored, as an interesting consequence of bug#14841. This was fixed by Eli. > * BADLY NEEDED TESTING: > > - Non-Windows environments. > - Anything "multi": multiple displays, multiple monitors, complex > multi-frame setups, multiple terminals, etc. > - daemon mode. > - GUI and tty frames in the same session. Still needing testing. I refuse to believe that lack of bug reports means everything's working flawlessly. Juanma