From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#16722: 24.3.50; `M-x man' does not handle case appropriately Date: Sat, 15 Feb 2014 11:55:15 -0800 (PST) Message-ID: <512c4f71-4f67-4f36-8e1d-d756ad446d2e@default> References: <85fvnkwarc.fsf@iznogoud.viz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1392494174 20278 80.91.229.3 (15 Feb 2014 19:56:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Feb 2014 19:56:14 +0000 (UTC) Cc: 16722@debbugs.gnu.org To: Wolfgang Jenkner Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 15 20:56:22 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WElLa-0006JW-5S for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Feb 2014 20:56:22 +0100 Original-Received: from localhost ([::1]:58180 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WElLZ-0003pf-Lc for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Feb 2014 14:56:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WElLP-0003pT-Uf for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2014 14:56:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WElLG-0000IS-SC for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2014 14:56:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WElLG-0000IO-Oc for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2014 14:56:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WElLG-0002ec-4p for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2014 14:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 Feb 2014 19:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16722 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16722-submit@debbugs.gnu.org id=B16722.139249414010164 (code B ref 16722); Sat, 15 Feb 2014 19:56:01 +0000 Original-Received: (at 16722) by debbugs.gnu.org; 15 Feb 2014 19:55:40 +0000 Original-Received: from localhost ([127.0.0.1]:53777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WElKs-0002dr-Ks for submit@debbugs.gnu.org; Sat, 15 Feb 2014 14:55:39 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:23554) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WElKo-0002dZ-7l for 16722@debbugs.gnu.org; Sat, 15 Feb 2014 14:55:35 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1FJtUHS010702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Feb 2014 19:55:36 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1FJtFt2029614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Feb 2014 19:55:21 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1FJt9NB004524; Sat, 15 Feb 2014 19:55:09 GMT In-Reply-To: <85fvnkwarc.fsf@iznogoud.viz> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:85634 Archived-At: > > M-x man RET > > Hitting TAB (with no minibuffer input) completes the empty input > > to the two chars `^:'. >=20 > This is a consequence of (1) and (2) below; the OP could confirm > (1), Not sure how to check that. In a bash shell (outside Emacs), if I do `man -k' I get the question "What manual page do you want?". If I then type `ls' then it is as if I typed `ls' from the outset: the files in the current dir are listed. If I do `man -k ls' or `man -k "ls"' or `man -k ^l' or `man -k "^l" then I get only the message "ls: nothing appropriate" (or the same with ^l instead of ls). However, if (in bash, outside Emacs) I type `man ls' or `man "ls"' then I get the normal `man' page output/behavior for `ls'. > while anybody can easily check (2) by looking at the code in man.el. >=20 > (1) `man -k' can't find any whatis database or all those files are > empty. >=20 > (2) This particular `man -k' sends "^: nothing appropriate" to > stdout and not to stderr (if the distinction is meaningful on > cygwin), which is supposed to mean that it's a line "from the > summary database", see > http://pubs.opengroup.org/onlinepubs/009696799/utilities/man.html >=20 > > Thereafter I can do nothing with that. Whether I type > > anything after the `^:' or not, TAB just completes to `^:'. >=20 > I think that has been fixed as a by-product of a 2013-01-10 change: >=20 > =09(man): Flush the completion cache between uses. Not sure what you mean, but the behavior is not fixed for me. I still get exactly the same behavior I reported, even with Emacs builds from only a few days ago. > I.e., the behaviour is now described by >=20 > > If I instead first type `l' (as in `ls') and then hit TAB, I get > > [No match]. It doesn't seem to matter what I type in the minibuffer: > > TAB always says [No match]. >=20 > which seems to be irreproachable in the light of (1) above. Dunno what that means, but that is still the behavior I see: there is no completion for `M-x man'. > The behaviour is different in the latter case because `man -k ^l' > sends a message "^l: nothing appropriate" to stdout, so "^l" is > collected as a possible man page name, but since this string is > not a completion of the "l" prefix it is discarded, after all. >=20 > The description above holds true for Gnu or Gnu/* but it is a lie on > other systems, where the output of `man -k l' is collected instead, > so you would still presented with "l:" as a possible completion. >=20 > Now, this can happen on correctly installed systems as well (if you > happen to search for a prefix which doesn't match any substring in > the summary database), so by setting `Man-man-k-use-anchor' to nil > on some of those systems which are likely to use the man-1.* package > without correcting the bug described in (2) above I introduced a > regression. >=20 > It seems (http://cygwin.com/packages/) that man-1.* is the man > package provided by default in cygwin, but I suppose cygwin > packages could also be used with a non-cygwin emacs? Would it > be reasonable to set the default for `Man-man-k-use-anchor' to > non-nil if the system type is `cygwin' or `windows-nt' or > `ms-dos'? I am using MS Windows 7, and I have Cygwin installed. FWIW, I tried setting `Man-man-k-use-anchor' to `t', but that changed nothing, AFAICT. `M-x man' works normally, except that there is no completion - completion is broken.