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: Freezing frameset-restore Date: Fri, 07 Mar 2014 23:31:55 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1394253127 19181 80.91.229.3 (8 Mar 2014 04:32:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Mar 2014 04:32:07 +0000 (UTC) Cc: Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 08 05:32:16 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 1WM8vn-0004fX-Ci for ged-emacs-devel@m.gmane.org; Sat, 08 Mar 2014 05:32:15 +0100 Original-Received: from localhost ([::1]:39322 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WM8vn-0000Sk-1T for ged-emacs-devel@m.gmane.org; Fri, 07 Mar 2014 23:32:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51874) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WM8vd-0000Ks-Ac for emacs-devel@gnu.org; Fri, 07 Mar 2014 23:32:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WM8vU-0001Iw-Fe for emacs-devel@gnu.org; Fri, 07 Mar 2014 23:32:05 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:13437) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WM8vU-0001Ir-BN for emacs-devel@gnu.org; Fri, 07 Mar 2014 23:31:56 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCppy/2dsb2JhbABEvw4Xc4IeAQEEAVYWCgMFCwsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av8EABK/CFFMCppy/2dsb2JhbABEvw4Xc4IeAQEEAVYWCgMFCwsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="50856863" Original-Received: from 76-10-154-114.dsl.teksavvy.com (HELO ceviche.home) ([76.10.154.114]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 07 Mar 2014 23:31:55 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 12C37660A5; Fri, 7 Mar 2014 23:31:55 -0500 (EST) In-Reply-To: (Juanma Barranquero's message of "Sat, 8 Mar 2014 02:42:16 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:170220 Archived-At: >> Right. But we're simplifying the "interface". > Hm. On one hand, the interface is already complex; on the other hand, > it's not more complex than make-network-process or defcustom ;-) The fact that it's bad already or that there's worse out there is no excuse. >> And we can provide a frameset-restore-cleanup function which does the >> default thing. > I don't understand what you mean, i.e, a function for the common case? Right (I'd expect that function to take the whole list, BTW, but if mapc can be used, it's not critical). Of course, with only 2 users so far, it might be tricky to decide what is "common". > I'm not sure we gain anything with this. As a net loss, we must > construct (and sort) I don't see why sorting would be needed. > the return list even if it is not going to be used, while in the > CLEANUP argument case, no list is constructed; in fact, if CLEANUP > = :keep, not even (frame-list) is called at that point. Clearly, the returned list does not need to give an action for all frames. Only for those which we did consider. So we don't need to call `frames-list' just so as to build the return value. > that many; it is a specialized feature anyway, and its main use case > (and the reason it was implemented) is already covered by desktop.el. Exactly. > I don't find it terrible, but neither do I find it cleaner. Anyway, > it's your call. I think it's cleaner. Stefan