[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Window configurations
From: |
Juri Linkov |
Subject: |
Re: Window configurations |
Date: |
Tue, 27 Apr 2010 11:54:11 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) |
> 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: Gtk tabs in emacs, new branch, (continued)
- Re: Gtk tabs in emacs, new branch, Juri Linkov, 2010/04/23
- RE: Gtk tabs in emacs, new branch, Drew Adams, 2010/04/23
- Re: Gtk tabs in emacs, new branch, Juri Linkov, 2010/04/24
- RE: Gtk tabs in emacs, new branch, Drew Adams, 2010/04/24
- Re: Gtk tabs in emacs, new branch, Juri Linkov, 2010/04/24
- RE: Gtk tabs in emacs, new branch, Drew Adams, 2010/04/24
- Re: Gtk tabs in emacs, new branch, Juri Linkov, 2010/04/25
- Re: Gtk tabs in emacs, new branch, martin rudalics, 2010/04/25
- Window configurations (was: Gtk tabs in emacs, new branch), Juri Linkov, 2010/04/25
- Re: Window configurations, martin rudalics, 2010/04/26
- Re: Window configurations,
Juri Linkov <=
- Re: Window configurations, martin rudalics, 2010/04/27
- Re: Window configurations, Juri Linkov, 2010/04/27
- Info buffers in Desktop, Juri Linkov, 2010/04/27
- Re: Window configurations, martin rudalics, 2010/04/28
- Re: Window configurations, Juri Linkov, 2010/04/28
- Re: Window configurations, Davis Herring, 2010/04/27
- Re: Window configurations, Juri Linkov, 2010/04/28
- Re: Window configurations, Davis Herring, 2010/04/28
- Re: Window configurations, martin rudalics, 2010/04/28
- Re: Window configurations, Stefan Monnier, 2010/04/28