From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17839 invoked by alias); 24 Sep 2015 06:10:31 -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: 20639 Received: (qmail 11097 invoked from network); 24 Sep 2015 06:10:30 -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-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=3nKcpWqyENibjMo0cQOb2tigyM0TjYKpO1DM/CyNlJs=; b=fAClQU6tyTjnoMhYig/p1nw3S5K/O55+8xaiL1suaqoCj6Hda+aXBENorby1HR7R5R XCGLZUH4JcZTeT8GNCp8a6DO8CVuHqOveSp/0z5v4oTaoriZWoLZ1szgPqUOB49P3BKu vl++m3nEu+bgmLQMC9PDlkJLwsZUrKl0z8aELU7grlyLg2Va6E21ApFCkfVCOITyFkDz wW6Wn+iR18n9Cr8C3MRqYiINObfRPgiDTPNDeqOXVMjB/Har9E9oZu14H5JerJVRLV4b iZFFyqniVDMs7uqw11VZ4G8qKcInj2eVq4OfHID6hShaGw2CcZBVpvBnzipRMpikrB2h poCg== X-Gm-Message-State: ALoCoQmD99k9afUAISNuJ/5thOjifGc/+5cbdFOUekyEMNNS2SisSgoP/D9NItmoBPhPj+GeBjtM X-Received: by 10.202.0.206 with SMTP id 197mr20936542oia.76.1443075026926; Wed, 23 Sep 2015 23:10:26 -0700 (PDT) From: Bart Schaefer Message-Id: <150923231024.ZM32382@torch.brasslantern.com> Date: Wed, 23 Sep 2015 23:10:24 -0700 In-Reply-To: <20150923094821.5c5d0b80@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Dynamic directory name function" (Sep 23, 9:48am) References: <20150922204251.05f3d291@ntlworld.com> <150922210756.ZM30253@torch.brasslantern.com> <20150923094821.5c5d0b80@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh Users Subject: Re: Dynamic directory name function MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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.