Re: Window configurations

Re: Window configurations

[grischka]

> The point of set-window-configuration-from-sexp is to restore the
> configuration of windows, not to duplicate the functionality of
> desktop.el.

FWIW I think the introduction of window-configurations (as API) was
a mistake and let them save to file is an even bigger mistake.

Really not every kludge is a feature and in this case the best you can
do is to get rid of it.

--- grischka

Re: Window configurations

[Juri Linkov]

> FWIW I think the introduction of window-configurations (as API) was
> a mistake and let them save to file is an even bigger mistake.
>
> Really not every kludge is a feature and in this case the best you can
> do is to get rid of it.

Thanks for the constructive comment.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[grischka]

Juri Linkov wrote:
>> FWIW I think the introduction of window-configurations (as API) was
>> a mistake and let them save to file is an even bigger mistake.
>>
>> Really not every kludge is a feature and in this case the best you can
>> do is to get rid of it.
> 
> Thanks for the constructive comment.
> 

That was deconstructive ;)

RE: Window configurations

[Drew Adams]

> > The point of set-window-configuration-from-sexp is to restore the
> > configuration of windows, not to duplicate the functionality of
> > desktop.el.
> 
> FWIW I think the introduction of window-configurations (as API) was
> a mistake and let them save to file is an even bigger mistake.
> 
> Really not every kludge is a feature and in this case the best you can
> do is to get rid of it.

Just a suggestion -

It can help others if you give _reasons_ why you feel the way you do. That might
even persuade others who would feel the same way if they knew your reasons.

Re: Window configurations

[grischka]

Maybe a matter of taste but I would not count on more conclusive behavior
from even more new options that allow packages to do what you want in case
anyone bothers to understand the complex specifications.  Instead it might
be much more effective to implement conclusive behavior in a simple algorithm
and remove any options for packages to circumvent it.

For instance, one could have a buffer stack for each window, such that each
buffer displayed is added on top of the window's buffer stack.  If a buffer is
killed or hidden, then the window's next buffer is displayed.  If there is
no "next", then the window is deleted (including the frame if it's the last
window).

--- grischka

From: martin rudalics
>    The `quit-restore' parameter tells how to proceed with a window when
> the user "quits" it by invoking `quit-restore-window', see *Note
> Displaying Buffers::.  The following non-`nil' values of this parameter
> have a special meaning.
>
> `t'
>      This means to delete the associated window.  By default, `t' is
>      used for a "temporary" window that was obtained by splitting an
>      existing window.
>
> `frame'
>      This means to delete the associated window's frame.  This value
>      indicates that the associated windows was obtained by popping up a
>      new frame showing just this window.  If the window is no more
>      needed, it should be deleted together with the containing frame.
>
> A list
>      This option is useful when the associated window was borrowed to
>      temporarily display some buffer and quitting shall "restore" the
>      previous contents of the window.  The first three elements of the
>      list must specify a buffer, a window start position, and a window
>      point.  Quitting the window will then try to display the indicated
>      buffer with the given start position and point in that window.
>
>      The fourth element, if non-`nil', must denote a live buffer.  If
>      specified, quitting will restore the previous window contents if
>      and only if the buffer shown in the window is the buffer named by
>      this element.
>
>      The fifth element, if non-`nil', should specify the desired height
>      of the window when its buffer is restored.  This value is applied
>      if the buffer temporarily shown in the window was in
>      `temp-buffer-resize-mode' to restore the original height of the
>      window.
>

Re: Window configurations

[martin rudalics]

 > Maybe a matter of taste but I would not count on more conclusive behavior
 > from even more new options that allow packages to do what you want in case
 > anyone bothers to understand the complex specifications.  Instead it might
 > be much more effective to implement conclusive behavior in a simple
 > algorithm
 > and remove any options for packages to circumvent it.

I didn't describe a new option.  The parameter I described is implicitly
present in the current behavior of help windows.  What I did was moving
it from such windows to `display-buffer' and also to a function intended
to get rid of window contents in some way.

 > For instance, one could have a buffer stack for each window, such that each
 > buffer displayed is added on top of the window's buffer stack.

Probably a buffer should be added at the time it's unshown and still
alive - yet another complication for `kill-buffer'.

 > If a
 > buffer is
 > killed or hidden, then the window's next buffer is displayed.

That's more or less what I do now - modulo the stack behavior, but this
could be changed.  One complication is that window configurations would
have to store the buffer stack and all buffer references.

What's more problematic, however, is that it's not clear whether each
and every occurrence of `set-window-buffer' should add its buffer to the
stack.  Currently, I put a buffer there only when `display-buffer'
displays it.  And, obviously, stacks have the usual annoying attitude to
forget about their tops, so sooner or later someone will come up and ask
for a ring or eventually a buffer history tree for each window and some
way to navigate it.

 > If there is
 > no "next", then the window is deleted (including the frame if it's the last
 > window).

I agree.  That is, I would certainly delete such a window if it never
displayed another buffer since it was created.  Also I would never
iconify a frame.  I'm not 100% sure whether a window should be deleted
because all buffers it displayed have been killed in the meantime.

But all this doesn't easily solve the problem of displaying a buffer in
the intuitively right window, for example, the window where it has been
already shown a couple of times before.  For this we could scan all
windows' stacks and pick the one that has this buffer at the most
prominent position - maybe supplied with some sort of a time-stamp.

martin

Re: Window configurations

[grischka]

martin rudalics wrote:
> ... And, obviously, stacks have the usual annoying attitude to
> forget about their tops, so sooner or later someone will come up and ask
> for a ring or eventually a buffer history tree for each window and some
> way to navigate it.

You're already lost if you plan to expose details of your design to users
or packages.  If people want rings or history, they can still implement
it on top of your design as a whole.  It is then their responsibility to
make their feature conclusive to yours.

> But all this doesn't easily solve the problem of displaying a buffer in
> the intuitively right window, for example, the window where it has been
> already shown a couple of times before.  For this we could scan all
> windows' stacks and pick the one that has this buffer at the most
> prominent position - maybe supplied with some sort of a time-stamp.

One mistake is to cater for windows on the same level of generality as you
obviously do for low level lisp.  Of course you want functions "cons" etc.
to allow generation of arbitrarily complex lisp structures, but it cannot
be the point of "split-window" to generate arbitrarily complex window-trees,
(and anyway the result of some such is not a "window-configuration" but at
most a "window-state").

The other mistake is _not_ to cater for windows on the same level of
_reliability_ as you obviously do for low level lisp.  "Cons" doesn't work
"intuitively" in the sense of "heuristically", and one has to accept that
there is no other "intuitively right window" to display some buffer except
the exactly one defined location where the user wants to see it.

And that is actually what "window-configuration" can only mean:  A way to
define windows for particular content (aka. buffers) _before_ the window
exists physically.

 From then on it is easy, you just need to tell "display-buffer" to use that
window rsp. to generate it if it doesn't yet exist.

--- grischka

> 
> martin
> 

Re: Window configurations

[martin rudalics]

 >> ... And, obviously, stacks have the usual annoying attitude to
 >> forget about their tops, so sooner or later someone will come up and ask
 >> for a ring or eventually a buffer history tree for each window and some
 >> way to navigate it.
 >
 > You're already lost if you plan to expose details of your design to users
 > or packages.  If people want rings or history, they can still implement
 > it on top of your design as a whole.  It is then their responsibility to
 > make their feature conclusive to yours.

There's hardly anything to implement "on top" of this.  The primitives
are `set-window-buffer' and `kill-buffer' so any implementation on top
of this would have to hook into `window-configuration-change-hook' and
`kill-buffer-hook'.

 > One mistake is to cater for windows on the same level of generality as you
 > obviously do for low level lisp.  Of course you want functions "cons" etc.
 > to allow generation of arbitrarily complex lisp structures, but it cannot
 > be the point of "split-window" to generate arbitrarily complex
 > window-trees,

I'm not sure whether I get your point.  But windows are first class
citizens in the Elisp world and `split-window' must be allowed to create
arbitrarily complex window trees on an arbitrarily complex machine.

 > (and anyway the result of some such is not a "window-configuration" but at
 > most a "window-state").

In my book a "window configuration" is "the state of all windows".

 > The other mistake is _not_ to cater for windows on the same level of
 > _reliability_ as you obviously do for low level lisp.  "Cons" doesn't work
 > "intuitively" in the sense of "heuristically", and one has to accept that
 > there is no other "intuitively right window" to display some buffer except
 > the exactly one defined location where the user wants to see it.

The question which buffer I want to display must be solved heuristically
because it's too complex to analyze the intentions of each and every
Emacs user (and possibly provide the necessary customizations) in Elisp.
The heuristics should guess the "intuitively right window" in a way
which can be roughly measured by the number of postings criticizing its
implementation.

 > And that is actually what "window-configuration" can only mean:  A way to
 > define windows for particular content (aka. buffers) _before_ the window
 > exists physically.

IIUC that's what packages like ECB do.  And ECB leaves it to Emacs and
its users to modify the configuration/state of the edit area.

 >  From then on it is easy, you just need to tell "display-buffer" to use
 > that
 > window rsp. to generate it if it doesn't yet exist.

martin

Re: Window configurations

[grischka]

martin rudalics wrote:
>  > One mistake is to cater for windows on the same level of generality  as you
>  > obviously do for low level lisp.  Of course you want functions "cons" etc.
>  > to allow generation of arbitrarily complex lisp structures, but it cannot
>  > be the point of "split-window" to generate arbitrarily complex
>  > window-trees,
> 
> I'm not sure whether I get your point.  But windows are first class
> citizens in the Elisp world and `split-window' must be allowed to create
> arbitrarily complex window trees on an arbitrarily complex machine.

Which does not mean that any feature can be allowed to use split-window
as it happens to think.

>  > (and anyway the result of some such is not a "window-configuration" but at
>  > most a "window-state").
> 
> In my book a "window configuration" is "the state of all windows".

In my book configuration is rules and state is result from their application
(together with other conditions).  Conflating the both will just produce a
classical chicken & egg problem.

>  > The other mistake is _not_ to cater for windows on the same level of
>  > _reliability_ as you obviously do for low level lisp.  "Cons" doesn't work
>  > "intuitively" in the sense of "heuristically", and one has to accept that
>  > there is no other "intuitively right window" to display some buffer except
>  > the exactly one defined location where the user wants to see it.
> 
> The question which buffer I want to display must be solved heuristically
> because it's too complex to analyze the intentions of each and every
> Emacs user (and possibly provide the necessary customizations) in Elisp.

There is no need to guess intentions if users were allowed to express them
(and emacs was disallowed to ignore them).

> The heuristics should guess the "intuitively right window" in a way
> which can be roughly measured by the number of postings criticizing its
> implementation.

You want "display-buffer" query the emacs bug tracker? ;)

>  > And that is actually what "window-configuration" can only mean:  A way to
>  > define windows for particular content (aka. buffers) _before_ the window
>  > exists physically.
> 
> IIUC that's what packages like ECB do.  And ECB leaves it to Emacs and
> its users to modify the configuration/state of the edit area.
> 
>  >  From then on it is easy, you just need to tell "display-buffer" to use
>  > that
>  > window rsp. to generate it if it doesn't yet exist.
> 
> martin
> 

--- grischka

Re: Window configurations

[martin rudalics]

 >> I'm not sure whether I get your point.  But windows are first class
 >> citizens in the Elisp world and `split-window' must be allowed to create
 >> arbitrarily complex window trees on an arbitrarily complex machine.
 >
 > Which does not mean that any feature can be allowed to use split-window
 > as it happens to think.

Features shouldn't do so, indeed.  `display-buffer' is the preferred
interface.

 >> In my book a "window configuration" is "the state of all windows".
 >
 > In my book configuration is rules and state is result from their
 > application
 > (together with other conditions).  Conflating the both will just produce a
 > classical chicken & egg problem.

If you specify a configuration procedurally you have to supply (1) an
initial state and (2) a set of actions and the order in which these
actions are applied.  In the context of window configurations, the state
resulting after applying (2) to (1) is the "state of all windows" as I
call it.  Hence the difference is basically only a matter of taste,
theroretically.

 From a practical point of view things are different: If you want to
derive (1) and (2) from the state of Emacs at some arbitrary point of
time you do have to guess a _minimum_ set of actions/rules that
reproduce the state of windows.  Otherwise, you end up like the
designers of ECB who record _all_ actions applied by the user and
"replay" them to produce the desired state.

 > There is no need to guess intentions if users were allowed to express them
 > (and emacs was disallowed to ignore them).

If we can come up with some simple set of customizable variables to
express the users' intentions.  But I'm afraid we won't be able to do
that.  Suppose I want to automatically show "another" buffer in some
window.  How is this other buffer chosen?  From the list of buffers that
(a) have been already displayed in that window, (b) that window's frame,
(c) somewhere (d) are alive?

 >> The heuristics should guess the "intuitively right window" in a way
 >> which can be roughly measured by the number of postings criticizing its
 >> implementation.
 >
 > You want "display-buffer" query the emacs bug tracker? ;)

More or less so, with some manual intervention ;-)

martin

Re: Window configurations

[grischka]

martin rudalics wrote:
>  > In my book configuration is rules and state is result from their application
>  > (together with other conditions).  Conflating the both will just produce a
>  > classical chicken & egg problem.
> 
> If you specify a configuration procedurally you have to supply (1) an
> initial state and (2) a set of actions and the order in which these
> actions are applied.  In the context of window configurations, the state
> resulting after applying (2) to (1) is the "state of all windows" as I
> call it.  Hence the difference is basically only a matter of taste,
> theroretically.

It might be a matter of taste whether you prefer eggs or chicken but
the difference is certainly more than theoretical ;)

>  From a practical point of view things are different: If you want to
> derive (1) and (2) from the state of Emacs at some arbitrary point of
> time you do have to guess a _minimum_ set of actions/rules that
> reproduce the state of windows.  Otherwise, you end up like the
> designers of ECB who record _all_ actions applied by the user and
> "replay" them to produce the desired state.

I remember that differently.  With ECB you can really choose from layouts
visually and even create new ones with a sort of interactive layout editor.
It is true that it stored the layouts as procedural sequences internally,
but that is just an implementation detail.

Aside from that it is really trivial to specify any reasonably complex
layouts as simple lisp structure, with sizes in percent, similar to say
framesets in html:

(setq my-layout '(
      (div-v
       (30 div-h
           (75 top-window-1)
           (25 top-window-2)
           )
       (55 div-h
           (25 div-v
               (50 sidebar-1)
               (25 sidebar-2)
               (25 sidebar-3)
               )
           (75 edit-area)
           )
       (15 tool-window)
       )))

That simple thing would be a pretty detailed layout already suited for
almost all purposes (except GUD perhaps).  More precisely, a layout
_configuration_, which means that the elements (windows) are shown only
when needed.

Now you'd have a function that processes the tree to remove the unshown
components, resizes the remaining components proportionally and then put
it on screen in one go using good old split-window and then shows the
buffers on top of each window's buffer stack.

For that of course you need a second set of preferences, that is what
buffer show in what pane:  For example,  *messages*, *compilation*,
*completion*, etc.  can be assigned to "tool-window", *speedbar* to
sidebar-1, *help* on "top-1", files and such to "edit-area", and so on ...

--- grischka

Re: Window configurations

[martin rudalics]

 > I remember that differently.  With ECB you can really choose from layouts
 > visually and even create new ones with a sort of interactive layout editor.
 > It is true that it stored the layouts as procedural sequences internally,
 > but that is just an implementation detail.

I was talking about practical issues, i.e., implementation.

 > Aside from that it is really trivial to specify any reasonably complex
 > layouts as simple lisp structure, with sizes in percent, similar to say
 > framesets in html:
 >
 > (setq my-layout '(

And we'd get this structure from `window-tree', I suppose?  Things like
that have been proposed and written a number of times already.

 > That simple thing would be a pretty detailed layout already suited for
 > almost all purposes (except GUD perhaps).  More precisely, a layout
 > _configuration_, which means that the elements (windows) are shown only
 > when needed.
 >
 > Now you'd have a function that processes the tree to remove the unshown
 > components, resizes the remaining components proportionally and then put
 > it on screen in one go using good old split-window and then shows the
 > buffers

That's what XEmacs does IIUC ...

 > on top of each window's buffer stack.

... just that it has no such stack.

 > For that of course you need a second set of preferences, that is what
 > buffer show in what pane:  For example,  *messages*, *compilation*,
 > *completion*, etc.  can be assigned to "tool-window", *speedbar* to
 > sidebar-1, *help* on "top-1", files and such to "edit-area", and so on ...

That's what ECB's layouts are supposed to accomplish.  But I still don't
know how we want to use a window's buffer stack.  It's probably trivial
when the only operation popping the stack also kills that buffer.
However, if the buffer remains alive where put it on the stack?  The
only reasonable answer is burying it.  But usually that buffer is the
one a user most likely wants to see first when unshowing another buffer
in that window.

martin

Re: Window configurations

[grischka]

martin rudalics wrote:
>  > (setq my-layout '(
> 
> And we'd get this structure from `window-tree', I suppose?  

But no!  You let the user define it.  And/or write one as default.
(And learn to love your users and to hate heuristics!)

> That's what ECB's layouts are supposed to accomplish.  But I still don't
> know how we want to use a window's buffer stack.  It's probably trivial
> when the only operation popping the stack also kills that buffer.
> However, if the buffer remains alive where put it on the stack?  The
> only reasonable answer is burying it.  But usually that buffer is the
> one a user most likely wants to see first when unshowing another buffer
> in that window.

A buffer-stack per window stands for some such as "virtually overlapped
windows", with a notion of "behind" if you want to.  Of course it is
possible to swap the two topmost position, if such semantics exist or
are desirable.

Probably it will help you with decisions if you can get the per window
tab-bar feature working, first.

--- grischka

> 
> martin
> 

Re: Window configurations

[Juri Linkov]

> Probably it will help you with decisions if you can get the per window
> tab-bar feature working, first.

There are different problems with per-window tab-bars.
They can be implemented using the header-line (like
tabbar.el already does).  But the main problem is that
currently only one header-line is allowed per window.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> And we'd get this structure from `window-tree', I suppose?
 >
 > But no!  You let the user define it.  And/or write one as default.
 > (And learn to love your users and to hate heuristics!)

Then you are missing one point: We need a structure that can be defined
(a) via some layout specification package as the one provided by ECB,
and (b) from user interactions in order to fit it into the desktop.el
framework.  In the latter case the user won't care about any such
structures, she simply wants her windows back.

 > A buffer-stack per window stands for some such as "virtually overlapped
 > windows", with a notion of "behind" if you want to.  Of course it is
 > possible to swap the two topmost position, if such semantics exist or
 > are desirable.

The question is what the _standard_ semantics are when a window ceases to
be topmost and we have to move it somewhere else on the stack.

martin

Re: Window configurations

[grischka]

martin rudalics wrote:
 >  >> And we'd get this structure from `window-tree', I suppose?
 >  >
 >  > But no!  You let the user define it.  And/or write one as default.
 >  > (And learn to love your users and to hate heuristics!)
 >
 > Then you are missing one point: We need a structure that can be defined
 > (a) via some layout specification package as the one provided by ECB,
 > and (b) from user interactions in order to fit it into the desktop.el
 > framework.  In the latter case the user won't care about any such
 > structures, she simply wants her windows back.

If is no necessary to save windows. You'd just use the same configuration
to show the same buffers, i.e. throw them at "display-buffer" which calls
into your window manager which will create windows in the same place as before
by definition, because to do this is the whole point of it:   To make sure
that same (class of) content is presented to the user in the same trusty
topological position always.

Anyway, it is true that you'll probably want some nifty code to let the
user interactively resize the layout configuration (e.g. by dragging borders
with the mouse).  It should be doable though.

 >  > A buffer-stack per window stands for some such as "virtually overlapped
 >  > windows", with a notion of "behind" if you want to.  Of course it is
 >  > possible to swap the two topmost position, if such semantics exist or
 >  > are desirable.
 >
 > The question is what the _standard_ semantics are when a window ceases to
 > be topmost and we have to move it somewhere else on the stack.

The standard semantics for "ceasing to be topmost" on a stack are "pushed down"
and "popped off".

--- grischka

 >
 > martin
 >

Re: Window configurations

[martin rudalics]

 > If is no necessary to save windows. You'd just use the same configuration
 > to show the same buffers, i.e. throw them at "display-buffer" which calls
 > into your window manager which will create windows in the same place as
 > before
 > by definition, because to do this is the whole point of it:   To make sure
 > that same (class of) content is presented to the user in the same trusty
 > topological position always.

`display-buffer' is completely untrustworthy in this regard.  The
trustworthy primitives to do what you mean are `split-window' and
`set-window-buffer'.

 >  > The question is what the _standard_ semantics are when a window
 > ceases to
 >  > be topmost and we have to move it somewhere else on the stack.
 >
 > The standard semantics for "ceasing to be topmost" on a stack are
 > "pushed down"
 > and "popped off".

Precisely that's why a stack is probably not sufficient for our purpose.

martin

Re: Window configurations

[grischka]

martin rudalics wrote:
>  > If is no necessary to save windows. You'd just use the same configuration
>  > to show the same buffers, i.e. throw them at "display-buffer" which calls
>  > into your window manager which will create windows in the same place as before
>  > by definition, because to do this is the whole point of it:   To make sure
>  > that same (class of) content is presented to the user in the same trusty
>  > topological position always.
> 
> `display-buffer' is completely untrustworthy in this regard.  The
> trustworthy primitives to do what you mean are `split-window' and
> `set-window-buffer'.

No.  Sometimes I write what I mean and obviously the "display-buffer"
function that calls into an emacs window manager has to be different
from the one that we already know.

--- grischka

Re: Window configurations

[Juri Linkov]

> Aside from that it is really trivial to specify any reasonably complex
> layouts as simple lisp structure, with sizes in percent, similar to say
> framesets in html:
>
> (setq my-layout '(
>      (div-v
>       (30 div-h
>           (75 top-window-1)
>           (25 top-window-2)
>           )
>       (55 div-h
>           (25 div-v
>               (50 sidebar-1)
>               (25 sidebar-2)
>               (25 sidebar-3)
>               )
>           (75 edit-area)
>           )
>       (15 tool-window)
>       )))

HTML framesets use the `rows' and `cols' attributes to split the screen
vertically and horizontally into frames (Emacs windows).

The above window configuration could be defined by HTML framesets as:

<FRAMESET rows="30%, 55%, 15%">
  <FRAMESET cols="75%, 25%">
    <FRAME src="top-window-1">
    <FRAME src="top-window-2">
  </FRAMESET>
  <FRAMESET cols="25%, 75%">
    <FRAMESET rows="50%, 25%, 25%">
      <FRAME src="sidebar-1">
      <FRAME src="sidebar-2">
      <FRAME src="sidebar-3">
    </FRAMESET>
    <FRAME src="edit-area">
  </FRAMESET>
  <FRAME src="tool-window">
</FRAMESET>

> That simple thing would be a pretty detailed layout already suited for
> almost all purposes (except GUD perhaps).

What's the problem with GUD?

> For that of course you need a second set of preferences, that is what
> buffer show in what pane:  For example,  *messages*, *compilation*,
> *completion*, etc.  can be assigned to "tool-window", *speedbar* to
> sidebar-1, *help* on "top-1", files and such to "edit-area", and so on ...

IOW, to "dedicate" a window to a buffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[grischka]

Juri Linkov wrote:
>> Aside from that it is really trivial to specify any reasonably complex
>> layouts as simple lisp structure, with sizes in percent, similar to say
>> framesets in html:
>>
>> (setq my-layout '(
>>      (div-v
>>       (30 div-h
>>           (75 top-window-1)
>>           (25 top-window-2)
>>           )
>>       (55 div-h
>>           (25 div-v
>>               (50 sidebar-1)
>>               (25 sidebar-2)
>>               (25 sidebar-3)
>>               )
>>           (75 edit-area)
>>           )
>>       (15 tool-window)
>>       )))
> 
> HTML framesets use the `rows' and `cols' attributes to split the screen
> vertically and horizontally into frames (Emacs windows).
> 
> The above window configuration could be defined by HTML framesets as:
> 
> <FRAMESET rows="30%, 55%, 15%">
>   <FRAMESET cols="75%, 25%">
>     <FRAME src="top-window-1">
>     <FRAME src="top-window-2">
>   </FRAMESET>
>   <FRAMESET cols="25%, 75%">
>     <FRAMESET rows="50%, 25%, 25%">
>       <FRAME src="sidebar-1">
>       <FRAME src="sidebar-2">
>       <FRAME src="sidebar-3">
>     </FRAMESET>
>     <FRAME src="edit-area">
>   </FRAMESET>
>   <FRAME src="tool-window">
> </FRAMESET>
> 
>> That simple thing would be a pretty detailed layout already suited for
>> almost all purposes (except GUD perhaps).
> 
> What's the problem with GUD?

I seem to remember it had more windows than the above layout provides.
GUD could of course come with it's own "GUD-configuration" that replaces
the user configuration as long as it's active.

>> For that of course you need a second set of preferences, that is what
>> buffer show in what pane:  For example,  *messages*, *compilation*,
>> *completion*, etc.  can be assigned to "tool-window", *speedbar* to
>> sidebar-1, *help* on "top-1", files and such to "edit-area", and so on ...
> 
> IOW, to "dedicate" a window to a buffer.
> 

Actually, to dedicate buffers to windows.

One aspect of the layout configuration is that windows have names, that
could evolve to a sort of convention.  Say, any configuration has to
provide some standard names, then packages/features could choose to
show their stuff in e.g. "edit-area", "sidebar", "tools-window", "top-pane"
(instead of just in "this" or "other" as currently).

--- grischka

Re: Window configurations

[martin rudalics]

 > One aspect of the layout configuration is that windows have names, that
 > could evolve to a sort of convention.  Say, any configuration has to
 > provide some standard names, then packages/features could choose to
 > show their stuff in e.g. "edit-area", "sidebar", "tools-window", "top-pane"
 > (instead of just in "this" or "other" as currently).

That's what `display-buffer-function' is for.  If a buffer is in some
way special wrt a specific package, that package has to take care of
displaying it in an appropriate way.

martin

Re: Window configurations

[Juri Linkov]

> <FRAMESET rows="30%, 55%, 15%">
>   <FRAMESET cols="75%, 25%">
>     <FRAME src="top-window-1">
>     <FRAME src="top-window-2">
>   </FRAMESET>
>   <FRAMESET cols="25%, 75%">
>     <FRAMESET rows="50%, 25%, 25%">
>       <FRAME src="sidebar-1">
>       <FRAME src="sidebar-2">
>       <FRAME src="sidebar-3">
>     </FRAMESET>
>     <FRAME src="edit-area">
>   </FRAMESET>
>   <FRAME src="tool-window">
> </FRAMESET>

We could use something like this to define window configurations because
FRAME is like Emacs window, and FRAMESET is like internal window, e.g.

(window-set (rows 30 55 15)
  (window-set (cols 75 25)
    (window (buffer . "top-window-1"))
    (window (buffer . "top-window-2")))
  (window-set (cols 25 75)
    (window-set (rows 50 25 25)
      (window (buffer . "sidebar-1"))
      (window (buffer . "sidebar-2"))
      (window (buffer . "sidebar-3")))
    (window (buffer . "edit-area")))
  (window (buffer . "tool-window")))

where window-set with rows splits vertically,
and window-set with cols splits horizontally.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > We could use something like this to define window configurations because
 > FRAME is like Emacs window, and FRAMESET is like internal window, e.g.
 >
 > (window-set (rows 30 55 15)
 >   (window-set (cols 75 25)
 >     (window (buffer . "top-window-1"))
[...]
 > where window-set with rows splits vertically,
 > and window-set with cols splits horizontally.

I suppose we need something more accurate than integer precentages.

And we have to decide how to handle fixed-size windows - they want some
absolute size.

martin

Re: Window configurations

[Juri Linkov]

>> We could use something like this to define window configurations because
>> FRAME is like Emacs window, and FRAMESET is like internal window, e.g.
>>
>> (window-set (rows 30 55 15)
>>   (window-set (cols 75 25)
>>     (window (buffer . "top-window-1"))
> [...]
>> where window-set with rows splits vertically,
>> and window-set with cols splits horizontally.
>
> I suppose we need something more accurate than integer precentages.
>
> And we have to decide how to handle fixed-size windows - they want some
> absolute size.

HTML frame configurations allow percentages, relative and absolute values,
e.g. rows="30%,400,*,2*".  We could support the same specification
http://www.w3.org/TR/REC-html40/present/frames.html with a list like
(rows 0.3 400 '* '(* 2))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Juri Linkov]

> One complication is that window configurations would
> have to store the buffer stack and all buffer references.

Yes, window configurations have to store the buffer stack.
Like frame configurations store the buffer list,
there is no problem with that.

> What's more problematic, however, is that it's not clear whether each
> and every occurrence of `set-window-buffer' should add its buffer to
> the stack.  Currently, I put a buffer there only when `display-buffer'
> displays it.

`set-window-buffer' could add its buffer to the stack only when
it is different than a buffer on the top of the stack.  A problem
may occur when `set-window-buffer' is used to set a buffer
temporarily.  Perhaps `set-window-buffer' should have a new argument
(e.g. NO-RECORD) to not change the stack in this case.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> One complication is that window configurations would
 >> have to store the buffer stack and all buffer references.
 >
 > Yes, window configurations have to store the buffer stack.
 > Like frame configurations store the buffer list,
 > there is no problem with that.

In a list structure we'd store buffer names and have to resolve the
known ambiguities.

 > `set-window-buffer' could add its buffer to the stack only when
 > it is different than a buffer on the top of the stack.

That's obvious.

 > A problem
 > may occur when `set-window-buffer' is used to set a buffer
 > temporarily.  Perhaps `set-window-buffer' should have a new argument
 > (e.g. NO-RECORD) to not change the stack in this case.

I suppose we need the extra argument also to specify whether the buffer
should go to the top or the bottom of the stack.  For example,
`quit-window' and `replace-buffer-in-windows' must be able to make sure
that the buffer goes to the bottom where it's the most unlikely
candidate to be shown again.  Otherwise, I might end up cycling through
a subset of the stacked buffers only when I continuously try to pop
items from it (via some `other-window-buffer' function, say).

On the other hand, when `display-buffer' reuses a window to show another
buffer in it, the old buffer should go to the top of the stack instead,
thus becoming the most likely candidate to be shown again.

martin

Re: Window configurations

[grischka]

 > I don't think that dedicated windows suck and even went so far as to
 > give them an entire section in the Elisp manual ;-)

I guess if the feature would dedicate buffers to windows (rather than
windows to buffers) it would be much more useful (and less suck).

--- grischka

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Jan D. wrote:
> Hello.
>
>
> I've published a new branch...

I have build that, but when I start Emacs, I don't 'see' any tabs. How 
can we enable those? I have a desktop file which opens several file when 
I start Emacs, so I would expect to see them in tabs! :-)

Perhaps we need something like 'M-x tabs-mode' (by default possibly! :-))

When I use 'M-x tab-new', I see a single buffer in two tabs. After 
closing the tabs, switching buffer as usually, with mouse-1/-3 on mode 
line, Emas becomes very slow, perhaps it hangs...

Anyway, thanks a lot for this new 'era' in Emacs!

Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Still some observation...

Suppose one starts Emacs, a single frame with 38 lines (Emacs.geometry: 
80x40-0+0 in .Xdefaults, for example). Now suppose one creates some 
tabs: M-x tab-new. The lines now are 37 because one line is that of tabs 
and the frame has the same size (height). If, now, one deletes the tabs, 
the lines remain at 37 but the frame has the height shorter by one line. 
Repeating this procedure the lines become 36, 35,... and the frame 
shorter, shorter...

Is this to be the right thing? My opinion is that the frame should have 
always the same height and the line should be 38 (N) or 37 (N-1) if the 
tabs are visible.

Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> Still some observation...
> 
> Suppose one starts Emacs, a single frame with 38 lines (Emacs.geometry: 
> 80x40-0+0 in .Xdefaults, for example). Now suppose one creates some 
> tabs: M-x tab-new. The lines now are 37 because one line is that of tabs 
> and the frame has the same size (height). If, now, one deletes the tabs, 
> the lines remain at 37 but the frame has the height shorter by one line. 
> Repeating this procedure the lines become 36, 35,... and the frame 
> shorter, shorter...
> 
> Is this to be the right thing? My opinion is that the frame should have 
> always the same height and the line should be 38 (N) or 37 (N-1) if the 
> tabs are visible.

Emacs tries to keep the frame size so an integral number of lines just fits. 
But tabs aren't (in general) exactly one or two lines high, so some resize 
will occur.  I made some fix.

I also made tab-mode a minor mode so it can be turned off by customize.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 10/04/2010 14.44, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> Still some observation...
>>
>> Suppose one starts Emacs, a single frame with 38 lines
>> (Emacs.geometry: 80x40-0+0 in .Xdefaults, for example). Now suppose
>> one creates some tabs: M-x tab-new. The lines now are 37 because one
>> line is that of tabs and the frame has the same size (height). If,
>> now, one deletes the tabs, the lines remain at 37 but the frame has
>> the height shorter by one line. Repeating this procedure the lines
>> become 36, 35,... and the frame shorter, shorter...
>>
>> Is this to be the right thing? My opinion is that the frame should
>> have always the same height and the line should be 38 (N) or 37 (N-1)
>> if the tabs are visible.
>
> Emacs tries to keep the frame size so an integral number of lines just
> fits. But tabs aren't (in general) exactly one or two lines high, so
> some resize will occur. I made some fix.
>
> I also made tab-mode a minor mode so it can be turned off by customize.

Good to hear! but I can't yet test it because bootstrapping rev. 99648 
(gtk-tabs branch) fails as follows:

[...]
make[3]: Entering directory `/tmp/emacs-gtk-tabs/build/lisp'
Compiling /tmp/emacs/src/../lisp/term/w32-win.el
Compiling /tmp/emacs/src/../lisp/emacs-lisp/easymenu.el
Wrote /tmp/emacs/lisp/term/w32-win.elc
Wrote /tmp/emacs/lisp/emacs-lisp/easymenu.elc
make[3]: Leaving directory `/tmp/emacs-gtk-tabs/build/lisp'
make[3]: Leaving directory `/tmp/emacs-gtk-tabs/build/lisp'
rm -f ../etc/DOC
../lib-src/make-docfile -d /tmp/emacs/src dosfns.o msdos.o xterm.o 
xfns.o[...]
/lisp/jka-cmpr-hook.elc ../lisp/ediff-hook.elc ../lisp/epa-hook.elc 
../lisp/widget.elc ../lisp/window.elc ../lisp/version.el
LC_ALL=C `/bin/pwd`/temacs -batch -l loadup dump
Loading loadup.el (source)...
Using load-path (/tmp/emacs/lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version.el (source)...
[...]
Loading tool-bar...
Loading font-setting...
Loading native-tabs.el (source)...
Attempt to autoload define-minor-mode while preparing to dump
make[2]: *** [emacs.exe] Error 255
make[2]: Leaving directory `/tmp/emacs-gtk-tabs/build/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/tmp/emacs-gtk-tabs/build'
make: *** [bootstrap] Error 2

This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same 
manner.


Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> Loading native-tabs.el (source)...
> Attempt to autoload define-minor-mode while preparing to dump
> make[2]: *** [emacs.exe] Error 255
> make[2]: Leaving directory `/tmp/emacs-gtk-tabs/build/src'
> make[1]: *** [src] Error 2
> make[1]: Leaving directory `/tmp/emacs-gtk-tabs/build'
> make: *** [bootstrap] Error 2
> 
> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same 
> manner.

Hmm, I have pushed a new version where the autoload is removed.  The problem 
is, then C-h f tab-mode doesn't show anything.

Anybody knows why this happens?

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 10/04/2010 20.03, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same
>> manner.
>
> Hmm, I have pushed a new version where the autoload is removed. The
> problem is, then C-h f tab-mode doesn't show anything.

I have tried also with rev. 99649, but same problem. :(

Angelo

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Did you make sure native-tabs.el is byte-compiled? Also do make clean  
and then make again.

        Jan D.

11 apr 2010 kl. 00.09 skrev Angelo Graziosi <angelo.graziosi@alice.it>:

> Il 10/04/2010 20.03, Jan Djärv ha scritto:
>> Angelo Graziosi skrev:
>>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the  
>>> same
>>> manner.
>>
>> Hmm, I have pushed a new version where the autoload is removed. The
>> problem is, then C-h f tab-mode doesn't show anything.
>
> I have tried also with rev. 99649, but same problem. :(
>
> Angelo
>
>

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

As I have flagged sometime on this list, I do ALWAYS clean build of 
Emacs, i.e. from a scratch tree not 'contaminated' by previous build. :-)

So, perhaps, that branch has other problems. For example,

$ grep native /tmp/emacs-gtk-tabs/src/Makefile.in

is empty in rev. 99648 and 99649.

The last useful build is with rev. 99645.

Ciao,
Angelo.


Il 11/04/2010 7.45, Jan Djärv ha scritto:
> Did you make sure native-tabs.el is byte-compiled? Also do make clean
> and then make again.
>
> Jan D.
>
> 11 apr 2010 kl. 00.09 skrev Angelo Graziosi <angelo.graziosi@alice.it>:
>
>> Il 10/04/2010 20.03, Jan Djärv ha scritto:
>>> Angelo Graziosi skrev:
>>>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same
>>>> manner.
>>>
>>> Hmm, I have pushed a new version where the autoload is removed. The
>>> problem is, then C-h f tab-mode doesn't show anything.
>>
>> I have tried also with rev. 99649, but same problem. :(
>>
>> Angelo
>>
>>

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> As I have flagged sometime on this list, I do ALWAYS clean build of 
> Emacs, i.e. from a scratch tree not 'contaminated' by previous build. :-)
> 
> So, perhaps, that branch has other problems. For example,
> 
> $ grep native /tmp/emacs-gtk-tabs/src/Makefile.in
> 
> is empty in rev. 99648 and 99649.
> 
> The last useful build is with rev. 99645.
> 

Ah, so lisp files goes in there now, I didn't know.
I pushed a fix.

Thanks,

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 11/04/2010 12.52, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> As I have flagged sometime on this list, I do ALWAYS clean build of
>> Emacs, i.e. from a scratch tree not 'contaminated' by previous build. :-)
>>
>> So, perhaps, that branch has other problems. For example,
>>
>> $ grep native /tmp/emacs-gtk-tabs/src/Makefile.in
>>
>> is empty in rev. 99648 and 99649.
>>
>> The last useful build is with rev. 99645.
>>
>
> Ah, so lisp files goes in there now, I didn't know.
> I pushed a fix.

Indeed, now it builds :-)

Observations: I see that in Options | Show/Hide Tabs are on by default 
(good!), but when I start Emacs I do not see any tabs. I still need 'M-x 
tab-new' to see some tab. I would expect that, if Tabs are on by 
default, starting Emacs shows desktop buffers in tabs, at least 
compatibly with the starting 'geometry' of Emacs.

So (sorry :( ), I still miss a short way to see desktop buffers in tabs. 
Probably, you are only thinking how to implement that...

Thanks for your efforts,
Angelo.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> Observations: I see that in Options | Show/Hide Tabs are on by default
> (good!), but when I start Emacs I do not see any tabs. I still need 'M-x
> tab-new' to see some tab. I would expect that, if Tabs are on by default,
> starting Emacs shows desktop buffers in tabs, at least compatibly with the
> starting 'geometry' of Emacs.

I implemented a new command line argument, so a command:

  emacs --tabs file1 file2 file3

will open each file in a new tab.  And

  emacsclient --create-tab

creates a new tab on the current Emacs frame.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

I also implemented C functions to save window configurations
in Lisp expressions that could be used later to save tabs
in the desktop file.  For example,

(current-window-configuration-to-sexp)
=>
(window-configuration
 (frame-cols . 80)
 (frame-lines . 41)
 (frame-menu-bar-lines . 1)
 (frame-tool-bar-lines . 4)
 (frame-tab-bar-lines . 4)
 (current-buffer . "*scratch*")
 (minibuf-scroll-window)
 (minibuf-selected-window)
 (saved-windows
  . (saved-window
     (current-window . t)
     (buffer . "*scratch*")
     (left-col . 0)
     (top-line . 5)
     (total-cols . 86)
     (total-lines . 35)
     (hscroll . 0)
     (min-hscroll . 0)
     (display-table)
     (orig-top-line)
     (orig-total-lines)
     (left-margin-cols)
     (right-margin-cols)
     (left-fringe-width)
     (right-fringe-width)
     (fringes-outside-margins)
     (scroll-bar-width)
     (vertical-scroll-bar-type . t)
     (dedicated)
     (resize-proportionally)
     (pointm . 236)
     (start . 1)
     (start-at-line-beg . t)
     (mark . 192)
     (next
      . (saved-window
         (buffer . " *Minibuf-0*")
         (left-col . 0)
         (top-line . 40)
         (total-cols . 86)
         (total-lines . 1)
         (hscroll . 0)
         (min-hscroll . 0)
         (display-table)
         (orig-top-line)
         (orig-total-lines)
         (left-margin-cols)
         (right-margin-cols)
         (left-fringe-width)
         (right-fringe-width)
         (fringes-outside-margins)
         (scroll-bar-width)
         (vertical-scroll-bar-type . t)
         (dedicated)
         (resize-proportionally)
         (pointm . 1)
         (start . 1)
         (start-at-line-beg))))))

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> From: Juri Linkov
> I also implemented C functions to save window configurations
> in Lisp expressions that could be used later to save tabs
> in the desktop file.  For example,
> 
> (current-window-configuration-to-sexp)
> =>
> (window-configuration
>  (frame-cols . 80)
>  (frame-lines . 41)
>  (frame-menu-bar-lines . 1)
>  (frame-tool-bar-lines . 4)
>  (frame-tab-bar-lines . 4)
...

Is the intention to be able to save and restore all current window & frame
configurations?

That is what I would like to see, to be able to save and restore an Emacs state
as completely as possible wrt frames and windows.

[That would of course mean saving all frame parameters that can be restored. I
would even like to see the ability for users to hook into such a feature, so
that user-defined frame parameters could be handled also. E.g. for a
user-defined frame parameter `foo', a user could specify how it can be saved and
restored, so that frame-config saving & restoring would then DTRT wrt it.]

Lennart made a stab at saving/restoring frame and window configs, but his code
didn't work when I tested it (there were apparently some dependencies on his
EmacsW32 etc.). Perhaps you and he could put together something general. It
seems like you're both close.

I would like to see the ability to save & restore each of the following
independently, in such a way that you could use them separately or together (to
save and restore various combinations): desktops, window configs, frame configs.

IOW, we should not couple any of them in such a way that you could no longer
save only a desktop (without also saving frame configs) or only the current
frame & window configs, etc.  E.g., a saved desktop should not necessarily
include frame and window configs, but you should also be able to save all at
once.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> Is the intention to be able to save and restore all current window & frame
> configurations?

Yes, I've implemented the task to save and restore frame and
window configurations in the desktop file.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> > Is the intention to be able to save and restore all current 
> > window & frame configurations?
> 
> Yes, I've implemented the task to save and restore frame and
> window configurations in the desktop file.

Is this feature part of the 23-1-91 pretest or otherwise intended for 23.2? If
so, is it documented? If it's in the pretest I would like to try it.

Can users save such frame & window configs independently of desktops - and vice
versa? Can they save individual frame/window configs as well as all configs
together? See the rest of my previous mail.

A desktop saves some variables, buffers, etc. Users should be able to save just
frame/window state or just the vars+bufs state, as well as being able to save
everything together at once. It doesn't matter whether this new feature is in a
separate library (which might be more modular) or is in desktop.el, but
frame/window saving/restoration should be separable from the traditional use of
desktops to save/restore buffers and vars.

Also, desktop.el has a big limitation (which I would like to see removed): it
assumes only one desktop file per directory. I would not like to see such a
gross limitation extended to the saving and restoring of frame and window
configs. There is no reason for that.

Please see the rest of my previous mail. Can users hook into this to handle
user-defined frame parameters also? The feature should be open and not limited
to a predefined set of parameters.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> Yes, I've implemented the task to save and restore frame and
>> window configurations in the desktop file.
>
> Is this feature part of the 23-1-91 pretest or otherwise intended for 23.2? If
> so, is it documented? If it's in the pretest I would like to try it.

This feature is part of the x-tabs branch.

> Can users save such frame & window configs independently of desktops - and vice
> versa? Can they save individual frame/window configs as well as all configs
> together?

If you want to save frame and window configurations independently of desktops,
you can easily do this using the same functions that desktop.el now uses.

> A desktop saves some variables, buffers, etc. Users should be able to save just
> frame/window state or just the vars+bufs state, as well as being able to save
> everything together at once.

There is a new variable `desktop-save-frame-configuration' that defines
whether to save frame and window configurations to the desktop.
It is nil by default.

> Also, desktop.el has a big limitation (which I would like to see removed): it
> assumes only one desktop file per directory.

It's a separate task to implement named desktops.

I imagine that named desktops should be an object above frames
in the hierarchy of screen objects:

 - desktop
  - frame
   - tab
    - window configuration
     - window

So switching desktops could be like switching frames:

  M-x select-desktop-by-name RET

will read a desktop name, delete old frames by calling `desktop-clear',
and create a new desktop by calling `desktop-read' with the selected name.

> Can users hook into this to handle user-defined frame parameters also?
> The feature should be open and not limited to a predefined set
> of parameters.

Yes, there is a new variable `desktop-frame-parameters-to-save'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> > Can users save such frame & window configs independently of 
> > desktops - and vice versa? Can they save individual
> > frame/window configs as well as all configs
> > together?
> 
> If you want to save frame and window configurations 
> independently of desktops, you can easily do this using the
> same functions that desktop.el now uses.

So is that confirmation or not that one can save desktops without frame+win
configs and one can also save frame configs or window configs or both
independently of desktops (the traditional desktop info)?

And can users do that interactively out of the box, or are you saying only that
someone is free to create some user commands to do that using existing desktop
functions?

> > A desktop saves some variables, buffers, etc. Users should 
> > be able to save just frame/window state or just the
> > vars+bufs state, as well as being able to save
> > everything together at once.
> 
> There is a new variable `desktop-save-frame-configuration' 
> that defines whether to save frame and window configurations
> to the desktop. It is nil by default.

You don't also say that there is a way to save frame and window configs without
saving them to a desktop file. Or whether there is a way to save them without
also saving the other desktop info (buffers, vars etc.). 

It sounds like frame+win are optionally part of a desktop, but not the contrary
as well. That is different from them being separate things that can optionally
be combined.

I don't care much about the names - whether, for instance, "desktop" applies to
what it means now (buffers, vars, etc.) or it is changed to apply to everything,
including frames and windows. What I am concerned about is being able to easily
save & restore the different kinds of things separately.

> > Also, desktop.el has a big limitation (which I would like 
> > to see removed): it assumes only one desktop file per directory.
> 
> It's a separate task to implement named desktops.
> 
> I imagine that named desktops should be an object above frames
> in the hierarchy of screen objects:
>  - desktop - frame - tab - window configuration - window
> So switching desktops could be like switching frames:
>   M-x select-desktop-by-name RET
> will read a desktop name, delete old frames by calling 
> `desktop-clear', and create a new desktop by calling
> `desktop-read' with the selected name.

I do not really want to see desktops and frames coupled that way. Again, the
names don't matter to me much - what I want is to be able to save & restore such
different things together or separately.

I did not mention "named desktops". I asked to be able to have more than one
desktop file per directory. Currently, the desktop functions assume you can have
only one desktop file per dir.

I would like the basic desktop functions to accept an optional FILE arg that
tells them where the desktop file is. (If no such arg is passed, then they could
do as they do now: look to `desktop-dirname' to find the file.) That would
permit other code to pass a FILE arg to directly specify a desktop file to use.

I have desktop bookmarks, for instance. Because the desktop.el code does not
allow a caller to specify the file to use, my code jumps through a few extra
hoops.

Look at `desktop-change-dir' and `desktop-read'. They just change to the desktop
represented by a particular desktop file. But they assume one file per dir, so
they accept only a dir as arg. You would expect that you could explicitly pass a
desktop file to read, but you cannot.

The desktop.el code seems to be oriented toward a particular interaction between
users and its basic features. That's the problem, as I see it. It has general
features of saving and restoring a desktop to/from a file, but the functions
that perform those basic operations are cobbled by making them assume a
particular UI. That makes them less general (less useful) than they could be.

IOW, there is not enough separation between the basic desktop functions and the
UI that uses them - the UI design bleeds down into the basic functions
themselves.

We need not change the desktop UI. (But we could do that, to let users use
multiple files per dir interactively as well.) The basic desktop functions could
still assume that the desktop file they need is in the `desktop-dirname' dir by
default. All I'm suggesting is that these functions should allow an optional
parameter that provides the desktop file location. 

Other changes to the code (e.g. locking) might also be necessary to allow use of
multiple files per dir - dunno. I'm guessing that the reason behind the original
one-desktop-file-per-dir design had to do with locking (multiple users etc.). I
don't know what all might be involved in trying to remove this limitation (maybe
allow multiple lock files per dir?). For my use of desktop files for bookmarks,
I want to let users save desktop files anywhere, and I don't use the locking.

I brought up this point because you seem to be coupling persistence of frame and
window configs with desktop files - and hence extending the limitation of one
such file per dir to the new feature as well. That means users cannot have
multiple frame-config files per dir etc.

Don't get me wrong. I'm very glad you're working on this, and I don't pretend to
be an expert on desktops or the desktop.el code. I just would like things to be
modular - separable and combinable, and I would like the basic save-&-restore
functions to handle multiple state-saving files per dir.

> > Can users hook into this to handle user-defined frame 
> > parameters also? The feature should be open and not limited to
> > a predefined set of parameters.
> 
> Yes, there is a new variable `desktop-frame-parameters-to-save'.

Very good.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> And can users do that interactively out of the box, or are you saying
> only that someone is free to create some user commands to do that
> using existing desktop functions?

Sorry, this is too abstract and premature.  You are asking for
generalization, but there is nothing to generalize yet, because
even saving to the desktop file is not ready yet.  Please wait
until it's ready, try it and then come up with concrete propositions:
what additional functions do you need, etc.  Or help to finish the task
of saving to the desktop file.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> Sorry, this is too abstract and premature.  You are asking for
> generalization, but there is nothing to generalize yet, because
> even saving to the desktop file is not ready yet.  Please wait
> until it's ready, try it and then come up with concrete propositions:
> what additional functions do you need, etc.  Or help to 
> finish the task of saving to the desktop file.

I asked specific (not only abstract) questions about the _design_ of the new
feature you're proposing. You're telling me that you cannot discuss the design,
that I should just wait until the implementation is finished before raising
questions about what it should do. That's an "interesting" attitude.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> I asked specific (not only abstract) questions about the _design_ of
> the new feature you're proposing. You're telling me that you cannot
> discuss the design, that I should just wait until the implementation
> is finished before raising questions about what it should do.

Of course, you are welcome to discuss the design.  Currently the design
is at the stage of deciding what format is better to represent the
window configuration.  There are two options: a window tree and
a plain list of windows.  I am inclined to the second option
since when saved it would be more compact.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Gtk tabs in emacs, new branch

[martin rudalics]

 > ... Currently the design
 > is at the stage of deciding what format is better to represent the
 > window configuration.  There are two options: a window tree and
 > a plain list of windows.  I am inclined to the second option
 > since when saved it would be more compact.

There's absolutely no need to make window configurations saved by
`current-window-configuration' (I call them CWCs here) and window
configurations saved for later reconstruction in a possibly different
session (called EWCs) save the same states of things.

CWCs are needed to restore the appearance of a frame after a short
excursion or because some error occurred.  They are heavily overused in
that respect (for example, every time you drag a window's modeline with
the mouse up or down by one line, Emacs saves and discards the current
window configuration twice) but certain aspects might be needed to keep
the appearance coherent like, for example, `hscroll' related entries.

EWCs should IMHO strip window configurations to the absolutely needed
bare minimum.  In particular `orig-top-line' and `orig-total-lines' do
more harm than good in EWCs (BTW, I've completely done away with these
in my rewrite of window.c) as all other minibuffer related information.
Also hscroll and min-hscroll should not be stored.

Whether margin, fringe and scrollbar information should be stored in
EWCs depends on whether the appropriate settings for frames and the
buffer local values are stored and orderly processed as well - otherwise
they make few sense.  I'm afraid we'd have to store/restore all of them,
although I'm also quite sure that hardly anyone could tell how their
final appearance on screen is determined.

Coordinates should probably be rather stored as fractions instead of
absolute lines and columns.  This would make it easier to (1) eventually
switch to pixel based coordinates and (2) put an EWC into an Emacs
window (that is, put an Emacs frame into an Emacs window) as some IDE
advocats mentioned earlier.

Since I suppose you're running `split-window' to restore configurations
you'd probably also want to remember whether a "split" was a vertical or
a horizontal one in EWCs.  Note that CWCs don't do this since they need
to restore the configuration from the stored "coordinates" anyway, but
the design is a bit awkward as code like

  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))

in `set-window-configuration' shows.

That said, the *entire* coordinate information of a particular window in
an EWC would consist of (1) whether it is a horizontal or a vertical
combination and (2) the proportional space - either a float or the
fraction of "some largest integer" - occupied by the window wrt to its
parent window.  Anything else would be pure overkill.

BTW in the earlier example structure you posted here I'm missing entries
for window-point, window-start, ...  Was that intentional?

martin

Window configurations (was: Gtk tabs in emacs, new branch)

[Juri Linkov]

>> ... Currently the design
>> is at the stage of deciding what format is better to represent the
>> window configuration.  There are two options: a window tree and
>> a plain list of windows.  I am inclined to the second option
>> since when saved it would be more compact.
>
> There's absolutely no need to make window configurations saved by
> `current-window-configuration' (I call them CWCs here) and window
> configurations saved for later reconstruction in a possibly different
> session (called EWCs) save the same states of things.

Yes.  That's why I added a new argument `live-p' to
`current-window-configuration-to-sexp'.  When non-nil, it adds live data
(window objects, buffer objects, markers, etc.) that are necessary
when its Lisp expression will be used in the same session.  When nil,
it returns bare minimum necessary to save and restore in another session.

> EWCs should IMHO strip window configurations to the absolutely needed
> bare minimum.  In particular `orig-top-line' and `orig-total-lines' do
> more harm than good in EWCs (BTW, I've completely done away with these
> in my rewrite of window.c)

Do you plan to create a branch for your rewrite of window.c?
It would be very interesting to look at it.

> Coordinates should probably be rather stored as fractions instead of
> absolute lines and columns.  This would make it easier to (1) eventually
> switch to pixel based coordinates and (2) put an EWC into an Emacs
> window (that is, put an Emacs frame into an Emacs window) as some IDE
> advocats mentioned earlier.

There are no problems with storing coordinates as absolute lines and
columns.  After restoring absolute coordinates `set-window-configuration'
resizes the frame thus keeping original relative sizes unchanged.

> Since I suppose you're running `split-window' to restore configurations
> you'd probably also want to remember whether a "split" was a vertical or
> a horizontal one in EWCs.  Note that CWCs don't do this since they need
> to restore the configuration from the stored "coordinates" anyway, but
> the design is a bit awkward as code like
>
>  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))
>
> in `set-window-configuration' shows.

No, I don't use `split-window'.  I use exactly the same algorithm as in
`set-window-configuration', and additionally make new windows.
In my tests, this works correctly.

> That said, the *entire* coordinate information of a particular window in
> an EWC would consist of (1) whether it is a horizontal or a vertical
> combination and (2) the proportional space - either a float or the
> fraction of "some largest integer" - occupied by the window wrt to its
> parent window.

Currently `set-window-configuration-from-sexp' works without these
parameters.  But maybe they would be useful for user-defined window
configurations.

> BTW in the earlier example structure you posted here I'm missing entries
> for window-point, window-start, ...  Was that intentional?

There are entries `pointm' and `start' in the output of of the really
working function `current-window-configuration-to-sexp'.

But the example of the output of `window-configuration-to-sexp' is for
demonstration purposes only.  It doesn't work yet, because I'm not sure yet
whether it's better than `current-window-configuration-to-sexp'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > Do you plan to create a branch for your rewrite of window.c?
 > It would be very interesting to look at it.

I have to catch up with recent developments on the trunk - currently I'm
at revision 99248.  And I yet have to write Change Logs.

 > No, I don't use `split-window'.  I use exactly the same algorithm as in
 > `set-window-configuration', and additionally make new windows.
 > In my tests, this works correctly.

That's what I intended to do when I first looked into this.  Making new
windows essentially has the problem that when, for whatever reason,
coordinates are garbled, you end up with a distorted frame and, in the
worst case, crash Emacs.  Checking window edges is simple with an
existing window tree.  But if you build the entire tree from scatch, you
also have to provide a safe way to GC windows you made just in case they
don't fit.  With `split-window' you always add one window at a time and
you never make a new one unless you're sure it fits.

By no means I want to talk you out of this ;-) but `split-window' is a
socially well-established function.  Saved window configurations will
hardly ever get used that much.  And we'll already have a hard time to
maintain compatibility, for example, when you want to restore a
configuration saved by Emacs 27 in an Emacs 29 session (or vice-versa).

 >> That said, the *entire* coordinate information of a particular window in
 >> an EWC would consist of (1) whether it is a horizontal or a vertical
 >> combination and (2) the proportional space - either a float or the
 >> fraction of "some largest integer" - occupied by the window wrt to its
 >> parent window.
 >
 > Currently `set-window-configuration-from-sexp' works without these
 > parameters.  But maybe they would be useful for user-defined window
 > configurations.

Users "define" window configurations by splitting and deleting windows.
They have no idea of the underlying window tree.  But if you don't use
`split-window' storing the type of window combinations doesn't make
sense anyway.  It's just that current window configurations have lots of
redundancy: For a vertical combination, the widths of all subwindows are
the same as that of the parent window, top-lines can be calculated on
the fly by adding the top-line of the left sibling to its height, ...

Anyway, the greatest problem IMO is to get windows correlate with their
buffers.  I don't think that restoring ediff configurations will become
ever feasible (unless you build this into the ediff code) and I'm also
pessimistic about Info buffers - in particular cloned ones.  And
obviously we'll fail to handle code based on window objects or overlays
with a window property.

But for merely "normal" buffers the integrity of buffer-local variables
affecting size and appearance of windows displaying them must be
preserved.  For example, when a buffer has `window-size-fixed' non-nil,
any frame resizing step in your `set-window-configuration' should keep
the size of the window fixed.

martin

Re: Window configurations

[Juri Linkov]

> By no means I want to talk you out of this ;-) but `split-window' is a
> socially well-established function.  Saved window configurations will
> hardly ever get used that much.  And we'll already have a hard time to
> maintain compatibility, for example, when you want to restore a
> configuration saved by Emacs 27 in an Emacs 29 session (or vice-versa).

I agree that when designing this feature, we should think about the future.
Let's imagine that Emacs 27 will switch from the tiling window manager
to an overlapping window manager.  Then `split-window' in window
configurations will make no sense.  This suggests that for the generality
window configurations should be defined as a list of windows with their
parameters, i.e. very much like frames are defined now.  Frame parameters
to define the frame geometry are `left', `top', `height', and `width'.
Window parameters to define the window geometry are `left-col', `top-line',
`total-lines', and `total-cols'.  Perhaps, in an overlapping window manager
they should be in pixels.

> Users "define" window configurations by splitting and deleting windows.
> They have no idea of the underlying window tree.  But if you don't use
> `split-window' storing the type of window combinations doesn't make
> sense anyway.  It's just that current window configurations have lots of
> redundancy: For a vertical combination, the widths of all subwindows are
> the same as that of the parent window, top-lines can be calculated on
> the fly by adding the top-line of the left sibling to its height, ...

Yes, currently window coordinates are redundant because of the
limitations of the tiling window manager.  So we have to find a minimal
set of window parameters to define the window location.  I agree that
a window tree is an implementation detail and users have no idea of the
underlying window tree.

Another variant is to define window geometry relative to the neighbor
windows, e.g. `left-window', `right-window' in terms of the package
windmove.el.  Such window configurations would be easy to define for users.

> Anyway, the greatest problem IMO is to get windows correlate with their
> buffers.  I don't think that restoring ediff configurations will become
> ever feasible (unless you build this into the ediff code)

I see no problems with window-to-buffer relations.  They can be defined
using buffer names.  This works successfully with desktop.el from the
x-tabs branch by saving and restoring window configurations in the
desktop file.

> and I'm also pessimistic about Info buffers

Window configurations with Info buffers are saved and restored
successfully in the desktop file as well.

> - in particular cloned ones.

What problems do you see with cloned Info buffers?

> And obviously we'll fail to handle code based on window objects
> or overlays with a window property.

Maybe a package that uses window overlays should use a new hook
to restore window overlays after a new window is created from
a window configuration.

> But for merely "normal" buffers the integrity of buffer-local variables
> affecting size and appearance of windows displaying them must be
> preserved.  For example, when a buffer has `window-size-fixed' non-nil,
> any frame resizing step in your `set-window-configuration' should keep
> the size of the window fixed.

It seems the frame resizing step in `set-window-configuration' already
keeps the size of the window fixed.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > This suggests that for the generality
 > window configurations should be defined as a list of windows with their
 > parameters, i.e. very much like frames are defined now.  Frame parameters
 > to define the frame geometry are `left', `top', `height', and `width'.
 > Window parameters to define the window geometry are `left-col', `top-line',
 > `total-lines', and `total-cols'.  Perhaps, in an overlapping window manager
 > they should be in pixels.

Sounds reasonable.  If we apply this idea today, the restore-from-sexp
step would decide how to rebuild the window tree from these geometry
parameters - that means how to nest windows into each others.

 > Yes, currently window coordinates are redundant because of the
 > limitations of the tiling window manager.  So we have to find a minimal
 > set of window parameters to define the window location.  I agree that
 > a window tree is an implementation detail and users have no idea of the
 > underlying window tree.

Some window managers are tiling window managers, even Windows XP has one
built in.  So even if Emacs permits overlapping windows it will probably
still offer tiled frames too.

 > Another variant is to define window geometry relative to the neighbor
 > windows, e.g. `left-window', `right-window' in terms of the package
 > windmove.el.  Such window configurations would be easy to define for users.

Hmm ... windmove never helped me that much.  I rewrote the core function
for my own purposes because there are windows I never want to select
interactively but the window behind such an unselectable one (or on the
left or right of it) is the window I really want.

 > I see no problems with window-to-buffer relations.  They can be defined
 > using buffer names.  This works successfully with desktop.el from the
 > x-tabs branch by saving and restoring window configurations in the
 > desktop file.

I have one buffer type which gets killed as soon as it's not shown in
any window.  Another one gets its name from the name of the window it's
shown in.  But I admit that in most cases the problematic issue is not
the buffer itself but the major or minor mode a window's buffer is in.

I suppose the solution is to (1) make the mode take care of saving the
relevant information and (2) untie buffer and window management in some
way.  How this would work for edebug, GDB, or diff sessions is currently
beyond my imagination.  Note that all I'm concerned here is that we now
should probably fix the order in which the restoring steps are perfomed
and what impact that has on restoring window configurations.  Whether
and how modes can be fully restored would be left to their designers.

 > Window configurations with Info buffers are saved and restored
 > successfully in the desktop file as well.
 >> - in particular cloned ones.
 >
 > What problems do you see with cloned Info buffers?

I never looked into this but I'm surprised that Info buffer would work
out of the box.  Do help buffers work well too?

 > Maybe a package that uses window overlays should use a new hook
 > to restore window overlays after a new window is created from
 > a window configuration.

I recall that Lennart tried to do that.  Currently, overlays can be a
mess after reverting a buffer so I think there are more important things
to do first.  Maybe we could try to handle this by giving windows fairly
unique print names.

 > It seems the frame resizing step in `set-window-configuration' already
 > keeps the size of the window fixed.

Probably at the expense of deleting windows when the frame gets too
small.  But my point was only that we have to process buffer-local
variables _before_ resizing frames.

martin

Re: Window configurations

[Juri Linkov]

>> This suggests that for the generality
>> window configurations should be defined as a list of windows with their
>> parameters, i.e. very much like frames are defined now.  Frame parameters
>> to define the frame geometry are `left', `top', `height', and `width'.
>> Window parameters to define the window geometry are `left-col', `top-line',
>> `total-lines', and `total-cols'.  Perhaps, in an overlapping window manager
>> they should be in pixels.
>
> Sounds reasonable.  If we apply this idea today, the restore-from-sexp
> step would decide how to rebuild the window tree from these geometry
> parameters - that means how to nest windows into each others.

For an overlapping window manager there is no need to rebuild the window
tree from geometry parameters.  And for the current tiling window manager
you said that window coordinates are redundant.  That's why I proposed
non-redundant and easy-to-define relative parameters.  I think it would
be sufficient to have two relative position parameters `left-window' and
`top-window' (that point to the left/top neighbor window) and two relative
size parameters `width' and `height' (fractions relative to the frame size).
I guess it would be possible to rebuild the window tree from this minimal
set of window parameters.

> Some window managers are tiling window managers, even Windows XP has one
> built in.  So even if Emacs permits overlapping windows it will probably
> still offer tiled frames too.

But none of these window managers define tiled windows as a split
window tree.  So probably an Emacs' overlapping window manager
will not be based on window trees.

> Hmm ... windmove never helped me that much.  I rewrote the core function
> for my own purposes because there are windows I never want to select
> interactively but the window behind such an unselectable one (or on the
> left or right of it) is the window I really want.

This looks like a new "intangible" window property discussed in the
window-group threads.  Have you implemented this in your rewrite of
window.c?

>> What problems do you see with cloned Info buffers?
>
> I never looked into this but I'm surprised that Info buffer would work
> out of the box.  Do help buffers work well too?

No, help buffers don't have an addressing scheme like in Info
with (info "(file)node").  Recently I proposed to display
Help information in the Info reader.  This will save and restore
buffers with Help information in the desktop file.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> Sounds reasonable.  If we apply this idea today, the restore-from-sexp
 >> step would decide how to rebuild the window tree from these geometry
 >> parameters - that means how to nest windows into each others.
 >
 > For an overlapping window manager there is no need to rebuild the window
 > tree from geometry parameters.  And for the current tiling window manager
 > you said that window coordinates are redundant.

That's what I said earlier.  But if we eventually do need them for an
overlapping window manager, we could build them into the current tiling
manager.  Just that (IMO) the tiling manager needs internal windows to
work correctly.  So the common format would be your four standard
parameters left column, top line, height and width for _all_ windows
including internal ones.

The restore step for the current tiling manager would have to process
the internal windows and reconstruct the nesting by comparing their
coordinates with those of the leaf windows - just like the current
`set-window-configuration' does in

	      if (!NILP (w->parent))
		{
		  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))
		    {
		      XWINDOW (w->parent)->vchild = p->window;
		      XWINDOW (w->parent)->hchild = Qnil;
		    }
		  else
		    {
		      XWINDOW (w->parent)->hchild = p->window;
		      XWINDOW (w->parent)->vchild = Qnil;
		    }

where it sets the vertical / horizontal child of a parent window
according to whether the number of its columns equals that of its child
windows (this work by virtue of Emacs's ability to collapse matryoshka
windows although it might not harm much if for such windows the split
direction would be inverted).

The restore step for the overlapping manager would simply ignore
internal windows.  So we could restore configurations stored by a tiling
manager in an overlapping manager.

 > That's why I proposed
 > non-redundant and easy-to-define relative parameters.  I think it would
 > be sufficient to have two relative position parameters `left-window' and
 > `top-window' (that point to the left/top neighbor window) and two relative
 > size parameters `width' and `height' (fractions relative to the frame size).
 > I guess it would be possible to rebuild the window tree from this minimal
 > set of window parameters.

Do you mean left would point to the left neighbor and top to the
neighbor above?  How would you assign them for a four window
configuration like this:

  -----
|1 |2 |
|-----|
|3 |4 |
  -----

Currently either 1+2 and 3+4 or 1+3 and 2+4 form internal windows.  How
would you convey that information with relative parameters?

 > This looks like a new "intangible" window property discussed in the
 > window-group threads.  Have you implemented this in your rewrite of
 > window.c?

It's virtually impossible to do that in a strict sense (unless you go
for a `post-command-hook').  Note that you can always do a thing like
(select-window (minibuffer-window)).

What I've done is to make `other-window' by default not select certain
window types.  That default can be overridden by window parameters.  And
I wrote a `window-in-direction' function which does this for the window
in a given direction (I need this because I never use C-x o).

martin

Re: Window configurations

[Juri Linkov]

> The restore step for the overlapping manager would simply ignore
> internal windows.  So we could restore configurations stored by a tiling
> manager in an overlapping manager.

I agree that in a tiling manager internal windows should have coordinates,
and an overlapping manager should ignore windows that don't display buffers
(if a window manager will support displaying windows without buffers
then window definitions should include a new window parameter for them).

> Do you mean left would point to the left neighbor and top to the
> neighbor above?

Yes.

> How would you assign them for a four window configuration like this:
>
>  -----
> |1 |2 |
> |-----|
> |3 |4 |
>  -----
>
> Currently either 1+2 and 3+4 or 1+3 and 2+4 form internal windows.  How
> would you convey that information with relative parameters?

This is easy to do.  Since split window trees are order-dependent,
a list of windows that defines the window configuration in the tiling
manager should be order-dependent too.  Thus

  (window 1
    (buffer . 1))
  (window 2
    (buffer . 2)
    (left-window . 1))
  (window 3
    (buffer . 3)
    (top-window . 1))
  (window 4
    (buffer . 4)
    (top-window . 2)
    (left-window . 3))

will create 1+2 and 3+4, and

  (window 1
    (buffer . 1))
  (window 3
    (buffer . 3)
    (top-window . 1))
  (window 2
    (buffer . 2)
    (left-window . 1))
  (window 4
    (buffer . 4)
    (top-window . 2)
    (left-window . 3))

will create 1+3 and 2+4.

>> This looks like a new "intangible" window property discussed in the
>> window-group threads.  Have you implemented this in your rewrite of
>> window.c?
>
> It's virtually impossible to do that in a strict sense (unless you go
> for a `post-command-hook').  Note that you can always do a thing like
> (select-window (minibuffer-window)).

This is right that primitives should be able to do this, and
user commands should take restrictions from additional parameters.

> What I've done is to make `other-window' by default not select certain
> window types.  That default can be overridden by window parameters.  And
> I wrote a `window-in-direction' function which does this for the window
> in a given direction (I need this because I never use C-x o).

Ok, I'll wait until you publish a Bzr branch to look at this.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Davis Herring]

> Users "define" window configurations by splitting and deleting windows.
> They have no idea of the underlying window tree.

I'm not sure that's right.  While users certainly don't know about
`frame-root-window' windows, the tree is otherwise readily apparent
(since, for instance, resizing or deleting a window distinguishes

+-+-+     +-+-+
|A|B|     |A|B|
+-|-+ and +---+
|C|D|     |C|D|
+-+-+     +-+-+

in an immediately obvious fashion).  Why not store a configuration as a
(resolution-independent) tree:

subtree = window | tree ;
tree = "(", horiz, subtree, split, { split }, ")" ;
split = fraction, subtree ;
horiz = nil | t ;            (* t for C-x 3 *)
fraction = ? float ? ;
window = ? ... ? ;           (* the hard part *)

very much like (window-tree)?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Window configurations

[martin rudalics]

 >> Users "define" window configurations by splitting and deleting windows.
 >> They have no idea of the underlying window tree.
 >
 > I'm not sure that's right.  While users certainly don't know about
 > `frame-root-window' windows, the tree is otherwise readily apparent
 > (since, for instance, resizing or deleting a window distinguishes
 >
 > +-+-+     +-+-+
 > |A|B|     |A|B|
 > +-|-+ and +---+
 > |C|D|     |C|D|
 > +-+-+     +-+-+
 >
 > in an immediately obvious fashion).

Yes.  But by merey looking at these configuration you can't tell the
difference.

 > Why not store a configuration as a
 > (resolution-independent) tree:
 >
 > subtree = window | tree ;
 > tree = "(", horiz, subtree, split, { split }, ")" ;
 > split = fraction, subtree ;
 > horiz = nil | t ;            (* t for C-x 3 *)
 > fraction = ? float ? ;
 > window = ? ... ? ;           (* the hard part *)

That's more or less what I proposed earlier: All I need for the current,
tiling window-manager based on window-trees is the type of the split
(horizontal or vertical) and the fraction occupied by a window wrt to
its parent window.  This implies, however, that an overlapping manager
processing such a structure must be able to understand window trees.

martin

Re: Window configurations

[Stefan Monnier]

> That's more or less what I proposed earlier: All I need for the current,
> tiling window-manager based on window-trees is the type of the split
> (horizontal or vertical) and the fraction occupied by a window wrt to
> its parent window.  This implies, however, that an overlapping manager
> processing such a structure must be able to understand window trees.

I think we should not pay attention to overlapping-windows for the
format.  If we ever add overlapping-windows, it'll be very easy then to
add backward-compatibility support for the tree format.  So a simple
tree with direction+fraction will work just fine.


        Stefan

Re: Window configurations

[Juri Linkov]

> Why not store a configuration as a (resolution-independent) tree:
>
> subtree = window | tree ;
> tree = "(", horiz, subtree, split, { split }, ")" ;
> split = fraction, subtree ;
> horiz = nil | t ;            (* t for C-x 3 *)
> fraction = ? float ? ;
> window = ? ... ? ;           (* the hard part *)
>
> very much like (window-tree)?

A window-tree format is good for androids.  But for human beings it is
too complicated.  Please see how ECB defines window configurations as
a plain list of function calls because it is more simple and convenient
for human users:

  (ecb-set-directories-buffer)
  (ecb-split-ver 0.3)
  (ecb-set-sources-buffer)
  (ecb-split-ver 0.5)
  (ecb-set-methods-buffer)
  (select-window (previous-window))
  (ecb-split-hor 0.5)
  (ecb-set-history-buffer)

But this format has one drawback - it is procedural.

Using a declarative, more general and future-proof format:

  (window A
    (buffer . A))
  (window B
    (buffer . B)
    (left-window . A))
  (window C
    (buffer . C)
    (top-window . A))
  (window D
    (buffer . D)
    (top-window . B)
    (left-window . C))

will create

  +-+-+
  |A|B|
  +---+
  |C|D|
  +-+-+

and with a different order of window definitions:

  (window A
    (buffer . A))
  (window C
    (buffer . C)
    (top-window . A))
  (window B
    (buffer . B)
    (left-window . A))
  (window D
    (buffer . D)
    (top-window . B)
    (left-window . C))

will create

  +-+-+
  |A|B|
  +-|-+
  |C|D|
  +-+-+

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Davis Herring]

> A window-tree format is good for androids.  But for human beings it is
> too complicated.  Please see how ECB defines window configurations as
> a plain list of function calls because it is more simple and convenient
> for human users:
>
>   (ecb-set-directories-buffer)
>   (ecb-split-ver 0.3)
>   (ecb-set-sources-buffer)
>   (ecb-split-ver 0.5)
>   (ecb-set-methods-buffer)
>   (select-window (previous-window))
>   (ecb-split-hor 0.5)
>   (ecb-set-history-buffer)

Perhaps then I am an android.  I look at that code and it takes me quite a
while to decide that the window-tree it produces (as I defined it) is (I
think)

(nil #<methods> 0.15 #<sources> 0.3 (t #<history> 0.5 #<directories>))

...assuming that ecb-split-{ver,hor} is just C-x {2,3} with the divide
placed the argument fraction of the way {down,right} the original window. 
On the other hand I find interpreting the window-tree easy because I can
just read it rather than tracing through it.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Window configurations

[Juri Linkov]

> Perhaps then I am an android.  I look at that code and it takes me quite a
> while to decide that the window-tree it produces (as I defined it) is (I
> think)
>
> (nil #<methods> 0.15 #<sources> 0.3 (t #<history> 0.5 #<directories>))

The problem is that the internal structure with the window configuration
is a list.  So when exposed to Lisp, it should be a Lisp list.

It you want a tree, it's possible to write a Lisp function
that converts a window list to a window tree, e.g.

  (window-configuration-to-tree
    (window-configuration-to-list
      (current-window-configuration)))

where `window-configuration-to-list' is a C function that
exposes #<window-configuration> to Lisp as a list like

  (window-configuration
   (frame-cols . 194)
   (frame-lines . 77)
   (root-window . #<window 16>)
   (windows
     (window
      (window . #<window 16>)
      (left-col . 0)
      (top-line . 5)
      (total-cols . 200)
      (total-lines . 71))
     (window
      (window . #<window 3 on *scratch*>)
      (parent . 0)
      (left-col . 0)
      (top-line . 5)
      (total-cols . 100)
      (total-lines . 71))
     (window
      (window . #<window 18>)
      (parent . 0)
      (prev . 1)
      (left-col . 100)
      (top-line . 5)
      (total-cols . 100)
      (total-lines . 71))
     (window
      (window . #<window 17 on *info*>)
      (parent . 2)
      (left-col . 100)
      (top-line . 5)
      (total-cols . 100)
      (total-lines . 35))
     (window
      (window . #<window 19 on *Messages*>)
      (parent . 2)
      (prev . 3)
      (left-col . 100)
      (top-line . 40)
      (total-cols . 100)
      (total-lines . 36))
     (window
      (window . #<window 4 on  *Minibuf-0*>)
      (prev . 0)
      (left-col . 0)
      (top-line . 76)
      (total-cols . 200)
      (total-lines . 1))))

and `window-configuration-to-tree' is a Lisp function that converts it
to a window-tree.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations (was: Gtk tabs in emacs, new branch)

[Ken Hori]

Juri,

Could we add as an extra `buffer-file-name' alist element in the sexp
of a window-configuration or is that a bad idea? (I was just tring to
reconstruct a window-configuration after an emacs reboot but quickly
found out filenames weren't just there.)


On Sun, Apr 25, 2010 at 11:33 AM, Juri Linkov <juri@jurta.org> wrote:
>>> ... Currently the design
>>> is at the stage of deciding what format is better to represent the
>>> window configuration.  There are two options: a window tree and
>>> a plain list of windows.  I am inclined to the second option
>>> since when saved it would be more compact.
>>
>> There's absolutely no need to make window configurations saved by
>> `current-window-configuration' (I call them CWCs here) and window
>> configurations saved for later reconstruction in a possibly different
>> session (called EWCs) save the same states of things.
>
> Yes.  That's why I added a new argument `live-p' to
> `current-window-configuration-to-sexp'.  When non-nil, it adds live data
> (window objects, buffer objects, markers, etc.) that are necessary
> when its Lisp expression will be used in the same session.  When nil,
> it returns bare minimum necessary to save and restore in another session.
>
>> EWCs should IMHO strip window configurations to the absolutely needed
>> bare minimum.  In particular `orig-top-line' and `orig-total-lines' do
>> more harm than good in EWCs (BTW, I've completely done away with these
>> in my rewrite of window.c)
>
> Do you plan to create a branch for your rewrite of window.c?
> It would be very interesting to look at it.
>
>> Coordinates should probably be rather stored as fractions instead of
>> absolute lines and columns.  This would make it easier to (1) eventually
>> switch to pixel based coordinates and (2) put an EWC into an Emacs
>> window (that is, put an Emacs frame into an Emacs window) as some IDE
>> advocats mentioned earlier.
>
> There are no problems with storing coordinates as absolute lines and
> columns.  After restoring absolute coordinates `set-window-configuration'
> resizes the frame thus keeping original relative sizes unchanged.
>
>> Since I suppose you're running `split-window' to restore configurations
>> you'd probably also want to remember whether a "split" was a vertical or
>> a horizontal one in EWCs.  Note that CWCs don't do this since they need
>> to restore the configuration from the stored "coordinates" anyway, but
>> the design is a bit awkward as code like
>>
>>  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))
>>
>> in `set-window-configuration' shows.
>
> No, I don't use `split-window'.  I use exactly the same algorithm as in
> `set-window-configuration', and additionally make new windows.
> In my tests, this works correctly.
>
>> That said, the *entire* coordinate information of a particular window in
>> an EWC would consist of (1) whether it is a horizontal or a vertical
>> combination and (2) the proportional space - either a float or the
>> fraction of "some largest integer" - occupied by the window wrt to its
>> parent window.
>
> Currently `set-window-configuration-from-sexp' works without these
> parameters.  But maybe they would be useful for user-defined window
> configurations.
>
>> BTW in the earlier example structure you posted here I'm missing entries
>> for window-point, window-start, ...  Was that intentional?
>
> There are entries `pointm' and `start' in the output of of the really
> working function `current-window-configuration-to-sexp'.
>
> But the example of the output of `window-configuration-to-sexp' is for
> demonstration purposes only.  It doesn't work yet, because I'm not sure yet
> whether it's better than `current-window-configuration-to-sexp'.
>
> --
> Juri Linkov
> http://www.jurta.org/emacs/
>
>
>

Re: Window configurations

[Stefan Monnier]

> Could we add as an extra `buffer-file-name' alist element in the sexp
> of a window-configuration or is that a bad idea? (I was just tring to
> reconstruct a window-configuration after an emacs reboot but quickly
> found out filenames weren't just there.)

For saving/restoring, we'll probably need to save the same info used
by bookmark.el or desktop.el (unifying the two might also be a good
idea, BTW).


        Stefan

Re: Window configurations

[Juri Linkov]

>> Could we add as an extra `buffer-file-name' alist element in the sexp
>> of a window-configuration or is that a bad idea? (I was just tring to
>> reconstruct a window-configuration after an emacs reboot but quickly
>> found out filenames weren't just there.)
>
> For saving/restoring, we'll probably need to save the same info used
> by bookmark.el or desktop.el (unifying the two might also be a good
> idea, BTW).

Since bookmark.el is conceptually more low-level than desktop.el,
the latter could use a subset of services provided by bookmarks.

There is one problem of using bookmark records for desktop.el.
Some bookmarks take too much time to restore when reading from the desktop
file.  So packages will need to distinguish between making a bookmark for
bookmark.el or desktop.el to not save some bookmarks in the desktop file.
Maybe `bookmark-make-record-function' will require a new argument for that.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Window configurations

[Drew Adams]

> >> Could we add as an extra `buffer-file-name' alist element
> >> in the sexp of a window-configuration or is that a bad idea?
> >> (I was just tring to reconstruct a window-configuration
> >> after an emacs reboot but quickly found out filenames
> >> weren't just there.)
> >
> > For saving/restoring, we'll probably need to save the same info used
> > by bookmark.el or desktop.el (unifying the two might also be a good
> > idea, BTW).
> 
> Since bookmark.el is conceptually more low-level than desktop.el,
> the latter could use a subset of services provided by bookmarks.
> 
> There is one problem of using bookmark records for desktop.el.
> Some bookmarks take too much time to restore when reading 
> from the desktop file.  So packages will need to distinguish
> between making a bookmark for bookmark.el or desktop.el to not
> save some bookmarks in the desktop file. Maybe
> `bookmark-make-record-function' will require a new argument for that.

Sigh. I really wish you guys wouldn't mess with this. Put what you want in a
window config, but please do not try "unifying" bookmarks and desktops (and
window configs).

If anything, bookmarks are more general and higher-level (not lower-level) than
desktops. Why? Because you can save/restore many different types of things as
bookmarks, each in its own way. Each can have its own handler.

Anything can be bookmarked. A desktop records one type of thing: a desktop, no
matter what you might want to stuff into a desktop, no matter how complex it is.

If you want to add handlers or other bells and whistles to desktops, go for it,
but please do not try to merge bookmarks and desktops as if they were the same
thing or one were an instance or a subset of the other. They both record state
persistently and restore it; that's all. There is no reason to confuse the
concepts or merge the code.

On the other hand, a desktop can be targeted as one kind of bookmark - a
bookmark can restore a desktop just as it can restore an Info node. That is the
case in bookmark+.el, for example. But it does not make sense to record all of
the info for a desktop directly in the bookmark (and thus in a bookmark file,
which can contain _lots_ of bookmarks).

What makes sense is for a desktop bookmark to simply refer to a particular
desktop file, which records the desktop info. Likewise, for a window-config
bookmark. (I'm still hoping you will not hard-couple window-configs and desktops
- each can be used independently of the other, as well as together.)

Nor does it make much sense to add bookmark records to a desktop file. I don't
know what kind of bookmark "info" or bookmark "services" you think would be
required by desktops. Do you plan on adding handlers to desktops? Whatever. Add
whatever you must to window-config records or desktop records, but please keep
bookmarks separate from them both.

Keep things simple and separate, so users and programmers can easily combine
them at will in various ways. Just give us a way to save and restore window
configs, and we can always combine that (or not) with saving and restoring
desktops. And we can always create a bookmark to either.

Please do not start "unifying" everything into one big ball of knots.

Wrt generalizing and improving _bookmarking_, which is a different topic from
making window configs persistent and restorable, see bookmark+.el. All of that
improvement could be added to Emacs, as a patch to bookmark.el. (No, I don't
want to argue about it. If you don't want it, that's fine.)
http://www.emacswiki.org/emacs/BookmarkPlus

Bookmarking is about saving and restoring something - anything. It is therefore
about handling different kinds of stateful things differently. To improve
bookmarking, work on making it easy for users to distinguish and access the
various types, provide type-specific UI features and help, and so on.

Forget about constructing the uber unifying
bookmark-cum-desktop-cum-window-config cathedral. Please. The goal should be
separate Lego blocks of different shapes that fit together, not a big wad of
fused plastic.

Re: Window configurations

[Stefan Monnier]

>> There is one problem of using bookmark records for desktop.el.
>> Some bookmarks take too much time to restore when reading
>> from the desktop file.

Juri, do you have more details on this?  I don't know of this problem.

> Sigh. I really wish you guys wouldn't mess with this. Put what you want in a
> window config, but please do not try "unifying" bookmarks and desktops (and
> window configs).

Noone's trying to unify the two: desktop.el uses internally
a representation of "the content and position of a given buffer" to be
able to reproduce it later, and as it turns out, this is the exact same
problem that bookmark tries to solve.  So it might make sense for
desktop.el to use bookmarks for that internal thingy.

I'm not 100% positive it does since the purpose is slightly different
(e.g. a bookmark is expected to be useful for a potentially long period
of time during which the file referenced might be modified many times,
so bookmark doesn't just record the buffer position but also some
context so as to find the same spot even if it's not at the same line
number any more.  It's probably less important for desktop.el).


        Stefan

Re: Window configurations

[Juri Linkov]

>>> There is one problem of using bookmark records for desktop.el.
>>> Some bookmarks take too much time to restore when reading
>>> from the desktop file.
>
> Juri, do you have more details on this?  I don't know of this problem.

Currently, Info mode doesn't save/restore virtual Info nodes to the
desktop file at all.  Even `dir' is not saved (which is a virtual file now).

The patch I sent on 2010-04-27 allows Info-desktop-buffer-misc-data
to save all virtual nodes to the desktop, except Info-apropos.
Info-apropos takes too much time to create a node with the search results.
So restoring an Info-apropos node from the desktop file would be
unacceptably slow.

One variant is to save the apropos search results as text in the desktop file,
but then it will grow too big.

There is no such problem for bookmarks because when the user decides
to restore a bookmark for an Info-apropos node, then the user is ready
to wait until this Info node is created and displayed.

> Noone's trying to unify the two: desktop.el uses internally
> a representation of "the content and position of a given buffer" to be
> able to reproduce it later, and as it turns out, this is the exact same
> problem that bookmark tries to solve.  So it might make sense for
> desktop.el to use bookmarks for that internal thingy.
>
> I'm not 100% positive it does since the purpose is slightly different
> (e.g. a bookmark is expected to be useful for a potentially long period
> of time during which the file referenced might be modified many times,
> so bookmark doesn't just record the buffer position but also some
> context so as to find the same spot even if it's not at the same line
> number any more.  It's probably less important for desktop.el).

There is another package that could benefit from the functionality of
bookmark.el - saveplace.el that saves places in files.  For instance,
when I put point on the `* Elisp: (elisp)' line in `dir', kill the
*info* buffer, and type `C-h i' again, then I'd like if point was
on the same `* Elisp: (elisp)' line.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Stefan Monnier]

> The patch I sent on 2010-04-27 allows Info-desktop-buffer-misc-data
> to save all virtual nodes to the desktop, except Info-apropos.
> Info-apropos takes too much time to create a node with the search results.
> So restoring an Info-apropos node from the desktop file would be
> unacceptably slow.
[...]
> There is no such problem for bookmarks because when the user decides
> to restore a bookmark for an Info-apropos node, then the user is ready
> to wait until this Info node is created and displayed.

Thanks, that makes sense.  So maybe the bookmark data should include
some `slow' tag of some sort if we want to use it for desktop.el.

> There is another package that could benefit from the functionality of
> bookmark.el - saveplace.el that saves places in files.  For instance,
> when I put point on the `* Elisp: (elisp)' line in `dir', kill the
> *info* buffer, and type `C-h i' again, then I'd like if point was
> on the same `* Elisp: (elisp)' line.

Of course.  The stack of *Help* topics is another one that could use it.


        Stefan

Re: Window configurations

[Juri Linkov]

>> There is no such problem for bookmarks because when the user decides
>> to restore a bookmark for an Info-apropos node, then the user is ready
>> to wait until this Info node is created and displayed.
>
> Thanks, that makes sense.  So maybe the bookmark data should include
> some `slow' tag of some sort if we want to use it for desktop.el.

A `slow' tag in the bookmark record would be useful not only for
desktop.el.  `bookmark-jump' could warn the user that restoring
the bookmark might take some time.

>> There is another package that could benefit from the functionality of
>> bookmark.el - saveplace.el that saves places in files.  For instance,
>> when I put point on the `* Elisp: (elisp)' line in `dir', kill the
>> *info* buffer, and type `C-h i' again, then I'd like if point was
>> on the same `* Elisp: (elisp)' line.
>
> Of course.  The stack of *Help* topics is another one that could use it.

And `Info-history' as well.  (Info and Help are another candidates for
unification.)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Stephen J. Turnbull]

Juri Linkov writes:

 > A `slow' tag in the bookmark record would be useful not only for
 > desktop.el.

Isn't the usual term for this "lazy", as in "lazy evaluation"?

Re: Window configurations

[Stefan Monnier]

>> A `slow' tag in the bookmark record would be useful not only for
>> desktop.el.
> Isn't the usual term for this "lazy", as in "lazy evaluation"?

I don't think so.  At least the the way I intend this `slow' to work: it
would simply indicate that fetching the corresponding bookmark can take
an unusually high amount of time.

Now, the users of that bookmark (e.g. desktop.el or the user) can then
make their own decision about how to handle such bookmarks, maybe
desktop could try and fetch them lazily indeed (e.g. delay fetching them
until the corresponding buffer is displayed).


        Stefan

Re: Window configurations

[Stephen J. Turnbull]

Stefan Monnier writes:

 > >> A `slow' tag in the bookmark record would be useful not only for
 > >> desktop.el.
 > > Isn't the usual term for this "lazy", as in "lazy evaluation"?
 > 
 > I don't think so.  At least the the way I intend this `slow' to work: it
 > would simply indicate that fetching the corresponding bookmark can take
 > an unusually high amount of time.

Ah, so it's a measure of cost to do a certain "primitive" operation.
That makes sense.

Re: Window configurations

[Juri Linkov]

>> Thanks, that makes sense.  So maybe the bookmark data should include
>> some `slow' tag of some sort if we want to use it for desktop.el.
>
> A `slow' tag in the bookmark record would be useful not only for
> desktop.el.  `bookmark-jump' could warn the user that restoring
> the bookmark might take some time.

I added a `slow' tag to the desktop record (not to the bookmark record yet)
as the first step.

Unifying desktop.el and bookmark.el has more problems:

1. Backward compatibility, i.e. existing desktop files should still load
fine even when newer desktop files will contain bookmark records.

2. Data duplication: the bookmark record contains `position' and
the desktop record has the same info for `point'.  (I suppose
the bookmark record should go to the 8-th element of the desktop data,
i.e. to the `desktop-save-buffer' element).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Juri Linkov]

> Could we add as an extra `buffer-file-name' alist element in the sexp
> of a window-configuration or is that a bad idea? (I was just tring to
> reconstruct a window-configuration after an emacs reboot but quickly
> found out filenames weren't just there.)

I think that information about file names is redundant.

To restore file buffers in windows of the saved window configuration,
you can prepare buffers (open files, call packages that create special
buffers, etc.), keep their buffer objects and use them later during
restoring the saved window configuration.  For instance,

(setq buffer1 (find-file-noselect "file1.txt"))
(setq buffer2 (find-file-noselect "file2.txt"))

(set-window-configuration-from-list
  '(window-configuration
     (frame-cols . 80)
     (frame-lines . 41)
     (window
       (buffer . buffer1)
       (left-col . 0)
       (top-line . 5)
       (total-cols . 86)
       (total-lines . 35)
       ...)
     (window
       (buffer . buffer2)
       (left-col . 0)
       (top-line . 5)
       (total-cols . 86)
       (total-lines . 35)
       ...)))

This is basically what desktop.el does: it restores buffers, and later
it can restore window configurations using restored buffer names.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Ken Hori]

Juri,

My point was that you wound't be able to open a file without
knowing buffer-file-name once emacs gets closed. In particular,
if a window-configuration-sexp doesn't contain such a thing as
buffer-file-name, you wound't be able to reconstruct

> (setq buffer1 (find-file-noselect "<file-path>"))

since <file-path> gets lost upon exit. Of course you can
store <file-path> for each file buffer "somewhere", but I
thought the point of having window-configuration-sexp's is to
save that kind of extra work and provide a canonical way of
restoring frame states.

I was hoping that ideally emacs would hold buffer-file-name's in
the sexp and let the user specify a "buffer-recovery-function" to
recover a frame state as well as buffers, so that, hypothetically,

(restore-window-configuration-from-sexp
  a-window-configuration-sexp 'live-p  #'find-file-noselect)

would restore buffers as well as a window configuration.


On Sun, May 2, 2010 at 1:28 PM, Juri Linkov <juri@jurta.org> wrote:
>> Could we add as an extra `buffer-file-name' alist element in the sexp
>> of a window-configuration or is that a bad idea? (I was just tring to
>> reconstruct a window-configuration after an emacs reboot but quickly
>> found out filenames weren't just there.)
>
> I think that information about file names is redundant.
>
> To restore file buffers in windows of the saved window configuration,
> you can prepare buffers (open files, call packages that create special
> buffers, etc.), keep their buffer objects and use them later during
> restoring the saved window configuration.  For instance,
>
> (setq buffer1 (find-file-noselect "file1.txt"))
> (setq buffer2 (find-file-noselect "file2.txt"))
>
> (set-window-configuration-from-list
>  '(window-configuration
>     (frame-cols . 80)
>     (frame-lines . 41)
>     (window
>       (buffer . buffer1)
>       (left-col . 0)
>       (top-line . 5)
>       (total-cols . 86)
>       (total-lines . 35)
>       ...)
>     (window
>       (buffer . buffer2)
>       (left-col . 0)
>       (top-line . 5)
>       (total-cols . 86)
>       (total-lines . 35)
>       ...)))
>
> This is basically what desktop.el does: it restores buffers, and later
> it can restore window configurations using restored buffer names.
>
> --
> Juri Linkov
> http://www.jurta.org/emacs/
>

Re: Window configurations

[Juri Linkov]

> My point was that you wound't be able to open a file without
> knowing buffer-file-name once emacs gets closed. In particular,
> if a window-configuration-sexp doesn't contain such a thing as
> buffer-file-name, you wound't be able to reconstruct
>
>> (setq buffer1 (find-file-noselect "<file-path>"))
>
> since <file-path> gets lost upon exit. Of course you can
> store <file-path> for each file buffer "somewhere", but I
> thought the point of having window-configuration-sexp's is to
> save that kind of extra work and provide a canonical way of
> restoring frame states.

The point of set-window-configuration-from-sexp is to restore the
configuration of windows, not to duplicate the functionality of desktop.el.

> I was hoping that ideally emacs would hold buffer-file-name's in
> the sexp and let the user specify a "buffer-recovery-function" to
> recover a frame state as well as buffers, so that, hypothetically,
>
> (restore-window-configuration-from-sexp
>   a-window-configuration-sexp 'live-p  #'find-file-noselect)
>
> would restore buffers as well as a window configuration.

It is the purpose of desktop.el to save and restore buffers.
It provides a special "hook" `desktop-save-buffer' where packages
can save their buffer info to be able to restore them later.

If you don't want to use desktop.el, perhaps you could take a look
at bookmark.el.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > The point of set-window-configuration-from-sexp is to restore the
 > configuration of windows, not to duplicate the functionality of desktop.el.

That's true from a theoretical point of view.  It separates concerns in
a clear way and gives clean semantics.  Hence I fully agree with you.

Unfortunately, in personal practice, I'm suffering from a quite similar
problem.  In particular, I display eldoc output on a per-window basis in
a one-line window below the code window (I hate eldoc output in the echo
area, I don't like it in the header line, and I very much hate tooltips.
Ideally, there would be a bottom-line right above the mode-line where I
could put it, but ...).

Now I'm killing such an eldoc-buffer as soon as it is no more shown in
its eldoc-window.  But when (1) a `save-window-excursion' restores the
saved configuration and (2) it has to restore a former eldoc-window that
was deleted within the body of `save-window-excursion', I get the first
buffer from `buffer-list' shown in that window which is downright silly.

I solved my problem by killing such stale eldoc-windows after the
configuration gets restored in a `window-configuration-change-hook'.
This is, however, a slight redisplay pain, in particular with such
niceties as (save-window-excursion (info)) in `info-lookup'.  I maybe
could come up with a satisfactory solution, but deleting and creating
windows in `window-configuration-change-hook' is error-prone :-(

So if we could hook into this in some way, for example by providing a
window parameter that tells `set-window-configuration(-from-sexp)' what
to do if the buffer no longer exists, that might not be a bad idea.

If the buffer had a `buffer-file-name', we could try to regenerate it
automatically from that name.  If the file was deleted in the meantime
(or is remote or hard to find), some warning message could be displayed
in a temporary buffer in the restored window.  Looking up a file via
bookmarks could happen here as well.

If the buffer was not associated with a file, we could try to regenerate
it based on the old name stored in the parameter.  For killed *info* and
*help* buffers probably more information would be required.  All this
would happen independently from desktop.el in the session version and in
the sexp version.

And, as noted above, this idea is not based on clean semantics but on
running into practical issues.

martin

Re: Window configurations

[Juri Linkov]

> But when (1) a `save-window-excursion' restores the saved
> configuration and (2) it has to restore a former eldoc-window that was
> deleted within the body of `save-window-excursion', I get the first
> buffer from `buffer-list' shown in that window which is
> downright silly.

I agree that displaying a random buffer (that happens to be the first
in `buffer-list') is silly.  This problem becomes more evident when
switching window configuration using tabs.

Let's summarize options we have to display when the buffer saved in
a window configuration is gone:

0. Display the first buffer from `buffer-list'.  Yes, this is silly.

1. Add a bookmark record (that may include `buffer-file-name' and other
   additional data from packages via `bookmark-make-record-function')
   to the window parameters in the window-configuration structure.
   After restoring the window configuration, try to regenerate it.

   I think this is a bad idea, because when the user deletes the buffer,
   and after switching to another window configuration this buffer
   automagically comes back, it would be annoying.

2. Delete the buffer's window after restoring the saved window configuration.

   Do you see any problem with doing this in `set-window-configuration'
   instead of `window-configuration-change-hook'?

3. Delete the buffer's window in the saved window configuration
   before restoring it.

   This looks good if it won't break other windows in the same
   window configuration.

4. Display some warning message in a temporary buffer in the
   restored window.

   This is good too.  It keeps the original window configuration unchanged,
   and provides information about the deleted buffers.


-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > 2. Delete the buffer's window after restoring the saved window configuration.
 >
 >    Do you see any problem with doing this in `set-window-configuration'
 >    instead of `window-configuration-change-hook'?

Since window configurations store coordinates it would have to be done
just before the place where `window-configuration-change-hook' is called
in `set-window-configuration'.  So the effect would be roughly the same.
It's not perfect since the windows showing deleted buffers might take up
the entire frame.

 > 3. Delete the buffer's window in the saved window configuration
 >    before restoring it.
 >
 >    This looks good if it won't break other windows in the same
 >    window configuration.

Hardly doable.  Note that we might also have to delete internal windows,
adjust coordinates or fractions ...

 > 4. Display some warning message in a temporary buffer in the
 >    restored window.
 >
 >    This is good too.  It keeps the original window configuration unchanged,
 >    and provides information about the deleted buffers.

Suitable for user created windows.  Not suitable for windows created
automatically.

What I really want is some sort of function `set-window-configuration'
could call whenever it encounters a window with a dead buffer.  As a
fallback it then would try your (2) first and (4) if the window can't be
deleted.

martin

Re: Window configurations

[Juri Linkov]

> What I really want is some sort of function `set-window-configuration'
> could call whenever it encounters a window with a dead buffer.  As a
> fallback it then would try your (2) first and (4) if the window can't be
> deleted.

Yes, a new function would be good.  If it can't delete the window,
then it could display a virtual buffer with the text like
"The buffer `kilroy.el' was here" and a button to restore
the killed buffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Juri Linkov]

> What I really want is some sort of function `set-window-configuration'
> could call whenever it encounters a window with a dead buffer.  As a
> fallback it then would try your (2) first and (4) if the window can't be
> deleted.

Thinking more about this, I believe now this function should be
like `view-mode-exit':

  (view-mode-exit &optional RETURN-TO-ALIST EXIT-ACTION ALL-WIN)

  Exit View mode in various ways, depending on optional arguments.
  RETURN-TO-ALIST, EXIT-ACTION and ALL-WIN determine what to do
  after exit.  EXIT-ACTION is nil or a function that is called with
  current buffer as argument.

  RETURN-TO-ALIST is an alist that, for some of the windows
  displaying the current buffer, maintains information on what to
  do when exiting those windows.  If ALL-WIN is non-nil or the
  variable `view-exits-all-viewing-windows' is non-nil,
  view-mode-exit attempts to restore all windows showing the
  current buffer to their old state.  Otherwise, only the selected
  window is affected (provided it is on RETURN-TO-ALIST).

  Elements of RETURN-TO-ALIST must have the format
    (WINDOW OLD-WINDOW . OLD-BUF-INFO) where

  WINDOW is a window displaying the current buffer and OLD-WINDOW
  is either nil or a window to select after viewing.  OLD-BUF-INFO
  provides information on what to do with WINDOW and may be one of:
  1) nil            Do nothing.
  2) t              Delete WINDOW and, if it is the only window and
                    `view-remove-frame-by-deleting' is non-nil, its
                    frame.
  3) (OLD-BUF START POINT)  Display buffer OLD-BUF with displayed text
                    starting at START and point at POINT in WINDOW.
  4) quit-window    Do `quit-window' in WINDOW.
  5) keep-frame     Like case 2) but do not delete the frame.

  If one of the WINDOW in RETURN-TO-ALIST is the selected window
  and the corresponding OLD-WINDOW is a live window, then select
  OLD-WINDOW.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > Thinking more about this, I believe now this function should be
 > like `view-mode-exit':

I had something like this in mind.  BTW, I have rewritten this code in
the meantime using a window parameter called `quit-restore'.  From a
preliminary description ...

    The `quit-restore' parameter tells how to proceed with a window when
the user "quits" it by invoking `quit-restore-window', see *Note
Displaying Buffers::.  The following non-`nil' values of this parameter
have a special meaning.

`t'
      This means to delete the associated window.  By default, `t' is
      used for a "temporary" window that was obtained by splitting an
      existing window.

`frame'
      This means to delete the associated window's frame.  This value
      indicates that the associated windows was obtained by popping up a
      new frame showing just this window.  If the window is no more
      needed, it should be deleted together with the containing frame.

A list
      This option is useful when the associated window was borrowed to
      temporarily display some buffer and quitting shall "restore" the
      previous contents of the window.  The first three elements of the
      list must specify a buffer, a window start position, and a window
      point.  Quitting the window will then try to display the indicated
      buffer with the given start position and point in that window.

      The fourth element, if non-`nil', must denote a live buffer.  If
      specified, quitting will restore the previous window contents if
      and only if the buffer shown in the window is the buffer named by
      this element.

      The fifth element, if non-`nil', should specify the desired height
      of the window when its buffer is restored.  This value is applied
      if the buffer temporarily shown in the window was in
      `temp-buffer-resize-mode' to restore the original height of the
      window.

... and the description of `quit-restore-window' goes like ...

    The command described next allows to quit the window chosen by
`display-buffer' and restore the previous state without undoing changes
to the window configuration that happend _after_ `display-buffer' was
called.  A more drastic solution is to save the window configuration
before calling `display-buffer' and eventually restoring the saved
configuration, *Note Window Configurations::.  That solution sometimes
has the undesirable side-effect that all changes that happened after
the configuration was saved are undone too.

  -- Command: quit-restore-window &optional window kill
      This command "quits" WINDOW restoring its previous contents if
      possible.  The argument WINDOW must be a live window and defaults
      to the selected one.  This function always returns `nil'.

      According to information stored in WINDOW's `quit-restore' window
      parameter (*note Window Parameters::) this function performs one
      of the following actions.

         * Delete WINDOW and its frame.  This action is useful when
           WINDOW was created on a standalone frame and there are other
           frames left.

         * Delete WINDOW.  This action is usually taken when WINDOW was
           obtained by splitting some existing window.

         * Restore the buffer previously displayed in WINDOW.  This
           action is taken when WINDOW was temporarily reused for
           displaying some other buffer.

         * Make WINDOW display some other buffer.  This action is usually
           taken when the three preceding ones are not applicable.

      If its value was non-`nil', this function resets WINDOW's
      `quit-restore' parameter to `nil'.

      If the optional argument KILL is non-`nil', this means in addition
      kill WINDOW's buffer.  If KILL is `nil', this simply puts WINDOW's
      buffer at the end of the buffer list.  Interactively, KILL is the
      prefix argument.

... where `quit-restore-window' here replaces `quit-window' which has
too obscure semantics for my taste.  And obviously, exiting `view-mode'
calls `quit-restore-window' here too.

However, restoring a window configuration is a more primitive operation
than exiting `view-mode'.  One of the most hairy situation occurs when
you kill a buffer: There's a window of vulnerability when the
`kill-buffer' routine calls `replace_buffer_in_all_windows' and the
latter, for some reason, doesn't do what it has been told, for example,
because a `window-configuration-change-hook' shows the buffer to be
killed in some other window.  Obviously, doing things like that in a
configuration change hook is foolish as in

(get-buffer-create "*foo*")

(defun foo-lish ()
   (let (window-configuration-change-hook)
     (set-window-buffer (frame-first-window) "*foo*")))

(add-hook 'window-configuration-change-hook 'foo-lish)

and now doing (kill-buffer "*foo*").  But I'm not sure whether there are
useful things a `window-configuration-change-hook' could do along these
lines.

martin

Re: Window configurations

[Juri Linkov]

> ... where `quit-restore-window' here replaces `quit-window' which has
> too obscure semantics for my taste.  And obviously, exiting `view-mode'
> calls `quit-restore-window' here too.

Yes, `quit-window' is useless because it doesn't help to avoid the mess
that occurs after killing buffers.  Please look at two examples:

1.

+---------+---------+
|         |         |
| dired 1 | dired 2 |
|         |         |
|         |         |
+---------+---------+

Now view a file in dired 1, select the second window, view another file
in dired 2, select the first window, quit view-mode with `q',
select the second window, quit view-mode with `q':

  `v  C-x o  v  C-x o  q  C-x o  q'

The window configuration is exactly as was before - very good.

Now do the same without using `view-mode' - visit a file in dired 1 with
RET, select the second window, visit another file in dired 2, select the
first window, kill the buffer, select the second window, kill the buffer:

  `RET  C-x o  RET  C-x o  C-x k  C-x o  C-x k'

The window configuration is broken with original buffers exchanged
their windows:

+---------+---------+
|         |         |
| dired 2 | dired 1 |
|         |         |
|         |         |
+---------+---------+

2. Another example - visit the same buffer in two windows, and put point
at different positions of the same buffer.

+---------+---------+
|         |         |
| dired 1 | dired 1 |
|         |         |
|         |         |
+---------+---------+

Now view a file in the first window, and quit: `v q'.
The window configuration is correctly restored
(without using `set-window-configuration') - good.

Now do the same without `view-mode': `RET C-x k'.
Instead of the original buffer, some random buffer is displayed
in this window.


It seems your implementation of `quit-restore-window' will fix this problem,
but I don't see how it will work without a window history as a list?
This list could be saved as a window parameter `window-history' where each
element is like you implemented for the `quit-restore' parameter.

Then every switch-to-buffer could add a `quit-restore' element to the
window history parameter, and every kill-buffer could remove it from the
history stack (and call its function at the same time).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> ... where `quit-restore-window' here replaces `quit-window' which has
 >> too obscure semantics for my taste.  And obviously, exiting `view-mode'
 >> calls `quit-restore-window' here too.
 >
 > Yes, `quit-window' is useless because it doesn't help to avoid the mess
 > that occurs after killing buffers.

You don't mean buffers killed by `quit-window' but by some standalone
`kill-buffer' I suppose?

 > Now do the same without using `view-mode' - visit a file in dired 1 with
 > RET, select the second window, visit another file in dired 2, select the
 > first window, kill the buffer, select the second window, kill the buffer:
 >
 >   `RET  C-x o  RET  C-x o  C-x k  C-x o  C-x k'
 >
 > The window configuration is broken with original buffers exchanged
 > their windows:
 >
 > +---------+---------+
 > |         |         |
 > | dired 2 | dired 1 |
 > |         |         |
 > |         |         |
 > +---------+---------+

The culprit here is the `other-buffer' call when unshowing the buffer.
Practically all occurrences of `other-buffer' in window handling code
are harmful.  Their original purpose was to make sure that the same
buffer isn't displayed twice on a frame I suppose.

 > 2. Another example - visit the same buffer in two windows, and put point
 > at different positions of the same buffer.
 >
 > +---------+---------+
 > |         |         |
 > | dired 1 | dired 1 |
 > |         |         |
 > |         |         |
 > +---------+---------+
 >
 > Now view a file in the first window, and quit: `v q'.
 > The window configuration is correctly restored
 > (without using `set-window-configuration') - good.
 >
 > Now do the same without `view-mode': `RET C-x k'.
 > Instead of the original buffer, some random buffer is displayed
 > in this window.

That's probably the most annoying instance of this.  For some magic
reason Emacs assumes that people never want to simultaneously look at
two distinct portions of the same buffer ;-)

 > It seems your implementation of `quit-restore-window' will fix this problem,
 > but I don't see how it will work without a window history as a list?

It doesn't solve any of these problems yet because `dired-find-file'
uses `switch-to-buffer' and in `switch-to-buffer' I don't record any
information about the dired buffer.  I obviously could do so easily but
we'd have to find a general agreement first.

And, for lack of a history, it works only for the last `display-buffer'
action which is sufficient for view mode purposes (by reverting to the
last buffer displayed before view mode was entered).

 > This list could be saved as a window parameter `window-history' where each
 > element is like you implemented for the `quit-restore' parameter.

Yes.  We have to agree that we pay for the costs of this though.

 > Then every switch-to-buffer could add a `quit-restore' element to the
 > window history parameter,

We'd have to enumerate all actions that would add such an element.

 > and every kill-buffer could remove it from the
 > history stack (and call its function at the same time).

`kill-buffer' would probably scan all live windows' history stacks.

But are we sure that a stack (a deque, rather) is sufficient?

martin

Re: Window configurations

[Juri Linkov]

>>> ... where `quit-restore-window' here replaces `quit-window' which has
>>> too obscure semantics for my taste.  And obviously, exiting `view-mode'
>>> calls `quit-restore-window' here too.
>>
>> Yes, `quit-window' is useless because it doesn't help to avoid the mess
>> that occurs after killing buffers.
>
> You don't mean buffers killed by `quit-window' but by some standalone
> `kill-buffer' I suppose?

I mean `quit-window' with non-nil argument KILL.  When its argument KILL
is nil (when the buffer is buried), the problem is the same.

> The culprit here is the `other-buffer' call when unshowing the buffer.
> Practically all occurrences of `other-buffer' in window handling code
> are harmful.  Their original purpose was to make sure that the same
> buffer isn't displayed twice on a frame I suppose.

Yes, and occurrences of `(car (buffer-list))' are harmful too.

> It doesn't solve any of these problems yet because `dired-find-file'
> uses `switch-to-buffer' and in `switch-to-buffer' I don't record any
> information about the dired buffer.  I obviously could do so easily but
> we'd have to find a general agreement first.
>
> And, for lack of a history, it works only for the last `display-buffer'
> action which is sufficient for view mode purposes (by reverting to the
> last buffer displayed before view mode was entered).

It is sufficient because it stores this information in the buffer-local
variable `view-return-to-alist'.  I don't think a similar variable
would help for other non-view buffers because it is specific to windows,
not to buffers.  So it seems a window parameter is more suitable.

>> Then every switch-to-buffer could add a `quit-restore' element to the
>> window history parameter,
>
> We'd have to enumerate all actions that would add such an element.

I think it should be every action that changes the window's buffer.

>> and every kill-buffer could remove it from the
>> history stack (and call its function at the same time).
>
> `kill-buffer' would probably scan all live windows' history stacks.

No need to scan all windows' history stacks.  During restoring the saved
state from the stack, we could drop elements with killed buffers and
continue popping the stack until we find an element with a live buffer.

> But are we sure that a stack (a deque, rather) is sufficient?

I think this window parameter should be treated like the frame parameter
`buffer-list'.  E.g. `other-buffer' prefers selected frame's buffer list
instead of the global buffer list, etc.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> The culprit here is the `other-buffer' call when unshowing the buffer.
 >> Practically all occurrences of `other-buffer' in window handling code
 >> are harmful.  Their original purpose was to make sure that the same
 >> buffer isn't displayed twice on a frame I suppose.
 >
 > Yes, and occurrences of `(car (buffer-list))' are harmful too.

Obviously.  It just makes it more difficult grepping them.

 > It is sufficient because it stores this information in the buffer-local
 > variable `view-return-to-alist'.  I don't think a similar variable
 > would help for other non-view buffers because it is specific to windows,
 > not to buffers.  So it seems a window parameter is more suitable.

What I meant is this: With view-mode the variable is useful in the sense
that when I exit view-mode I get the last non-view-mode buffer shown in
that window.  For commands like "show me the last meaningful view-mode
buffer when I'm already in view mode" or "show me the last meaningful
non-view-mode buffer when I'm not in view-mode" I need a stack where to
pop that buffer from.

 >>> Then every switch-to-buffer could add a `quit-restore' element to the
 >>> window history parameter,
 >> We'd have to enumerate all actions that would add such an element.
 >
 > I think it should be every action that changes the window's buffer.

And these should all boil down to `set-window-buffer' calls.

 > No need to scan all windows' history stacks.  During restoring the saved
 > state from the stack, we could drop elements with killed buffers and
 > continue popping the stack until we find an element with a live buffer.

OK.  If we put an upper limit on the size of such stacks, stale entries
will get removed automatically after some time.

 > I think this window parameter should be treated like the frame parameter
 > `buffer-list'.  E.g. `other-buffer' prefers selected frame's buffer list
 > instead of the global buffer list, etc.

We'd have to specify the meaning of "prefers" here.

martin

Re: Window configurations

[Juri Linkov]

>> I think this window parameter should be treated like the frame parameter
>> `buffer-list'.  E.g. `other-buffer' prefers selected frame's buffer list
>> instead of the global buffer list, etc.
>
> We'd have to specify the meaning of "prefers" here.

In the functions `buffer-list' and `other-buffer' the buffers in the
selected frame's `buffer-list' come first, followed by the rest of the
buffers from the global value of `buffer-list', and buffers from the
selected frame's parameters `buried-buffer-list' come last.

Doing the same for the window-local parameter `buffer-list',
i.e. when `buffer-list' will return a list composed of

 window-local buffer-list
 frame-local buffer-list
 global buffer-list
 frame-local buried-buffer-list
 window-local buried-buffer-list

then `quit-window' and all occurrences of `other-buffer'
in window handling code should do the right thing like
`view-return-to-alist' does (i.e. to get the right buffer).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > Doing the same for the window-local parameter `buffer-list',
 > i.e. when `buffer-list' will return a list composed of
 >
 >  window-local buffer-list
 >  frame-local buffer-list
 >  global buffer-list
 >  frame-local buried-buffer-list
 >  window-local buried-buffer-list
 >
 > then `quit-window' and all occurrences of `other-buffer'
 > in window handling code should do the right thing like
 > `view-return-to-alist' does (i.e. to get the right buffer).

So I need a window-local buried-buffer-list too.  And obviously no more
stack semantics.

martin

Re: Window configurations

[Juri Linkov]

>> Doing the same for the window-local parameter `buffer-list',
>> i.e. when `buffer-list' will return a list composed of
>>
>>  window-local buffer-list
>>  frame-local buffer-list
>>  global buffer-list
>>  frame-local buried-buffer-list
>>  window-local buried-buffer-list
>>
>> then `quit-window' and all occurrences of `other-buffer'
>> in window handling code should do the right thing like
>> `view-return-to-alist' does (i.e. to get the right buffer).
>
> So I need a window-local buried-buffer-list too.  And obviously no more
> stack semantics.

Do you see a problem with that?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> So I need a window-local buried-buffer-list too.  And obviously no more
 >> stack semantics.
 >
 > Do you see a problem with that?

Not yet.  Just that I wouldn't store this as a window parameter but
right in the window structure.  I have to review `bury-buffer' anyway.
Currently it adds its argument to the buried-buffer-list of the selected
frame even if that buffer never appeared on it.

martin

Re: Window configurations

[martin rudalics]

 > In the functions `buffer-list' and `other-buffer' the buffers in the
 > selected frame's `buffer-list' come first, followed by the rest of the
 > buffers from the global value of `buffer-list', and buffers from the
 > selected frame's parameters `buried-buffer-list' come last.
 >
 > Doing the same for the window-local parameter `buffer-list',
 > i.e. when `buffer-list' will return a list composed of
 >
 >  window-local buffer-list
 >  frame-local buffer-list
 >  global buffer-list
 >  frame-local buried-buffer-list
 >  window-local buried-buffer-list
 >
 > then `quit-window' and all occurrences of `other-buffer'
 > in window handling code should do the right thing like
 > `view-return-to-alist' does (i.e. to get the right buffer).

I've been looking into this now.  `buffer-list' and `other-buffer' are
currently in pretty bad shape so it's occasionally difficult to tell
what they are supposed to do.  Anyway, the three major obstacles to your
approach seem:

(1) All calls to `other-buffer' for determining which buffer to show in
a window have the second argument nil.  So if a buffer is already shown
in another window it's against some unwritten rule to show it in the
window in question again.  If I follow that rule, then working with two
windows showing the same buffer remains just as tedious as it is now.

(2) The length of frame-local buffer-lists is unbound.  For a one-frame
user this already doubles the consing and maintenance overhead of buffer
lists without any gain.  If we add window-local buffer-lists, we'd
double the current overhead once more for one window/one frame users.

(3) For each buffer on the window-local buffer-list I'd have to maintain
its old point and its old window start position as markers.  Otherwise
restoring the buffer would either get me a silly position if the buffer
was modified in the meantime (a rare case probably, but unacceptable
nevertheless) or a useless position like `point' (which would usually
coincide with `window-point' of some other window showing that buffer).
This means that for each buffer we get as many additional markers as
there are live windows in which the buffer was shown (times two).

martin

Re: Window configurations

[Stefan Monnier]

> (1) All calls to `other-buffer' for determining which buffer to show in
> a window have the second argument nil.  So if a buffer is already shown
> in another window it's against some unwritten rule to show it in the
> window in question again.  If I follow that rule, then working with two
> windows showing the same buffer remains just as tedious as it is now.

Yes, the window handling code currently considers that the most likely
thing the user wants is to see a buffer that's not currently shown.
[ I'm not sure if it's careful to distinguish "shown on the current
terminal" from "shown in some other terminal, miles away from here",
which it should. ]
This seems like a good default rule, so if we/you want to not follow
this rule in some cases, we should think about how we can tell which is
the better choice in a given situation.

> (2) The length of frame-local buffer-lists is unbound.  For a one-frame
> user this already doubles the consing and maintenance overhead of buffer
> lists without any gain.  If we add window-local buffer-lists, we'd
> double the current overhead once more for one window/one frame users.

Is this overhead really significant?  Say the list is 100 buffers long,
that's 1 or 2 KB, right?  Isn't this lost in the noise?

> (3) For each buffer on the window-local buffer-list I'd have to maintain
> its old point and its old window start position as markers.  Otherwise
> restoring the buffer would either get me a silly position if the buffer
> was modified in the meantime (a rare case probably, but unacceptable
> nevertheless) or a useless position like `point' (which would usually
> coincide with `window-point' of some other window showing that buffer).
> This means that for each buffer we get as many additional markers as
> there are live windows in which the buffer was shown (times two).

The use of `point' for that has not brought many complaints over the
many years it's been used.  Any reason to think it's a bad choice?


        Stefan "who coded up a hack for doc-view which preserves
                window-specific buffer-positions"

Re: Window configurations

[Lennart Borgman]

On Mon, May 31, 2010 at 8:39 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> The use of `point' for that has not brought many complaints over the
> many years it's been used.  Any reason to think it's a bad choice?

Could that be because people are using winpoint.el instead of
complaining. At least that is what I do.

But I really think Emacs should solve this internally by using
window-point instead of point. winpoint is nice but does not solve the
whole problem (and it may interfere badly with other code for window
configuration, perhaps).

Re: Window configurations

[Juri Linkov]

>> The use of `point' for that has not brought many complaints over the
>> many years it's been used.  Any reason to think it's a bad choice?
>
> Could that be because people are using winpoint.el instead of
> complaining. At least that is what I do.

Yes, it seems people are using various tricks to workaround
this limitation (I prefer a view.el-like trick).

> But I really think Emacs should solve this internally by using
> window-point instead of point. winpoint is nice but does not solve the
> whole problem (and it may interfere badly with other code for window
> configuration, perhaps).

Is winpoint.el too intrusive?  I think we should try storing window point
positions in the window-local buffer list.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> The use of `point' for that has not brought many complaints over the
 >> many years it's been used.  Any reason to think it's a bad choice?
 >
 > Could that be because people are using winpoint.el instead of
 > complaining. At least that is what I do.

And the rest probably uses `pointback-mode' ;-)

martin

Re: Window configurations

[Juri Linkov]

>> (1) All calls to `other-buffer' for determining which buffer to show in
>> a window have the second argument nil.  So if a buffer is already shown
>> in another window it's against some unwritten rule to show it in the
>> window in question again.  If I follow that rule, then working with two
>> windows showing the same buffer remains just as tedious as it is now.
>
> Yes, the window handling code currently considers that the most likely
> thing the user wants is to see a buffer that's not currently shown.
> [ I'm not sure if it's careful to distinguish "shown on the current
> terminal" from "shown in some other terminal, miles away from here",
> which it should. ]
> This seems like a good default rule, so if we/you want to not follow
> this rule in some cases, we should think about how we can tell which is
> the better choice in a given situation.

It's a good default rule for some cases like switching to another
buffer with e.g. `C-x b', for other cases (like killing a buffer
and finding another buffer to show in its place) a better rule
would be to not see if that buffer is currently shown.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Stefan Monnier]

> It's a good default rule for some cases like switching to another
> buffer with e.g. `C-x b', for other cases (like killing a buffer
> and finding another buffer to show in its place) a better rule
> would be to not see if that buffer is currently shown.

Even in the kill-buffer case, it's very common for the "prefer
a non-shown buffer" to be a good/better default.
I think the only case where we might want to overlook the fact that
buffer is already displayed is in cases where we "go back to a previous
state", so we'd need to mark that somehow.


        Stefan

Re: Window configurations

[martin rudalics]

 > Even in the kill-buffer case, it's very common for the "prefer
 > a non-shown buffer" to be a good/better default.
 > I think the only case where we might want to overlook the fact that
 > buffer is already displayed is in cases where we "go back to a previous
 > state", so we'd need to mark that somehow.

As I noted earlier we could easily make this customizable.

martin

Re: Window configurations

[Stefan Monnier]

>> Even in the kill-buffer case, it's very common for the "prefer
>> a non-shown buffer" to be a good/better default.
>> I think the only case where we might want to overlook the fact that
>> buffer is already displayed is in cases where we "go back to a previous
>> state", so we'd need to mark that somehow.
> As I noted earlier we could easily make this customizable.

But it's a cop-out.


        Stefan

Re: Window configurations

[martin rudalics]

 >> (1) All calls to `other-buffer' for determining which buffer to show in
 >> a window have the second argument nil.  So if a buffer is already shown
 >> in another window it's against some unwritten rule to show it in the
 >> window in question again.  If I follow that rule, then working with two
 >> windows showing the same buffer remains just as tedious as it is now.
 >
 > Yes, the window handling code currently considers that the most likely
 > thing the user wants is to see a buffer that's not currently shown.
 > [ I'm not sure if it's careful to distinguish "shown on the current
 > terminal" from "shown in some other terminal, miles away from here",
 > which it should. ]

It's not that careful.

 > This seems like a good default rule, so if we/you want to not follow
 > this rule in some cases,

The case at hand was a scenario earlier posted by Juri as ...

------------------------------------------------------------------------
2. Another example - visit the same buffer in two windows, and put point
at different positions of the same buffer.

+---------+---------+
|         |         |
| dired 1 | dired 1 |
|         |         |
|         |         |
+---------+---------+

Now view a file in the first window, and quit: `v q'.
The window configuration is correctly restored
(without using `set-window-configuration') - good.

Now do the same without `view-mode': `RET C-x k'.
Instead of the original buffer, some random buffer is displayed
in this window.
------------------------------------------------------------------------

... which, together with another scenario, triggered the present
discussion.

 > we should think about how we can tell which is
 > the better choice in a given situation.

We could make this customizable.

 >> (2) The length of frame-local buffer-lists is unbound.  For a one-frame
 >> user this already doubles the consing and maintenance overhead of buffer
 >> lists without any gain.  If we add window-local buffer-lists, we'd
 >> double the current overhead once more for one window/one frame users.
 >
 > Is this overhead really significant?  Say the list is 100 buffers long,
 > that's 1 or 2 KB, right?  Isn't this lost in the noise?

Look at the following stretch from `other-buffer':

   tail = Vbuffer_alist;
   pred = frame_buffer_predicate (frame);

   /* Consider buffers that have been seen in the selected frame
      before other buffers.  */

   tem = frame_buffer_list (frame);
   add_ons = Qnil;
   while (CONSP (tem))
     {
       if (BUFFERP (XCAR (tem)))
	add_ons = Fcons (Fcons (Qnil, XCAR (tem)), add_ons);
       tem = XCDR (tem);
     }
   tail = nconc2 (Fnreverse (add_ons), tail);

This prepends a list of (nil . buffer) conses for every non-buried
buffer on the selected frame (or some specified frame) to the list of
all buffers.  Note that reusing a window in `display-buffer' doesn't
bury the previous buffer.

Now for one-frame Emacs users this means that its consing overhead is
usually always proportional to the number of live buffers.  Given the
fact that `bury-buffer' (and thus `next-buffer') and evaluating the `b'
and `B' interactive arguments all call `other-buffer' this makes me
think that some GC overhead result.

It shouldn't be too hard to fix this.  [`other-buffer' has not been coded
very cleanly, just try evaluating

(other-buffer nil nil 1)

in a _separate_ instance of Emacs.]

Similar problems exist for `buffer-list' and `last-buffer'.

 >> (3) For each buffer on the window-local buffer-list I'd have to maintain
 >> its old point and its old window start position as markers.  Otherwise
 >> restoring the buffer would either get me a silly position if the buffer
 >> was modified in the meantime (a rare case probably, but unacceptable
 >> nevertheless) or a useless position like `point' (which would usually
 >> coincide with `window-point' of some other window showing that buffer).
 >> This means that for each buffer we get as many additional markers as
 >> there are live windows in which the buffer was shown (times two).
 >
 > The use of `point' for that has not brought many complaints over the
 > many years it's been used.  Any reason to think it's a bad choice?

It's a bad choice if you show a buffer in two windows W1 and W2,
temporaily show another buffer in W2, select W1, and switch back to the
original buffer in W2.  The whole "point" of showing the same buffer in
two windows is lost.  Note that if the temporarily displayed buffer is
in view or help mode you don't have this problem since `view-mode-exit'
handles the case.

martin

Re: Window configurations

[Stefan Monnier]

> +---------+---------+
> |         |         |
> | dired 1 | dired 1 |
> |         |         |
> |         |         |
> +---------+---------+

> Now view a file in the first window, and quit: `v q'.
> The window configuration is correctly restored
> (without using `set-window-configuration') - good.

> Now do the same without `view-mode': `RET C-x k'.
> Instead of the original buffer, some random buffer is displayed
> in this window.

So you're saying that C-x k's heuristic should be to try and restore the
previous window state?  I guess that could make sense, yes.

>> we should think about how we can tell which is
>> the better choice in a given situation.
> We could make this customizable.

No, we want instead to try and think in each case which behavior would
make more sense.  And maybe you're right that in "all" cases, trying to
restore the previous window state is TRT, rather than choosing some
non-shown buffer.


        Stefan

Re: Window configurations

[Lennart Borgman]

On Tue, Jun 1, 2010 at 3:08 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> No, we want instead to try and think in each case which behavior would
> make more sense.  And maybe you're right that in "all" cases, trying to
> restore the previous window state is TRT, rather than choosing some
> non-shown buffer.


Maybe something like this:

1) Save window config when running a command that changes window
config (and not does it as a user request).

2) Keep this around until either:

  - It is used.
  - A user request changes the window configuration.
  - 1 is applied again. (No stack.)

Re: Window configurations

[martin rudalics]

 > So you're saying that C-x k's heuristic should be to try and restore the
 > previous window state?  I guess that could make sense, yes.

I was saying that _if_ we want to fix the behavior to handle Juri's
case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or
something the like).

 >> We could make this customizable.
 >
 > No, we want instead to try and think in each case which behavior would
 > make more sense.

We probably all agree that a window should not show a buffer visible
elsewhere when its buffer is killed or buried and its window-local
buffer list contains no other buffer.  Maybe we also agree that we
should show such a buffer when the window was "stolen" by a construct
like `with-temp-buffer'.

However, I'm afraid that there's no good approximation for the remaining
cases.  There are people used to edit large buffers by showing related
sections in two or more windows.  And there are people who don't do
that.  [The latter group should not be affected much by the new behavior
since we expect them to never show the same buffer twice at the same
time.  But I'm not sure whether the use of `split-window' runs counter
to such an assumption.]

 > And maybe you're right that in "all" cases, trying to
 > restore the previous window state is TRT, rather than choosing some
 > non-shown buffer.

I cannot be right since I never proposed that ;-)

martin

Re: Window configurations

[Stefan Monnier]

>>> We could make this customizable.
>> No, we want instead to try and think in each case which behavior would
>> make more sense.
> We probably all agree that a window should not show a buffer visible
> elsewhere when its buffer is killed or buried and its window-local
> buffer list contains no other buffer.

Makes sense, yes/

> Maybe we also agree that we should show such a buffer when the window
> was "stolen" by a construct like `with-temp-buffer'.

with-temp-buffer is probably a poor example since it doesn't affect
windows, but if you mean something like with-output-to-temp-buffer, then
yes, we probably all agree.

> However, I'm afraid that there's no good approximation for the remaining
> cases.  There are people used to edit large buffers by showing related
> sections in two or more windows.  And there are people who don't do
> that.  [The latter group should not be affected much by the new behavior
> since we expect them to never show the same buffer twice at the same
> time.  But I'm not sure whether the use of `split-window' runs counter
> to such an assumption.]

We can solve each case as it shows up.  E.g. for the split-window case
(i.e. buffer shown in 2 windows only because that's what split-window
does, but the user then immediately switches to some other buffer), we
should try and find a way to capture the user's intention.
E.g. "immediately" after split-window, any set-window-buffer will not
push the current buffer on the buffer-list of that window.

>> And maybe you're right that in "all" cases, trying to restore the
>> previous window state is TRT, rather than choosing some
>> non-shown buffer.
> I cannot be right since I never proposed that ;-)

I thought you suggested to have a config var to decide whether to use
the current heuristic, or to use another heuristic which prefers buffers
from the window's buffer-list regardless of whether they are
shown elsewhere.  Isn't that what you meant in:

   >> we should think about how we can tell which is
   >> the better choice in a given situation.
   > We could make this customizable.


-- Stefan

Re: Window configurations

[martin rudalics]

 >> Maybe we also agree that we should show such a buffer when the window
 >> was "stolen" by a construct like `with-temp-buffer'.
 >
 > with-temp-buffer is probably a poor example since it doesn't affect
 > windows, but if you mean something like with-output-to-temp-buffer,

That's what I meant.

 > then
 > yes, we probably all agree.

Tracing `with-output-to-temp-buffer' is a pain.  I suppose
temp_output_buffer_show needs some reserved value for the second
argument of `display-buffer' so the latter can set up the window-local
buffer list appropriately.

 > We can solve each case as it shows up.  E.g. for the split-window case
 > (i.e. buffer shown in 2 windows only because that's what split-window
 > does, but the user then immediately switches to some other buffer), we
 > should try and find a way to capture the user's intention.

That's precisely the case I had in mind.  I have no idea how and why
people use `split-window'.  Hardly always to show the same buffer twice.
But I don't even know how I use it myself.

 > E.g. "immediately" after split-window, any set-window-buffer will not
 > push the current buffer on the buffer-list of that window.

Aren't there too many ways to make this `set-window-buffer' happen?  One
of the simplest is `next-buffer' which does `bury-buffer' for the old
buffer so it won't create any problems.  But what if the user decides to
consult some buffer switching application that pops up a window with
suggestions?

 > I thought you suggested to have a config var to decide whether to use
 > the current heuristic, or to use another heuristic which prefers buffers
 > from the window's buffer-list regardless of whether they are
 > shown elsewhere.  Isn't that what you meant in:
 >
 >    >> we should think about how we can tell which is
 >    >> the better choice in a given situation.
 >    > We could make this customizable.

Not really.  I want to avoid that changing the established behavior
causes people who do not care anyway ask for getting the old behavior
back.  If we make this customizable we can concentrate on the criticism
of people who really do care.

martin

Re: Window configurations

[Stefan Monnier]

>> then yes, we probably all agree.

> Tracing `with-output-to-temp-buffer' is a pain.  I suppose
> temp_output_buffer_show needs some reserved value for the second
> argument of `display-buffer' so the latter can set up the window-local
> buffer list appropriately.

I don't want to link with-output-to-temp-buffer and display-buffer.
I.e. if it requires something special from display-buffer, then that
extra flexibility will have to be added to display-buffer, but not in
a "reserved value" kind of way.

>> E.g. "immediately" after split-window, any set-window-buffer will not
>> push the current buffer on the buffer-list of that window.
> Aren't there too many ways to make this `set-window-buffer' happen?

Maybe.  I think we won't know before we try it.

>> > We could make this customizable.
> Not really.  I want to avoid that changing the established behavior
> causes people who do not care anyway ask for getting the old behavior
> back.  If we make this customizable we can concentrate on the criticism
> of people who really do care.

I'd rather deal with the disgruntled than add a customization variable.


        Stefan

Re: Window configurations

[martin rudalics]

 > I don't want to link with-output-to-temp-buffer and display-buffer.
 > I.e. if it requires something special from display-buffer, then that
 > extra flexibility will have to be added to display-buffer, but not in
 > a "reserved value" kind of way.

If you eventually want to replace `switch-to-buffer' by `pop-to-buffer'
it becomes important to distinguish calls to show a specific buffer from
calls for showing unspecified, temporary buffers.  Otherwise, you can't
tell apart the explicit placing of buffers in windows from merely
accidental ones that happened just because some window had the right
size at the right moment.

 > I'd rather deal with the disgruntled than add a customization variable.

I'll take your word for that.

martin

Re: Window configurations

[Juri Linkov]

>> So you're saying that C-x k's heuristic should be to try and restore
>> the previous window state?  I guess that could make sense, yes.
>
> I was saying that _if_ we want to fix the behavior to handle Juri's
> case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or
> something the like).

I think changing the argument VISIBLE_OK won't help.  The existing
calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
current behavior of `other-buffer' that prefers not visible buffers
to visible buffers (when the window-local buffer-list is empty).

>>> We could make this customizable.
>>
>> No, we want instead to try and think in each case which behavior would
>> make more sense.
>
> We probably all agree that a window should not show a buffer visible
> elsewhere when its buffer is killed or buried and its window-local
> buffer list contains no other buffer.

Yes, without making this customizable, a simple rule could be to get
next buffers from the window-local buffer-list when it is non-empty.

> However, I'm afraid that there's no good approximation for the remaining
> cases.  There are people used to edit large buffers by showing related
> sections in two or more windows.  And there are people who don't do
> that.  [The latter group should not be affected much by the new behavior
> since we expect them to never show the same buffer twice at the same
> time.  But I'm not sure whether the use of `split-window' runs counter
> to such an assumption.]

I see no problem if we will push the current buffer to the window-local
buffer-list in the same places in code where currently the buffer is
pushed to the frame-local buffer-list (and buried-buffer-list).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > I think changing the argument VISIBLE_OK won't help.  The existing
 > calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
 > current behavior of `other-buffer' that prefers not visible buffers
 > to visible buffers (when the window-local buffer-list is empty).

You mean that when the window-local buffer-list is not empty these calls
should be allowed to choose a visible buffer?  What if an application
wants to specify for a specific call that `other-buffer' does not return
a visible buffer?

 > I see no problem if we will push the current buffer to the window-local
 > buffer-list in the same places in code where currently the buffer is
 > pushed to the frame-local buffer-list (and buried-buffer-list).

We'd change the behavior for people used to see the same buffer in two
windows simultaneously only for the short period when they've split a
window and have not yet shown the wanted buffer in it.

martin

Re: Window configurations

[Juri Linkov]

>> I think changing the argument VISIBLE_OK won't help.  The existing
>> calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
>> current behavior of `other-buffer' that prefers not visible buffers
>> to visible buffers (when the window-local buffer-list is empty).
>
> You mean that when the window-local buffer-list is not empty these calls
> should be allowed to choose a visible buffer?  What if an application
> wants to specify for a specific call that `other-buffer' does not return
> a visible buffer?

Then `other-buffer' is too low-level to implement this.
Maybe `kill-buffer' and `bury-buffer' are more suitable places.

>> I see no problem if we will push the current buffer to the window-local
>> buffer-list in the same places in code where currently the buffer is
>> pushed to the frame-local buffer-list (and buried-buffer-list).
>
> We'd change the behavior for people used to see the same buffer in two
> windows simultaneously only for the short period when they've split a
> window and have not yet shown the wanted buffer in it.

I don't see a problem with `split-window': after splitting, the second
window's buffer-list is empty, thus it adheres to the current behavior.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >>> I think changing the argument VISIBLE_OK won't help.  The existing
 >>> calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
 >>> current behavior of `other-buffer' that prefers not visible buffers
 >>> to visible buffers (when the window-local buffer-list is empty).
 >> You mean that when the window-local buffer-list is not empty these calls
 >> should be allowed to choose a visible buffer?  What if an application
 >> wants to specify for a specific call that `other-buffer' does not return
 >> a visible buffer?
 >
 > Then `other-buffer' is too low-level to implement this.
 > Maybe `kill-buffer' and `bury-buffer' are more suitable places.

We could use a 'this-window-only value for the VISIBLE_OK argument.

 > I don't see a problem with `split-window': after splitting, the second
 > window's buffer-list is empty, thus it adheres to the current behavior.

I meant after splitting _and_ selecting the new window in order to
decide which buffer to display in it.  I suppose we always want to
update the window-local buffer list after selecting a window with
NORECORD nil?

martin

Re: Window configurations

[Juri Linkov]

> I meant after splitting _and_ selecting the new window in order to
> decide which buffer to display in it.  I suppose we always want to
> update the window-local buffer list after selecting a window with
> NORECORD nil?

I think the window-local buffer list should be updated in all places
where the frame-local buffer list is currently updated.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >>> So you're saying that C-x k's heuristic should be to try and restore
 >>> the previous window state?  I guess that could make sense, yes.
 >> I was saying that _if_ we want to fix the behavior to handle Juri's
 >> case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or
 >> something the like).
 >
 > I think changing the argument VISIBLE_OK won't help.  The existing
 > calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
 > current behavior of `other-buffer' that prefers not visible buffers
 > to visible buffers (when the window-local buffer-list is empty).

Sorry, I don't get you here.  Reconsider your earlier example:

------------------------------------------------------------------------
2. Another example - visit the same buffer in two windows, and put point
at different positions of the same buffer.

+---------+---------+
|         |         |
| dired 1 | dired 1 |
|         |         |
|         |         |
+---------+---------+

Now view a file in the first window, and quit: `v q'.
The window configuration is correctly restored
(without using `set-window-configuration') - good.

Now do the same without `view-mode': `RET C-x k'.
Instead of the original buffer, some random buffer is displayed
in this window.
------------------------------------------------------------------------

Doing C-x k currently winds up calling

replace_buffer_in_all_windows (buffer);

which calls

Fother_buffer (w->buffer, Qnil, w->frame)

so a visible buffer will not be put into that window.

martin

Re: Window configurations

[Juri Linkov]

> Doing C-x k currently winds up calling
>
> replace_buffer_in_all_windows (buffer);
>
> which calls
>
> Fother_buffer (w->buffer, Qnil, w->frame)
>
> so a visible buffer will not be put into that window.

Right.  But it should put a visible buffer into that window,
if the window-local buffer-list is non-empty and that buffer
happens to be at the top of the window-local buffer-list.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> Doing C-x k currently winds up calling
 >>
 >> replace_buffer_in_all_windows (buffer);
 >>
 >> which calls
 >>
 >> Fother_buffer (w->buffer, Qnil, w->frame)
 >>
 >> so a visible buffer will not be put into that window.
 >
 > Right.  But it should put a visible buffer into that window,
 > if the window-local buffer-list is non-empty and that buffer
 > happens to be at the top of the window-local buffer-list.

So we have to decide

(1) wherever this "But it should put ..." shall be done (in
     `bury-buffer', `quit-window', ...), and

(2) whether a window-local buffer-list may contain something else but
     entries associated with buffers (as your text somehow insinuates).

martin

Re: Window configurations

[Juri Linkov]

> So we have to decide
>
> (1) wherever this "But it should put ..." shall be done (in
>     `bury-buffer', `quit-window', ...), and

I suppose this should be done in all places that currently modify
the buffer-list.

> (2) whether a window-local buffer-list may contain something else but
>     entries associated with buffers (as your text somehow insinuates).

Yes, elements of a window-local buffer-list should also contain
window-start and window-point.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> So we have to decide
 >>
 >> (1) wherever this "But it should put ..." shall be done (in
 >>     `bury-buffer', `quit-window', ...), and
 >
 > I suppose this should be done in all places that currently modify
 > the buffer-list.

`select-window' does modify the buffer list but there we probably don't
care.  Anyway, what I need to know is how to deal with all the
`other-buffer' calls in general.  For example, how do we determine the
prompt for `read-buffer-to-switch'?  This is called by
`switch-to-buffer' but also by `switch-to-buffer-other-window' and
`switch-to-buffer-other-frame' where we don't know the target window in
advance.  And we certainly don't want to prompt with a visible buffer
there.

 >> (2) whether a window-local buffer-list may contain something else but
 >>     entries associated with buffers (as your text somehow insinuates).
 >
 > Yes, elements of a window-local buffer-list should also contain
 > window-start and window-point.

In my `quit-restore-window' parameter I currently store whether to the
kill the window and which window to select instead.  These are not very
compatible with buffer lists but I do need them in order to keep up the
current behavior of quitting a help buffer or view mode.  Mixing these
into window local buffer list is not very nice.

martin

Re: Window configurations

[Juri Linkov]

> Anyway, what I need to know is how to deal with all the `other-buffer'
> calls in general.  For example, how do we determine the prompt for
> `read-buffer-to-switch'?  This is called by `switch-to-buffer' but
> also by `switch-to-buffer-other-window' and `switch-to-buffer-other-frame'
> where we don't know the target window in advance.  And we certainly
> don't want to prompt with a visible buffer there.

If we don't know the target window in advance, then we can't use
the window-local buffer-list for `read-buffer-to-switch'.

> In my `quit-restore-window' parameter I currently store whether to the
> kill the window and which window to select instead.  These are not very
> compatible with buffer lists but I do need them in order to keep up the
> current behavior of quitting a help buffer or view mode.  Mixing these
> into window local buffer list is not very nice.

This means that you need to store more information for the first
element of the window-local buffer-list, i.e. when popping the
stack of buffers reaches the first element, it should know what to do
after popping the last element: whether to kill the window and
which window to select instead.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > If we don't know the target window in advance, then we can't use
 > the window-local buffer-list for `read-buffer-to-switch'.

In `switch-to-buffer' we usually know the target window.  In
`switch-to-buffer-other-window' we don't.  How distinguish the two?

But I'm afraid that the idea of handling window local buffer lists just
like the other buffer lists is flawed anyway.  For example, when I
display a buffer without selecting the window as in
`with-output-to-temp-buffer' I do want to update the window local buffer
list.  When I do `bury-buffer' and the buffer is not displayed in the
selected but maybe some other window the buffer will get buried in the
selected window and remains the first buffer in the other window.  Both
make hardly sense either (and are flawed for frame local buffer lists as
well).

I suppose that for the moment I'll abandon the idea of window local
buffer lists and return to them after I have solved some other issues.

 > This means that you need to store more information for the first
 > element of the window-local buffer-list, i.e. when popping the
 > stack of buffers reaches the first element, it should know what to do
 > after popping the last element: whether to kill the window and
 > which window to select instead.

The problem is that the information contained there might be already
stale (the user might have done a lot of things in between).  For help
windows it makes sense to check whether the window still displays the
help buffer and only if it does I proceed according to the information
stored in the window parameter.  For arbitrary buffers in non-dedicated
windows I might just violate the principle of least surprise.

martin

Re: Window configurations

[Juri Linkov]

> (and are flawed for frame local buffer lists as well).

If frame-local buffer-lists are flawed, they should be fixed.
But I think window-local buffer-lists should be modelled after
frame-local buffer-lists.  A frame-local buffer-list is a frame
parameter, so a window-local buffer-list could be a window parameter,
with more information associated with every element (window-start,
window-point, quit-restore function).

> I suppose that for the moment I'll abandon the idea of window local
> buffer lists and return to them after I have solved some other issues.

You will need window-local buffer-lists anyway to correctly restore
previous places when quitting the window.  IOW, instead of
`quit-restore-window' parameter (that saves only 1 previous place),
you can add a window parameter `buffer-list' (and use it to restore
previous places when quitting) that later could combine its values
with frame-local `buffer-list' and global `buffer-list' for the
function `(buffer-list)'.

> The problem is that the information contained there might be already
> stale (the user might have done a lot of things in between).  For help
> windows it makes sense to check whether the window still displays the
> help buffer and only if it does I proceed according to the information
> stored in the window parameter.  For arbitrary buffers in non-dedicated
> windows I might just violate the principle of least surprise.

I see no such problems for `view-return-to-alist', so maybe it won't
a problem for other buffers too.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > If frame-local buffer-lists are flawed, they should be fixed.
 > But I think window-local buffer-lists should be modelled after
 > frame-local buffer-lists.  A frame-local buffer-list is a frame
 > parameter,

... implemented within the frame structure ...

 > so a window-local buffer-list could be a window parameter,
 > with more information associated with every element (window-start,
 > window-point, quit-restore function).
 >
 >> I suppose that for the moment I'll abandon the idea of window local
 >> buffer lists and return to them after I have solved some other issues.
 >
 > You will need window-local buffer-lists anyway to correctly restore
 > previous places when quitting the window.  IOW, instead of
 > `quit-restore-window' parameter (that saves only 1 previous place),
 > you can add a window parameter `buffer-list' (and use it to restore
 > previous places when quitting) that later could combine its values
 > with frame-local `buffer-list' and global `buffer-list' for the
 > function `(buffer-list)'.

Yes.  But my `quit-restore-window' parameter was a very simple start.
It doesn't use markers and doesn't do much when a window's buffer no
longer equals that specified in the parameter.  OTOH, `view-mode' has
other pitfalls like the need for copying the parameter when splitting
the window.

 >> The problem is that the information contained there might be already
 >> stale (the user might have done a lot of things in between).  For help
 >> windows it makes sense to check whether the window still displays the
 >> help buffer and only if it does I proceed according to the information
 >> stored in the window parameter.  For arbitrary buffers in non-dedicated
 >> windows I might just violate the principle of least surprise.
 >
 > I see no such problems for `view-return-to-alist', so maybe it won't
 > a problem for other buffers too.

It does not have problems because you do it via `View-quit', hence the
window is probably still the same window showing the same buffer.  If
you switch to another buffer in an earlier popped up help window, then
having a later `unbury-buffer' delete that window might be surprising.

martin

Re: Window configurations

[Juri Linkov]

>> I see no such problems for `view-return-to-alist', so maybe it won't
>> a problem for other buffers too.
>
> It does not have problems because you do it via `View-quit', hence the
> window is probably still the same window showing the same buffer.  If
> you switch to another buffer in an earlier popped up help window, then
> having a later `unbury-buffer' delete that window might be surprising.

I'm not sure this will be surprising because it will delete the window
when the Help buffer is displayed in it, not with some other buffer.
So when I see the Help buffer and type `q', I expect that it will delete
that window.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Lennart Borgman]

On Thu, Jun 17, 2010 at 10:38 PM, Juri Linkov <juri@jurta.org> wrote:
>>> I see no such problems for `view-return-to-alist', so maybe it won't
>>> a problem for other buffers too.
>>
>> It does not have problems because you do it via `View-quit', hence the
>> window is probably still the same window showing the same buffer.  If
>> you switch to another buffer in an earlier popped up help window, then
>> having a later `unbury-buffer' delete that window might be surprising.
>
> I'm not sure this will be surprising because it will delete the window
> when the Help buffer is displayed in it, not with some other buffer.
> So when I see the Help buffer and type `q', I expect that it will delete
> that window.

Yes, if helped opened it.

But not if help was just displayed in that window. Then I expect q to
remove help and show what was there before.

I simply expect q to restore the state if it is possible.


However on thing that has disturbed me is that for example window
configurations are restored after I have made changes to the temporary
window configuration. That does not seem useful (except in the case of
debugging which is very different).

Re: Window configurations

[martin rudalics]

 >> It does not have problems because you do it via `View-quit', hence the
 >> window is probably still the same window showing the same buffer.  If
 >> you switch to another buffer in an earlier popped up help window, then
 >> having a later `unbury-buffer' delete that window might be surprising.
 >
 > I'm not sure this will be surprising because it will delete the window
 > when the Help buffer is displayed in it, not with some other buffer.
 > So when I see the Help buffer and type `q', I expect that it will delete
 > that window.

My description was unclear.  I meant:

(1) Pop up the help window.

(2) In that window display some other buffer.

(3) Kill that other buffer.

What Emacs now shall do with the window is unclear.  If it does delete
the window and step (3) happens some time after (1) the effect will be
strange because the user already has forgotten about (1).  If it does
not delete the window the case where my step (3) is rewritten as

(3') Switch back to the help buffer.

will not delete the window.

I solve this problem currently by checking whether the buffer in (3) is
the buffer displayed by (1).  But this doesn't solve the problem when
(2) and (3) appear as

(2") Reuse the window to display info.

(3") Quit info.

which likely should delete the window.  [Note that making the help
window weakly dedicated in step (1) will currently have (2") fail.]

martin

Re: Window configurations

[Juri Linkov]

> My description was unclear.  I meant:
>
> (1) Pop up the help window.
>
> (2) In that window display some other buffer.
>
> (3) Kill that other buffer.
>
> What Emacs now shall do with the window is unclear.

Of course, it should switch back to the help buffer
without deleting the window.

> (2") Reuse the window to display info.
>
> (3") Quit info.
>
> which likely should delete the window.

3" should not delete the window.

Everything should work exactly as it already works in the simplest case:

(0) Run `emacs -Q'.

(1) Pop up the help window. `C-h f car RET C-x o'

(2) Reuse the window to display info.  `C-h i'

(3) In that window display some other buffer.  `C-h C-t'

(4) Kill that other buffer.  `C-x k RET'
    The previous buffer "*info*" is displayed in this window.

(5) Quit info.  `q'
    The previous buffer "*Help*" is displayed in this window.

(6) Type `q'
    The window is deleted.

IOW, we should not invent a new behavior, just fix some cases
(that I mentioned earlier where selecting another windows messes up
the global buffer list and thus detaches the buffer from its original
window).  I believe that using a window parameter `buffer-list'
will help to fix this.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> My description was unclear.  I meant:
 >>
 >> (1) Pop up the help window.
 >>
 >> (2) In that window display some other buffer.
 >>
 >> (3) Kill that other buffer.
 >>
 >> What Emacs now shall do with the window is unclear.
 >
 > Of course, it should switch back to the help buffer
 > without deleting the window.

I said that (3) would happen after some time.  Meanwhile the help buffer
could have been popped up a number of times, with completely different
contents, have been killed a number of times ...

martin

Re: Window configurations

[Juri Linkov]

>>> My description was unclear.  I meant:
>>>
>>> (1) Pop up the help window.
>>>
>>> (2) In that window display some other buffer.
>>>
>>> (3) Kill that other buffer.
>>>
>>> What Emacs now shall do with the window is unclear.
>>
>> Of course, it should switch back to the help buffer
>> without deleting the window.
>
> I said that (3) would happen after some time.  Meanwhile the help buffer
> could have been popped up a number of times, with completely different
> contents, have been killed a number of times ...

The best way to observe possible problems is to implement
a simple prototype with a window parameter `buffer-list',
and see how well it works ;-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

> The best way to observe possible problems is to implement
> a simple prototype with a window parameter `buffer-list',
> and see how well it works ;-)

I'm too silly dodging this :-(

martin

Re: Window configurations

[Juri Linkov]

>> The best way to observe possible problems is to implement
>> a simple prototype with a window parameter `buffer-list',
>> and see how well it works ;-)
>
> I'm too silly dodging this :-(

And I'm no less silly doing that  ;-)
I believe by trial-and-error we could
find an optimal implementation.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

> I believe by trial-and-error we could
> find an optimal implementation.

If you take care of the trials I'll do the errors ;-)

martin

Re: Window configurations

[Juri Linkov]

> just try evaluating
>
> (other-buffer nil nil 1)

The docstring of `other-buffer' contains this line:

  If BUFFER is omitted or nil, some interesting buffer is returned.

We could add a similar line:

  If FRAME is 1, something interesting happens.

:-)

> Similar problems exist for `buffer-list' and `last-buffer'.

I don't see the same problem in `buffer-list' because it has
guards `FRAMEP (frame)' and `CHECK_FRAME (frame)'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> Similar problems exist for `buffer-list' and `last-buffer'.
 >
 > I don't see the same problem in `buffer-list' because it has
 > guards `FRAMEP (frame)' and `CHECK_FRAME (frame)'.

Try evaluating

(let ((list (list "*scratch*")))
   (set-frame-parameter nil 'buffer-list (setcdr list list))
   (buffer-list (selected-frame)))

;-)

martin

Re: Window configurations

[Juri Linkov]

>>> Similar problems exist for `buffer-list' and `last-buffer'.
>>
>> I don't see the same problem in `buffer-list' because it has
>> guards `FRAMEP (frame)' and `CHECK_FRAME (frame)'.
>
> Try evaluating
>
> (let ((list (list "*scratch*")))
>   (set-frame-parameter nil 'buffer-list (setcdr list list))
>   (buffer-list (selected-frame)))

This is unfair ;-) You can break almost everything with a cyclic list.

However, I'd like to fix the invalid frame case for
`(other-buffer nil nil 1)' with:

=== modified file 'src/buffer.c'
--- src/buffer.c	2010-05-27 23:30:11 +0000
+++ src/buffer.c	2010-06-02 19:49:04 +0000
@@ -1299,6 +1299,7 @@ (at your option) any later version.
 
   if (NILP (frame))
     frame = selected_frame;
+  CHECK_FRAME (frame);
 
   tail = Vbuffer_alist;
   pred = frame_buffer_predicate (frame);

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> (let ((list (list "*scratch*")))
 >>   (set-frame-parameter nil 'buffer-list (setcdr list list))
 >>   (buffer-list (selected-frame)))
 >
 > This is unfair ;-) You can break almost everything with a cyclic list.

But usually you can quit via C-g.  This case has a special history: Once
upon a time Vbuffer_alist "used to be a variable, but is no longer, to
prevent lossage due to user rplac'ing this alist or its elements".  Then
eventually Richard decided to "not use Frassq, Fmemq or Fdelq since
their loops allow quitting.  Write a special loop by hand." which was
still OK because Vbuffer_alist was no longer accessible from Elisp.
Next we got frame local buffer lists and finally someone decided to
allow setting a frame's buffer list from Elisp ...

I think two things have to be done here: Remove the special constructs
that don't allow quitting.  They are hardly useful today.  Moreover,
there are routines operating on buffer lists that _do allow quitting_
like unrecord_buffer so the original motivation is moot anyway (unless
we want unrecord_buffer use a construct like record_buffer).

In addition we should disallow changing a frame's buffer and buried
buffer lists by setting the corresponding frame's parameter.  I think
this was part of an attempt to make each and every frame related object
part of a frame's parameters.  But an application should not be allowed
to alter the history of buffers shown on a particular frame.  Let's
leave such activities to politicians - that's what they get paid for.

 > However, I'd like to fix the invalid frame case for
 > `(other-buffer nil nil 1)' with:
[...]

Elementary.

martin

Re: Window configurations

[Stefan Monnier]

> eventually Richard decided to "not use Frassq, Fmemq or Fdelq since
> their loops allow quitting.  Write a special loop by hand." which was

What was the problem with quitting?

> part of a frame's parameters.  But an application should not be allowed
> to alter the history of buffers shown on a particular frame.

Why not?


        Stefan

Re: Window configurations

[martin rudalics]

 >> eventually Richard decided to "not use Frassq, Fmemq or Fdelq since
 >> their loops allow quitting.  Write a special loop by hand." which was
 >
 > What was the problem with quitting?

Probably that Vbuffer_list gets corrupted when the user triggers a quit
before the Fdelq gets executed.  In that case a buffer might get dropped
from the buffer list and not be reinserted as first element.

I don't know whether this might happen at all and what kind of
consequences this could have.  The fact that Funrecord_buffer uses Fdelq
without complaints for years seems to indicate that there's no problem.

 >> part of a frame's parameters.  But an application should not be allowed
 >> to alter the history of buffers shown on a particular frame.
 >
 > Why not?

Why should it lie?  Histories should not be altered at will.

But this is a minor issue.  Hardly anyone knows that a frame's buried
buffer list can be altered, and which application would want to change
it anyway?  It's only some wasted lines in the manual (just like those
for a frame's buffer-predicate).

martin

Re: Window configurations

[Stefan Monnier]

>>> part of a frame's parameters.  But an application should not be allowed
>>> to alter the history of buffers shown on a particular frame.
>> Why not?
> Why should it lie?  Histories should not be altered at will.

This list is not a "sworn statement about history".  It's just
a data-structure where we record some state so as to help some heuristic
make decisions.  Modifying it won't get us trapped in a time warp.

> But this is a minor issue.  Hardly anyone knows that a frame's buried
> buffer list can be altered, and which application would want to change
> it anyway?  It's only some wasted lines in the manual (just like those
> for a frame's buffer-predicate).

I don't have much opinion about whether it's worth mentioning in the
manual, but I really can't think of any reason why we should
prevent modification.


        Stefan

Re: Window configurations

[martin rudalics]

 > This list is not a "sworn statement about history".  It's just
 > a data-structure where we record some state so as to help some heuristic
 > make decisions.  Modifying it won't get us trapped in a time warp.

Surely not.  The list isn't very useful anyway after a longer window
excursion.

 > I don't have much opinion about whether it's worth mentioning in the
 > manual, but I really can't think of any reason why we should
 > prevent modification.

Maybe Juri has an argument why modifying it _is_ useful.

martin

Re: Window configurations

[Juri Linkov]

> Maybe Juri has an argument why modifying it _is_ useful.

No, you have to prove why modifying it _is_ illegal ;-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> Maybe Juri has an argument why modifying it _is_ useful.
 >
 > No, you have to prove why modifying it _is_ illegal ;-)

You know that I can't ;-)

martin

Re: Window configurations

[Richard Stallman]

    > eventually Richard decided to "not use Frassq, Fmemq or Fdelq since
    > their loops allow quitting.  Write a special loop by hand." which was

    What was the problem with quitting?

If it is a matter of deleting a window, it is a bug to quit anywhere
in the middle of that.  It has to be either done completely or not
done at all.  Therefore it must not use functions that can quit.
Or else it has to inhibit quitting some other way.

Re: Window configurations

[martin rudalics]

 >     What was the problem with quitting?
 >
 > If it is a matter of deleting a window, it is a bug to quit anywhere
 > in the middle of that.  It has to be either done completely or not
 > done at all.  Therefore it must not use functions that can quit.
 > Or else it has to inhibit quitting some other way.

It's not related to window deletion.  When Emacs buries a buffer it
first removes the buffer from the buffer list and then adds it to the
end of that list in the following way:

       aelt = Frassq (buffer, Vbuffer_alist);
       link = Fmemq (aelt, Vbuffer_alist);
       Vbuffer_alist = Fdelq (aelt, Vbuffer_alist);
       XSETCDR (link, Qnil);
       Vbuffer_alist = nconc2 (Vbuffer_alist, link);

If the Fdelq above quits, the buffer is lost (in some sense).  The code
for record_buffer avoids the problem but chokes on circular lists.

martin

Re: Window configurations

[Juri Linkov]

> In addition we should disallow changing a frame's buffer and buried
> buffer lists by setting the corresponding frame's parameter.  I think
> this was part of an attempt to make each and every frame related object
> part of a frame's parameters.  But an application should not be allowed
> to alter the history of buffers shown on a particular frame.  Let's
> leave such activities to politicians - that's what they get paid for.

Definitely not, changing a frame's buffer and buried buffer lists
is the only way to implement a sane behavior for the tab-bar!
Switching tabs should save the frame's buffer list of the current tab
into a variable and update the frame's parameters with the value
of frame's buffer list of the next tab.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > Definitely not, changing a frame's buffer and buried buffer lists
 > is the only way to implement a sane behavior for the tab-bar!
 > Switching tabs should save the frame's buffer list of the current tab
 > into a variable and update the frame's parameters with the value
 > of frame's buffer list of the next tab.

But why should working from the tab-bar affect these?  Shouldn't such
side-effects stay within the framework of the tab-bar functions?

martin

Re: Window configurations

[Juri Linkov]

>> Definitely not, changing a frame's buffer and buried buffer lists
>> is the only way to implement a sane behavior for the tab-bar!
>> Switching tabs should save the frame's buffer list of the current tab
>> into a variable and update the frame's parameters with the value
>> of frame's buffer list of the next tab.
>
> But why should working from the tab-bar affect these?

They implement tab-local buffer-list by modifying the frame-local
buffer-list after switching the tab.

> Shouldn't such side-effects stay within the framework of the
> tab-bar functions?

The tab-bar functions implemented by Lisp packages use
`modify-frame-parameters' to change `buffer-list' frame parameter.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > They implement tab-local buffer-list by modifying the frame-local
 > buffer-list after switching the tab.

Could you please explain in one or two sentences?  Where can I find the
source of these tab-bars?

 > The tab-bar functions implemented by Lisp packages use
 > `modify-frame-parameters' to change `buffer-list' frame parameter.

But wouldn't it make more sense to have tab-bar use its own list?  Can
tab-bar live with the fact that a user switches buffers without using
tab-bar and thus `select-window' changes the list?

martin

Re: Window configurations

[Juri Linkov]

>> They implement tab-local buffer-list by modifying the frame-local
>> buffer-list after switching the tab.
>
> Could you please explain in one or two sentences?  Where can I find the
> source of these tab-bars?

Please see for example in the branch x-tabs/lisp/tab.el.

>> The tab-bar functions implemented by Lisp packages use
>> `modify-frame-parameters' to change `buffer-list' frame parameter.
>
> But wouldn't it make more sense to have tab-bar use its own list?

Yes, it makes sense to have the following composite buffer-list:

 window-local buffer-list
 tab-local buffer-list
 frame-local buffer-list
 global buffer-list
 frame-local buried-buffer-list
 tab-local buried-buffer-list
 window-local buried-buffer-list

But how would you implement tab-local buffer-list without modifying
frame-local buffer-list?

> Can tab-bar live with the fact that a user switches buffers without
> using tab-bar and thus `select-window' changes the list?

A user can switch buffers inside the same tab - this modifies the
frame-local (tab-local) buffer-list.  A user can switch tabs without
using tab-bar - this updates the frame-local (tab-local) buffer-list
with the buffer-list of another tab.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Stefan Monnier]

> But how would you implement tab-local buffer-list without modifying
> frame-local buffer-list?

You could imagine getting rid of this special handling of frames and
buffers's buffer-list and instead provide a record-buffer-function and
a buffer-list-function, so Elisp packages can implement them as
they wish.  I'm not sure it's worth the trouble.


        Stefan

Re: Window configurations

[Juri Linkov]

>> But how would you implement tab-local buffer-list without modifying
>> frame-local buffer-list?
>
> You could imagine getting rid of this special handling of frames and
> buffers's buffer-list and instead provide a record-buffer-function and
> a buffer-list-function, so Elisp packages can implement them as
> they wish.  I'm not sure it's worth the trouble.

Maybe record-buffer-functions and buffer-list-functions (plural)
where Elisp packages could add own function to a list of functions.
Then core primitives will construct a composite list by appending
values returned by these functions.  An example of buffer-list-functions:
'(window-buffer-list-function tab-buffer-list-function frame-buffer-list-function).
created with code in

window.el:
  (add-to-list 'buffer-list-functions 'window-buffer-list-function)

tab.el
  (add-to-list 'buffer-list-functions 'tab-buffer-list-function)

frame.el
  (add-to-list 'buffer-list-functions 'frame-buffer-list-function)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Juri Linkov]

> The case at hand was a scenario earlier posted by Juri as ...

There is another case that is more annoying:

1. Run `emacs -q', the current buffer is "*scratch*".

2. Type `C-h i', the current buffer is "*info*".

3. Type `C-h C-t', the current buffer is "TODO".

4. Type `C-h C-n', the current buffer is "NEWS".

5. Type `C-x k RET', the current buffer is the previous buffer "TODO", good.

6. Type `C-x k RET', the current buffer is "*scratch*".  Why?
   The previous buffer is "*info*", not "*scratch*"!

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > There is another case that is more annoying:
 >
 > 1. Run `emacs -q', the current buffer is "*scratch*".
 >
 > 2. Type `C-h i', the current buffer is "*info*".
 >
 > 3. Type `C-h C-t', the current buffer is "TODO".
 >
 > 4. Type `C-h C-n', the current buffer is "NEWS".
 >
 > 5. Type `C-x k RET', the current buffer is the previous buffer "TODO", good.
 >
 > 6. Type `C-x k RET', the current buffer is "*scratch*".  Why?
 >    The previous buffer is "*info*", not "*scratch*"!

This happened in revision 90833 of `pop-to-buffer' from 2008-09-13.
Since then `pop-to-buffer' doesn't reselect the selected window.

The culprit is this conditional

     (unless (eq new-window old-window)
       ;; `display-buffer' has chosen another window, select it.

which does not select the *info* window because it was already selected
before but obviously doesn't record the *info* buffer either :-(

I'm running my code without the conditional for more than two months
now so it shouldn't harm if you remove it as well.

martin

Re: Window configurations

[Juri Linkov]

>> There is another case that is more annoying:
>>
>> 1. Run `emacs -q', the current buffer is "*scratch*".
>>
>> 2. Type `C-h i', the current buffer is "*info*".
>>
>> 3. Type `C-h C-t', the current buffer is "TODO".
>>
>> 4. Type `C-h C-n', the current buffer is "NEWS".
>>
>> 5. Type `C-x k RET', the current buffer is the previous buffer "TODO", good.
>>
>> 6. Type `C-x k RET', the current buffer is "*scratch*".  Why?
>>    The previous buffer is "*info*", not "*scratch*"!
>
> This happened in revision 90833 of `pop-to-buffer' from 2008-09-13.
> Since then `pop-to-buffer' doesn't reselect the selected window.
>
> The culprit is this conditional
>
>     (unless (eq new-window old-window)
>       ;; `display-buffer' has chosen another window, select it.
>
> which does not select the *info* window because it was already selected
> before but obviously doesn't record the *info* buffer either :-(
>
> I'm running my code without the conditional for more than two months
> now so it shouldn't harm if you remove it as well.

I tried to remove the conditional, but it doesn't help.
Maybe some other your changes fixed that?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > I tried to remove the conditional, but it doesn't help.
 > Maybe some other your changes fixed that?

[Indeed.  Just that I had the fix in my build but no more in the
source so it took me three hours to find out what really happened.]

It's a longstanding bug in Fselect_window.  At the time I changed
`pop-to-buffer' I wasn't aware of it and thus only added to the
confusion.

Please do two things: In Fselect_window move the

   if (NILP (norecord))
     record_buffer (w->buffer);

up into the

   if (NILP (norecord))
     {
       ++window_select_count;
       XSETFASTINT (w->use_time, window_select_count);
     }

clause such that the latter reads as

   if (NILP (norecord))
     {
       ++window_select_count;
       XSETFASTINT (w->use_time, window_select_count);
       record_buffer (w->buffer);
     }

so the buffer gets recorded even if the selected window does not change.

In addition, remove the conditional from `pop-to-buffer' as explained
before.  If you don't encounter problems, please check it in.

martin


PS: I'm not sure whether in Fselect_window this

   /* Go to the point recorded in the window.
      This is important when the buffer is in more
      than one window.  It also matters when
      redisplay_window has altered point after scrolling,
      because it makes the change only in the window.  */
   {
     register int new_point = marker_position (w->pointm);
     if (new_point < BEGV)
       SET_PT (BEGV);
     else if (new_point > ZV)
       SET_PT (ZV);
     else
       SET_PT (new_point);
   }

stuff should be moved in front of the

   if (EQ (window, selected_window))
     return window;

as well.  Any ideas?

Re: Window configurations

[Juri Linkov]

>   if (NILP (norecord))
>     {
>       ++window_select_count;
>       XSETFASTINT (w->use_time, window_select_count);
>       record_buffer (w->buffer);
>     }
>
> so the buffer gets recorded even if the selected window does not change.
>
> In addition, remove the conditional from `pop-to-buffer' as explained
> before.  If you don't encounter problems, please check it in.

Thanks for finding the source of this bug.  It works now.
Stefan, is it ok to install this change?

> PS: I'm not sure whether in Fselect_window this
>
>   /* Go to the point recorded in the window.
>      This is important when the buffer is in more
>      than one window.  It also matters when
>      redisplay_window has altered point after scrolling,
>      because it makes the change only in the window.  */
>   {
>     register int new_point = marker_position (w->pointm);
>     if (new_point < BEGV)
>       SET_PT (BEGV);
>     else if (new_point > ZV)
>       SET_PT (ZV);
>     else
>       SET_PT (new_point);
>   }
>
> stuff should be moved in front of the
>
>   if (EQ (window, selected_window))
>     return window;
>
> as well.  Any ideas?

But this will move it in front of Fset_buffer too.  Is this right?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[Stefan Monnier]

>> so the buffer gets recorded even if the selected window does not change.
>> In addition, remove the conditional from `pop-to-buffer' as explained
>> before.  If you don't encounter problems, please check it in.

> Thanks for finding the source of this bug.  It works now.
> Stefan, is it ok to install this change?

I'm not sure what kind of impact this might have, but we can try
checking it in and then seeing what changes.


        Stefan

Re: Window configurations

[Juri Linkov]

>>> so the buffer gets recorded even if the selected window does not change.
>>> In addition, remove the conditional from `pop-to-buffer' as explained
>>> before.  If you don't encounter problems, please check it in.
>
>> Thanks for finding the source of this bug.  It works now.
>> Stefan, is it ok to install this change?
>
> I'm not sure what kind of impact this might have, but we can try
> checking it in and then seeing what changes.

Checked in.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 >> PS: I'm not sure whether in Fselect_window this
[...]
 >> stuff should be moved in front of the
 >>
 >>   if (EQ (window, selected_window))
 >>     return window;
 >>
 >> as well.  Any ideas?
 >
 > But this will move it in front of Fset_buffer too.  Is this right?

I'm afraid not.  It would probably also interact badly with the
set_marker_both stuff.  I suppose most of what is missing here is later
covered up by the command loop synchronizing selected window and current
buffer via set_buffer_internal_1.

One of my favorite mysteries is why, when WINDOW is already selected,
`select-window' should not set the current buffer.

martin

Re: Window configurations

[Stefan Monnier]

> One of my favorite mysteries is why, when WINDOW is already selected,
> `select-window' should not set the current buffer.

I think the answer is simply "because it's not needed".  In contrast,
when we do have to change the selected window, we have to pay attention
to the point/window-point correspondence which makes it necessary to set
the buffer.  Of course, this necessity could be made just internal.

IOW, it's mostly accidental.


        Stefan

Re: Window configurations

[martin rudalics]

 >> One of my favorite mysteries is why, when WINDOW is already selected,
 >> `select-window' should not set the current buffer.
 >
 > I think the answer is simply "because it's not needed".  In contrast,
 > when we do have to change the selected window, we have to pay attention
 > to the point/window-point correspondence which makes it necessary to set
 > the buffer.  Of course, this necessity could be made just internal.
 >
 > IOW, it's mostly accidental.

What I meant was that the current implementation gives very contrived
semantics.  The test in

(with-current-buffer buffer
   (with-selected-window window
     (eq (current-buffer) buffer)

succeeds unless `window' was not selected and did not display `buffer'
at the time `with-selected-window' was entered.

martin

Re: Window configurations

[Stefan Monnier]

> What I meant was that the current implementation gives very contrived
> semantics.

I know.  Maybe we should "fix it", as you implicitly suggested, by
simply always doing a set-buffer.  It's fairly risky, kind of like
replacing every (save-excursion (set-buffer foo) bar) with
(with-current-buffer foo bar) ;-)


        Stefan

Re: Window configurations

[Lennart Borgman]

On Mon, Jun 7, 2010 at 5:36 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> What I meant was that the current implementation gives very contrived
>> semantics.
>
> I know.  Maybe we should "fix it", as you implicitly suggested, by
> simply always doing a set-buffer.  It's fairly risky, kind of like
> replacing every (save-excursion (set-buffer foo) bar) with
> (with-current-buffer foo bar) ;-)


Why is it risky? This is on the display level so to say and always
associated with windows on the display. I think there will be no big
surprises.

Re: Window configurations

[martin rudalics]

 > I know.  Maybe we should "fix it", as you implicitly suggested, by
 > simply always doing a set-buffer.  It's fairly risky, kind of like
 > replacing every (save-excursion (set-buffer foo) bar) with
 > (with-current-buffer foo bar) ;-)

I haven't looked into the calls in xdisp.c but I hope you're right ;-)

Vivisecting Fselect_window reveals at least three suspicious components.
------------------------------------------------------------------------
   /* Store the current buffer's actual point into the
      old selected window.  It belongs to that window,
      and when the window is not selected, must be in the window.  */
   if (!NILP (selected_window))
     {
       ow = XWINDOW (selected_window);
       if (! NILP (ow->buffer))
	set_marker_both (ow->pointm, ow->buffer,
			 BUF_PT (XBUFFER (ow->buffer)),
			 BUF_PT_BYTE (XBUFFER (ow->buffer)));
     }

I suppose "current buffer" means the buffer displayed in the currently
selected window which is not the window we are going to select.  Why the
heck do we care about storing `point' into that window's `window-point'?
------------------------------------------------------------------------
   XBUFFER (w->buffer)->last_selected_window = window;

IMHO it's a bug to not set last_selected_window when the selected window
did not change but the buffer displayed in it did change.  It means that
when we remove the buffer from the window and display it in that window
again Emacs will not go to the previous `window-point' but to `point'.
------------------------------------------------------------------------
   /* Go to the point recorded in the window.
      This is important when the buffer is in more
      than one window.  It also matters when
      redisplay_window has altered point after scrolling,
      because it makes the change only in the window.  */
   {
     register int new_point = marker_position (w->pointm);
     if (new_point < BEGV)
       SET_PT (BEGV);
     else if (new_point > ZV)
       SET_PT (ZV);
     else
       SET_PT (new_point);
   }

It sets `point' to `window-point'.  If the selected window didn't change
but the buffer did, the buffer's `point' is not changed.  Obviously,
command_loop_1 will fix this eventually but any code running after the
call of `select-window' will have `point' positioned as whether the
selected window changed or not.
------------------------------------------------------------------------
Neither of these seems to have bothered anyone so far.  But the problem
Juri brought up wasn't noticed either - till now.

martin

Re: Window configurations

[Stefan Monnier]

> I suppose "current buffer" means the buffer displayed in the currently
> selected window which is not the window we are going to select.  Why the
> heck do we care about storing `point' into that window's `window-point'?

Because when a window is selected, the window-point is actually stored
in the buffer's point.  So when we deselect it we have to copy the
buffer's point back into the window-point.


        Stefan

Re: Window configurations

[martin rudalics]

 > Because when a window is selected, the window-point is actually stored
 > in the buffer's point.  So when we deselect it we have to copy the
 > buffer's point back into the window-point.

Thanks.  No way to get around this.  So I'd rather skip this part when
the selected window does not change.

Initially, I wanted to store a pointer to a window's buffer list in a
window configuration but that apparently breaks things when restoring
the configuration.  IIUC I'd have to copy window buffer lists when
saving a configuration since otherwise they can get messed up by an
intermittent `delq'.  Copying buffer lists is 100% not worth the
trouble.  Hence any change to a window's buffer list that happens inside
a window excursion will get recorded (including selections that happen
inside a window that is deleted when the configuration is restored).

martin

Re: Window configurations

[Stefan Monnier]

> Initially, I wanted to store a pointer to a window's buffer list in a
> window configuration but that apparently breaks things when restoring
> the configuration.  IIUC I'd have to copy window buffer lists when
> saving a configuration since otherwise they can get messed up by an
> intermittent `delq'.  Copying buffer lists is 100% not worth the
> trouble.  Hence any change to a window's buffer list that happens inside
> a window excursion will get recorded (including selections that happen
> inside a window that is deleted when the configuration is restored).

I'm not sure if keeping window's buffer-lists in window-configs would be
a good thing, and/or if it's worth the trouble, but we could use a new
Fremq rather Fdelq.


        Stefan

Re: Window configurations

[martin rudalics]

 > I'm not sure if keeping window's buffer-lists in window-configs would be
 > a good thing, and/or if it's worth the trouble, but we could use a new
 > Fremq rather Fdelq.

I don't understand how that would help here.  Besides, `remq' does copy
the list so what would we gain?

Anyway, I'm afraid that our previous "fix" of `select-window' was wrong:
With two frames f1 and f2 and f1 selected, selecting a window on f2 will
cause that window's buffer get recorded for f1 :-(

martin

Re: Window configurations

[Stefan Monnier]

> problem.  In particular, I display eldoc output on a per-window basis in
> a one-line window below the code window (I hate eldoc output in the echo
> area, I don't like it in the header line, and I very much hate tooltips.
> Ideally, there would be a bottom-line right above the mode-line where I
> could put it, but ...).

Interesting problem in itself, indeed.  Luckily, I'm satisfied with the
each area for that purpose.  Good luck!

> Now I'm killing such an eldoc-buffer as soon as it is no more shown in
> its eldoc-window.  But when (1) a `save-window-excursion' restores the
> saved configuration and (2) it has to restore a former eldoc-window that
> was deleted within the body of `save-window-excursion', I get the first
> buffer from `buffer-list' shown in that window which is downright silly.

I know you think dedicated windows suck and that I like them so much
that "when you have a hammer everything looks like a nail", but I think
this is really a good case to mark the window dedicated.  I'm not sure
whether set-window-configuration would do the right thing currently
(kill the window if the buffer died), but if it doesn't, it'd be
a clear bug that needs fixing.


        Stefan

Re: Window configurations

[martin rudalics]

 > Interesting problem in itself, indeed.  Luckily, I'm satisfied with the
 > each area for that purpose.  Good luck!

The echo area sucks for two reasons: When you have windows above each
other and work in the upper one, your eyes have to continuously pass
through the lower window down to the echo area.  What's worse, however,
is that the eldoc message obscures all sorts of other messages which is
particularly annoying when you want to read them during debugging.

 > I know you think dedicated windows suck and that I like them so much
 > that "when you have a hammer everything looks like a nail", but I think
 > this is really a good case to mark the window dedicated.  I'm not sure
 > whether set-window-configuration would do the right thing currently
 > (kill the window if the buffer died), but if it doesn't, it'd be
 > a clear bug that needs fixing.

I don't think that dedicated windows suck and even went so far as to
give them an entire section in the Elisp manual ;-)

On the average, 50% of my windows are dedicated and they suit my needs
well.  So I think that hardly anyone out there uses dedicated windows
more than me.  And my eldoc-windows are obviously dedicated - they would
not be usable otherwise.

Having `set-window-configuration' "kill the window if the buffer died"
is not entirely trivial though.  What shall we do when the last window
has a deleted buffer?  Kill the frame?

martin

Re: Window configurations

[Stefan Monnier]

>> Interesting problem in itself, indeed.  Luckily, I'm satisfied with the
>> echo area for that purpose.  Good luck!
> The echo area sucks for two reasons: When you have windows above each
> other and work in the upper one, your eyes have to continuously pass
> through the lower window down to the echo area.  What's worse, however,
> is that the eldoc message obscures all sorts of other messages which is
> particularly annoying when you want to read them during debugging.

Yes, I'm not trying to argue it's perfect.  Just that I'm satisfied for
my own use.  Of course we should try to minimize the number of cases
where it hides useful info.  One possibility is to try and provide
better control so the user can prevent eldoc from showing up while she's
reading a previous message, and so that she can remove the eldoc message
to recover the previous message.

> Having `set-window-configuration' "kill the window if the buffer died"
> is not entirely trivial though.

What kind of problems did you encounter (other than the one below)?

> What shall we do when the last window has a deleted buffer?
> Kill the frame?

That could make sense, yes, since that's what would happen if the
deletion had taken place while the frame was displayed.  But we could
also fallback to the current behavior in that corner case, since
I'd assume it to be rare anyway (i.e. not worth spending too much time,
at least for now).


        Stefan

Re: Window configurations

[martin rudalics]

 >> Having `set-window-configuration' "kill the window if the buffer died"
 >> is not entirely trivial though.
 >
 > What kind of problems did you encounter (other than the one below)?

A minor technical annoyance - I have to construct a list of windows to
delete because I cannot delete a window before restoration is complete.
And obviously I have to assign some buffer during restoration just to
handle the case where the deletion fails for whatever reason.

 >> What shall we do when the last window has a deleted buffer?
 >> Kill the frame?
 >
 > That could make sense, yes, since that's what would happen if the
 > deletion had taken place while the frame was displayed.  But we could
 > also fallback to the current behavior in that corner case, since
 > I'd assume it to be rare anyway (i.e. not worth spending too much time,
 > at least for now).

We'd still have to solve the problem where a frame is the last frame
anyway.  But we haven't yet decided what to do with non-dedicated
windows that lose their buffers.  Solving that more general problem
should solve this corner case too.

martin

Re: Window configurations

[Stefan Monnier]

>>> Having `set-window-configuration' "kill the window if the buffer died"
>>> is not entirely trivial though.
>> What kind of problems did you encounter (other than the one below)?
> A minor technical annoyance - I have to construct a list of windows to
> delete because I cannot delete a window before restoration is complete.
> And obviously I have to assign some buffer during restoration just to
> handle the case where the deletion fails for whatever reason.

I think it's OK.  If you can provide a patch for it, please submit (or
install) it.

> We'd still have to solve the problem where a frame is the last frame
> anyway.  But we haven't yet decided what to do with non-dedicated
> windows that lose their buffers.  Solving that more general problem
> should solve this corner case too.

The desired behavior for (non-sole) dedicated windows is pretty clear,
so we can install a fix for it right away.

For the remaining cases, it's much less clear what would be the "right"
behavior (it seems to depend on the intention behind the save&restore of
the window-config, so it should probably be handled at some other
level).


        Stefan

Re: Window configurations

[Kevin Rodgers]

martin rudalics wrote:
>  > The point of set-window-configuration-from-sexp is to restore the
>  > configuration of windows, not to duplicate the functionality of 
> desktop.el.
> 
> That's true from a theoretical point of view.  It separates concerns in
> a clear way and gives clean semantics.  Hence I fully agree with you.
> 
> Unfortunately, in personal practice, I'm suffering from a quite similar
> problem.  In particular, I display eldoc output on a per-window basis in
> a one-line window below the code window (I hate eldoc output in the echo
> area, I don't like it in the header line, and I very much hate tooltips.
> Ideally, there would be a bottom-line right above the mode-line where I
> could put it, but ...).

Have you tried displaying a tooltip in that position, by let-binding
tooltip-frame-parameters around the call to tooltip-show?

,----[ C-h f tooltip-show RET ]
| tooltip-show is a compiled Lisp function in `tooltip.el'.
| (tooltip-show text &optional use-echo-area)
|
| Show a tooltip window displaying text.
|
| Text larger than `x-max-tooltip-size' is clipped.
|
| If the alist in `tooltip-frame-parameters' includes `left' and `top'
| parameters, they determine the x and y position where the tooltip
| is displayed.  Otherwise, the tooltip pops at offsets specified by
| `tooltip-x-offset' and `tooltip-y-offset' from the current mouse
| position.
|
| Optional second arg use-echo-area non-nil means to show tooltip
| in echo area.
|
| [back]
`----

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Window configurations

[martin rudalics]

 > Have you tried displaying a tooltip in that position, by let-binding
 > tooltip-frame-parameters around the call to tooltip-show?

You convinced me ;-)

Only that `tooltip-show' displays the text in `tooltip' face, spoiling
everything.  However, `x-show-tip' works fine and is much much cheaper
than the tribulations of `eldoc-display-message-no-interference-p' and
`eldoc-pre-command-refresh-echo-area'.

martin

Re: Window configurations

[Lennart Borgman]

On Sat, May 8, 2010 at 3:54 PM, martin rudalics <rudalics@gmx.at> wrote:
>> Have you tried displaying a tooltip in that position, by let-binding
>> tooltip-frame-parameters around the call to tooltip-show?
>
> You convinced me ;-)
>
> Only that `tooltip-show' displays the text in `tooltip' face, spoiling
> everything.  However, `x-show-tip' works fine and is much much cheaper
> than the tribulations of `eldoc-display-message-no-interference-p' and
> `eldoc-pre-command-refresh-echo-area'.

How about adding that to the trunk?

Re: Window configurations

[martin rudalics]

 > How about adding that to the trunk?

We could add something like that eventually.  However, I suppose that
most people would like to see the tooltip frame at the right of `point'
in some otherwise blank space of the screen.  This means that I probably
should be able to format argument lists and doc-strings vertically.
And, interaction with the mouse cursor would have to be evaluated too.

Also, tooltips currently have quite a number of annoying features which
must be corrected first.

martin

Re: Window configurations

[Lennart Borgman]

On Sun, May 9, 2010 at 4:01 PM, martin rudalics <rudalics@gmx.at> wrote:
>> How about adding that to the trunk?
>
> We could add something like that eventually.  However, I suppose that
> most people would like to see the tooltip frame at the right of `point'
> in some otherwise blank space of the screen.

Does not this very much depend on the purpose of the tooltip?

>   This means that I probably
> should be able to format argument lists and doc-strings vertically.
> And, interaction with the mouse cursor would have to be evaluated too.
>
> Also, tooltips currently have quite a number of annoying features which
> must be corrected first.

Maybe a topmost frame is not the best frame style. I
suppose "transient-for" (on w32 "owned") is better. This was discussed
a bit in the thread below:

  http://comments.gmane.org/gmane.emacs.devel/124334

Re: Window configurations

[martin rudalics]

 >> We could add something like that eventually.  However, I suppose that
 >> most people would like to see the tooltip frame at the right of `point'
 >> in some otherwise blank space of the screen.
 >
 > Does not this very much depend on the purpose of the tooltip?

Maybe.  But displaying the tooltip frame right above the modeline is
just my personal preference.  I doubt many people will like it.

 >> Also, tooltips currently have quite a number of annoying features which
 >> must be corrected first.
 >
 > Maybe a topmost frame is not the best frame style. I
 > suppose "transient-for" (on w32 "owned") is better.

Maybe.  But first of all, the mode-line updating in `delete-frame' has
to be made conditional on non-tooltip frames since currently this
interacts very badly with timers.  (There's also a splendid sillyness in
delete_frame, apparently introduced by yours truly, which allows running
hooks when they shouldn't.)  But so far I don't understand why we have
to always delete tooltip frames in the first place.  Also, tooltip
frames should be either moved or made invisible whenever frames are
resized - the current behavior is intolerable in this regard.  Finally,
the `tooltip-show' interface should be improved to allow, for example,
merging with other faces.  BTW, is there any way to make tooltip frames
transparent?

martin

Re: Window configurations

[martin rudalics]

 > Do you plan to create a branch for your rewrite of window.c?
 > It would be very interesting to look at it.

I've now put up a branch called window-pub.  Please have a look.

The major aspects are

- Internal windows exposed in Elisp

- Window resizing moved to Elisp

- Basic support for window groups and compound windows

ChangeLog entries are rudimentary.

The branch does NOT incorporate any of

- the window local buffer list implementation,

- the new semantics for the second argument of `display-buffer',

because I'm afraid that providing these will break things.  It will take
some time to add them ;-)

martin

Re: Window configurations

[Juri Linkov]

>> Do you plan to create a branch for your rewrite of window.c?
>> It would be very interesting to look at it.
>
> I've now put up a branch called window-pub.  Please have a look.

Thank you!

> The major aspects are
>
> - Internal windows exposed in Elisp
>
> - Window resizing moved to Elisp
>
> - Basic support for window groups and compound windows

Could you put a short informal explanation of every aspect
to a file (e.g. README.window-pub) in the window-pub branch,

> ChangeLog entries are rudimentary.
>
> The branch does NOT incorporate any of
>
> - the window local buffer list implementation,
>
> - the new semantics for the second argument of `display-buffer',
>
> because I'm afraid that providing these will break things.  It will take
> some time to add them ;-)

It's not terrible to break things in the branch ;-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > Could you put a short informal explanation of every aspect
 > to a file (e.g. README.window-pub) in the window-pub branch,

Please try to read the Elisp manual section on windows first.

 > It's not terrible to break things in the branch ;-)

Sure.  But the remainder works here quite well for some times and I'd
hate to lose any feedback on that part due to bugs in features I have
not yet tested throughly myself.

martin

Re: Window configurations

[Juanma Barranquero]

I know you're not supposed to do that (I was just stress-testing) but after

   (setq window-safe-min-height 0 window-min-height 0)

you can make a one-line window with no mode-line. Shouldn't that be checked?

    Juanma

Re: Window configurations

[martin rudalics]

 > I know you're not supposed to do that (I was just stress-testing) but after
 >
 >    (setq window-safe-min-height 0 window-min-height 0)
 >
 > you can make a one-line window with no mode-line. Shouldn't that be checked?

I'm cheating here.  The doc-string of the former says

   "The absolut minimum number of lines of a window.
Anything less might crash Emacs."

but you can quietly set it to an arbitrary value.  Emacs will crash ;-)
regardless of whether this has been changed - the value 1 is hardcoded
in C.

Now as a matter of fact if you do

   (setq window-safe-min-height 0)
   (setq window-min-height 0)

you can make the modeline of a window disappear.  This is intentional
for the following reason: When I drastically shrink a frame with the
window manager I prefer making windows without a modeline rather than
delete them.  The modelines will reappear as soon as the frame grows
again.  Unfortunately, I don't see any way to prevent this in the case
you describe since the window resizing code is in Elisp.  IIUC, even
putting these constants in pure store wouldn't prevent it.  But, after
all, anyone who changes the value of a constant is on her own?

martin

Re: Window configurations

[Juanma Barranquero]

On Tue, Jun 29, 2010 at 14:16, martin rudalics <rudalics@gmx.at> wrote:

> you can make the modeline of a window disappear.  This is intentional
> for the following reason: When I drastically shrink a frame with the
> window manager I prefer making windows without a modeline rather than
> delete them.  The modelines will reappear as soon as the frame grows
> again.

OK, this makes sense.

> But, after
> all, anyone who changes the value of a constant is on her own?

Sure.

    Juanma

Re: Window configurations

[Juri Linkov]

> The major aspects are
>
> - Internal windows exposed in Elisp

Does this mean that now it's possible to create/restore
window configurations in Elisp?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Window configurations

[martin rudalics]

 > Does this mean that now it's possible to create/restore
 > window configurations in Elisp?

As a matter of fact I expected you to write that.  Your proposals in
this context were pretty convincing so that I even threw out some
routines I wrote earlier (mostly for putting frames into windows and
vice versa).

So please have a look into what I wrote and tell me what you need to
make your code work.  We could provide functions like `make-window',
`set-window-parent', `set-window-vchild', ... in Elisp and write a C
function - say `replace-window' - which replaces an existing (internal)
window with an (internal) window constructed by the routines mentioned
before.

But I'd do that iff your "construct configuration from sexps" approach
really profited from it since we'd have to augment the window structure
by new_parent, new_vchild, new_sibling, ... fields which is cumbersome.

martin

Re: Window configurations

[Juri Linkov]

> So please have a look into what I wrote and tell me what you need to
> make your code work.  We could provide functions like `make-window',
> `set-window-parent', `set-window-vchild', ... in Elisp and write a C
> function - say `replace-window' - which replaces an existing (internal)
> window with an (internal) window constructed by the routines mentioned
> before.

Ok, I'll have a look into what is necessary to rewrite
`current-window-configuration' and `set-window-configuration'
in Elisp.

> But I'd do that iff your "construct configuration from sexps" approach
> really profited from it since we'd have to augment the window structure
> by new_parent, new_vchild, new_sibling, ... fields which is cumbersome.

I guess after rewriting existing two functions `current-window-configuration'
and `set-window-configuration' in Elisp, implementing "construct
configuration from sexps" would be trivial.

-- 
Juri Linkov
http://www.jurta.org/emacs/