Re[2]: idea -> internal frames?

[Eric M. Ludlam]

>>> Richard Stallman <address@hidden> seems to think that:
>    > For speedbar, should the window be outside the usual window hierarchy?
>    > In other words, should next-window and walk-windows see the speedbar
>    > window, or should they ignore it?
>
>    IMHO, these commands should ignore Speedbar.
>
>Some other questions, to figure out what is the most useful feature
>for this job:
>
>* Should there be any keyboard-command to select the Speedbar window?

Maybe.  Special frames like speedbar would probably have custom
commands jump the their frames if desired.  If there is no generic way
to get to these windows/frames, then it would be tough for a
programmer to fix mistakes on a terminal.

>* Should it be possible for a Lisp program to select the Speedbar
>window, even temporarily?

Yes, otherwise the above could not be done should there be no general
keyboard command to get to these special frames.

>* Are there internal uses of walk-windows (or equivalent constructs)
>which do need to see these windows, perhaps for redisplay purposes?
>In particular, I am thinking of the code that checks whether a buffer
>appears in more than one window, but there could be others.

A bug that annoys many w/ speedbar is when they try to close the frame
which hosts Speedbar's minibuffer, at which time it throws an error.
Such a walk-windows feature would allow some bit of code to seek out
frames whos minibuffers are hosted in such another frame.

>* Should the speedbar window have the full height of the frame,
>including the minibuffer's share of the height?

It does this now, though there is the above bug.  A minibuffer in
speedbar's frame is not useful IMO because it is too short to show any
useful information.

>Anyway, it seems to me that the best feature for this sort of thing is
>to be able to create some special windows at any edge of a frame.
>These windows could be designed so that they never change size except
>when the frame does, and are not deleted by one-window.
>
>next-window would normally not see them, but there could be a special
>mode in which it does see them.  Or each of these windows could have a
>flag which controls whether next-window will see it.
>
>An internal design question: should these windows be part of the usual
>window-tree data structure, or stored in some separate data structure?
>Each alternative makes some jobs easy and makes some jobs hard.
>
>Maybe the frame's root_window field would point to the uppermost
>"ordinary" window, and we would have a new field outer_root_window to
>point to the uppormost window including special windows.  This way,
>special windows could be split off either horizontally or vertically,
>and when both are done they could be done in either order.
  [ ... ]

That is a little deep for me.  I have a rather long set of emails
between you, gerd, and myself archived which I could concatenate
together and email you if you think they would be useful.  The above
discussion is very similar so little might be gained.

Attached at the end a messages from the middle of our conversation
that seems to summarize several of the ideas from before:

Have fun
-Eric

-----------------
From: Gerd Moellmann <address@hidden>
Date: 30 Sep 1999 13:59:45 +0200
In-Reply-To: "Eric M. Ludlam"'s message of "Mon, 27 Sep 1999 13:52:54 -0400"
X-UIDL: c7c84dec3cf0fec7214c0fd832336499

"Eric M. Ludlam" <address@hidden> writes:

> >>> Gerd Moellmann <address@hidden> seems to think that:
> >Richard Stallman <address@hidden> writes:
> >
> >>       (let ((wc (current-window-configuration)))
> >>     (delete-other-windows)
> >>     (split-window-horizontally size)
> >>     (other-window 1)
> >>     (do-speedbar-init-thingies)
> >>     (make-window-special-thingies)
> >>     (other-window 1)
> >>     (set-window-configuration wc))
>   [ ... ]
> >We could, for example, just allow 1 special windows on each side of a
> >frame.  These would be unsplittable, and I think they should not allow
> >to switch buffers.  To emphasize that such special windows are not
> >part of the window tree (and more like transient frame decorations), I
> >would also propose the following:
> >
> >1. C-x 7 is a prefix for commands applying to special windows.
> >   C-x 7 [tblr] select the top, bottom, left, right special window
> >   C-x 7 o cycles through special windows
> >   C-x 7 0 deletes the selected special window
> >   C-x 7 1 deletes all special windows except the selected one
> >   C-x 7 ^ enlarges the selected special window (?)
> >
> >2. C-x [0123] signal errors in special windows.
> >
> >3. C-x o doesn't cycle through special windows.
> >
> >4. Special windows are not part of the window configuration.  (That's
> >has problems---what to do if we restore a window configuration after
> >special windows have been deleted?  The recorded window sizes might
> >be wrong for the frame size.)
> >
> >5. Special windows are not created with a keystroke, but rather as
> >part of modes.  For example, M-x speedbar-mode could create a special
> >window programmatically.
> 
> I agree with many ideas here, especially limiting them to [tbrl] edges
> of the main frame.
> 
> I think that 1, and 5 conflict.  If a window can only be created by a
> program, it should only be destroyed by said program.  Of course doing
> so means that authors of modes for special windows would have to
> follow rules to make a set of common bindings behaviors.
> 

Right, I agree.  There shouldn't be user-commands for deleting special
windows.  Instead, switching modes on or off should create or delete
these windows.

> In the reverse, if there is a binding C-x 7 1 (or 0), then a C-x 7 2
> (or 3) might also be handy (though how to differentiate top and bottom
> might be interesting.)  If I want a window up that never goes away (a
> reference file, info pages, man page, etc) I often put it in it's own
> frame.  A set of bindings or commands to do it all in the main frame
> would be cool.
> 
> Ok, as for having keybindings (C-x 7) at all, this conflicts with the
> notion of dedicated windows.  This seems to be a flag set on a window
> to prevent their deletion via user commands.  If a user ends up with
> only one dedicated window in a frame, there is no command way (that I
> know of) to get back to normal.  The use of dedicated windows in
> speedbar and ediff might be better served with a dedicated frame, and
> the use of dedicated windows in a regular Emacs frame would then use
> these special windows because they would always leave the user with at
> least one regular window to work in.
> 

I'm not sure in which way the key-bindings would conflict.  Could you
please explain?

> 
> Anyway, I really like the idea of special windows occupying one of 4
> alleyways, and having them be completely absent from any window lists.
> (Though a function to get all special windows would be needed.)  I
> also think it's important that these windows appear different in some
> way, though I'm not sure how to accomplish this without wasting space
> on a terminal.
> 
> I'm neutral on the keybindings as I don't have a better suggestion.
> 
> It will also be important to specify how special windows should be
> managed by their programs.  I will certainly want to be able to let a
> user choose a position of "left", "right", or "frame", for instance.
> Should there be a common set of names for this?  Protocol for resizing
> the parent frame if you want to leave the original space the same
> size?
> 

I don't have suggestions for a high-level API right now.  I think that
should be designed after we have the primitive operations, and can
experiment with them to find the most convenient way of using them.

For the primitive operations, I thought of the following as a first
step (I would like to replace `special' with something better---any
suggestions?)

-.Function: create-special-window LOCATION &optional FRAME

Create a special window on FRAME, or selected frame if FRAME is
omitted or nil.  LOCATION says where on that frame to create the
window, and must be one of `top', `bottom', `left', `right'.  Value is
the window created.  (The frame is not resized.)

- Function: delete-special-window LOCATION &optional FRAME

Delete special window at LOCATION.

- Function special-window LOCATION &optional FRAME

Return the special at LOCATION on FRAME, or nil if there is none.

- Function window-special-p WINDOW

Value is non-nil if WINDOW is "special".