Re: Dynamic directory name function

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Wed, 23 Sep 2015 23:10:24 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> 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.

That's probably what I'll go with, unless someone who is actually going
to use this really feels the need for styles.  But thanks for the
comments.

> 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.

Yes, although I've just modified it so you can start with a style to
find the top variable.  Given the variables can be linked how you like
(nothing needs to be defined locally), the difference between the two
isn't that great.

> 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?

Yes.

> 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).
>...
> I don't see we've lost any readability/remember-ability at this level,

OK, that's pretty similar.  There's the repetition of ZDN_wrapper_name,
but that's more to do with protecting the namespace (you'd need it as
the prefix to an associative array if you wanted to be careful, unless
you do what I do and define it locally).  There's also the backslashes,
but more careful people than me probably don't mind those.

> 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 ...

Yes, but you can do that just by having them reference the same
global associative arrays.  With a zstyle pointing to the top
associative array you can again define everything outside the wrapper.

> Maybe we should be doing
> 
>     zstyle ZDN_/scratch/$USER/git/ next-part \
> 	p myscratchproject \
> 	s somescratchproject

This is now at the level where if somebody put it in front of me I'd
find it too fiddly to use.

I think, really, it's six and two threes (or six of one and half a dozen
of the other, as the wordier people born south of Tyneside say).  zstyle
gives you a few extra tricks if you can probe the obscurity, although
obscurity is an entirely subjective concept.  Variables allow you to
define the whole thing inside a single function with no globals the way
I originally did, which doesn't really fit the zstyle model, and I would
think anyone who knows what an associative array is can pick it up the
entire system very quickly.

However, it was certainly useful to compare.

pws