bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[asocial-hired.0l--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hello,

I am running latest emacs, built today (./configure —with-native-compilation —without-pop). This is also bug in earlier versions.

When running `M-x man <RET> command-name ` where this is a command-name followed by a space, MacOS Ventura emacs in some cases lags heavily and some cases crashes.

I find through investigation, for example, when it is `M-x man <RET> 2[ ]`, 2 followed by a space, it performs the equivalent ‘man -k ^’ and ‘man -k ^2’ internally. On my Linux VM, running 5.14.8-arch1-1, this is a non-issue, and speaking to others on Linux systems, it is also a non-issue there. 

I have fixed this temporarily on my MacOS machine by giving man advice; however, this same advice causes man not to work on my Linux VM.

Currently, it is a non-issue for me, but I would like to report it nonetheless.

Best,
An emacs user

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Eli Zaretskii]

> Date: Thu, 27 Apr 2023 14:10:40 -0700
> From: asocial-hired.0l--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Hello,
> 
> I am running latest emacs, built today (./configure —with-native-compilation —without-pop). This is also bug in earlier versions.
> 
> When running `M-x man <RET> command-name ` where this is a command-name followed by a space, MacOS Ventura emacs in some cases lags heavily and some cases crashes.
> 
> I find through investigation, for example, when it is `M-x man <RET> 2[ ]`, 2 followed by a space, it performs the equivalent ‘man -k ^’ and ‘man -k ^2’ internally. On my Linux VM, running 5.14.8-arch1-1, this is a non-issue, and speaking to others on Linux systems, it is also a non-issue there. 
> 
> I have fixed this temporarily on my MacOS machine by giving man advice; however, this same advice causes man not to work on my Linux VM.
> 
> Currently, it is a non-issue for me, but I would like to report it nonetheless.

Thanks.

Does the patch below give good results?

diff --git a/lisp/man.el b/lisp/man.el
index 479bf9f..02be396 100644
--- a/lisp/man.el
+++ b/lisp/man.el
@@ -664,10 +664,9 @@ Man-build-man-command
 (defun Man-translate-cleanup (string)
   "Strip leading, trailing and middle spaces."
   (when (stringp string)
-    ;;  Strip leading and trailing
-    (if (string-match "^[ \t\f\r\n]*\\(.+[^ \t\f\r\n]\\)" string)
-        (setq string (match-string 1 string)))
-    ;; middle spaces
+    ;;  Strip leading and trailing spaces.
+    (setq string (string-trim string "[ \t\f\r\n]" "[ \t\f\r\n]"))
+    ;; Remove middle spaces.
     (setq string (replace-regexp-in-string "[\t\r\n]" " " string))
     (setq string (replace-regexp-in-string "  +" " " string))
     string))

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Eli Zaretskii]

[Please use Reply All tp keep the bug address onm the CC list.]

> from: asocial-hired.0l@icloud.com
> Date: Fri, 28 Apr 2023 00:26:40 -0700
> 
> Unfortunately not. The lag is still noticeable. Here is the advice function that resolved the issue on
> MacOS:

I don't understand.  I thought the problem was that trailing
whitespace in "2 " was being passed to the 'man' command?  Are you
saying the fix still leaves the trailing whitespace in the argument?

Can you show the exact step by step recipe for reproducing the problem
starting from "emacs -Q"?  That is, what exactly do you type to
reproduce the problem?

> (define-advice man (:around (orig-func &rest args) no-completing-read)
> 
>   "Inhibit `completing-read'."

Please tell what is wrong with the arguments passed to the 'man'
commands, so I could think about fixing that without any advices.

Thanks.

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Eli Zaretskii]

> Cc: 63132@debbugs.gnu.org
> Date: Fri, 28 Apr 2023 10:49:30 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > (define-advice man (:around (orig-func &rest args) no-completing-read)
> > 
> >   "Inhibit `completing-read'."
> 
> Please tell what is wrong with the arguments passed to the 'man'
> commands, so I could think about fixing that without any advices.

I think I understand the issue now: it happens inside
Man-completion-table, right?

But then I don't understand the situation: why would someone type
"M-x man RET 2 ", with the trailing space?  Is this simply a mistake
on behalf of the user?

Stefan, any ideas how we can catch this situation?  I don't think we
can blindly remove the trailing whitespace, since this could be
meaningful in completion?

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Arteen1000]

The reason I do it is to get the ‘man 2 read’ page. I believe the issue is primarily caused by call to ‘man -k ^2’ and ‘man -k ^’ from Man-completion-table but I am unsure. The advice defined doesn’t work on Linux VM (makes it crash) but works on MacOS, so I am not sure why exactly this is.

> On Apr 28, 2023, at 3:43 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 
>> 
>> Cc: 63132@debbugs.gnu.org
>> Date: Fri, 28 Apr 2023 10:49:30 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>>> (define-advice man (:around (orig-func &rest args) no-completing-read)
>>> 
>>>  "Inhibit `completing-read'."
>> 
>> Please tell what is wrong with the arguments passed to the 'man'
>> commands, so I could think about fixing that without any advices.
> 
> I think I understand the issue now: it happens inside
> Man-completion-table, right?
> 
> But then I don't understand the situation: why would someone type
> "M-x man RET 2 ", with the trailing space?  Is this simply a mistake
> on behalf of the user?
> 
> Stefan, any ideas how we can catch this situation?  I don't think we
> can blindly remove the trailing whitespace, since this could be
> meaningful in completion?

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> But then I don't understand the situation: why would someone type
> "M-x man RET 2 ", with the trailing space?  Is this simply a mistake
> on behalf of the user?

`M-x man` accepts various special syntaxes in the minibuffer, such as
`2 read` to mean "read the manpage for `read` in the 2nd section"
(i.e. syscalls), like Arteen1000 mentions.

So `M-x man RET 2 SPC TAB` should (hopefully) list all the section
2's manpages.


        Stefan

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: asocial-hired.0l@icloud.com,  63132@debbugs.gnu.org
> Date: Mon, 01 May 2023 12:30:39 -0400
> 
> > But then I don't understand the situation: why would someone type
> > "M-x man RET 2 ", with the trailing space?  Is this simply a mistake
> > on behalf of the user?
> 
> `M-x man` accepts various special syntaxes in the minibuffer, such as
> `2 read` to mean "read the manpage for `read` in the 2nd section"
> (i.e. syscalls), like Arteen1000 mentions.
> 
> So `M-x man RET 2 SPC TAB` should (hopefully) list all the section
> 2's manpages.

So you are saying the lags here are unavoidable?

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> So `M-x man RET 2 SPC TAB` should (hopefully) list all the section
>> 2's manpages.
> So you are saying the lags here are unavoidable?

I don't know.  I don't see any significant lag here.  But if that's
a problem, maybe we should tweak the system so we only fetch the list
when there's at least one char after the space (to keep the list
shorter)?

The OP mentions Emacs crashing, which points to another problem than
mere lag.  I can't investigate this because I can't reproduce it here
on Debian.

And maybe it depends on the system (or more specifically on what kind of
`man` program is installed and how it supports `man -k`; e/g. if
there's no prebuilt index and `man -k` scans through all the installed
troff pages every time)?


        Stefan

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: asocial-hired.0l@icloud.com,  63132@debbugs.gnu.org
> Date: Mon, 01 May 2023 14:03:40 -0400
> 
> >> So `M-x man RET 2 SPC TAB` should (hopefully) list all the section
> >> 2's manpages.
> > So you are saying the lags here are unavoidable?
> 
> I don't know.  I don't see any significant lag here.

The OP says it only happens on macOS, not on GNU/Linux.

> But if that's a problem, maybe we should tweak the system so we only
> fetch the list when there's at least one char after the space (to
> keep the list shorter)?

Something like that.

> The OP mentions Emacs crashing, which points to another problem than
> mere lag.  I can't investigate this because I can't reproduce it here
> on Debian.
> 
> And maybe it depends on the system (or more specifically on what kind of
> `man` program is installed and how it supports `man -k`; e/g. if
> there's no prebuilt index and `man -k` scans through all the installed
> troff pages every time)?

Any macOS users out there who could reproduce and debug this?

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: asocial-hired.0l@icloud.com,  63132@debbugs.gnu.org
>> Date: Mon, 01 May 2023 14:03:40 -0400
>>
>> >> So `M-x man RET 2 SPC TAB` should (hopefully) list all the section
>> >> 2's manpages.
>> > So you are saying the lags here are unavoidable?
>>
>> I don't know.  I don't see any significant lag here.
>
> The OP says it only happens on macOS, not on GNU/Linux.
>
>> But if that's a problem, maybe we should tweak the system so we only
>> fetch the list when there's at least one char after the space (to
>> keep the list shorter)?
>
> Something like that.
>

I can confirm that completion in `M-x man` induces a seconds-long lag on
Mac OS.  I believe that has been the case, for me, for at least a couple
of years.  I often find myself typing out the man page name I'm looking
for in full and avoiding completion because of this.

>> The OP mentions Emacs crashing, which points to another problem than
>> mere lag.

This I cannot confirm or reproduce.  AFAIR I never had Emacs crash while
using `M-x man`.

>> And maybe it depends on the system (or more specifically on what kind of
>> `man` program is installed and how it supports `man -k`; e/g. if
>> there's no prebuilt index and `man -k` scans through all the installed
>> troff pages every time)?
>
> Any macOS users out there who could reproduce and debug this?

On my i9 Ventura MacBook Pro, just running `man -k read > /dev/null`
takes almost 2.5 seconds, it'd seem that's indeed the main cause of this
lag in `M-x man` completion.


-- 
Eshel

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Eli Zaretskii]

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  63132@debbugs.gnu.org,
>   asocial-hired.0l@icloud.com
> Date: Tue, 02 May 2023 09:33:31 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Cc: asocial-hired.0l@icloud.com,  63132@debbugs.gnu.org
> >> Date: Mon, 01 May 2023 14:03:40 -0400
> >>
> >> >> So `M-x man RET 2 SPC TAB` should (hopefully) list all the section
> >> >> 2's manpages.
> >> > So you are saying the lags here are unavoidable?
> >>
> >> I don't know.  I don't see any significant lag here.
> >
> > The OP says it only happens on macOS, not on GNU/Linux.
> >
> >> But if that's a problem, maybe we should tweak the system so we only
> >> fetch the list when there's at least one char after the space (to
> >> keep the list shorter)?
> >
> > Something like that.
> >
> 
> I can confirm that completion in `M-x man` induces a seconds-long lag on
> Mac OS.  I believe that has been the case, for me, for at least a couple
> of years.  I often find myself typing out the man page name I'm looking
> for in full and avoiding completion because of this.

Are you saying that any completion in "M-x man" produces a lag?  If
so, there's nothing we can do here, except suggest that the OP
switches to a better OS.

The OP seemed to say that the lag happens only for some inputs
following "M-x man", in particular those which ends with a space.  Is
that not what you see?

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> I can confirm that completion in `M-x man` induces a seconds-long lag on
>> Mac OS.  I believe that has been the case, for me, for at least a couple
>> of years.  I often find myself typing out the man page name I'm looking
>> for in full and avoiding completion because of this.
>
> Are you saying that any completion in "M-x man" produces a lag?  If
> so, there's nothing we can do here, except suggest that the OP
> switches to a better OS.

Yes, exactly.  I don't know if lag is the right word, but it takes a
couple of seconds for Emacs to pop the *Completions* buffer after
hitting TAB or SPC or ?, regardless of the current input.

> The OP seemed to say that the lag happens only for some inputs
> following "M-x man", in particular those which ends with a space.  Is
> that not what you see?

That's not what I see, no.  I think OP simply stumbled upon the fact
that SPC also invokes completion, which takes a long time in this case.

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> On my i9 Ventura MacBook Pro, just running `man -k read > /dev/null`
> takes almost 2.5 seconds, it'd seem that's indeed the main cause of this
> lag in `M-x man` completion.

Hmm... here on my 10 years old desktop running Debian stable it's more
like 0.03s.  If it's so slow even for situations where the users have
already typed `read`, ... hmm ... maybe we should try and make the
completion asynchronous or at least abort the `man -k` as soon as the
user types something, or add some level of caching...?


        Stefan

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> On my i9 Ventura MacBook Pro, just running `man -k read > /dev/null`
>> takes almost 2.5 seconds, it'd seem that's indeed the main cause of this
>> lag in `M-x man` completion.
>
> Hmm... here on my 10 years old desktop running Debian stable it's more
> like 0.03s.  If it's so slow even for situations where the users have
> already typed `read`, ... hmm ... maybe we should try and make the
> completion asynchronous or at least abort the `man -k` as soon as the
> user types something, or add some level of caching...?
>

Note that there is already some caching in place, but it gets reset
between invocations of `M-x man` and it only hits if the previous input
for completion is a prefix of the next one.

AFAICT Stefan added this caching back in 2009 along with a comment that
seems to be relevant still:

--8<---------------cut here---------------start------------->8---
On my machine, "man -k" is so fast that a cache makes no sense,
but apparently that's not the case in all cases, so let's add a cache.
--8<---------------cut here---------------end--------------->8---

Perhaps we could do some more aggressive caching under the condition
that "man -k" is really slow (as determined by e.g. some
`Man-man-k-slow-p` variable that'd be non-nil by default on macOS)?

-- 
Eshel

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Perhaps we could do some more aggressive caching under the condition
> that "man -k" is really slow (as determined by e.g. some
> `Man-man-k-slow-p` variable that'd be non-nil by default on macOS)?

I'd hope the root of the problem can be fixed, but I don't think Emacs
can fix it on its own, so indeed we may have to come up with some kind
of workaround, probably disabling completion for `man` on macOS.


        Stefan


BTW, maybe the slowdown is related to
https://discussions.apple.com/thread/250806874 ?

bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'

[Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Yes, exactly.  I don't know if lag is the right word, but it takes a
> couple of seconds for Emacs to pop the *Completions* buffer after
> hitting TAB or SPC or ?, regardless of the current input.

The experience is even worse with Icomplete, Vertico, etc.  When I start
typing after 'M-x man RET', Emacs freezes for good 6 or 7 seconds, and
prints "Waiting for process to die...done" in the meantime.  This
happens on every single lookup.

Rudy
-- 
"I love deadlines.  I love the whooshing noise they make as they go by."
-- Douglas Adams, The Salmon of Doubt, 2002

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia