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: Sat, 8 Mar 2014 17:34:36 +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 1394296512 3087 80.91.229.3 (8 Mar 2014 16:35:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Mar 2014 16:35:12 +0000 (UTC) Cc: Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 08 17:35:22 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 1WMKDZ-0001Bh-LA for ged-emacs-devel@m.gmane.org; Sat, 08 Mar 2014 17:35:21 +0100 Original-Received: from localhost ([::1]:41118 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMKDZ-0004ai-4n for ged-emacs-devel@m.gmane.org; Sat, 08 Mar 2014 11:35:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMKDW-0004Xf-I4 for emacs-devel@gnu.org; Sat, 08 Mar 2014 11:35:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMKDV-00036C-LA for emacs-devel@gnu.org; Sat, 08 Mar 2014 11:35:18 -0500 Original-Received: from mail-yh0-x236.google.com ([2607:f8b0:4002:c01::236]:63838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMKDV-000352-GP for emacs-devel@gnu.org; Sat, 08 Mar 2014 11:35:17 -0500 Original-Received: by mail-yh0-f54.google.com with SMTP id c41so5543187yho.41 for ; Sat, 08 Mar 2014 08:35:17 -0800 (PST) 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=GsqCyW8bnzwdjhcoEhJf1y6g1zf9zw6KxZ83ZdQH++E=; b=NE3WUQOsxHO8rfSXWqW0w6adZRUq3vnsx1L+giVGB37MhIoue4MwSCNcI9J0wiTkPH +hXol1rrO+db+yoqy0N7dAhd6TWd+AaEowUoF0p8vbEMzN0BfP2+OODNXUNCrDitMcZw nwrkulO4NViIuDzXMN+13t+/Rh15XHvQH+SUGgIsEeiquybVR+hciulzTPArQaVzocWf CPX0p3Fe1SD4sgGe1SRXH7E1pVbf7VlirM6QfUxOs0TxxivNzpU4blyylBFicn8QuYOK WvK7trDzXcXIgINSldZKWwYy00Qk+bBysSMODmeyHIWu52TuxaGiwFODESpuCldMeWAl 4Oyw== X-Received: by 10.236.160.136 with SMTP id u8mr1097454yhk.32.1394296516904; Sat, 08 Mar 2014 08:35:16 -0800 (PST) Original-Received: by 10.170.163.3 with HTTP; Sat, 8 Mar 2014 08:34:36 -0800 (PST) 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::236 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:170229 Archived-At: On Sat, Mar 8, 2014 at 3:27 PM, Stefan Monnier wrote: > The function returns the frames that it considered and what action it > took with it. It will not necessarily return an entry for each > existing frame. What is the gain? In most cases, it already has to consider every frame, for several reasons, chief among them that it tries to match the frameset id. The only cases that is not so is if you explicitly pass a LIST to REUSE-FRAMES, or :none. >> any case, I suspect that I strongly disagree. For example, you could >> pass REUSE-FRAMES = :none, which wouldn't "consider" any existing >> frame at all, and yet want to delete all previously-existing frames. > > I don't see why that would be problem. The returned list simply > wouldn't mention any of the existing frames, so if you want to delete > those you'll have to call `frame-list'. And check against the returned list (you don't want to delete the just restored frames). Messier than have the full list in the first place. frameset-restore is not a high-performance function to be called many times per second, it's a user-level function, it operates in human time. It already has to call frame-list, build and filter out frame parameter lists, etc. > Look at it not as "move stuff from frameset-restore to its caller" but > as "split frameset-restore into two functions". That's what I've done with frameset-restore-cleanup. I think the current interface (in my last patch) is good and clear enough. J