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 16:06:56 +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 1394464054 17379 80.91.229.3 (10 Mar 2014 15:07:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2014 15:07:34 +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 16:07:44 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 1WN1nr-0000rR-Iu for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2014 16:07:43 +0100 Original-Received: from localhost ([::1]:49274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN1nr-0007oA-2T for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2014 11:07:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN1nn-0007o2-6l for emacs-devel@gnu.org; Mon, 10 Mar 2014 11:07:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WN1nk-0003fq-JJ for emacs-devel@gnu.org; Mon, 10 Mar 2014 11:07:39 -0400 Original-Received: from mail-yk0-x22c.google.com ([2607:f8b0:4002:c07::22c]:40738) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN1nk-0003fj-Ff for emacs-devel@gnu.org; Mon, 10 Mar 2014 11:07:36 -0400 Original-Received: by mail-yk0-f172.google.com with SMTP id 200so19445275ykr.3 for ; Mon, 10 Mar 2014 08:07:36 -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=dg+QGA5tajuYBCnh3R/aeIQWVXiMBOsWlretz7CGN48=; b=OMWsLC8F4UvnPoBb6VsEuKTGgQM33wp0FWt5esoh1yRGgKQcqrwvbZfEYiHbaPcG0a I+1TOOocmdfgVznoeDg7mfWV/qbXIkL72UUTy/9bb0cfcPuK7w+T58SSvSnE+gpVPpsP cfLbC2mR47qoJS4KU+yQoibjYh2ML4van10TY5pWmBQy21tKDU/PVvsatK4/4ol8zQfi wzpH9yWfSbZlL2w/pfuuYd4ZP6l8qo1YMLM2J+i3dCqVvFx5NTHLeL7cyEHOk3k+fB9c noI8umKnQ48uakjQxUU3qRfSTp3o7r16ZRj8/rC5rbCsSltjDSyg1/uBWMowpNb5biET V+hg== X-Received: by 10.236.149.2 with SMTP id w2mr2485772yhj.114.1394464056108; Mon, 10 Mar 2014 08:07:36 -0700 (PDT) Original-Received: by 10.170.163.3 with HTTP; Mon, 10 Mar 2014 08:06:56 -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:c07::22c 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:170253 Archived-At: On Mon, Mar 10, 2014 at 3:19 PM, Stefan Monnier wrote: > I'm not opposed to keywords as arguments in general: I'm opposed to > them when the argument is itself specified via a keyword. OK. Ill change that, too. > This choice is not based on an estimate of which case will be more > common, but rather I think that given the argument name ":reuse-frames" > a nil value which says "don't reuse any frames" is more intuitive than > one that says "reuse all frames". Hence the change. Hmm. I think you're right. That's two in a row. ;-) > Don't convert to an alist at the end: just return the hashtable. Eh, no. As I said already, processing the frames in random (maphash) order just isn't going to cut it if you want to delete frames. > Again, we're talking about very few callers. You want the code to be as > simple as possible, since the rare callers can pay the extra price, if needed. I'm unconvinced, but it's not a big deal. It's a much bigger deal that, as I've argued again in my next message, I think we shouldn't be extracting cleanup from frameset-restore. > It's only artificial in your mind: the code already did it in two phases > (just within the same function). That would be an argument to split every long function along its length, just by looking for appropriate places where it can be "cleanly" done, but that's not an argument that I can accept. Restoring a frameset is going from one frame configuration to another one; cleanup isn't just something that gets accidentally done afterwards. > Once you change the code to return a hashtable, pcase-dolist will be > replaced with maphash anyway ;-) See above. And please don't say that we can return a hash and leave the sorting for the caller. The caller is us, we already call delete-frame, so we'll have to add yet *more* ugly code at the point of call of frameset-restore. We keep having this conversation where you extract conclusions from our two use cases; but I'm trying to design an interface for those people out there who will perhaps have ideas and uses we cannot think of right now. That's why there is a frameset.el library, isn't it? To allow people to be creative with it? > That's pretty close to the definition of over-engineering. That's also pretty close to the definition of writing a library, as opposed to a tightly knitted piece of code. > Personally, I'd just ditch frameset-restore-cleanup. I'd ditch it too, for a CLEANUP arg to frameset-restore. > Aha! Can you expand on this? What do you mean exactly by > "non-visible"? You can create an invisible frame, save it in a frameset, then delete it (so you have just one frame, visible), and then restore the frameset over your only frame. Presto! If frameset-restore doesn't protect against it, you end with just one, quite invisible, frame. So frameset-restore checks that (except in daemon mode) at least one frame is visible after restoration. IMO, that check should be (and it was until now) the last step in restoration, after everything else that affects the existing frames. J