bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

[Drew Adams]

I have Cygwin installed (a rather old version; dunno which one or how to
tell).  I load `cygwin-mount.el', then `setup-cygwin.el', both of which
are available on EmacsWiki:
 
http://www.emacswiki.org/emacs/download/cygwin-mount.el
http://www.emacswiki.org/emacs/download/setup-cygwin.el
 
emacs -Q
 
M-x man RET
 
Hitting TAB (with no minibuffer input) completes the empty input to the
two chars `^:'.  Thereafter I can do nothing with that.  Whether I type
anything after the `^:' or not, TAB just completes to `^:'.
 
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].
 
(I can of course enter a complete command name, such as `ls' and hit
RET.  `man' then works correctly.  It is only the UNIX command-name
completion that is seemingly broken.
 
Am I missing something?  I tried to debug this a bit but wasn't
successful in following what was happening.  Please advise.  Thx.
 

In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
 of 2012-02-15 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 18 Feb 2012 11:51:23 -0800
> 
> emacs -Q
>  
> M-x man RET
>  
> Hitting TAB (with no minibuffer input) completes the empty input to the
> two chars `^:'.  Thereafter I can do nothing with that.  Whether I type
> anything after the `^:' or not, TAB just completes to `^:'.

man.el invokes the `man' command with "^" concatenated to whatever you
typed.  So the question becomes what does your port of `man' produce
if you invoke it from the shell command line like this:

   man ^

bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 18 Feb 2012 11:51:23 -0800
> 
> emacs -Q
>  
> M-x man RET
>  
> Hitting TAB (with no minibuffer input) completes the empty input to the
> two chars `^:'.  Thereafter I can do nothing with that.  Whether I type
> anything after the `^:' or not, TAB just completes to `^:'.

man.el invokes the `man' command with "^" concatenated to whatever you
typed.  So the question becomes what does your port of `man' produce
if you invoke it from the shell command line like this:

   man -k ^

bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

[Drew Adams]

> man.el invokes the `man' command with "^" concatenated to whatever you
> typed.  So the question becomes what does your port of `man' produce
> if you invoke it from the shell command line like this:
> 
>    man -k ^

You also sent a mail saying to try `man ^', i.e., without `-k'.  I tried both.

 $ man -k ^
 ^: nothing appropriate

 $ man ^
 No manual entry for ^

Dunno whether that helps.  As I said, if I type nothing in the minibuffer and
then hit TAB it completes to `^:' with no further completion available.  If I
instead type something (e.g. `l') and then hit TAB I get the message `[No
match]'.

The shell is bash.  (And "man ls RET" works fine at the bash prompt.)

bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <10840@debbugs.gnu.org>
> Date: Sat, 18 Feb 2012 12:28:04 -0800
> 
>  $ man -k ^
>  ^: nothing appropriate

I guess your `man' doesn't support this option, or maybe it needs for
you to create the apropos database.  In any case, "M-x man" should
handle this kind of output gracefully, which it evidently doesn't.

bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

[Drew Adams]

> >  $ man -k ^
> >  ^: nothing appropriate
> 
> I guess your `man' doesn't support this option, or maybe it needs for
> you to create the apropos database.  In any case, "M-x man" should
> handle this kind of output gracefully, which it evidently doesn't.

ping

bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

[Wolfgang Jenkner]

On Mon, Sep 17 2012, Drew Adams wrote:

>> >  $ man -k ^
>> >  ^: nothing appropriate
>> 
>> I guess your `man' doesn't support this option, or maybe it needs for
>> you to create the apropos database.  In any case, "M-x man" should
>> handle this kind of output gracefully, which it evidently doesn't.
>
> ping

As Eli suggested, the question is if your man program supports the `-k'
option.

If you don't have a `whatis' database you should have a `makewhatis' or
a `mandb' program to generate it.

Then, please try

$ man -k ls

What do you get then? Does one of

$ apropos ls

or

$ whatis ls

work?

If there's no joy, please post the output of

$ man -h
$ man --help
$ man --version

Wolfgang

bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

[Wolfgang Jenkner]

On Sat, Dec 15 2012, Wolfgang Jenkner wrote:

> On Mon, Sep 17 2012, Drew Adams wrote:
>
>>> >  $ man -k ^
>>> >  ^: nothing appropriate
>>> 
>>> I guess your `man' doesn't support this option, or maybe it needs for
>>> you to create the apropos database.  In any case, "M-x man" should
>>> handle this kind of output gracefully, which it evidently doesn't.
>>
>> ping
>
> As Eli suggested, the question is if your man program supports the `-k'
> option.
>
> If you don't have a `whatis' database you should have a `makewhatis' or
> a `mandb' program to generate it.

I suspect you have the man program from

http://primates.ximian.com/~flucifredi/man/

In this case, essentially, "man -k ^" ends up calling "apropos ^", which
gives this output if it can't find any `whatis' database file or all
those files are empty.

Otherwise, "man -k ^" works fine, even in the 1999 vintage man-1.5g.

Also, `apropos' is a shell script, so you can easily inspect it and
debug your `man' installation.

> Hitting TAB (with no minibuffer input) completes the empty input to the
> two chars `^:'.  Thereafter I can do nothing with that.  Whether I type
> anything after the `^:' or not, TAB just completes to `^:'.

The empty string is a prefix of "^:",

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

but "l" is not a prefix of "^l:".

bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

[Lars Ingebrigtsen]

Wolfgang Jenkner <wjenkner@inode.at> writes:

> I suspect you have the man program from
>
> http://primates.ximian.com/~flucifredi/man/
>
> In this case, essentially, "man -k ^" ends up calling "apropos ^", which
> gives this output if it can't find any `whatis' database file or all
> those files are empty.
>
> Otherwise, "man -k ^" works fine, even in the 1999 vintage man-1.5g.
>
> Also, `apropos' is a shell script, so you can easily inspect it and
> debug your `man' installation.

This doesn't seem to be an Emacs bug, then.  Closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#10840: 24.0.93; No `man' command completion on Windows (using Cygwin for man pages)

[Drew Adams]

> This doesn't seem to be an Emacs bug, then.  Closing.

Hm, I don't see why it follows from what Eli said that there is
no Emacs bug here.  Here is what he said:


  I guess your `man' doesn't support this option, or maybe it
  needs for you to create the apropos database.

  In any case, "M-x man" should handle this kind of output gracefully,
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  which it evidently doesn't.

Sounds like an Emacs bug, to me.