GNU bug report logs - #14964
24.3.50; doc of `compare-window-configurations'

Previous Next

Full log

View this message in rfc822 format

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 14964 <at> debbugs.gnu.org
Subject: bug#14964: 24.3.50; doc of `compare-window-configurations'
Date: Tue, 30 Jul 2013 03:05:37 +0200

On Tue, Jul 30, 2013 at 1:56 AM, Drew Adams <drew.adams <at> oracle.com> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.