From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.bugs Subject: bug#14964: 24.3.50; doc of `compare-window-configurations' Date: Tue, 30 Jul 2013 03:05:37 +0200 Message-ID: References: <51e98138-a20c-48ad-bea2-de67eb6b04b5@default> <51F3826F.9060600@gmx.at> <51F4D8FF.6000703@gmx.at> <25701584-34ff-4754-8d10-7f2d223205ac@default> <415a3d22-c36e-4736-bae1-877b19c0e658@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1375146438 26300 80.91.229.3 (30 Jul 2013 01:07:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Jul 2013 01:07:18 +0000 (UTC) Cc: 14964@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 30 03:07:19 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1V3yPF-00048G-ME for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Jul 2013 03:07:17 +0200 Original-Received: from localhost ([::1]:56324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3yPF-0006M8-5B for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Jul 2013 21:07:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3yP6-0006J9-0X for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 21:07:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3yP1-0006Sm-F4 for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 21:07:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34484) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3yP1-0006Si-Bi for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 21:07:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V3yP0-0002sd-Bh for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 21:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Jul 2013 01:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14964 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14964-submit@debbugs.gnu.org id=B14964.137514638810981 (code B ref 14964); Tue, 30 Jul 2013 01:07:02 +0000 Original-Received: (at 14964) by debbugs.gnu.org; 30 Jul 2013 01:06:28 +0000 Original-Received: from localhost ([127.0.0.1]:57032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V3yOR-0002r2-31 for submit@debbugs.gnu.org; Mon, 29 Jul 2013 21:06:27 -0400 Original-Received: from mail-ea0-f172.google.com ([209.85.215.172]:41634) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V3yON-0002qm-Lo for 14964@debbugs.gnu.org; Mon, 29 Jul 2013 21:06:24 -0400 Original-Received: by mail-ea0-f172.google.com with SMTP id q10so3302619eaj.3 for <14964@debbugs.gnu.org>; Mon, 29 Jul 2013 18:06:17 -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=osp4ZRIpyqzwQspG+MA+O6sV/ti5TM61j0Db9mS7+qk=; b=XDtelOAfr2wLYa98jxrOXiYqUV4ldsVJoDmQwm5/GEHuIs3P0hfIEJ8wswiUmM3won gH4mKS2q5NcN0ArrbeiY+UJak73MgK7KppwSACQTuN6dgr5OwC5PyhLam7Q6uxUMFcBq AEmo1u8CpVVZQfwAjUV2o2uTRNTDUOLUxTstrgo+lhzhyOcRqD0hUUXZbNHz26r87ZZs bc02cKrH0T9f8V3bfQEM8WSd0qVThNkajQw2ZZxtTCMnPS9gsHtfV2Oy8HV7S+NtBGke LJNPdGYwkatdGKv9MLsQrj67WiJp0auafiryqYHAwKx1qhNUvR71TKeokyStjxKw11nf Htwg== X-Received: by 10.15.76.71 with SMTP id m47mr61138847eey.70.1375146377693; Mon, 29 Jul 2013 18:06:17 -0700 (PDT) Original-Received: by 10.15.23.70 with HTTP; Mon, 29 Jul 2013 18:05:37 -0700 (PDT) In-Reply-To: <415a3d22-c36e-4736-bae1-877b19c0e658@default> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:76784 Archived-At: On Tue, Jul 30, 2013 at 1:56 AM, Drew Adams wrote: >> Frame configurations: >> - Are low level (coded in C). > > Code them in Lisp. No, not me. I'm not interested in frame configurations. >> - Not flexible (they have basically two ops, >> current-frame-configuration and set-window-configuration; >> frame-configuration-to-register seems an afterthought). > > Add more ops. Make them general. Same answer. >> - Opaque; not supposed to be modified or played with other than from >> their get/set functions. > > Supposed to? Who says so? Their API says so. Their limited options say so. The fact that they are hardly ever used (search the sources). > It makes no sense to counter that they are not (yet) serializable and > are opaque. Or that the Desktop frame-saving and the `window-state-*' > window-saving are not (yet) recognizable, component-accessible > structures. That's the whole point of my request: to do just that, > bring them together, giving the advantages of each to both. There is no "both". They are not the same thing. They are somewhat similar, and that's all. > So are frame configs and window configs used as UI tools. Why do you > think we have `frame-configuration-to-register' and then jumping to a > frame-config register? Because there was no other alternative, and because once you had current-frame-configuration and set-frame-configuration, the -register variants were low-hanging fruit. > I, for one, would I think vote for tossing it and moving to only Lisp and > only a Lisp-readable representation - essentially the code you've written. > Use it as (the basis of) the new implementation of frame configs. Use > Martin's `window-state-*' code as (the basis of) the new implementation of > window configs. No, I don't think so. (let ((current (current-frame-configuration))) (unwind-protect (some-code) (set-frame-configuration current))) is always going to be faster than my code, and useful for `with-*' type macros. That's the whole point of what I'm saying: they are different things. They only seem similar. I think the logical thing to do, assuming my frame-state works and people finds it useful and reliable on the long term, is moving uses of frame configs to frame-states and let frame configs work for what they were intended to do: low-level temporary frame manipulation. There's no need to conflate their APIs. They will never be interchangeable. > I'm not at all rejecting what you've done. I'm asking that you take it > one step further and replace the existing frame & window configs with > your implementation. Too son. Let's talk about this in a few years. > And at that same time, make your code use a standard, recognizable > structure with defined accessor functions for its components. Yes. > IOW, make > it usable for frame-config and window-config uses too. No. > I don't really care so much what the final structure looks like or what > info it contains. As long as it can be used (together with other > state-saving code perhaps) for saving desktops Yes. > AND it can be used in > place of an Emacs frame config (e.g. get a config from the current > set of states and set the current set of states from a frame config, as > now), I'll be happy. No. Though I'm sorry to make you unhappy :-( > Right. That's precisely what I want to avoid. Today, if I want to take > the info saved in a frame-config register and persist it and use it in > another session, I would need to convert that info to your frame-state > form. If I want to put your frame-state info into a register so it can > be used with `jump-to-register' to restore/apply it, I would need to > convert it to a frame config. Then let's make frame-states register-jumpy-friendly. > And if I want to test whether some list in fact represents frame-state > info then what do I do? There is no identifying predicate, such as > `frame-configuration-p'. And there is no identifying tag (AFAIK), such > as a `frame-config' wrapper or an identifying attribute/keyword. > Give us a way to recognize the beast, please. Done. > And if I want the equivalent of function `window-configuration-frame' > for a `window-state-*' saved state, what do I do? Accessor functions, > please. Sorry, that does not make much sense. You can ask `(window-configuration-frame CONFIG) because the windows *and* the frame exist. But you can manipulate a frame-state without making the frame exist, and also, once the frame exists, the frame-state does not contain any pointer to it (it does not contain live objects, ever). Aside: In fact, currently you could implement that with a frame state (i.e., asking a frame state about the frame, because the code I'm writing now ads a persistent parameter frame-state-id, so once restored, frames will always be identifiable; but as a general concept, frame-states are not directly related to real, live frame objects; they are serialization objects only). > Not a great name, but the name is not the most important thing now. You have perhaps a couple days to propose a new name before I commit my code. Later it will be harder to change it ;-)I > The point is that there is some info, in fact a lot, I suspect, that is > in common. And there are some uses/operations that are also in common. > That should be plenty to serve as a basis for finding common ground and > factoring it out to serve both use cases. I think I've stated my case that I don't agree. Also, that I have no interest in working on frame configs / window configs. > (Ouch; that is such a bad name. It misleads me each time I read it > into thinking you are talking about the state of a frame, instead of the > state of all of the frames.) :-) > I don't mean that we need to limit what a "new-style" frame config can > do or be used for to what today's frame configs can do or be used for. > I mean only that if, as you suggest, there are some things that Desktop > needs to save for its use of frames that you think will never have any > use outside Desktop, then fine, let's leave those things out of the > new-style frame config but keep them for Desktop, separately. Most of these things are not really desktop-specific. If you develop a customized application of frame-states (ahem, whatever the name) and do a (voluntary or accidental) roundtrip through a tty session, you will also want things to be restored correctly, and would be upset if sizes, positions and maximized states were destroyed. > I don't argue that it is. I don't argue that you can just take the > existing thing you call a frame-state (a state representing the state > of all frames) You really hate the name, don't you? ;-) > I expect that > there will some stuff to exclude from the frame config and keep only > in Desktop. Yes, some things. > Ah, well maybe we will converge. Let's aim to have it replace the > existing frame configs then. And let's please make sure such a beast > can be easily recognized and its components easily accessed (e.g. by name). > > If we do that then I'll be a happy camper. (Likewise for window configs.) > It was an illustration of the kind of thing that's needed, not a > proposed implementation. I think (hope) you can see that and appreciate > that gross level of communication as well. I was not criticizing your programming, but pointing out what I've said above: that frame configs and window configs depend on and use the fact that they are dealing with live frames and windows. > I'm not sure it is. We should have a type predicate and accessor (i.e., > slot functions). Those are the main things a defstruct offers. What > would be wrong with using a defstruct, concretely ("overkill" doesn't > explain much)? The predicate is trivial, and the accessors too. A defstruct makes more sense to me if you're going to make use of most of its facilities (copier, type-checking ,print function, etc.). >> You just... [lots of specific description of why this is not the right >> implmentation of a `readable-frame' function] > > See above - it was an illustration of the idea, not an implementation > proposal. Again, I was not criticizing your programming. My point was that desktop-save-frames (now frame-state-save, tomorrow who knows what) has more global impact. Though I'm working on minimizing that. > Hoping beyond that that we might find some common ground. Oh, I'm sure we will. At least, we can agree on a name ;-) Juanma