irritating flaws:
a) The old way of always using the top or left if the choice is
ambiguous is annoying when the layout is unbalanced.
b) The new way of remembering the last used pane is annoying if the
layout is balanced and the leftmost is obvious to the user (because
clearly if we go right from the top-left in a tiled set of four we want
to end up in top-right, even if we were last using the bottom-right).
So instead, use a combination of both: if there is only one possible
pane alongside the current pane, move to it, otherwise choose the most
recently used of the choice.
The current behaviour of mouse-resize-pane is such that if the mouse
button is held down and a selection takes place within a pane, that if
the mouse pointer then hits a border edge, that pane-resize would
initiate.
This seems counter-intuitive; instead, check for a resize condition if
the border of a pane is selected, and in the case of mouse selection
within a pane, no longer resize the pane if edge of the border is hit.
By Thomas Adam.
The current behaviour of mouse-resize-pane is such that if the mouse button
is held down and a selection takes place within a pane, that if the mouse
pointer then hits a border edge, that pane-resize would initiate.
This seems counter-intuitive; instead, check for a resize condition if the
border of a pane is selected, and in the case of mouse selection within a
pane, no longer resize the pane if edge of the border is hit.
When a pane is maximized, and text is selected, we end up checking if a pane
switch is needed. This therefore means we might end up selecting panes
which aren't visible.
window or unzoom (restored to the normal layout) if it already zoomed,
bound to C-b z by default. The pane is unzoomed on pretty much any
excuse whatsoever.
We considered making this a new layout but the requirements are quite
different from layouts so decided it is better as a special case. Each
current layout cell is saved, a temporary one-cell layout generated and
all except the active pane set to NULL.
Prompted by suggestions and scripts from several. Thanks to Aaron Jensen
and Thiago Padilha for testing an earlier version.
or unzoom (restored to the normal layout) if it already zoomed, bound to C-b z
by default. The pane is unzoomed on pretty much any excuse whatsoever.
We considered making this a new layout but the requirements are quite different
from layouts so decided it is better as a special case. Each current layout
cell is saved, a temporary one-cell layout generated and all except the active
pane set to NULL.
Prompted by suggestions and scripts from several. Thanks to Aaron Jensen and
Thiago Padilha for testing an earlier version.
Add move-pane command (like join-pane but allows the same window). Also
-b flag to join-pane and move-pane to place the pane to the left or
above. From George Nachman.
Custom layouts. list-windows command displays the layout as a string (such as
"bb62,159x48,0,0{79x48,0,0,79x48,80,0}") and it can be applied to another
window (with the same number of panes or fewer) using select-layout.
Massive spaces->tabs and trailing whitespace cleanup, hopefully for the last
time now I've configured emacs to make them displayed in really annoying
colours...
Each window now has a tree of layout cells associated with it. In this tree,
each node is either a horizontal or vertical cell containing a list of other
cells running from left-to-right or top-to-bottom, or a leaf cell which is
associated with a pane.
The major functional changes are:
- panes may now be split arbitrarily both horizontally (splitw -h, C-b %) and
vertically (splitw -v, C-b ");
- panes may be resized both horizontally and vertically (resizep -L/-R/-U/-D,
bound to C-b left/right/up/down and C-b M-left/right/up/down);
- layouts are now applied and then may be modified by resizing or splitting
panes, rather than being fixed and reapplied when the window is resized or
panes are added;
- manual-vertical layout is no longer necessary, and active-only layout is gone
(but may return in future);
- the main-pane layouts now reduce the size of the main pane to fit all panes
if possible.
Thanks to all who tested.
Each window now has a tree of layout cells associated with it. In this tree,
each node is either a horizontal or vertical cell containing a list of other
cells running from left-to-right or top-to-bottom, or a leaf cell which is
associated with a pane.
The major functional changes are:
- panes may now be split arbitrarily both horizontally (splitw -h, C-b %) and
vertically (splitw -v, C-b ");
- panes may be resized both horizontally and vertically (resizep -L/-R/-U/-D,
bound to C-b left/right/up/down and C-b M-left/right/up/down);
- layouts are now applied and then may be modified by resizing or splitting
panes, rather than being fixed and reapplied when the window is resized or
panes are added;
- manual-vertical layout is no longer necessary, and active-only layout is gone
(but may return in future);
- the main-pane layouts now reduce the size of the main pane to fit all panes
if possible.
Thanks to all who tested.
decision for whether or not a pane should be drawn out of the layout code and
into the redraw code.
This is needed for the new layout design, getting it in now to make that easier
to work on.
decision for whether or not a pane should be drawn out of the layout code and
into the redraw code.
This is needed for the new layout design, getting it in now to make that easier
to work on.
terminal to be switched between several different windows and programs
displayed on one terminal be detached from one terminal and moved to another.
ok deraadt pirofti
- change the one layout function into two _refresh and _resize
- create layout-manual.c for manual layout code
- move the fit panes/update panes code from window.c to the new file as it is only used by manual layout now
- move the resize pane code into layout-manual.c as well
- get rid of the direct calls to fit/update and make them go through layout
- rename a couple of variables
This is mainly as a first step before reworking the manual layout code to see if anything breaks.
