Annoying window/frame-configuration registers

Annoying window/frame-configuration registers

[Leo]

Hello,

I wonder if someone has any idea why window/frame-configuration
registers also restore point in the current buffer. For me, that makes
them nearly useless. I have also talked with two other active Emacs
users/authors in #emacs and they are already using a replacement.

For example, assume I set up Emacs windows/frames for a writing task. I
like the setup and it takes a few seconds to arrange it. So I save the
configuration to a register. As I progress with my writing, something
destroys the window/frame layout. When I restore the layout by C-x r j,
I find the point move to a surprising spot.

I think the frame/window configuration registers are doing too much by
restoring point. Any objection to changing that behaviour? Thanks

Leo

Re: Annoying window/frame-configuration registers

[Stefan Monnier]

> I think the frame/window configuration registers are doing too much by
> restoring point. Any objection to changing that behaviour? Thanks

The window-config code needs to be overhauled, indeed.  E.g. so as to be
able to restore a window config in another frame.
Your change might be OK, but only if it affects the behavior of
registers but not of the many internal uses of window-configs.


        Stefan

Re: Annoying window/frame-configuration registers

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Mon, 28 Mar 2011 23:51:43 +0800
> 
> I think the frame/window configuration registers are doing too much by
> restoring point. Any objection to changing that behaviour? Thanks

I'm quite sure there are use cases where point restoration is needed.
However, a customizable option to do what you want is probably a good
idea.

Re: Annoying window/frame-configuration registers

[martin rudalics]

 > For example, assume I set up Emacs windows/frames for a writing task. I
 > like the setup and it takes a few seconds to arrange it. So I save the
 > configuration to a register. As I progress with my writing, something
 > destroys the window/frame layout. When I restore the layout by C-x r j,
 > I find the point move to a surprising spot.
 >
 > I think the frame/window configuration registers are doing too much by
 > restoring point. Any objection to changing that behaviour? Thanks

`jump-to-register' is a command which does

   "Move point to location stored in a register."

Your change would keep `point' unaltered which doesn't fit the
description of the function.  I would write a new function say
`restore-window-configuration-from-register' and try to find some key
for it.

martin

Re: Annoying window/frame-configuration registers

[Leo]

On 2011-03-29 02:14 +0800, Eli Zaretskii wrote:
> I'm quite sure there are use cases where point restoration is needed.
> However, a customizable option to do what you want is probably a good
> idea.

I suspect so but I can not find any more information from the history.
Would be good to know its use cases and check whether they are obsolete.

On 2011-03-29 02:51 +0800, martin rudalics wrote:
> `jump-to-register' is a command which does
>
>   "Move point to location stored in a register."
>
> Your change would keep `point' unaltered which doesn't fit the
> description of the function.  I would write a new function say
> `restore-window-configuration-from-register' and try to find some key
> for it.
>
> martin

In that case, I wonder if it makes sense to change the doc string to
mean 'jump to the state recorded by a register'. Finding another
key binding is less inconvenient since there is one more key to remember
and I kind of like 'C x r j'. WDYT?

Thanks to all for comments.
Leo

Re: Annoying window/frame-configuration registers

[Leo]

On 2011-03-29 02:12 +0800, Stefan Monnier wrote:
> The window-config code needs to be overhauled, indeed.  E.g. so as to be
> able to restore a window config in another frame.
> Your change might be OK, but only if it affects the behavior of
> registers but not of the many internal uses of window-configs.

It will only affect registers.

Leo

Re: Annoying window/frame-configuration registers

[Lennart Borgman]

On Mon, Mar 28, 2011 at 8:12 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> I think the frame/window configuration registers are doing too much by
>> restoring point. Any objection to changing that behaviour? Thanks
>
> The window-config code needs to be overhauled, indeed.  E.g. so as to be
> able to restore a window config in another frame.
> Your change might be OK, but only if it affects the behavior of
> registers but not of the many internal uses of window-configs.

There is some code for that in winsav.el in nXhtml. (Though everything
can't be restored on the elisp level.)

Re: Annoying window/frame-configuration registers

[martin rudalics]

 > In that case, I wonder if it makes sense to change the doc string to
 > mean 'jump to the state recorded by a register'. Finding another
 > key binding is less inconvenient since there is one more key to remember
 > and I kind of like 'C x r j'. WDYT?

If you make it customizable in register.el as Eli proposed and change
the doc appropriately it looks like a fine change.

martin

Re: Annoying window/frame-configuration registers

[martin rudalics]

 > The window-config code needs to be overhauled, indeed.  E.g. so as to be
 > able to restore a window config in another frame.

For anyone interested in such a feature: The window-pub branch contains
two functions called `window-state-get' and `window-state-put' which
should allow to do that.

martin

Re: Annoying window/frame-configuration registers

[joakim]

martin rudalics <rudalics@gmx.at> writes:

>> The window-config code needs to be overhauled, indeed.  E.g. so as to be
>> able to restore a window config in another frame.
>
> For anyone interested in such a feature: The window-pub branch contains
> two functions called `window-state-get' and `window-state-put' which
> should allow to do that.

Whats lacking to get the branch merged to trunk?

>
> martin
>
>

-- 
Joakim Verona

Re: Annoying window/frame-configuration registers

[martin rudalics]

 > Whats lacking to get the branch merged to trunk?

Testers.  So far Juanma was the only one to help here.

martin

PS: Some changes in the `display-buffer' department are guaranteed to
break existing code.

Re: Annoying window/frame-configuration registers

[joakim]

martin rudalics <rudalics@gmx.at> writes:

>> Whats lacking to get the branch merged to trunk?
>
> Testers.  So far Juanma was the only one to help here.

Cool, I can start to use the branch then. Would simply using the branch
in daily work be enough of a test?

I still have the original use case that we did the "window group" patch
for. Does your branch cover the case of having multiple window groups
and pinnable windows? 

>
> martin
>
> PS: Some changes in the `display-buffer' department are guaranteed to
> break existing code.

Are clients supposed to adopt or the other way around?

-- 
Joakim Verona

Re: Annoying window/frame-configuration registers

[martin rudalics]

 > Cool, I can start to use the branch then. Would simply using the branch
 > in daily work be enough of a test?

For some features like window splitting, resizing, and deleting the
answer is yes.  Others features like side windows or atomic windows are
completely new so it would make sense to check the Elisp manual sections
on these first.

 > I still have the original use case that we did the "window group" patch
 > for. Does your branch cover the case of having multiple window groups
 > and pinnable windows?

It's mostly in what I call "side windows" now.  I'm currently working on
a more expanded version of this but what there is in the branch should
be enough to start working.  In particular, it should suffice to
implement ECB without any advices and similar tricks.

 >> PS: Some changes in the `display-buffer' department are guaranteed to
 >> break existing code.
 >
 > Are clients supposed to adopt or the other way around?

Adopt.  There are two major changes:

(1) All `display-buffer' related options have been concentrated in one
     single option called `display-buffer-alist'.  Obviously, this
     affects users as well but there is a function to convert a user's
     settings to values for the new option.

(2) The semantics of the second and third argument of `display-buffer'
     have completely changed their meaning.  This will affect mostly
     components like calendar, gdb, gnus, org-mode and calculator.  I
     have changed the code in most other clients already.

The other changes I made should not be noticeable in daily work.  But
since my workflow is quite different from that of other people there's a
chance that I have broken some standard behavior.  That's what I would
need testers for.

martin