customize location and shape of a new window in a frame

customize location and shape of a new window in a frame

[Roland Winkler]

Someone posted this on the BBDB mailing list

http://lists.nongnu.org/archive/html/bbdb-user/2018-09/msg00031.html

But the question is quite generic, and I guess it must be an issue
for other packages, too:

BBDB wants to pop-up a window in a frame that already has multiple
windows.  Different users like to do this in different ways and
split an existing window vertically or horizontally, giving a
customizable percentage of screen estate to the new window.

Is there a general function that BBDB could use here, a function
that users can customize for their needs?

Currently, BBDB uses the function bbdb-pop-up-window for this, which
already provides some flexibility.  I could try to tweak this
function as described in the above request.  But it seems to me that
I might reinvent the wheel.  There should be general code for this
that BBDB could use.

Am I missing something?

Roland

Re: customize location and shape of a new window in a frame

[Eric Abrahamsen]

"Roland Winkler" <winkler@gnu.org> writes:

> Someone posted this on the BBDB mailing list
>
> http://lists.nongnu.org/archive/html/bbdb-user/2018-09/msg00031.html
>
> But the question is quite generic, and I guess it must be an issue
> for other packages, too:
>
> BBDB wants to pop-up a window in a frame that already has multiple
> windows.  Different users like to do this in different ways and
> split an existing window vertically or horizontally, giving a
> customizable percentage of screen estate to the new window.
>
> Is there a general function that BBDB could use here, a function
> that users can customize for their needs?

Assuming the user is running BBDB with Gnus, Gnus has its own window
layout system, and you need to work with that. Usually that looks like:

(add-to-list 'gnus-window-to-buffer
       `(bbdb-gnus . "*BBDB*"))

(gnus-add-configuration
  (article
    ,(cond
      (gnus-use-trees
       '(vertical 1.0
		  (summary 0.25 point)
		  (tree 0.25)
		  (horizontal 1.0
			      (article 1.0)
			      (bbdb-gnus 0.4))))
      (t
       '(vertical 1.0
		  (summary 0.25 point)
		  (horizontal 1.0
			      (article 1.0)
			      (bbdb-gnus 0.4))))))

What Gnus *should* be using, and what would be probably the right
solution for BBDB in other (non-Gnus) circumstances, is Side Windows
(see Elisp manual). Side windows give pretty good control over where the
window is placed, and they're made just for situations like this.

Eric

Re: customize location and shape of a new window in a frame

[Stefan Monnier]

> Currently, BBDB uses the function bbdb-pop-up-window for this, which
> already provides some flexibility.  I could try to tweak this
> function as described in the above request.  But it seems to me that
> I might reinvent the wheel.  There should be general code for this
> that BBDB could use.

The main system Emacs uses for that is `display-buffer`, which the user
can customize via `display-buffer-alist`.


        Stefan

Re: customize location and shape of a new window in a frame

[N. Jackson]

At 14:22 -0700 on Tuesday 2018-09-11, Eric Abrahamsen wrote:
>
> Assuming the user is running BBDB with Gnus, Gnus has its own window
> layout system, and you need to work with that. Usually that looks like:
>
> (add-to-list 'gnus-window-to-buffer
>        `(bbdb-gnus . "*BBDB*"))
>
> (gnus-add-configuration
>   (article
>     ,(cond
>       (gnus-use-trees
>        '(vertical 1.0
> 		  (summary 0.25 point)
> 		  (tree 0.25)
> 		  (horizontal 1.0
> 			      (article 1.0)
> 			      (bbdb-gnus 0.4))))
>       (t
>        '(vertical 1.0
> 		  (summary 0.25 point)
> 		  (horizontal 1.0
> 			      (article 1.0)
> 			      (bbdb-gnus 0.4))))))

Evaluating the second form gives:

Debugger entered--Lisp error: (void-function article)
  (article ,(cond (gnus-use-trees '(vertical 1.0 (summary 0.25 point) (tree 0.25) (horizontal 1.0 (article 1.0) (bbdb-gnus 0.4)))) (t '(vertical 1.0 (summary 0.25 point) (horizontal 1.0 (article 1.0) (bbdb-gnus 0.4))))))
  eval((article ,(cond (gnus-use-trees '(vertical 1.0 (summary 0.25 point) (tree 0.25) (horizontal 1.0 ... ...))) (t '(vertical 1.0 (summary 0.25 point) (horizontal 1.0 ... ...))))) nil)

Re: customize location and shape of a new window in a frame

[Eric Abrahamsen]

On 09/12/18 15:36 PM, N. Jackson wrote:
> At 14:22 -0700 on Tuesday 2018-09-11, Eric Abrahamsen wrote:
>>
>> Assuming the user is running BBDB with Gnus, Gnus has its own window
>> layout system, and you need to work with that. Usually that looks like:
>>
>> (add-to-list 'gnus-window-to-buffer
>>        `(bbdb-gnus . "*BBDB*"))
>>
>> (gnus-add-configuration
>>   (article
>>     ,(cond
>>       (gnus-use-trees
>>        '(vertical 1.0
>> 		  (summary 0.25 point)
>> 		  (tree 0.25)
>> 		  (horizontal 1.0
>> 			      (article 1.0)
>> 			      (bbdb-gnus 0.4))))
>>       (t
>>        '(vertical 1.0
>> 		  (summary 0.25 point)
>> 		  (horizontal 1.0
>> 			      (article 1.0)
>> 			      (bbdb-gnus 0.4))))))
>
> Evaluating the second form gives:
>
> Debugger entered--Lisp error: (void-function article)
>   (article ,(cond (gnus-use-trees '(vertical 1.0 (summary 0.25 point)
> (tree 0.25) (horizontal 1.0 (article 1.0) (bbdb-gnus 0.4)))) (t
> '(vertical 1.0 (summary 0.25 point) (horizontal 1.0 (article 1.0)
> (bbdb-gnus 0.4))))))
>   eval((article ,(cond (gnus-use-trees '(vertical 1.0 (summary 0.25
> point) (tree 0.25) (horizontal 1.0 ... ...))) (t '(vertical 1.0
> (summary 0.25 point) (horizontal 1.0 ... ...))))) nil)

Yup, that was a cut-and-paste problem from my larger config. Just stick
a ` before the "(article" part.

Sorry about that,
Eric

Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[N. Jackson]

Thanks Eric,

At 13:12 -0700 on Wednesday 2018-09-12, Eric Abrahamsen wrote:
>
> On 09/12/18 15:36 PM, N. Jackson wrote:
>> At 14:22 -0700 on Tuesday 2018-09-11, Eric Abrahamsen wrote:
>>>
>>> (add-to-list 'gnus-window-to-buffer
>>>        `(bbdb-gnus . "*BBDB*"))
>>>
>>> (gnus-add-configuration
>>>   (article
>>>     ,(cond
>>>       (gnus-use-trees
>>>        '(vertical 1.0
>>> 		  (summary 0.25 point)
>>> 		  (tree 0.25)
>>> 		  (horizontal 1.0
>>> 			      (article 1.0)
>>> 			      (bbdb-gnus 0.4))))
>>>       (t
>>>        '(vertical 1.0
>>> 		  (summary 0.25 point)
>>> 		  (horizontal 1.0
>>> 			      (article 1.0)
>>> 			      (bbdb-gnus 0.4))))))
>>
>> Evaluating the second form gives:
>>
>> Debugger entered--Lisp error: (void-function article)
>
> Yup, that was a cut-and-paste problem from my larger config. Just stick
> a ` before the "(article" part.

After quoting with a ' (not a `) and removing the comma before the
`cond', this does exactly what I was looking for. I now have the
following in my .gnus file:

  ;;; 2018-09-12 Arrange for Gnus to place BBDB window sensibly.
  (add-to-list 'gnus-window-to-buffer
	       `(bbdb-gnus . "*BBDB*"))
  (gnus-add-configuration
   '(article
     (cond
      (gnus-use-trees
       '(vertical 1.0
		  (summary 0.25 point)
		  (tree 0.25)
		  (horizontal 1.0
			      (article 1.0)
			      (bbdb-gnus 0.4))))
      (t
       '(vertical 1.0
		  (summary 0.25 point)
		  (horizontal 1.0
			      (article 1.0)
			      (bbdb-gnus 0.4)))))))


However, it seems odd to be able to get this:

  +-------------------------------+
  |                               |
  |           Summary             |
  |                               |
  +-------------------------------+
  |                               |
  |                               |
  |           Article             |
  |                               |
  |                               |
  |-------------------------------|
  |            BBDB               |
  +-------------------------------+
  
and this:

  +-------------------------------+
  |                   |           |
  |      Summary      |   BBDB    |
  |                   |           |
  +-------------------------------+
  |                               |
  |                               |
  |                               |
  |            Article            |
  |                               |
  |                               |
  |                               |
  +-------------------------------+

simply by customizing the variable `bbdb-mua-pop-up', but in order
to get

  +-------------------------------+
  |                               |
  |           Summary             |
  |                               |
  +-------------------------------+
  |                   |           |
  |                   |           |
  |                   |           |
  |      Article      |   BBDB    |
  |                   |           |
  |                   |           |
  |                   |           |
  +-------------------------------+

the user has to do some fairly heavy-duty configuration in Gnus. I'm
impressed by the power of this feature in Gnus, but it feels like
overkill for a case like this.

It seems to me that what is really needed is a new function or three.

Currently `bbdb-pop-up-window' uses `split-window' to display its
window. The problem here is that `split-window' takes a WINDOW
argument so BBDB first has to figure out which window to split.

If there was a function (frame-split-biggest-window FRAME SIZE SIDE
PIXELWISE) to split the "biggest" [*] window in the frame, then
neither BBDB nor any other Elisp code would need to keep reinventing
this wheel.

(The other two functions, more for interactive use, would be
`frame-split-biggest-window-below' and
`frame-split-biggest-window-right'.)

[*] To find the "biggest" window when splitting below, find the
tallest window or windows and split the widest of them; when
splitting right, find the widest window or windows and split the
tallest of them.

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[martin rudalics]

 > If there was a function (frame-split-biggest-window FRAME SIZE SIDE
 > PIXELWISE) to split the "biggest" [*] window in the frame, then
 > neither BBDB nor any other Elisp code would need to keep reinventing
 > this wheel.
 >
 > (The other two functions, more for interactive use, would be
 > `frame-split-biggest-window-below' and
 > `frame-split-biggest-window-right'.)
 >
 > [*] To find the "biggest" window when splitting below, find the
 > tallest window or windows and split the widest of them; when
 > splitting right, find the widest window or windows and split the
 > tallest of them.

We have a number of options for that.  One of them is the option
'split-window-preferred-function' (a misnomer) which is by default set
to 'split-window-sensibly'.  Consult their definitions first.  The
latter's behavior is guided by the options 'split-height-threshold'
and 'split-width-threshold' (two more misnomers) .  Together, these
should provide a boilerplate for writing your own function which you
can then put into 'display-buffer-alist'.

One functionality Emacs is sadly lacking is that of orderly setting up
and saving compositions of windows in form of a rectangle.  Eclipse
calls these "perspectives", in Emacs the concept of "window state"
comes most closely.  Currently, you have to set up such a state by
using a sequence of 'split-window' calls which requires to know the
intrinsics of window splitting, the relationship of parent and child
windows, window combinations and the like.  Using 'display-buffer' for
setting up states will hardly produce good results.

It would be nice to have some sort of basic, prefabricated layouts
like the ones you sketched and choose from them (though a four window
layout with a different window in each corner of them frame would
still require to know whether the root window is a vertical or
horizontal combination).  But I have no good idea yet which layout
types are really needed and how to provide a suitable interface for
accessing them.  IIRC the "Emacs IDE" had provisions for them but I
have not heard from its developers for years.

martin

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[N. Jackson]

At 09:45 +0200 on Thursday 2018-09-13, martin rudalics wrote:
>
>> If there was a function (frame-split-biggest-window FRAME SIZE SIDE
>> PIXELWISE) to split the "biggest" [*] window in the frame, then
>> neither BBDB nor any other Elisp code would need to keep reinventing
>> this wheel.
>>
>> (The other two functions, more for interactive use, would be
>> `frame-split-biggest-window-below' and
>> `frame-split-biggest-window-right'.)
>>
>> [*] To find the "biggest" window when splitting below, find the
>> tallest window or windows and split the widest of them; when
>> splitting right, find the widest window or windows and split the
>> tallest of them.
>
> We have a number of options for that.  One of them is the option
> 'split-window-preferred-function' (a misnomer) which is by default set
> to 'split-window-sensibly'.  Consult their definitions first.  The
> latter's behavior is guided by the options 'split-height-threshold'
> and 'split-width-threshold' (two more misnomers) .  Together, these
> should provide a boilerplate for writing your own function which you
> can then put into 'display-buffer-alist'.

What's missing with these functions is that they start from a given
window. What's needed is functionality that looks at all the windows
on (in?) the frame and chooses which one to split.

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Eric Abrahamsen]

martin rudalics <rudalics@gmx.at> writes:

>> If there was a function (frame-split-biggest-window FRAME SIZE SIDE
>> PIXELWISE) to split the "biggest" [*] window in the frame, then
>> neither BBDB nor any other Elisp code would need to keep reinventing
>> this wheel.
>>
>> (The other two functions, more for interactive use, would be
>> `frame-split-biggest-window-below' and
>> `frame-split-biggest-window-right'.)
>>
>> [*] To find the "biggest" window when splitting below, find the
>> tallest window or windows and split the widest of them; when
>> splitting right, find the widest window or windows and split the
>> tallest of them.
>
> We have a number of options for that.  One of them is the option
> 'split-window-preferred-function' (a misnomer) which is by default set
> to 'split-window-sensibly'.  Consult their definitions first.  The
> latter's behavior is guided by the options 'split-height-threshold'
> and 'split-width-threshold' (two more misnomers) .  Together, these
> should provide a boilerplate for writing your own function which you
> can then put into 'display-buffer-alist'.
>
> One functionality Emacs is sadly lacking is that of orderly setting up
> and saving compositions of windows in form of a rectangle.  Eclipse
> calls these "perspectives", in Emacs the concept of "window state"
> comes most closely.  Currently, you have to set up such a state by
> using a sequence of 'split-window' calls which requires to know the
> intrinsics of window splitting, the relationship of parent and child
> windows, window combinations and the like.  Using 'display-buffer' for
> setting up states will hardly produce good results.
>
> It would be nice to have some sort of basic, prefabricated layouts
> like the ones you sketched and choose from them (though a four window
> layout with a different window in each corner of them frame would
> still require to know whether the root window is a vertical or
> horizontal combination).  But I have no good idea yet which layout
> types are really needed and how to provide a suitable interface for
> accessing them.  IIRC the "Emacs IDE" had provisions for them but I
> have not heard from its developers for years.

I thought this is what side windows are for? Maybe it would be tricky to
save and restore whole-frame window configurations (though there are
other tools for that), but side windows, combined perhaps with atomic
windows, seem like the right tool for making rectangular compositions.
The docs even say something about making Emacs look like a traditional
IDE, etc...

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Eric Abrahamsen]

"N. Jackson" <nljlistbox2@gmail.com> writes:

> Thanks Eric,
>
> At 13:12 -0700 on Wednesday 2018-09-12, Eric Abrahamsen wrote:
>>
>> On 09/12/18 15:36 PM, N. Jackson wrote:
>>> At 14:22 -0700 on Tuesday 2018-09-11, Eric Abrahamsen wrote:
>>>>
>>>> (add-to-list 'gnus-window-to-buffer
>>>>        `(bbdb-gnus . "*BBDB*"))
>>>>
>>>> (gnus-add-configuration
>>>>   (article
>>>>     ,(cond
>>>>       (gnus-use-trees
>>>>        '(vertical 1.0
>>>> 		  (summary 0.25 point)
>>>> 		  (tree 0.25)
>>>> 		  (horizontal 1.0
>>>> 			      (article 1.0)
>>>> 			      (bbdb-gnus 0.4))))
>>>>       (t
>>>>        '(vertical 1.0
>>>> 		  (summary 0.25 point)
>>>> 		  (horizontal 1.0
>>>> 			      (article 1.0)
>>>> 			      (bbdb-gnus 0.4))))))
>>>
>>> Evaluating the second form gives:
>>>
>>> Debugger entered--Lisp error: (void-function article)
>>
>> Yup, that was a cut-and-paste problem from my larger config. Just stick
>> a ` before the "(article" part.
>
> After quoting with a ' (not a `) and removing the comma before the
> `cond', this does exactly what I was looking for. I now have the
> following in my .gnus file:

That code was taken from EBDB, where I wanted to make sure the pop-up
worked correctly regardless of whether the user used Gnus trees or not:
you could just delete the cond and one of the branches, depending on
whether you use tree view or not.

>;;; 2018-09-12 Arrange for Gnus to place BBDB window sensibly.
>   (add-to-list 'gnus-window-to-buffer
> 	       `(bbdb-gnus . "*BBDB*"))
>   (gnus-add-configuration
>    '(article
>      (cond
>       (gnus-use-trees
>        '(vertical 1.0
> 		  (summary 0.25 point)
> 		  (tree 0.25)
> 		  (horizontal 1.0
> 			      (article 1.0)
> 			      (bbdb-gnus 0.4))))
>       (t
>        '(vertical 1.0
> 		  (summary 0.25 point)
> 		  (horizontal 1.0
> 			      (article 1.0)
> 			      (bbdb-gnus 0.4)))))))
>
>
> However, it seems odd to be able to get this:
>
>   +-------------------------------+
>   |                               |
>   |           Summary             |
>   |                               |
>   +-------------------------------+
>   |                               |
>   |                               |
>   |           Article             |
>   |                               |
>   |                               |
>   |-------------------------------|
>   |            BBDB               |
>   +-------------------------------+
>   
> and this:
>
>   +-------------------------------+
>   |                   |           |
>   |      Summary      |   BBDB    |
>   |                   |           |
>   +-------------------------------+
>   |                               |
>   |                               |
>   |                               |
>   |            Article            |
>   |                               |
>   |                               |
>   |                               |
>   +-------------------------------+
>
> simply by customizing the variable `bbdb-mua-pop-up', but in order
> to get
>
>   +-------------------------------+
>   |                               |
>   |           Summary             |
>   |                               |
>   +-------------------------------+
>   |                   |           |
>   |                   |           |
>   |                   |           |
>   |      Article      |   BBDB    |
>   |                   |           |
>   |                   |           |
>   |                   |           |
>   +-------------------------------+
>
> the user has to do some fairly heavy-duty configuration in Gnus. I'm
> impressed by the power of this feature in Gnus, but it feels like
> overkill for a case like this.

I haven't used BBDB for a while, but I could have sworn there was
someplace where you can put a predicate callable that could return the
window to split. I think it was the HORIZ-P argument to
`bbdb-pop-up-window' that can be a function (it should return t when it
is called with the article window as an argument), but now I don't
remember how the HORIZ-P predicate gets passed in.

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Roland Winkler]

On Thu Sep 13 2018 martin rudalics wrote:
> One functionality Emacs is sadly lacking is that of orderly setting up
> and saving compositions of windows in form of a rectangle.  Eclipse
> calls these "perspectives", in Emacs the concept of "window state"
> comes most closely.  Currently, you have to set up such a state by
> using a sequence of 'split-window' calls which requires to know the
> intrinsics of window splitting, the relationship of parent and child
> windows, window combinations and the like.  Using 'display-buffer' for
> setting up states will hardly produce good results.

Much agreed!

How is it possible that (as confirmed on this list)
gnus-window-to-buffer and gnus-add-configuration can be used to make
BBDB interact with Gnus windows as expected, while BBDB's function
bbdb-pop-up-window for creating BBDB windows does not know anything
about Gnus' mechanism for managing window layouts?  When I first
heard of gnus-window-to-buffer and gnus-add-configuration I thought
this cannot work with BBDB because Gnus will bring its own
hand-crafted functions to create windows, functions that obey the
customizations using gnus-window-to-buffer and gnus-add-configuration.

> It would be nice to have some sort of basic, prefabricated layouts
> like the ones you sketched and choose from them.

Again: much agreed!

Can `display-buffer-alist' mentioned by Stefan do that (at least: in
principle)?  I looked at its documentation in the elisp manual (not
the Emacs manual!), and I could not figure out how to use this
variable to achieve the goals discussed here.  Does
`display-buffer-alist' provide the same functionality as the Gnus
code discussed in this thread?

Certainly, it would be nice if different packages like Gnus and
other MUAs could use the same code for the generic problem of
defining window layouts so that a package like BBDB can interact
with this, too.

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[martin rudalics]

 >> We have a number of options for that.  One of them is the option
 >> 'split-window-preferred-function' (a misnomer) which is by default set
 >> to 'split-window-sensibly'.  Consult their definitions first.  The
 >> latter's behavior is guided by the options 'split-height-threshold'
 >> and 'split-width-threshold' (two more misnomers) .  Together, these
 >> should provide a boilerplate for writing your own function which you
 >> can then put into 'display-buffer-alist'.
 >
 > What's missing with these functions is that they start from a given
 > window. What's needed is functionality that looks at all the windows
 > on (in?) the frame and chooses which one to split.

Specifying such heuristics is non-trivial - 'display-buffer' tries to
first split the largest and then the least recently used window.
Maybe we should refine 'get-largest-window' in the spirit of
'split-window-sensibly'.  But when the latter was introduced, there
were a number of complaints because the behavior of 'display-buffer'
changed in an unexpected way - people were surprised to suddenly see a
window split horizontally.  So any changes should be done carefully.

Also, some buffer display action functions roughly try to split the
window as one at the top or bottom of the frame or the selected one in
order to show the buffer there.  And you can put a window on any side
of a frame by using side windows.  All these try to reconcile window
splitting and reusing to achieve the intended effect.

martin

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[martin rudalics]

 >> It would be nice to have some sort of basic, prefabricated layouts
 >> like the ones you sketched and choose from them (though a four window
 >> layout with a different window in each corner of them frame would
 >> still require to know whether the root window is a vertical or
 >> horizontal combination).  But I have no good idea yet which layout
 >> types are really needed and how to provide a suitable interface for
 >> accessing them.  IIRC the "Emacs IDE" had provisions for them but I
 >> have not heard from its developers for years.
 >
 > I thought this is what side windows are for? Maybe it would be tricky to
 > save and restore whole-frame window configurations (though there are
 > other tools for that), but side windows, combined perhaps with atomic
 > windows, seem like the right tool for making rectangular compositions.
 > The docs even say something about making Emacs look like a traditional
 > IDE, etc...

The intention of side windows was to provide a framework for ECB (the
Emacs Code Browser) to embed such layouts without the need to advice
basic window functions.  Unfortunately, work on ECB seems to have
stalled a decade ago and nobody seems very interested in continuing
it.

martin

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[martin rudalics]

 > Can `display-buffer-alist' mentioned by Stefan do that (at least: in
 > principle)?  I looked at its documentation in the elisp manual (not
 > the Emacs manual!), and I could not figure out how to use this
 > variable to achieve the goals discussed here.  Does
 > `display-buffer-alist' provide the same functionality as the Gnus
 > code discussed in this thread?

The purpose of 'display-buffer-alist' is to set up a window for one
single buffer.  It already fails miserably to make sure that two
buffers get displayed simultaneously as the thread of Bug#32607 shows.

martin

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Stefan Monnier]

>> Can `display-buffer-alist' mentioned by Stefan do that (at least: in
>> principle)?  I looked at its documentation in the elisp manual (not
>> the Emacs manual!), and I could not figure out how to use this
>> variable to achieve the goals discussed here.  Does
>> `display-buffer-alist' provide the same functionality as the Gnus
>> code discussed in this thread?
> The purpose of 'display-buffer-alist' is to set up a window for one
> single buffer.  It already fails miserably to make sure that two
> buffers get displayed simultaneously as the thread of Bug#32607 shows.

Exactly.  So for the purpose of "orderly setting up
and saving compositions of windows", it's of no use, but in the specific
case of BBDB (which just needs to (temporarily) pop up a single buffer),
it should be sufficient.


        Stefan

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Eric Abrahamsen]

martin rudalics <rudalics@gmx.at> writes:

>>> It would be nice to have some sort of basic, prefabricated layouts
>>> like the ones you sketched and choose from them (though a four window
>>> layout with a different window in each corner of them frame would
>>> still require to know whether the root window is a vertical or
>>> horizontal combination).  But I have no good idea yet which layout
>>> types are really needed and how to provide a suitable interface for
>>> accessing them.  IIRC the "Emacs IDE" had provisions for them but I
>>> have not heard from its developers for years.
>>
>> I thought this is what side windows are for? Maybe it would be tricky to
>> save and restore whole-frame window configurations (though there are
>> other tools for that), but side windows, combined perhaps with atomic
>> windows, seem like the right tool for making rectangular compositions.
>> The docs even say something about making Emacs look like a traditional
>> IDE, etc...
>
> The intention of side windows was to provide a framework for ECB (the
> Emacs Code Browser) to embed such layouts without the need to advice
> basic window functions.  Unfortunately, work on ECB seems to have
> stalled a decade ago and nobody seems very interested in continuing
> it.

Huh, thanks for the background. But in my experimentation, at least,
side windows seem to work perfectly well (especially in combination with
atomic windows). Is there any particular reason not to use them?

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The purpose of 'display-buffer-alist' is to set up a window for one
  > single buffer.

Perhaps the doc string and/or the manual should explicitly clarify
this point.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Roland Winkler]

On Fri Sep 14 2018 Stefan Monnier wrote:
> > The purpose of 'display-buffer-alist' is to set up a window for one
> > single buffer.  It already fails miserably to make sure that two
> > buffers get displayed simultaneously as the thread of Bug#32607 shows.
> 
> Exactly.  So for the purpose of "orderly setting up and saving
> compositions of windows", it's of no use, but in the specific case
> of BBDB (which just needs to (temporarily) pop up a single
> buffer), it should be sufficient.

The current discussion of 'display-buffer-alist' in the elisp manual
appears rather technical, suited only for expert users.  On the
other hand, the variable is declared with defcustom, as if
individual users should customize it to their personal liking.
Phrased differently: a package like BBDB should not hijack this
variable for its needs (but at best it could contribute to its value
via a user option), correct?

If that's the case, then it would really help to extend the
documentation for this variable, stating not only that it works only
for a single buffer, but also adding one or two real-world examples
similar to what we have been discussing here.

I believe it is quite common that users may want to customize how
emacs pops up new windows.  Having a unified customization scheme
for that would be much nicer than having different approaches
implemented in different packages.

RE: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Drew Adams]

> The current discussion of 'display-buffer-alist' in the elisp manual
> appears rather technical, suited only for expert users.  On the
> other hand, the variable is declared with defcustom, as if
> individual users should customize it to their personal liking.
> Phrased differently: a package like BBDB should not hijack this
> variable for its needs (but at best it could contribute to its value
> via a user option), correct?
> 
> If that's the case, then it would really help to extend the
> documentation for this variable, stating not only that it works only
> for a single buffer, but also adding one or two real-world examples
> similar to what we have been discussing here.
> 
> I believe it is quite common that users may want to customize how
> emacs pops up new windows.  Having a unified customization scheme
> for that would be much nicer than having different approaches
> implemented in different packages.

+1

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[martin rudalics]

 > Huh, thanks for the background. But in my experimentation, at least,
 > side windows seem to work perfectly well (especially in combination with
 > atomic windows). Is there any particular reason not to use them?

Hopefully not.  They should work well, even if not perfectly.

martin

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[martin rudalics]

 >    > The purpose of 'display-buffer-alist' is to set up a window for one
 >    > single buffer.
 >
 > Perhaps the doc string and/or the manual should explicitly clarify
 > this point.

My sentence above is misleading: It's a sloppy abbreviation for the
two sentences

"The purpose of 'display-buffer' is to set up a window for one single
buffer.  Hence 'display-buffer-alist' can only be used for customizing
the setup of a window for one single buffer - the one specified by the
first argument of 'display-buffer'."

So if anything would have to be clarified here, it's the doc of
'display-buffer'.  Now conceptually, 'display-buffer' can be called
multiple times in a row and should do something reasonable in that
case - if programmed correctly.  But it cannot be used for setting up
windows for two or more buffers in one single call and that should be
evident from its doc-string.

martin

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[martin rudalics]

 > The current discussion of 'display-buffer-alist' in the elisp manual
 > appears rather technical, suited only for expert users.  On the
 > other hand, the variable is declared with defcustom, as if
 > individual users should customize it to their personal liking.
 > Phrased differently: a package like BBDB should not hijack this
 > variable for its needs (but at best it could contribute to its value
 > via a user option), correct?

I think so.  No package should hijack this variable for its needs -
it's entirely left to the user.  Packages like BBDB should only use
the ACTION argument of 'display-buffer'.  Only in a few, special and
well documented cases, 'display-buffer-overriding-action' may be used
to override a user's customization of 'display-buffer-alist'.

 > If that's the case, then it would really help to extend the
 > documentation for this variable, stating not only that it works only
 > for a single buffer, but also adding one or two real-world examples
 > similar to what we have been discussing here.
 >
 > I believe it is quite common that users may want to customize how
 > emacs pops up new windows.  Having a unified customization scheme
 > for that would be much nicer than having different approaches
 > implemented in different packages.

There is an example at the end of section 28.14.  If you want it to
say things differently, say more, or whether to put it somewhere else
please tell us.

martin

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[N. Jackson]

At 08:01 -0400 on Friday 2018-09-14, Stefan Monnier wrote:
>
>> The purpose of 'display-buffer-alist' is to set up a window for
>> one single buffer. It already fails miserably to make sure that
>> two buffers get displayed simultaneously as the thread of
>> Bug#32607 shows.
>
> Exactly. So for the purpose of "orderly setting up and saving
> compositions of windows", it's of no use, but in the specific case
> of BBDB (which just needs to (temporarily) pop up a single
> buffer), it should be sufficient.

The BBDB window isn't as ephemeral as a completions window is (for
example) which just needs to pop up temporarily. Here I have the
BBDB window displayed at all times when I'm reading mail and news --
it displays the records for the sender and/or recipients of the
message.

Perhaps `display-buffer-alist' is sufficient for the BBDB case. As
its documentation is a little unclear (while recursive code is okay,
recursive documentation is a little bit trying), it would be nice to
see an example of how this might be done.

It seems to me that it requires the developer or the user to write
code (to iterate through all the windows in the frame) that will be
almost identical to the code that the OP of this thread suggested
should not need to be reinvented by every developer/user wanting to
do essentially the same thing; rather the functionality should be
provided by the Emacs infrastructure.

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Stefan Monnier]

> Perhaps `display-buffer-alist' is sufficient for the BBDB case. As
> its documentation is a little unclear (while recursive code is okay,
> recursive documentation is a little bit trying), it would be nice to
> see an example of how this might be done.
                        ^^^^

I don't know what this "this" refers to.
If you mean "customize the location and shape", then I think currently
the answer will depend a lot on what "location" and what "shape"
you want.
But I think "side window" is part of the answer.


        Stefan

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Roland Winkler]

On Sat Sep 15 2018 martin rudalics wrote:
> I think so.  No package should hijack this variable for its needs -
> it's entirely left to the user.  Packages like BBDB should only use
> the ACTION argument of 'display-buffer'.  

Thanks for the clarification!  So BBDB can use the ACTION argument
of 'display-buffer'.  Then it can also just provide a default for
ACTION which users can customize if they do not like it (via some
BBDB user variable).  Such a working default may help users that
want to customize this, but they feel overwhelmed by how this works.

> There is an example at the end of section 28.14.

Great, this was exactly what I was looking for.

> If you want it to say things differently, say more, or whether to
> put it somewhere else please tell us.

- As `display-buffer-alist' is the variable that users want to
  customize (hence: it is the entry point for people wanting to
  customize these things), I suggest that the description of
  `display-buffer-alist' in the elisp manual should include a link
  to the example in section 28.14.

- If I understand correctly, the example in Sec. 28.14 is slightly
  outdated: 

  window-height is an outdated alias for window-total-height
  and window-width is an outdated alias for window-body-width
  (as described in the node Window sizes of the elisp manual).

  This applies also to the description of
  `display-buffer-below-selected' and possibly other spots in the
  elisp manual.

- Is there a possibility to specify, using an ACTION, that a new
  window should take over a certain fraction of an existing window
  in a vertical split?  I believe this is a common case.  (I may be
  missing that this is described somewhere.)

(I thought that `display-buffer-alist' was only mentioned in the
elisp manual but not in the emacs manual.  Yet this was my mistake
due to my configuration of info-lookup that jumps straight to the
elisp manual.)

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Stefan Monnier]

> - Is there a possibility to specify, using an ACTION, that a new
>   window should take over a certain fraction of an existing window
>   in a vertical split?  I believe this is a common case.  (I may be
>   missing that this is described somewhere.)

ACTION can be any function you like, so the answer is obviously yes.
But I don't think there's currently a pre-existing function which does
that, no.


        Stefan

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Roland Winkler]

On Sat Sep 15 2018 Stefan Monnier wrote:
> > - Is there a possibility to specify, using an ACTION, that a new
> >   window should take over a certain fraction of an existing window
> >   in a vertical split?  I believe this is a common case.  (I may be
> >   missing that this is described somewhere.)
> 
> ACTION can be any function you like, so the answer is obviously yes.
> But I don't think there's currently a pre-existing function which does
> that, no.

To make the ACTION arg attractive for a wider range of use cases, I
believe it would be helpful to provide a function that can help with
this.  Yet currently my understanding of the ACTION machinery is too
limited for more specific suggestions of how such a function should
work and hook into this machinery.  (Certainly it is not desirable
if multple packages wanting to use such an approach had to invent
the wheel repeatedly.)

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > My sentence above is misleading: It's a sloppy abbreviation for the
  > two sentences

If the actual text is already clear enough, that's fine with me.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[John Yates]

Having struggled unsuccessfully in the past with display-buffer
I can state that for me the current text is insufficient.  I found
Martin's recent clarification helpful.  I have bookmarked it for
my own purposes and vote for incorporating something along
those lines into the official manual.

/john

On Sat, Sep 15, 2018 at 11:16 PM Richard Stallman <rms@gnu.org> wrote:
>
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > My sentence above is misleading: It's a sloppy abbreviation for the
>   > two sentences
>
> If the actual text is already clear enough, that's fine with me.
>
>
> --
> Dr Richard Stallman
> President, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>


-- 
John Yates
505 Tremont St, #803
Boston, MA 02116

Re: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Sun, 16 Sep 2018 15:05:19 -0400
> Cc: nljlistbox2@gmail.com, eric@ericabrahamsen.net, winkler@gnu.org,
> 	Emacs developers <emacs-devel@gnu.org>, martin rudalics <rudalics@gmx.at>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>
> 
> I can state that for me the current text is insufficient.  I found
> Martin's recent clarification helpful.  I have bookmarked it for
> my own purposes and vote for incorporating something along
> those lines into the official manual.

I'm sure Martin will do that.

Thanks.

RE: Suggesting `frame-split-biggest-window' Re: customize location and shape of a new window in a frame

[Drew Adams]

> Having struggled unsuccessfully in the past with display-buffer
> I can state that for me the current text is insufficient.  I found
> Martin's recent clarification helpful.  I have bookmarked it for
> my own purposes and vote for incorporating something along
> those lines into the official manual.

+1