bug#40888: M-x man: don't redraw good pages when not finding bad pages

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[積丹尼 Dan Jacobson]

$ emacs -q
M-x man cat
M-x man dog

Why does it have to redraw the entire cat man page, before just saying
it can't find dog? Why can't it just say it can't find dog?
Just leave the good page there undisturbed.

Redrawing the cat man page makes our eyes think maybe it has got
something new, when it hasn't.

It also distracts us from noticing the failure message in the
minibuffer.

emacs-version "26.3".

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[Tomas Nordin]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> $ emacs -q
> M-x man cat
> M-x man dog
>
> Why does it have to redraw the entire cat man page, before just saying
> it can't find dog? Why can't it just say it can't find dog?
> Just leave the good page there undisturbed.

I think it is fixed to work like that, it does here with 28.0.50.

Maybe this news item is relevant

*** New function 'display-buffer-reuse-mode-window' is an action function
suitable for use in 'display-buffer-alist'.  For example, to avoid
creating a new window when opening man pages when there's already one,
use

(add-to-list 'display-buffer-alist
     '("\\`\\*Man .*\\*\\'" .
       (display-buffer-reuse-mode-window
        (inhibit-same-window . nil)
        (mode . Man-mode))))

under the super heading * Lisp Changes in Emacs 26.1.

> emacs-version "26.3".

Confusing then. But maybe that function was used later for the man
rendering.

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[積丹尼 Dan Jacobson]

>>>>> "TN" == Tomas Nordin <tomasn@posteo.net> writes:
TN> under the super heading * Lisp Changes in Emacs 26.1.
Well all I know is with 26.3,
emacs or emacs -nw,
I still see a blink (the whole cat man page redrawn) when I do M-x man dog.

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[Stefan Kangas]

Dan Jacobson <jidanni@jidanni.org> writes:

> >>>>> "TN" == Tomas Nordin <tomasn@posteo.net> writes:
> TN> under the super heading * Lisp Changes in Emacs 26.1.
> Well all I know is with 26.3,
> emacs or emacs -nw,
> I still see a blink (the whole cat man page redrawn) when I do M-x man dog.

I can reproduce this here.

GNU Emacs 28.0.50 (build 51, x86_64-pc-linux-gnu, GTK+ Version
3.24.18, cairo version 1.16.0) of 2020-04-25

Best regards,
Stefan Kangas

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[Tomas Nordin]

Stefan Kangas <stefan@marxist.se> writes:

> Dan Jacobson <jidanni@jidanni.org> writes:
>
>> >>>>> "TN" == Tomas Nordin <tomasn@posteo.net> writes:
>> TN> under the super heading * Lisp Changes in Emacs 26.1.
>> Well all I know is with 26.3,
>> emacs or emacs -nw,
>> I still see a blink (the whole cat man page redrawn) when I do M-x man dog.
>
> I can reproduce this here.

Me too. I misunderstood and thought that the cat man buffer was
destroyed. But yes, I see the blink too, now I get the point.

>
> GNU Emacs 28.0.50 (build 51, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.18, cairo version 1.16.0) of 2020-04-25
>
> Best regards,
> Stefan Kangas

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> >>>>> "TN" == Tomas Nordin <tomasn@posteo.net> writes:
>> TN> under the super heading * Lisp Changes in Emacs 26.1.
>> Well all I know is with 26.3,
>> emacs or emacs -nw,
>> I still see a blink (the whole cat man page redrawn) when I do M-x man dog.
>
> I can reproduce this here.

Me too...  but I don't think there's a redrawing of the cat page,
really.

What seems to be happening is that M-x man RET dog RET pops up a "*Man
dog*" buffer in a window, and then starts working in the background.

And then it can't find the dog man page, and then kills the buffer (and
window).

This makes everything redisplay, which is the blink we're seeing.

I'm not sure whether anything can be done about this -- it's an artefact
of working asynchronously, and then restoring window configurations.

Anybody got any ideas?

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

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[積丹尼 Dan Jacobson]

>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:
LI> Me too...  but I don't think there's a redrawing of the cat page,
LI> really.

LI> What seems to be happening is that M-x man RET dog RET pops up a "*Man
LI> dog*" buffer in a window, and then starts working in the background.

LI> And then it can't find the dog man page, and then kills the buffer (and
LI> window).

LI> This makes everything redisplay, which is the blink we're seeing.

LI> I'm not sure whether anything can be done about this -- it's an artefact
LI> of working asynchronously, and then restoring window configurations.

LI> Anybody got any ideas?

Well, just like we don't purchase a house for our client before we check
if he has money in the bank, even if it means waiting for business
hours, it seems the program should first make sure what it intends to
display even exists. "test -f" certainly won't slow things down that much.

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> Well, just like we don't purchase a house for our client before we check
> if he has money in the bank, even if it means waiting for business
> hours, it seems the program should first make sure what it intends to
> display even exists. "test -f" certainly won't slow things down that much.

What would you test to see whether the "man" command is going to be
successful or not?

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

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
>  <jidanni@jidanni.org>
> Date: Thu, 06 Aug 2020 13:32:51 +0800
> Cc: Tomas Nordin <tomasn@posteo.net>, 40888@debbugs.gnu.org,
>  Stefan Kangas <stefan@marxist.se>
> 
> Well, just like we don't purchase a house for our client before we check
> if he has money in the bank, even if it means waiting for business
> hours, it seems the program should first make sure what it intends to
> display even exists. "test -f" certainly won't slow things down that much.

"test -f" won't do the job, because 'man' employs a non-trivial logic
to find the man page, using environment variables, command-line
options, and hardcoded directories and file names.  IOW, there's no
easy way of knowing what to put after "test -f".

Sounds like you are suggesting that Emacs either (a) reproduces all
that 'man' logic internally (not easily done, as different
implementations vary in how they do it), or (b)rely on 'man' itself
telling whether the file exists, which AFAIK must use command-line
options that aren't necessarily available in all versions of 'man', to
say nothing about slowing down the command due to duplicate
invocation.

All that to solve a minor annoyance?  Is that really justified?

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
>> From: 積丹尼 Dan Jacobson
>> <jidanni@jidanni.org>
>> Date: Thu, 06 Aug 2020 13:32:51 +0800
>> Cc: Tomas Nordin <tomasn@posteo.net>, 40888@debbugs.gnu.org,
>> Stefan Kangas <stefan@marxist.se>
>> 
>> Well, just like we don't purchase a house for our client before we check
>> if he has money in the bank, even if it means waiting for business
>> hours, it seems the program should first make sure what it intends to
>> display even exists. "test -f" certainly won't slow things down that much.

EZ> "test -f" won't do the job, because 'man' employs a non-trivial logic
EZ> to find the man page, using environment variables, command-line
EZ> options, and hardcoded directories and file names.  IOW, there's no
EZ> easy way of knowing what to put after "test -f".

EZ> Sounds like you are suggesting that Emacs either (a) reproduces all
EZ> that 'man' logic internally (not easily done, as different
EZ> implementations vary in how they do it), or (b)rely on 'man' itself
EZ> telling whether the file exists, which AFAIK must use command-line
EZ> options that aren't necessarily available in all versions of 'man', to
EZ> say nothing about slowing down the command due to duplicate
EZ> invocation.

EZ> All that to solve a minor annoyance?  Is that really justified?

OK, instead of
1. Make a buffer
2. Get the stuff to put into it.
3. Put that stuff into it.

Do:
2. Get the stuff to put into it.
1. Make a buffer
3. Put that stuff into it.

That way if (2) fails, it can quit before (1) happens, instead of before
(3) happens.

Just like at theaters, one doesn't change the stage set for actor B, if
he isn't coming tonight, then have to change it back so actor A can keep
acting some more.

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> Do:
> 2. Get the stuff to put into it.
> 1. Make a buffer
> 3. Put that stuff into it.
>
> That way if (2) fails, it can quit before (1) happens, instead of before
> (3) happens.

No, when doing async stuff that opens buffers, Emacs tries to open the
buffer first before doing anything -- because popping up a buffer
a random amount of time later can be annoying and steal keyboard focus
and stuff.

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

bug#40888: M-x man: don't redraw good pages when not finding bad pages

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> No, when doing async stuff that opens buffers, Emacs tries to open the
> buffer first before doing anything -- because popping up a buffer
> a random amount of time later can be annoying and steal keyboard focus
> and stuff.

So I think the conclusion here is that this is working as designed, and
I'm therefore closing this bug report.

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