unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#24828: 26.0.50; Renaming of display-buffer-in-major-side-window broke which-key.el
@ 2016-10-30 18:21 Óscar Fuentes
  2016-10-30 19:34 ` martin rudalics
  0 siblings, 1 reply; 7+ messages in thread
From: Óscar Fuentes @ 2016-10-30 18:21 UTC (permalink / raw)
  To: 24828


As the subject says. Maybe an alias is in order?

I don't know if there are more cases like this.


In GNU Emacs 26.0.50.1 (x86_64-pc-linux-gnu, X toolkit)
 of 2016-10-21 built on qcore
Repository revision: 0929e061fb544c0f4c10ff0412a41cf7e8148270
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:	Ubuntu 16.10





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#24828: 26.0.50; Renaming of display-buffer-in-major-side-window broke which-key.el
  2016-10-30 18:21 bug#24828: 26.0.50; Renaming of display-buffer-in-major-side-window broke which-key.el Óscar Fuentes
@ 2016-10-30 19:34 ` martin rudalics
       [not found]   ` <CAF5dqNJWV28XF4=qT3zcm1CygP_UYUqTLFjrAp-y9qQ1a7WH-Q@mail.gmail.com>
  0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2016-10-30 19:34 UTC (permalink / raw)
  To: Óscar Fuentes, 24828, justin

 > Renaming of display-buffer-in-major-side-window broke which-key.el
 >
 > As the subject says. Maybe an alias is in order?
 >
 > I don't know if there are more cases like this.

Hmm...  all this is obviously my fault.  As a matter of fact, I wasn't
aware that side windows were anywhere used at all.

The problem is that ‘display-buffer-in-major-side-window’, which I
renamed to ‘window--make-major-side-window’, actually is an internal
function which should not be used outside of window.el.  With other
words: If there is anything ‘window--make-major-side-window’ does which
‘display-buffer-in-side-window’ doesn't, then I should fix that in the
latter rather than exposing the side window internals.

I added the author to the list of recipients.  Maybe he can tell us
more.  If there's no other way, I'll obviously make the alias.

Thanks for the report, martin






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#24828: 26.0.50; Renaming of display-buffer-in-major-side-window broke which-key.el
       [not found]   ` <CAF5dqNJWV28XF4=qT3zcm1CygP_UYUqTLFjrAp-y9qQ1a7WH-Q@mail.gmail.com>
@ 2016-10-31  7:42     ` martin rudalics
  2016-10-31 17:31       ` Justin Burkett
  2016-10-31 18:23       ` Óscar Fuentes
  0 siblings, 2 replies; 7+ messages in thread
From: martin rudalics @ 2016-10-31  7:42 UTC (permalink / raw)
  To: Justin Burkett, 24828

 > I wasn't aware that that function was internal, since it appears to
 > function like the other display-buffer actions.

Unfortunately so.  It was my fault to pretend otherwise.

 > If I remember right that
 > code was written by a contributor, and I don't remember the motivation for
 > choosing that one. If it really is internal then I will investigate
 > changing to the proper method when I have some more time.

I see.  The problem is that the structure on the right

     ;; +-------------------------+         +-------------------------+
     ;; |     regular window      |         |     regular window      |
     ;; |                         |         +------------+------------+
     ;; +------------+------------+   -->   | side-win 1 | side-win 2 |
     ;; | side-win 1 | side-win 2 |         |------------+------------|
     ;; |            |            |         |     which-key window    |
     ;; +------------+------------+         +------------+------------+

was never really supported.  I initially wanted to allow that but later
found out that I cannot reliably split side windows in both directions.
It might work with Emacs 24 in a few basic use cases but will surely
break with more complicated setups.  So you essentially will have to
fall back on

     ;; +-------------------------+
     ;; |     regular window      |
     ;; |                         |
     ;; +------+-------+----------|
     ;; | side-| side- | which-key|
     ;; | win-1| win-2 | window   |
     ;; +------+-------+----------+

or

     ;; +-------------------------+
     ;; |     regular window      |
     ;; |                         |
     ;; +----------- +------------|
     ;; | side-win-1 | which-key  |
     ;; |            | window     |
     ;; +------------+------------+

sooner or later anyway.  For this, ‘which-key’ should either supply a
side window slot value for customization and/or tell the user how to
customize ‘display-buffer-alist’ for displaying the which-key window.
Then the user can decide which windows she wants which-key to share with
(the completions window looks like a good candidate because it's
ephemeral too).

Note that side windows were initially designed as more persistent but I
can easily see that the ‘which-key’ use case might come in pretty handy
too.  Hence it should be possible to make the side-win-1 and side-win-2
windows temporarily very small in order to give the which-key window
sufficient space.

 From what I've seen, ‘which-key’ is a fine mode, very neatly written.
It should be in ELPA.  In any case, keep up the good work.

martin






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#24828: 26.0.50; Renaming of display-buffer-in-major-side-window broke which-key.el
  2016-10-31  7:42     ` martin rudalics
@ 2016-10-31 17:31       ` Justin Burkett
  2016-11-01  7:41         ` martin rudalics
  2016-10-31 18:23       ` Óscar Fuentes
  1 sibling, 1 reply; 7+ messages in thread
From: Justin Burkett @ 2016-10-31 17:31 UTC (permalink / raw)
  To: martin rudalics; +Cc: 24828

[-- Attachment #1: Type: text/plain, Size: 2958 bytes --]

Martin,

Thank you for the explanation (and for the kind words). I will follow your
suggestions.

Best,
Justin

On Mon, Oct 31, 2016 at 3:42 AM, martin rudalics <rudalics@gmx.at> wrote:

> > I wasn't aware that that function was internal, since it appears to
> > function like the other display-buffer actions.
>
> Unfortunately so.  It was my fault to pretend otherwise.
>
> > If I remember right that
> > code was written by a contributor, and I don't remember the motivation
> for
> > choosing that one. If it really is internal then I will investigate
> > changing to the proper method when I have some more time.
>
> I see.  The problem is that the structure on the right
>
>     ;; +-------------------------+         +-------------------------+
>     ;; |     regular window      |         |     regular window      |
>     ;; |                         |         +------------+------------+
>     ;; +------------+------------+   -->   | side-win 1 | side-win 2 |
>     ;; | side-win 1 | side-win 2 |         |------------+------------|
>     ;; |            |            |         |     which-key window    |
>     ;; +------------+------------+         +------------+------------+
>
> was never really supported.  I initially wanted to allow that but later
> found out that I cannot reliably split side windows in both directions.
> It might work with Emacs 24 in a few basic use cases but will surely
> break with more complicated setups.  So you essentially will have to
> fall back on
>
>     ;; +-------------------------+
>     ;; |     regular window      |
>     ;; |                         |
>     ;; +------+-------+----------|
>     ;; | side-| side- | which-key|
>     ;; | win-1| win-2 | window   |
>     ;; +------+-------+----------+
>
> or
>
>     ;; +-------------------------+
>     ;; |     regular window      |
>     ;; |                         |
>     ;; +----------- +------------|
>     ;; | side-win-1 | which-key  |
>     ;; |            | window     |
>     ;; +------------+------------+
>
> sooner or later anyway.  For this, ‘which-key’ should either supply a
> side window slot value for customization and/or tell the user how to
> customize ‘display-buffer-alist’ for displaying the which-key window.
> Then the user can decide which windows she wants which-key to share with
> (the completions window looks like a good candidate because it's
> ephemeral too).
>
> Note that side windows were initially designed as more persistent but I
> can easily see that the ‘which-key’ use case might come in pretty handy
> too.  Hence it should be possible to make the side-win-1 and side-win-2
> windows temporarily very small in order to give the which-key window
> sufficient space.
>
> From what I've seen, ‘which-key’ is a fine mode, very neatly written.
> It should be in ELPA.  In any case, keep up the good work.
>
> martin
>
>

[-- Attachment #2: Type: text/html, Size: 3748 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#24828: 26.0.50; Renaming of display-buffer-in-major-side-window broke which-key.el
  2016-10-31  7:42     ` martin rudalics
  2016-10-31 17:31       ` Justin Burkett
@ 2016-10-31 18:23       ` Óscar Fuentes
  2016-11-01  7:41         ` martin rudalics
  1 sibling, 1 reply; 7+ messages in thread
From: Óscar Fuentes @ 2016-10-31 18:23 UTC (permalink / raw)
  To: martin rudalics; +Cc: 24828-done, Justin Burkett

which-key.el was "fixed" with the following commit message:

 Remove use of display-buffer-in-major-side-window

 According to emacs bug #24828, this is an internal function and should
 not be used. Following the advice from that report, switch to
 display-buffer-in-side-window and add an option for the user to specify
 the slot value for that function.

Closing this bug. Let's hope that there are no more packages out there
that use this function(s).





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#24828: 26.0.50; Renaming of display-buffer-in-major-side-window broke which-key.el
  2016-10-31 17:31       ` Justin Burkett
@ 2016-11-01  7:41         ` martin rudalics
  0 siblings, 0 replies; 7+ messages in thread
From: martin rudalics @ 2016-11-01  7:41 UTC (permalink / raw)
  To: Justin Burkett; +Cc: 24828

Thank you very much for fixing this on your side.

BTW, you might eventually want to make the first sentence of doc-strings
always occupy the first line of the doc-string.  This makes them work
better with things like ‘eldoc-mode’.  Also the doc-strings of
‘which-key-side-window-max-width/-height’ do not quite match their
customization type - IIUC the latter always ask for a float.

martin






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#24828: 26.0.50; Renaming of display-buffer-in-major-side-window broke which-key.el
  2016-10-31 18:23       ` Óscar Fuentes
@ 2016-11-01  7:41         ` martin rudalics
  0 siblings, 0 replies; 7+ messages in thread
From: martin rudalics @ 2016-11-01  7:41 UTC (permalink / raw)
  To: Óscar Fuentes; +Cc: 24828-done, Justin Burkett

 > Closing this bug.

Thanks again for reporting it.

 > Let's hope that there are no more packages out there
 > that use this function(s).

Fingers crossed.

martin





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2016-11-01  7:41 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-30 18:21 bug#24828: 26.0.50; Renaming of display-buffer-in-major-side-window broke which-key.el Óscar Fuentes
2016-10-30 19:34 ` martin rudalics
     [not found]   ` <CAF5dqNJWV28XF4=qT3zcm1CygP_UYUqTLFjrAp-y9qQ1a7WH-Q@mail.gmail.com>
2016-10-31  7:42     ` martin rudalics
2016-10-31 17:31       ` Justin Burkett
2016-11-01  7:41         ` martin rudalics
2016-10-31 18:23       ` Óscar Fuentes
2016-11-01  7:41         ` martin rudalics

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).