Re: [ELPA] Brief v5.90: neighboring window merge on deletion

[路客 <luke.yx.lee@gmail.com>]

> Please explain how this differs from the value 'pos'
> of 'delete-window-choose-selected'.

I will try, not sure if I can explain it well with pure texts.  You
will need fixed-fonts configuration to see my ASCII graphs below.

This paragraph explains how the MS-DOS Brief behaves, feel free to
skip if you already know.  In Brief, the `<F4> <arrow>' key command can
`delete and merge' the target window into your current selected window,
as long as the target window is aligned (of the same width or height
with your current selected window.  Well, I put a tolerance value of 1
character so that the target window and your selected window need only
to be `almost' the same width or height, instead of `exact match'
requirement of the original legacy MS-DOS Brief).  The target window is
chosen from your current cursor point of your selected window, to the
direction your <arrow> key points to.  So if you press `<F4> <right>',
it will try to `delete and merge' the right-side neighboring window into
your current selected window, not just deleting the right side window
and letting Emacs decide how to show the other affected windows.

Now we come to the difference between how Emacs' original `deletion'
behaves and the Brief `delete and merge' behavior.  Sometimes they are
identical.  If you use Emacs to divide your single window frame into
four parts by first vertically split the window via `C-x 3' and then
followed by two `C-x 2' in each of the just split window, you will get
a window layout like:
 _____
|_S|T_|
|__|__|

Say if we would like to delete the target upper-right window where I
marked as `T', in Emacs you need to select it and `C-x 0'.  Then the
window layout will become:
 _____
|_S|  |
|__|__|

because we split the frame vertically first so the `T' window is bound
to the right half side of the frame, regardless of the setting of the
variable `delete-window-choose-selected'.  `S' and `T' are of different
(internal) parent windows so they are not mergeable.

Now if we use Brief `<F4> <right>' command from the `S' (`S'elected)
window to delete the `T' (`T'arget) window, it will reconstruct the
windows by deleting all the windows keeping only `S', then re-split
the frame by first split horizontally the window, then reconstruct
the bottom two windows achieving the desired layout:
 _____
|_S___|
|__|__|

This reconstruction happens instantaneously so it's almost not
noticeable to users unless on slow terminals.  Sometimes in X windows
the affected window boundary might shift a little if the original layout
is complicated or is 1-character in width/height difference between
`S' and `T' (my default 1-character tolerance setting).

This also explains why the following `circular' layout is not possible
as we can't find a split line either vertically or horizontally.
 ______
|____| |
| |__|_|
|_|____|

Hope this is clarified.

On Sun, Mar 24, 2024 at 2:34 AM Juri Linkov <juri@linkov.net> wrote:
>
> > In case you are interested.  I've just released the Brief editor mode
> > v5.90 targeting the feature `merge neighboring window on deletion'.
> > This functionality merges two aligned adjacent windows regardless of how
> > Emacs currently splits the frame.  It meaning that even if two aligned
> > neighboring windows in the same frame belong to different parent
> > (internal) windows, they can almost always be merged by reconstructing
> > the window tree properly.
>
> Please explain how this differs from the value 'pos'
> of 'delete-window-choose-selected'.
>
> > This is probably not a big deal but for me this task had been postponed
> > for over 20 years due to not finding time to implement them until
> > recently.  It took me sometime early this year to figure out an
> > efficient algorithm.  It reconstructs window subtree reorganizing
> > vertical/horizontal spliter lines to achieve the desired window layout.
> > However, due to the restriction on how Emacs split windows there are
> > still layouts that can't be displayed by Emacs.  A typical such window
> > layout is:
> >  ______
> > |____| |
> > | |__|_|
> > |_|____|
> >
> > Any such structure within any sub-window of a frame cannot be displayed,
> > as far as I know (let me know if any of you know a simple way to do so).
> > But for regular daily use we don't really need this kind of window
> > layout so it won't be supported unless a simple approach is found.
> >
> > Notice that the atomic window is not yet properly handled and is
> > on-going, if you find any other window attribute not taken care of
> > properly, please be sure to let me know.



-- 
Best regards,
Luke Lee