From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Wolfgang Jenkner Newsgroups: gmane.emacs.bugs Subject: bug#16722: 24.3.50; `M-x man' does not handle case appropriately Date: Sat, 15 Feb 2014 18:17:08 +0100 Message-ID: <85fvnkwarc.fsf@iznogoud.viz> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392485050 23325 80.91.229.3 (15 Feb 2014 17:24:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Feb 2014 17:24:10 +0000 (UTC) Cc: 16722@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 15 18:24:18 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 1WEiyP-0005tL-3J for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Feb 2014 18:24:17 +0100 Original-Received: from localhost ([::1]:57647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEiyO-0007zS-Mq for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Feb 2014 12:24:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37649) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEiyG-0007wk-9B for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2014 12:24:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEiyB-0001Ov-7W for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2014 12:24:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEiyB-0001Or-3z for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2014 12:24:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WEiyA-0006uS-E3 for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2014 12:24:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Wolfgang Jenkner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 Feb 2014 17:24:02 +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.139248501126497 (code B ref 16722); Sat, 15 Feb 2014 17:24:02 +0000 Original-Received: (at 16722) by debbugs.gnu.org; 15 Feb 2014 17:23:31 +0000 Original-Received: from localhost ([127.0.0.1]:53666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WEixe-0006tJ-HJ for submit@debbugs.gnu.org; Sat, 15 Feb 2014 12:23:30 -0500 Original-Received: from b2bfep15.mx.upcmail.net ([62.179.121.60]:55204) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WEixb-0006t3-BF for 16722@debbugs.gnu.org; Sat, 15 Feb 2014 12:23:28 -0500 Original-Received: from edge12.upcmail.net ([192.168.13.82]) by b2bfep15-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20140215172320.DLOP16013.b2bfep15-int.chello.at@edge12.upcmail.net>; Sat, 15 Feb 2014 18:23:20 +0100 Original-Received: from iznogoud.viz ([91.119.197.0]) by edge12.upcmail.net with edge id ShPL1n00C00zuln0ChPLvq; Sat, 15 Feb 2014 18:23:20 +0100 X-SourceIP: 91.119.197.0 Original-Received: from wolfgang by iznogoud.viz with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WEixT-0000Uu-WC; Sat, 15 Feb 2014 18:23:20 +0100 User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (berkeley-unix) 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:85627 Archived-At: On Tue, Feb 11 2014, Drew Adams wrote: > This is Eli's comment on the Emacs bug that needs fixing: > > In any case, "M-x man" should handle this kind of output gracefully, > which it evidently doesn't. > > See bug #10840 for recipe and details. Here's, AFAIK, the current state with regard to Drew's observations. On Sat, Feb 18 2012, Drew Adams wrote: > I have Cygwin installed (a rather old version; dunno which one or how to > tell). [...] > M-x man RET > > Hitting TAB (with no minibuffer input) completes the empty input to the > two chars `^:'. This is a consequence of (1) and (2) below; the OP could confirm (1), while anybody can easily check (2) by looking at the code in man.el. (1) `man -k' can't find any whatis database or all those files are empty. (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 > Thereafter I can do nothing with that. Whether I type > anything after the `^:' or not, TAB just completes to `^:'. I think that has been fixed as a by-product of a 2013-01-10 change: (man): Flush the completion cache between uses. I.e., the behaviour is now described by > 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]. which seems to be irreproachable in the light of (1) above. 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. 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. 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. 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'? Wolfgang