From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8312 invoked by alias); 24 Sep 2015 08:38:08 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20640 Received: (qmail 24908 invoked from network); 24 Sep 2015 08:38:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f5-f794b6d000001495-a1-5603b6692cdb Date: Thu, 24 Sep 2015 09:37:52 +0100 From: Peter Stephenson To: Zsh Users Subject: Re: Dynamic directory name function Message-id: <20150924093752.581dcee9@pwslap01u.europe.root.pri> In-reply-to: <150923231024.ZM32382@torch.brasslantern.com> References: <20150922204251.05f3d291@ntlworld.com> <150922210756.ZM30253@torch.brasslantern.com> <20150923094821.5c5d0b80@pwslap01u.europe.root.pri> <150923231024.ZM32382@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsVy+t/xy7qZ25jDDJq3q1rsOLmS0YHRY9XB D0wBjFFcNimpOZllqUX6dglcGS8PfmEv6JCr+Pgzr4HxsHgXIyeHhICJxN3ec0wQtpjEhXvr 2boYuTiEBJYySry5d50VwpnGJPF08jMmCGcbo8S7je3MIC0sAqoSr8+9YQGx2QQMJaZums0I YosIKEqc+fUNbKywgI5Ex87nrCA2r4C9RMP5BjCbU8BK4tefZqgNJxglbi3bATaIX0Bf4urf T1A32UvMvHKGEaJZUOLH5HtgNcwCWhKbtzWxQtjyEpvXvAU7SEhAXeLG3d3sExiFZiFpmYWk ZRaSlgWMzKsYRVNLkwuKk9JzjfSKE3OLS/PS9ZLzczcxQsL26w7GpcesDjEKcDAq8fDO1GEO E2JNLCuuzD3EKMHBrCTCq9QPFOJNSaysSi3Kjy8qzUktPsQozcGiJM47c9f7ECGB9MSS1OzU 1ILUIpgsEwenVANj0j/HbdJ6c9k3Jk5Qmbnia8EbK/04braINc0Hn+tklc9QjOU3ivj5sP/2 fJc82dp79ncLtDTuzjE6XnC5eGJQYbjCpriuHYuLnAS5onVbz+YrTbbsEeNb+WjmnNmvtqh8 kjrzZEqz4U/lqTMMs4tX/aq++rKlPmiGzNw3GQ+l9k7b+HDNliU6SizFGYmGWsxFxYkA2/C5 y1cCAAA= On Wed, 23 Sep 2015 23:10:24 -0700 Bart Schaefer 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