bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Drew Adams]

> > 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),

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

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

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

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.