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: Freezing frameset-restore Date: Mon, 10 Mar 2014 22:07:06 +0100 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 1394485667 31560 80.91.229.3 (10 Mar 2014 21:07:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2014 21:07:47 +0000 (UTC) Cc: Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 10 22:07:57 2014 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 1WN7QS-0002PS-Gd for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2014 22:07:56 +0100 Original-Received: from localhost ([::1]:51183 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN7QR-0002Cx-IZ for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2014 17:07:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN7QN-0002Cr-Ti for emacs-devel@gnu.org; Mon, 10 Mar 2014 17:07:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WN7QJ-0007Bv-6x for emacs-devel@gnu.org; Mon, 10 Mar 2014 17:07:51 -0400 Original-Received: from mail-yh0-x234.google.com ([2607:f8b0:4002:c01::234]:49053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN7QJ-0007Br-1j for emacs-devel@gnu.org; Mon, 10 Mar 2014 17:07:47 -0400 Original-Received: by mail-yh0-f52.google.com with SMTP id c41so1120277yho.11 for ; Mon, 10 Mar 2014 14:07:46 -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=GGKHMZv/Bu90rEqny09zPbUxdldgMdVmPKDd4wmuS+E=; b=XkEf5F6HK+csBUR1piu8m2ZyvTWRT+y6bKA5YxreNeXdRjCcdsnOVcbpxLaKhTT/ms ka57rSAtzkLTNHMQAkiB1uc9QxEiEUWCeyQaMfN/nusxk0PD4/2WuF5E/WyDGJ68Y3qp fP6TVgMdYEB7/GjK4DZr7fwQkM1ZNfB8fqR2WB7NPn7mGR0ogklbwKwl92+I3RDsb/uW hYuDKrCqwlsV6y+wIvce647lHC8/Ifon/NBzhN0oo4TZ/zgQYoH+d9repGXX3vgGXIMM vYEfGXXFE2ZlYQIpkt0uYxzye1TbB0bU0CPXnzrzfWx78JZz+GpjVIyYNEDQob0BlG3s nRaA== X-Received: by 10.236.110.132 with SMTP id u4mr4977671yhg.119.1394485666662; Mon, 10 Mar 2014 14:07:46 -0700 (PDT) Original-Received: by 10.170.163.3 with HTTP; Mon, 10 Mar 2014 14:07:06 -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:4002:c01::234 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:170261 Archived-At: On Mon, Mar 10, 2014 at 9:32 PM, Stefan Monnier wrote: > Ah, then we need to fix the docstring and specify that the order of > elements in the returned list is not arbitrary but provides some kind of > guarantee (which we need to describe). Yuck. I'll add that to the appropriate place, once we agree about it. > Yes, every caller of frame-restore will probably want to cleanup > afterwards, but that doesn't mean we should provide "one function that > does it all". If you excuse my analogy, it's like changing a flat tyre. Of course it can be divided into removing the old one, and putting the new one. Other than a bit of sharing (the jack carries over from the first operation to the second), they are separate operations. Yet no one thinks of it that way because the user experience is "fixing the tyre so the car can go again". You think of frameset restoration like two operations: 1) restoring frames, and 2) cleaning up frames. But frameset-restore is just one operation: going from a frame configuration in your display(s) to another, different one. 2) is as part of it as 1), and in most cases (certainly, in *our* use cases) it is a non-null operation. > OK, but then make it very simple: it should be a function that takes > a frame and a symbol (the action that was taken on that frame) and its > return value is ignored. Currently (in my last patch), it's just that, plus the options t and nil to simplify common use cases. Do you want me to remove the t/nil options? > But your frameset has 2 frames, so after restoration you should also > have 2 frames, no? If you're doing it via desktop.el, yes. But you can save a frameset from a partial set of the current frames. And just in case you think it's too artificial, I discovered the problem because it happened to me (though I don't remember what was I doing at the time). And even if you are saving the full frame list with desktop.el, if you switch displays or something like that you can end restoring less frames than originally saved, so it can definitely happen. It's better to protect against the case, however unlikely, that present the user with an invisible running Emacs. J