bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Wolfgang Jenkner
Subject: bug#16722: 24.3.50; `M-x man' does not handle case appropriately
Date: Sat, 15 Feb 2014 18:17:08 +0100
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (berkeley-unix)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]