emacs-devel
[Top][All Lists]
Advanced

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

Re: Fixes to let woman.el deal with MANPATH_MAP elements


From: David Kastrup
Subject: Re: Fixes to let woman.el deal with MANPATH_MAP elements
Date: Fri, 23 Mar 2007 22:09:26 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.96 (gnu/linux)

David Kastrup <address@hidden> writes:

> I am utterly befuddled by the code in woman.el.  Should I be using
> "parse-colon-path" or "woman-parse-colon-path" here?
>
> It is not clear to me whether "PATH" is covered by the same special
> rules that either one of the above functions would use.
>
> As the code appears to be cowritten by you, could you suggest what to
> use instead of
>
> (split-string (getenv "PATH") ":" t)
>
> here?  Should I use one of the above-mentioned functions, or just
> (split-string (getenv "PATH") path-separator t)?

Ok, I have seen that parse-colon-path returns directory names rather
than directory file names, so that is unsuitable for MANPATH_MAP.
Also it would appear that I overlooked woman-Cyg-to-Win's behavior
(not sure whether Cygwin even has MANPATH_MAP, but better safe than
sorry).  I believe that now the behavior should be more or less
consistent in the Windows case (at least not less consistent than the
preexisting mess).

I don't understand why all this Cygwinniness should be in woman.el to
start with: this kind of stuff does not seem specific to woman.el, but
more like a general problem.

It also turns out that woman.texi exists, so it seems like I need to
add some words there, too.

Sigh.  Fixing things is more work than I'd like to.

Could some people using Windows and/or Cygwin systems perhaps check
the behavior?  Bonus points if their manpath.conf contains MANPATH_MAP
elements.  The current code should not cause a regression.

Attachment: txtSsZ4ejejZ9.txt
Description: Text Data


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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