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: How to restore the layout? Date: Wed, 3 Jul 2013 16:54:29 +0200 Message-ID: References: <51C5AA68.4000204@alice.it> <2FB4C583-960C-4DA8-8B2E-29DF8D96770E@swipnet.se> <51CD6324.2040504@gmx.at> <834ncifkq9.fsf@gnu.org> <83zjuae19s.fsf@gnu.org> <83r4fmdsw5.fsf@gnu.org> <85k3ldtion.fsf@member.fsf.org> <4E4C522D-DBCC-4133-A764-82C9CCE81E2D@swipnet.se> <8913208E-7FE2-41F5-AC93-000108413C47@swipnet.se> <51D126A4.50402@gmx.at> <55419fed-b69d-4d07-81b2-b5b70f113929@default> <54cfe77b-f378-4402-b185-21372177ed60@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1372863321 9282 80.91.229.3 (3 Jul 2013 14:55:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Jul 2013 14:55:21 +0000 (UTC) Cc: martin rudalics , Emacs developers To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 03 16:55:22 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 1UuOSm-00016w-IO for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2013 16:55:20 +0200 Original-Received: from localhost ([::1]:57148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuOSm-0003jE-81 for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2013 10:55:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuOSd-0003V9-Ms for emacs-devel@gnu.org; Wed, 03 Jul 2013 10:55:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuOSc-0000DR-3b for emacs-devel@gnu.org; Wed, 03 Jul 2013 10:55:11 -0400 Original-Received: from mail-ie0-x22b.google.com ([2607:f8b0:4001:c03::22b]:58595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuOSb-0000DB-Tf for emacs-devel@gnu.org; Wed, 03 Jul 2013 10:55:09 -0400 Original-Received: by mail-ie0-f171.google.com with SMTP id qd12so612062ieb.16 for ; Wed, 03 Jul 2013 07:55:09 -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 :cc:content-type; bh=QWROeg2aFf7lhdlACoKATfHtf2VZXRxufXePxUoXGJs=; b=W7k60FlCPvkWPlPyVqfnae3YJm3NpuPevggDXgSS4MFNIrXBrPKBxq1zr2WOdnh9Gr OCK5kwWXBYgBo1Bi5Qt6lg+ZzdIV7bw/BjYVqbCiNLtzQvLxzHaGZUkMhDQl0jba8vKb Ht3BbZMkB3NAcn03wvYj7BsITlHw/ZOLAhHSysH4YxUCCeZu4L3An3Ylk7rLoGCTwasT ZzSBvypdosk6wO6zGfKYTt4gcqkl5qKyEkcT91EDVLCjFYS2dbBuwQAQiqmKLaie1TTR w+OVejy3TScmV6R+BaVZQefIzTMpCdpCBmHS8tH7P6hfc+U/EEPwcbgySyjz72E+NvLx 1Ozg== X-Received: by 10.50.18.5 with SMTP id s5mr902419igd.6.1372863309197; Wed, 03 Jul 2013 07:55:09 -0700 (PDT) Original-Received: by 10.64.250.7 with HTTP; Wed, 3 Jul 2013 07:54:29 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22b 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:161479 Archived-At: On Wed, Jul 3, 2013 at 4:08 PM, Drew Adams wrote: > I'm not familiar with the code, but a priori it feels like that should > be doable and done at the outset. Is there some reason it would be hard > to stop Desktop from saving (or restoring) the other stuff? I'm not > asking you to go into detail here, just wondering what the difficulty is > in general terms. The "other stuff" is buffers (and a few global variables, but that's almost irrelevant). window-state depends on buffers. Of course it is already possible to restore a window and find that its buffer is missing (currently, I think the end result is that the buffer will be recreated in fundamental mode). But it does not make much sense not to save buffers but do save frames and windows, unless and until we define an UI to allow the user to more precisely explain what does she want to save and what doesn't want to. Which seems useful, but not something I'm going to worry about right now. > IOW, why argue that people with standalone minibuffer frames lose locality > if the supporting case is a single frame scenario? Sounds a bit like > saying that a teaspoon is not the best pot for boiling lots of water. I've never argued that standalone minibuffer frames lose locality. I've argued that they lose it for me. They are farther, and in the few cases that I use two or more frames, more so. > OK. But I thought we were discussing the "locality" argument you raised > generally. No. Of course no. That's why I've mentioned my problems with recentering scrolling. I do know it's not a general problem, because many users enjoy recentering scrolling, which to me is so incredibly annoying that I would literally be unable to use Emacs if I weren't able to customize away that "feature". In the same vein, many people find useful to have things at the same location in the screen (that's why the taskbar does exist, after all). J