Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: hierarchical module names
- X-seq: zsh-workers 9056
- From: Zefram <zefram@xxxxxxxx>
- To: pws@xxxxxxxxxxxxxxxxxxxxxxxx (Peter Stephenson)
- Subject: Re: PATCH: hierarchical module names
- Date: Wed, 15 Dec 1999 10:52:15 +0000 (GMT)
- Cc: zsh-workers@xxxxxxxxxxxxxx
- In-reply-to: <E11y1cO-0003fh-00.1999-12-14-23-44-33@xxxxxxxxxxxxxxxxxxx> from Peter Stephenson at "Dec 14, 1999 11:45:32 pm"
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Peter Stephenson wrote:
>I don't like this bit. It means zmodload behaves differently from the way
>it's done for several years now. I don't see why the main modules
>shouldn't keep their old names.
Ah, yes, there's another thing that got lost as the patch grew. I'd
intended to do some sort of backward compatibility, but hadn't decided
quite how to do it.
I think the old modules do need to keep their historical names, one way or
another. But I don't see a problem with all new modules getting a prefix.
"zsh/", in particular, is not an onerous amount of extra typing.
>Or, if you prefer, you can make a name without a slash equivalent to the
>same with zsh/ stuck in front. That might be the simplest.
This is a reasonable solution. Three other solutions occur to me:
1. Have only the historically-established names be aliased.
2. Alias the historically-established names by filesystem links, so that
the executable doesn't need to know about specific names.
3. Have alias modules for the historically-established names. We'd have,
for example, a `zle' module, which has a built-in dependency on
`zsh/zle' but doesn't actually do anything itself. So loading `zle'
would have the effect of loading `zsh/zle', and zmodload would then
report both `zle' and `zsh/zle' as loaded.
I favour solution 3. It seems to maintain the greatest degree of
compatibility, while not requiring any changes to the mechanism.
>> * There is no way to load a module from a specified filename. There
>> should probably be a distinct option for this, if the capability is
>> to exist at all.
>I don't think this is a worry; you can write a function with some $fpath
>trickery if you're desparate.
That's pretty much what I thought. The only issue is what happens if
the module file has the `wrong' name, or is in a subdirectory with the
wrong name, for example, where it is compiled in the zsh build tree.
That's what the extra option would be for.
Possible technique: have zmodload check module name syntax at command-line
time, rather than at load time, and then extend the syntax to allow
<module-name>:<file-name> to specify loading a module from a specific
Messages sorted by: