GNU bug report logs - #38164
quit-restore-window doesn't restore point in man

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38164 in the body.
You can then email your comments to 38164 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: quit-restore-window doesn't restore point in man
Date: Sun, 10 Nov 2019 22:45:08 +0200

Creating a new bug report as a spin-off of bug#19064.

>> But this problem is not new.  The same can be reproduced
>> in older versions with
>>
>> (progn
>>    (man "XYZ")
>>    (read-string "-->"))
>>
>> This is because quit-restore-window moves point to wrong window.
>
> What should 'quit-restore-window' do here in particular?

quit-restore-window should move point to old-selected-window,
i.e. the minibuffer window that was selected before Man-bgproc-sentinel
kicked in.  But I don't understand why it's not doing that.

Message #8 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Mon, 11 Nov 2019 10:33:45 +0100

>>> (progn
>>>     (man "XYZ")
>>>     (read-string "-->"))
>>>
>>> This is because quit-restore-window moves point to wrong window.
>>
>> What should 'quit-restore-window' do here in particular?
>
> quit-restore-window should move point to old-selected-window,
> i.e. the minibuffer window that was selected before Man-bgproc-sentinel
> kicked in.  But I don't understand why it's not doing that.

I'm not sure what you mean.  At the time 'man' calls 'display-buffer',
the latter simply records the window returned by 'selected-window' as
the one to reselect when the *Man XYZ* window gets deleted.  That
recorded window is not the minibuffer window here, even if I evaluate
the form via M-:.  Am I missing something?

martin

Message #11 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Tue, 12 Nov 2019 22:50:12 +0200

>>>> (progn
>>>>     (man "XYZ")
>>>>     (read-string "-->"))
>>>>
>>>> This is because quit-restore-window moves point to wrong window.
>>>
>>> What should 'quit-restore-window' do here in particular?
>>
>> quit-restore-window should move point to old-selected-window,
>> i.e. the minibuffer window that was selected before Man-bgproc-sentinel
>> kicked in.  But I don't understand why it's not doing that.
>
> I'm not sure what you mean.  At the time 'man' calls 'display-buffer',
> the latter simply records the window returned by 'selected-window' as
> the one to reselect when the *Man XYZ* window gets deleted.  That
> recorded window is not the minibuffer window here, even if I evaluate
> the form via M-:.  Am I missing something?

Removing these lines from 'quit-restore-window' fixes the problem:

      ;; Select old window.
      (when (window-live-p (nth 2 quit-restore))
        (select-window (nth 2 quit-restore)))

If there lines are the whole purpose of 'quit-restore-window',
then in man.el we need to reselect the original window explicitly:

diff --git a/lisp/man.el b/lisp/man.el
index ce01fdc805..76890f74a9 100644
--- a/lisp/man.el
+++ b/lisp/man.el
@@ -1469,8 +1469,10 @@ Man-bgproc-sentinel
 
       (when delete-buff
         (if (window-live-p (get-buffer-window Man-buffer t))
-            (quit-restore-window
-             (get-buffer-window Man-buffer t) 'kill)
+            (progn
+              (quit-restore-window
+               (get-buffer-window Man-buffer t) 'kill)
+              (select-window (old-selected-window)))
           (kill-buffer Man-buffer)))
 
       (when message

Message #14 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Wed, 13 Nov 2019 09:04:12 +0100

> Removing these lines from 'quit-restore-window' fixes the problem:
>
>        ;; Select old window.
>        (when (window-live-p (nth 2 quit-restore))
>          (select-window (nth 2 quit-restore)))
>
> If there lines are the whole purpose of 'quit-restore-window',
> then in man.el we need to reselect the original window explicitly:
>
> diff --git a/lisp/man.el b/lisp/man.el
> index ce01fdc805..76890f74a9 100644
> --- a/lisp/man.el
> +++ b/lisp/man.el
> @@ -1469,8 +1469,10 @@ Man-bgproc-sentinel
>
>         (when delete-buff
>           (if (window-live-p (get-buffer-window Man-buffer t))
> -            (quit-restore-window
> -             (get-buffer-window Man-buffer t) 'kill)
> +            (progn
> +              (quit-restore-window
> +               (get-buffer-window Man-buffer t) 'kill)
> +              (select-window (old-selected-window)))
>             (kill-buffer Man-buffer)))
>
>         (when message

I'm completely lost now.  Can you tell me in a detailed fashion what
goes wrong here?  Is the window stored in (nth 2 quit-restore) the
wrong window right from the outset?  Or is it in a sense falsified by
what happens later during minibuffer interaction?

martin

Message #17 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Wed, 13 Nov 2019 23:29:10 +0200

>> @@ -1469,8 +1469,10 @@ Man-bgproc-sentinel
>>
>>         (when delete-buff
>>           (if (window-live-p (get-buffer-window Man-buffer t))
>> -            (quit-restore-window
>> -             (get-buffer-window Man-buffer t) 'kill)
>> +            (progn
>> +              (quit-restore-window
>> +               (get-buffer-window Man-buffer t) 'kill)
>> +              (select-window (old-selected-window)))
>>             (kill-buffer Man-buffer)))
>
> I'm completely lost now.  Can you tell me in a detailed fashion what
> goes wrong here?  Is the window stored in (nth 2 quit-restore) the
> wrong window right from the outset?  Or is it in a sense falsified by
> what happens later during minibuffer interaction?

(progn
  (man "XYZ")
  (read-string "--> "))

'read-string' activates the minibuffer, but asynchronous Man-bgproc-sentinel
later calls 'quit-restore-window' that selects its previous window,
ignoring the fact that now the selected window was in the minibuffer.
So we need an exception for the case of active minibuffer.

Message #20 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Thu, 14 Nov 2019 10:20:09 +0100

> (progn
>    (man "XYZ")
>    (read-string "--> "))
>
> 'read-string' activates the minibuffer, but asynchronous Man-bgproc-sentinel
> later calls 'quit-restore-window' that selects its previous window,
> ignoring the fact that now the selected window was in the minibuffer.
> So we need an exception for the case of active minibuffer.

So what you want is probably (twice)

      (when (and (window-live-p (nth 2 quit-restore))
                 (not (eq (selected-window) (minibuffer-window))))
	(select-window (nth 2 quit-restore))))

But note that quitting the minibuffer will restore the previous window
configuration and thus undo that selection and all other changes done
by 'quit-restore-window' anyway.

martin

Message #23 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Fri, 15 Nov 2019 01:13:46 +0200

>> (progn
>>    (man "XYZ")
>>    (read-string "--> "))
>>
>> 'read-string' activates the minibuffer, but asynchronous Man-bgproc-sentinel
>> later calls 'quit-restore-window' that selects its previous window,
>> ignoring the fact that now the selected window was in the minibuffer.
>> So we need an exception for the case of active minibuffer.
>
> So what you want is probably (twice)
>
>       (when (and (window-live-p (nth 2 quit-restore))
>                  (not (eq (selected-window) (minibuffer-window))))
> 	(select-window (nth 2 quit-restore))))
>
> But note that quitting the minibuffer will restore the previous window
> configuration and thus undo that selection and all other changes done
> by 'quit-restore-window' anyway.

Is it possible to not restore the previous window configuration
when quitting the minibuffer?

Message #26 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Fri, 15 Nov 2019 09:13:09 +0100

> Is it possible to not restore the previous window configuration
> when quitting the minibuffer?

No.  It's a very elaborate scheme in read_minibuf triggered by

  record_unwind_protect (restore_buffer, Fcurrent_buffer ());

  choose_minibuf_frame ();

  record_unwind_protect_void (choose_minibuf_frame);

  record_unwind_protect (restore_window_configuration,
			 Fcurrent_window_configuration (Qnil));

  /* If the minibuffer window is on a different frame, save that
     frame's configuration too.  */
  mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
  if (!EQ (mini_frame, selected_frame))
    record_unwind_protect (restore_window_configuration,
			   Fcurrent_window_configuration (mini_frame));

so it may even save two window configurations.

martin

Message #29 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Mon, 18 Nov 2019 23:21:27 +0200

>> Is it possible to not restore the previous window configuration
>> when quitting the minibuffer?
>
> No.  It's a very elaborate scheme in read_minibuf triggered by
>
>   record_unwind_protect (restore_buffer, Fcurrent_buffer ());

Why should quitting the minibuffer restore the previous window configuration?

Sometimes to get help on a previously run M-x command, typing

  M-x M-p C-h f RET

displays the function Help window about the previous command. Then clicking
on the link with the source file name in the Help buffer opens its source code.
This creates a nice window layout with the Help window and the source window.
But quitting the minibuffer destroys this nice layout, and returns some
old obsolete layout.  Why should it do this?

Message #32 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Tue, 19 Nov 2019 05:28:35 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Date: Mon, 18 Nov 2019 23:21:27 +0200
> Cc: 38164 <at> debbugs.gnu.org
> 
> Sometimes to get help on a previously run M-x command, typing
> 
>   M-x M-p C-h f RET
> 
> displays the function Help window about the previous command. Then clicking
> on the link with the source file name in the Help buffer opens its source code.
> This creates a nice window layout with the Help window and the source window.
> But quitting the minibuffer destroys this nice layout, and returns some
> old obsolete layout.  Why should it do this?

Because that's what quitting help does?  If you don't want this, just
don't quit; you can simply leave the windows as they were and
continue.

Message #35 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Juri Linkov <juri <at> linkov.net>
Cc: 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Tue, 19 Nov 2019 08:56:54 +0100

> Because that's what quitting help does?  If you don't want this, just
> don't quit; you can simply leave the windows as they were and
> continue.

IIUC Juri doesn't want to quit help.  He wants to leave the
minibuffer, maybe for running another command.

martin

Message #38 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38164 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Tue, 19 Nov 2019 18:06:44 +0200

> Cc: 38164 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Tue, 19 Nov 2019 08:56:54 +0100
> 
>  > Because that's what quitting help does?  If you don't want this, just
>  > don't quit; you can simply leave the windows as they were and
>  > continue.
> 
> IIUC Juri doesn't want to quit help.  He wants to leave the
> minibuffer, maybe for running another command.

Apologies if I was confused, but Juri explicitly asked about "quitting
the minibuffer".

Message #41 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38164 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Tue, 19 Nov 2019 17:53:29 +0100

>>   > Because that's what quitting help does?  If you don't want this, just
>>   > don't quit; you can simply leave the windows as they were and
>>   > continue.
>>
>> IIUC Juri doesn't want to quit help.  He wants to leave the
>> minibuffer, maybe for running another command.
>
> Apologies if I was confused, but Juri explicitly asked about "quitting
> the minibuffer".

Quitting help should never destroy a window layout these days.  If it
did, we'd have a bug.  Quitting the minibuffer, for example via C-g,
may destroy the window layout (of two frames even).  But I'll let Juri
speak for himself now.

martin

Message #44 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38164 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Tue, 19 Nov 2019 19:36:14 +0200

> Cc: juri <at> linkov.net, 38164 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Tue, 19 Nov 2019 17:53:29 +0100
> 
>  >>   > Because that's what quitting help does?  If you don't want this, just
>  >>   > don't quit; you can simply leave the windows as they were and
>  >>   > continue.
>  >>
>  >> IIUC Juri doesn't want to quit help.  He wants to leave the
>  >> minibuffer, maybe for running another command.
>  >
>  > Apologies if I was confused, but Juri explicitly asked about "quitting
>  > the minibuffer".
> 
> Quitting help should never destroy a window layout these days.  If it
> did, we'd have a bug.

Sounds like there's some misunderstanding.  What I mean is this:

  emacs -Q
  C-h f find-file RET (any function will do)
  C-x o
  q

The last 'q' command deletes the window showing *Help*, and that is
what I call "quitting help".  I believe Emacs behaved like that since
time immemoriam.

Message #47 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38164 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Tue, 19 Nov 2019 19:15:54 +0100

>> Quitting help should never destroy a window layout these days.  If it
>> did, we'd have a bug.
>
> Sounds like there's some misunderstanding.  What I mean is this:
>
>    emacs -Q
>    C-h f find-file RET (any function will do)
>    C-x o
>    q
>
> The last 'q' command deletes the window showing *Help*, and that is
> what I call "quitting help".  I believe Emacs behaved like that since
> time immemoriam.

Try with Emacs 22 and, for example,

emacs -Q
C-x 2
C-h f find-file RET (any function will do)
C-x o
q

Tempus fugit.

martin

Message #50 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Wed, 20 Nov 2019 01:03:01 +0200

>>>   > Because that's what quitting help does?  If you don't want this, just
>>>   > don't quit; you can simply leave the windows as they were and
>>>   > continue.
>>>
>>> IIUC Juri doesn't want to quit help.  He wants to leave the
>>> minibuffer, maybe for running another command.
>>
>> Apologies if I was confused, but Juri explicitly asked about "quitting
>> the minibuffer".
>
> Quitting help should never destroy a window layout these days.  If it
> did, we'd have a bug.  Quitting the minibuffer, for example via C-g,
> may destroy the window layout (of two frames even).  But I'll let Juri
> speak for himself now.

This is the case that I meant:

 emacs -Q

 M-x info               ;; don't type RET
 C-h f RET              ;; describe function 'info'
 C-x o C-x o            ;; switch to Help window
 <tab> <return>         ;; visit info.el from help link
 C-x o C-x o            ;; switch to minibuffer
 C-g                    ;; exit minibuffer

Message #53 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Wed, 20 Nov 2019 08:59:06 +0100

> This is the case that I meant:
>
>   emacs -Q
>
>   M-x info               ;; don't type RET
>   C-h f RET              ;; describe function 'info'
>   C-x o C-x o            ;; switch to Help window
>   <tab> <return>         ;; visit info.el from help link
>   C-x o C-x o            ;; switch to minibuffer
>   C-g                    ;; exit minibuffer

And if the minibuffer appears on another frame, it will reset that
frame as well.  We could make the behavior customizable with an option
say 'exit-minibuffer-restore-window-configuration', t by default.

martin

Message #56 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Wed, 20 Nov 2019 18:02:14 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  38164 <at> debbugs.gnu.org
> Date: Wed, 20 Nov 2019 01:03:01 +0200
> 
>  emacs -Q
> 
>  M-x info               ;; don't type RET
>  C-h f RET              ;; describe function 'info'
>  C-x o C-x o            ;; switch to Help window
>  <tab> <return>         ;; visit info.el from help link
>  C-x o C-x o            ;; switch to minibuffer
>  C-g                    ;; exit minibuffer

How is this different from the below?

 emacs -Q

 M-x info               ;; don't type RET
 C-h f RET              ;; describe function 'info'
 C-g

IOW, a C-g means "get me out of here all the way to top-level", so it
removes all the windows created by whatever you did in the aborted
operation.  (Of course, the buffers are still there, and if you have
tab-line-mode turned on, you can easily get them displayed ;-)

Message #59 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Thu, 21 Nov 2019 00:35:44 +0200

>>   M-x info               ;; don't type RET
>>   C-h f RET              ;; describe function 'info'
>>   C-x o C-x o            ;; switch to Help window
>>   <tab> <return>         ;; visit info.el from help link
>>   C-x o C-x o            ;; switch to minibuffer
>>   C-g                    ;; exit minibuffer
>
> And if the minibuffer appears on another frame, it will reset that
> frame as well.  We could make the behavior customizable with an option
> say 'exit-minibuffer-restore-window-configuration', t by default.

I'm not sure if I'll ever want to customize such a new variable
'exit-minibuffer-restore-window-configuration' to nil,
because sometimes it's desirable to restore a previous
window configuration, sometimes not.

But at least it could help to resolve the remaining problem in man.el,
if other solutions are not possible.

Message #62 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: martin rudalics <rudalics <at> gmx.at>, 38164 <at> debbugs.gnu.org
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Mon, 21 Sep 2020 15:08:10 +0200

Juri Linkov <juri <at> linkov.net> writes:

> -            (quit-restore-window
> -             (get-buffer-window Man-buffer t) 'kill)
> +            (progn
> +              (quit-restore-window
> +               (get-buffer-window Man-buffer t) 'kill)
> +              (select-window (old-selected-window)))

The discussion then dealt mostly with general quit-restore-windows
issues, but I think this patch should be applied, since it fixes an
annoying problem in Man.  So I've now pushed it to Emacs 28.

Skimming the rest of this thread, there doesn't seem to be a lot of hope
for making any progress on the general issue, so I'm closing this bug
report, and perhaps a new one (or an emacs-devel) discussion would be
appropriate.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #71 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 38164 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Sun, 04 Apr 2021 19:13:01 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Juri Linkov <juri <at> linkov.net> writes:
>
>> -            (quit-restore-window
>> -             (get-buffer-window Man-buffer t) 'kill)
>> +            (progn
>> +              (quit-restore-window
>> +               (get-buffer-window Man-buffer t) 'kill)
>> +              (select-window (old-selected-window)))
>
> The discussion then dealt mostly with general quit-restore-windows
> issues, but I think this patch should be applied, since it fixes an
> annoying problem in Man.  So I've now pushed it to Emacs 28.

This gives rise to the following regression:

0. emacs -Q
1. (setq Man-notify-method 'aggressive) C-x C-e
2. M-x man RET mythical RET

This used to pop up and very quickly hide a window (but that's a
separate issue), and then the echo area displayed:

  Can't find the mythical manpage

Whereas now the phantom window remains displayed much longer, the echo
area displays:

  error in process sentinel:
  Wrong type argument: window-live-p, #<window 8>

and the *Messages* buffer also contains:

  error in process sentinel:
  Man-bgproc-sentinel: Wrong type argument: window-live-p, #<window 8>

Ideally a non-existent manpage would result only in the "can't find"
message, without any inadvertent Lisp errors or window dances.

Thanks,

-- 
Basil

Message #74 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: larsi <at> gnus.org, 38164 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Sun, 04 Apr 2021 21:28:38 +0300

> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Date: Sun, 04 Apr 2021 19:13:01 +0100
> Cc: 38164 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > Juri Linkov <juri <at> linkov.net> writes:
> >
> >> -            (quit-restore-window
> >> -             (get-buffer-window Man-buffer t) 'kill)
> >> +            (progn
> >> +              (quit-restore-window
> >> +               (get-buffer-window Man-buffer t) 'kill)
> >> +              (select-window (old-selected-window)))
> >
> > The discussion then dealt mostly with general quit-restore-windows
> > issues, but I think this patch should be applied, since it fixes an
> > annoying problem in Man.  So I've now pushed it to Emacs 28.
> 
> This gives rise to the following regression:
> 
> 0. emacs -Q
> 1. (setq Man-notify-method 'aggressive) C-x C-e
> 2. M-x man RET mythical RET
> 
> This used to pop up and very quickly hide a window (but that's a
> separate issue), and then the echo area displayed:
> 
>   Can't find the mythical manpage
> 
> Whereas now the phantom window remains displayed much longer, the echo
> area displays:
> 
>   error in process sentinel:
>   Wrong type argument: window-live-p, #<window 8>
> 
> and the *Messages* buffer also contains:
> 
>   error in process sentinel:
>   Man-bgproc-sentinel: Wrong type argument: window-live-p, #<window 8>

So we traded a minor issue for a more serious one.  (And if I try the
recipe which triggered that change, I see a perfectly expected
behavior in Emacs 24.)

I think that change should be reverted.

Message #77 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 38164 <at> debbugs.gnu.org,
 juri <at> linkov.net
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Sun, 04 Apr 2021 21:19:44 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> So we traded a minor issue for a more serious one.  (And if I try the
> recipe which triggered that change, I see a perfectly expected
> behavior in Emacs 24.)
>
> I think that change should be reverted.

The recipe is unclear -- I think it's really

M-x man RET man RET
select the man window
M-: (progn (man "XYZ") (read-string "-->"))

In Emacs 27, this will pop out of the read-string, which is the bug?

I'd rather fix the (setq Man-notify-method 'aggressive) regression than
bring that awkward interface bug back.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #80 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: contovob <at> tcd.ie, 38164 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Sun, 04 Apr 2021 22:36:00 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>,  38164 <at> debbugs.gnu.org,
>   juri <at> linkov.net
> Date: Sun, 04 Apr 2021 21:19:44 +0200
> 
> The recipe is unclear -- I think it's really
> 
> M-x man RET man RET
> select the man window
> M-: (progn (man "XYZ") (read-string "-->"))

Do you understand the practical importance of the last command?  IOW,
in which practical use case will 'man' be called like that?

> In Emacs 27, this will pop out of the read-string, which is the bug?

A very minor annoyance, I'd say.  It's easy dealt with.

> I'd rather fix the (setq Man-notify-method 'aggressive) regression than
> bring that awkward interface bug back.

If there's a practical use case there, I might agree.  Otherwise, we
will be jumping through hoops for a reason that isn't necessarily a
good one.

Message #83 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 38164 <at> debbugs.gnu.org,
 juri <at> linkov.net
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Sun, 04 Apr 2021 21:38:18 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I'd rather fix the (setq Man-notify-method 'aggressive) regression than
> bring that awkward interface bug back.

I've now worked around the issue with the immediate error in this
setting, but the basic issue still remains -- in some of the
Man-notify-method methods, the error ends up changing the selected
window upon an error (which shouldn't happen).

Somebody should go through all the combinations for that variable and
iron out the problems so that this never happens (and open a new bug
report for that).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #86 received at 38164 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: contovob <at> tcd.ie, 38164 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38164: quit-restore-window doesn't restore point in man
Date: Sun, 04 Apr 2021 21:40:17 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> The recipe is unclear -- I think it's really
>> 
>> M-x man RET man RET
>> select the man window
>> M-: (progn (man "XYZ") (read-string "-->"))
>
> Do you understand the practical importance of the last command?  IOW,
> in which practical use case will 'man' be called like that?

The practical issue was that you do an M-x man on something, and then
start doing something else (for instance a new M-x).  The error message
reported asynchronously will then select a random different buffer.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.