all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#40888: M-x man: don't redraw good pages when not finding bad pages
@ 2020-04-26 22:59 積丹尼 Dan Jacobson
  2020-04-27  8:33 ` Tomas Nordin
  0 siblings, 1 reply; 12+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-04-26 22:59 UTC (permalink / raw)
  To: 40888

$ 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".





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-04-26 22:59 bug#40888: M-x man: don't redraw good pages when not finding bad pages 積丹尼 Dan Jacobson
@ 2020-04-27  8:33 ` Tomas Nordin
  2020-04-27 14:54   ` 積丹尼 Dan Jacobson
  0 siblings, 1 reply; 12+ messages in thread
From: Tomas Nordin @ 2020-04-27  8:33 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson, 40888

積丹尼 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.





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-04-27  8:33 ` Tomas Nordin
@ 2020-04-27 14:54   ` 積丹尼 Dan Jacobson
  2020-04-27 15:07     ` Stefan Kangas
  0 siblings, 1 reply; 12+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-04-27 14:54 UTC (permalink / raw)
  To: Tomas Nordin; +Cc: 40888

>>>>> "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.





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-04-27 14:54   ` 積丹尼 Dan Jacobson
@ 2020-04-27 15:07     ` Stefan Kangas
  2020-04-27 20:25       ` Tomas Nordin
  2020-08-05 11:28       ` Lars Ingebrigtsen
  0 siblings, 2 replies; 12+ messages in thread
From: Stefan Kangas @ 2020-04-27 15:07 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: Tomas Nordin, 40888

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





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-04-27 15:07     ` Stefan Kangas
@ 2020-04-27 20:25       ` Tomas Nordin
  2020-08-05 11:28       ` Lars Ingebrigtsen
  1 sibling, 0 replies; 12+ messages in thread
From: Tomas Nordin @ 2020-04-27 20:25 UTC (permalink / raw)
  To: Stefan Kangas, 積丹尼 Dan Jacobson; +Cc: 40888

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





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-04-27 15:07     ` Stefan Kangas
  2020-04-27 20:25       ` Tomas Nordin
@ 2020-08-05 11:28       ` Lars Ingebrigtsen
  2020-08-06  5:32         ` 積丹尼 Dan Jacobson
  1 sibling, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-05 11:28 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Tomas Nordin, 40888, 積丹尼 Dan Jacobson

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





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-08-05 11:28       ` Lars Ingebrigtsen
@ 2020-08-06  5:32         ` 積丹尼 Dan Jacobson
  2020-08-06  7:17           ` Lars Ingebrigtsen
  2020-08-06 13:40           ` Eli Zaretskii
  0 siblings, 2 replies; 12+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-08-06  5:32 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Tomas Nordin, 40888, Stefan Kangas

>>>>> "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.





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-08-06  5:32         ` 積丹尼 Dan Jacobson
@ 2020-08-06  7:17           ` Lars Ingebrigtsen
  2020-08-06 13:40           ` Eli Zaretskii
  1 sibling, 0 replies; 12+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-06  7:17 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: Tomas Nordin, 40888, Stefan Kangas

積丹尼 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





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-08-06  5:32         ` 積丹尼 Dan Jacobson
  2020-08-06  7:17           ` Lars Ingebrigtsen
@ 2020-08-06 13:40           ` Eli Zaretskii
  2020-08-06 17:39             ` 積丹尼 Dan Jacobson
  1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2020-08-06 13:40 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: larsi, 40888, stefan, tomasn

> 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?





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-08-06 13:40           ` Eli Zaretskii
@ 2020-08-06 17:39             ` 積丹尼 Dan Jacobson
  2020-08-06 17:41               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 12+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-08-06 17:39 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 40888, stefan, tomasn

>>>>> "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.





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-08-06 17:39             ` 積丹尼 Dan Jacobson
@ 2020-08-06 17:41               ` Lars Ingebrigtsen
  2022-02-20 14:17                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-06 17:41 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 40888, stefan, tomasn

積丹尼 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





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

* bug#40888: M-x man: don't redraw good pages when not finding bad pages
  2020-08-06 17:41               ` Lars Ingebrigtsen
@ 2022-02-20 14:17                 ` Lars Ingebrigtsen
  0 siblings, 0 replies; 12+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-20 14:17 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 40888, stefan, tomasn

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





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

end of thread, other threads:[~2022-02-20 14:17 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-26 22:59 bug#40888: M-x man: don't redraw good pages when not finding bad pages 積丹尼 Dan Jacobson
2020-04-27  8:33 ` Tomas Nordin
2020-04-27 14:54   ` 積丹尼 Dan Jacobson
2020-04-27 15:07     ` Stefan Kangas
2020-04-27 20:25       ` Tomas Nordin
2020-08-05 11:28       ` Lars Ingebrigtsen
2020-08-06  5:32         ` 積丹尼 Dan Jacobson
2020-08-06  7:17           ` Lars Ingebrigtsen
2020-08-06 13:40           ` Eli Zaretskii
2020-08-06 17:39             ` 積丹尼 Dan Jacobson
2020-08-06 17:41               ` Lars Ingebrigtsen
2022-02-20 14:17                 ` Lars Ingebrigtsen

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.