[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