Re: window groups

[Thomas Lord]

martin rudalics wrote:
> > Temporary windows (e.g., completion, help) would be less of a problem
> > if there was support for splitting a frame at the *top* of the window
> > tree.  Ditto for toolbars.
>
> Could you explain what you mean here?  The toolbar is not part of a
> frame's root window.

By "splitting at the top of the window tree":   As far as I know,
right now the only way to create a new window (in an existing
frame) is to split an existing window horizontally or vertically.
New windows are always created by dividing a leaf node of the
window tree.    The new functionality would be to support
splitting the root window of a frame.

Consider (standard keybings): C-x 2 C-x 3 C-x o C-x o C-x 3

Compared to: C-x 2 C-x 2 C-x o C-x 3 C-x o C-x o C-x 3
               or C-x 2 C-x 3 C-x o C-x o C-x 2 C-x 3
               or C-x 3 C-x o C-x 2 C-x o C-x o C-x 3
               or C-x 3 C-x 2 C-x 3 C-x o C-x o C-x 3

Given the window configuration from the first key-sequence,
I'm suggesting a function to get to basically the same configuration
as any of the other four (not necessarily with the same window
sizes, though).   Miles suggested wanting to better expose the
window tree to lisp.   This suggestion is an intermediate step:
it doesn't further expose the whole window tree - it just adds some
functions that work on the root of the tree.

That kind of splitting could be handy for many kinds of pop-ups,
such as completion windows, especially when the rest of the
window configuration is created by an app that wants to use
each of the other windows in only a specific way.

I guess I shouldn't have said "tool-bar" since that creates confusion
with tool-bars as currently implemented.   I meant that that kind
of pop-up (full-frame split) could be used for something "tool-bar
like".   Instead of tool-bar functionality being built-in as a primitive
concept of the display, it could be done as special buffers that
contain widgets.

Doing tool-bar functionality as a buffer could be convenient.  For
example, consider the "location" bar in a typical web browser (say,
firefox).  There are a few buttons.   A text field for a URL.  More
buttons.  A text field for search.  And more buttons.  That'd be natural
to do in a buffer but very ad hoc as more and more primitive functions
added to display.

Continuing the location-bar example:  Consider how browsers often
create "drop down" windows for completion as a URL field or
search field is filled in.   If a location bar is implemented as an emacs
buffer, instead of a new "drop down" the window showing the buffer
could be temporarily enlarged, showing completions in the 2nd and
further lines of the buffer.



> > pop-up (like a help window), it would be nice to take some care so 
> that if
> > the window config doesn't change other than by that window being 
> deleted,
> > the former windows return precisely to their former sizes and 
> locations.
>
> Returning "precisely" to former sizes is non-trivial.

How so?


> > (It might even be
> > worth exploring the practicality of making complex command invocation
> > a *non*-recursive operation -- it might be significantly easier than 
> adding
> > cooperative threads and even if threads come along it could still be a
> > beneficial thing to do.)
>
> Do you mean to pop-up a new window for each command invocation?

I mean: 

Currently, when a complex command is selected by input events
Emacs (essentially) invokes the command loop recursively from
within a "save-window-excursion".   That's deeply built-in to both
C code and lisp code, I realize.   It's very natural, in many cases.
It is awkward in other cases, though.   For example, because of the
way it relies on the C stack, if you start two complex commands at
the same time - say, in two different frames - the second one that
you start has to run before the first one can run.

My "might even be worth exploring" notion is that perhaps complex
commands don't really need a recursive edit -- don't need to use the
C stack that way.   Instead, when the command loop wants to begin
collecting arguments for a complex command it can create a minibuffer
for that invocation, display that buffer in the minibuffer window, sure.
Save the current buffer, window, point location, etc. in buffer local
variables in that minibuffer.   Make that minibuffer the current buffer -
and return.   After the return, editing continues in that minibuffer,
collecting arguments.   When all arguments are collected, the command
is invoked.

*If* - and I realize that this is a "big if" that happens to not be too hard
to make work, *then* fancier things should fall out trivially.   Firefox
again provides an example:   Firefox has a "search" feature that is
in some ways like Emacs' i-search.   A difference in the firefox approach
is that the incremental search command doesn't invoke a recursive
interaction loop - it "pops up" (in the emacs sense, not the X11 sense) a
special purpose, minibuffer-like tool with a text field in which to edit
the string searched for, buttons to move to previous and next match, etc.

It could be elegant if Emacs arrived at similar functionality "for free,"
and for all complex commands, just by changing the low-level way
in which all complex commands are invoked.

There would be numerous UI details to get right.   It could be very
nice.   It would go well with "top level frame splitting" and "tool-bar
like buffers".



> > Window-local variables would also be handy.   "Apps" can search
> > window bindings to find which window to take over for a particular
> > buffer being popped up.   And, as I earlier argued, window-local 
> variables
> > could help make the point, mark, and selection cleaner -- so now I've
> > got two arguments in favor of the long-contemplated window-local vars.
>
> I always wanted them.  However, as Stefan points out in another thread,
> this seems to be difficult.

Is it difficult because it would be hard or have strange semantics to
mix up lisp scoping that way?

If so:  window property lists (not X11 properties - lisp property lists
attached to windows) might be enough.

-t