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

Previous Next

Full log

View this message in rfc822 format

From: Eshel Yaron <me <at> eshelyaron.com>
To: 63132 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, monnier <at> iro.umontreal.ca, asocial-hired.0l <at> icloud.com
Subject: bug#63132: Bug on Darwin MacOS with 'M-x man RET commandname[ ]'
Date: Wed, 03 May 2023 15:09:09 +0300

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> 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

Previous Next

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