Re: Dynamic directory name function

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 23,  9:48am, Peter Stephenson wrote:
}
} I did think about that.  But having written the wrapper function, with
} the variables the way they are, everything immediately fell out neatly
} and clearly with associative arrays having a natural meaning.

As long as they're all local to the wrapper or use a naming convention
to avoid clashing with any other variables, I suppose that's fine.
Naming convention is mostly what zstyle is for.

The other useful thing about zstyle is that the naming convention
doesn't have to fit any other convention (such as, what is legal in
the name of an identifier).

} (I can never remember how the more complicated
} styles work in completion.)

As was observed in a thread some months ago, allowing wildcards to
match delimiters makes it possible to define zstyles that are shortcuts
but are also ambiguous.  At some level it might have made things more
understandable if, like slashes in globbing, we picked a delimiter and
always required the same number of them to appear in the definition
and the lookup (or at least required "**" for calling out ambiguity).

But that ship is already leaving the harbor if not past the horizon.

} But maybe you can come up with an example of how you'd set styles that
} shows it working neatly and obviously.

I'd probably have to understand dynamic directory naming to do a very
good job of that, and I've never had a need for that feature so I've
always sort of ignored it.  Partial path completion is sufficient.

However, as far as I understand zsh_directory_name_generic from looking
at the code and comments, you always start with the zdn_top hash, and
its values can contain substrings of the form ":identifier" where that
identifier then refers to another hash, and so on.

So if I've got ~[x:y], I have to find key "x" in zdn_top, and either
that has to have a ":identifier" in its value, or there has to be a
":default:" key with another ":identifier", and in either case the
hash referenced by that identifier has to have key "y", and so on.

Right so far?

Then as usual with zstyle you have to decide on what is context and
what is style.  I guess to follow your model closely, we should make
the identifier be the style, and the context is the the name of the
wrapper function.

So you'd define the styles like this:

    zstyle ZDN_wrapper_name zdn_top \
	g   ~/git \
	ga  ~/alternate/git \
	gs  /scratch/$USER/git/:second2 \
	:default: /:second1

    zstyle ZDN_wrapper_name second1 \
    	p  myproject \
	s  somproject \
	os otherproject/subproject/:third

    zstyle ZDN_wrapper_name third \
	s  top/srcdir \
	d  top/documentation

(rest omitted for brevity).  Everything works just like what you have
now, except you assign with

    zstyle -a ZDN_${funcstack[2]} $_zdn_var _zdn_assoc

in place of

    _zdn_assoc=(${(Pkv)_zdn_var})

I don't see we've lost any readability/remember-ability at this level,
but now those declarations can be global instead of local to each
wrapper, so we can have multiple wrappers share them by doing

    zstyle 'ZDN_*' third ...

The other thing that this points out is that the name is now the only
thing unique to the wrapper; we could do

    functions[wrapper_name]=$functions[zsh_directory_name_generic]

and it would all still work (well, except for having to adjust the
$funcstack[2] reference).  So maybe that's not the right context to
use in the first place.  Maybe we should be doing

    zstyle ZDN_/scratch/$USER/git/ next-part \
	p myscratchproject \
	s somescratchproject

and looking up with (if I'm reading your source correctly)

    if zstyle -a ZDN_${_zdn_sofar}/ next-part _zdn_assoc; then ...

and then you don't even need the :identifier thing to point to yet
another hash, you just either declare what the next parts are or
you don't.  There's probably some clean way to replace ":default:"
with a wildcard in the style pattern but the way you've set it up
I expect it would need it's own lookup, perhaps

    zstyle -a ZDN_${zdn_words[1]} default _zdn_assoc

which I think would need some restructuring of your loop; I don't
really have a good vision of that part.