From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24233 invoked from network); 15 Jul 2000 02:42:29 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Jul 2000 02:42:29 -0000 Received: (qmail 28358 invoked by alias); 15 Jul 2000 02:42:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12255 Received: (qmail 28351 invoked from network); 15 Jul 2000 02:42:12 -0000 Message-ID: <20000715024209.9385.qmail@web1303.mail.yahoo.com> Date: Fri, 14 Jul 2000 19:42:09 -0700 (PDT) From: Felix Rosencrantz Subject: Re: ZLE Widget: Insert last word (except &) To: zsh-workers MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >It would definetely be useful, but it's not trivial. ... Yes, I attempted to do it with shell code, parsing just simple command lines I use, and started to appreciate how difficult it would be to do. >However: one of the things I want to try after 4.0 is moving more of >ZLE into shell code (optionally, as for completion). One of the >things on my list is the C-code for completion, probably with a small >new builtin for the pre- and post-widget code, but partly in shell >code. The pre-code would allow to parse a string as if it were the >command line and would return all the information completion widgets >get in the special parameters. I hadn't thought about doing this by >moving some code into the core and adding a new parameter expansion, >though. I'm not sure where the code would end up anyway, because parts >of it wouldn't depend on the completion code, so they may be moved to >zutil or something. > >Well, and that combined with a change to the completion system which >can be used to generate the context without generating completions... Not sure if it has to be a new parameter expansion flag, though that was one possible solution. It would be useful if it could be performed on full command lines (e.g. from history or a file.) So what kind of things do you imagine would be possible with these new changes? >>... >> Or in the history completer/widget having context information would make it >> a lot easier to look at command line structure, and prune away things that >> are unwanted, or make it easier to find things that are useful. > >That sounds terribly slow ;-) I was playing around with something that would accumulate frequency information about the first command on a line using preexec. I was hoping this information would be useful to add to something like Bart's predict widget. I suspect something similar could be used to track other interesting words or relations (e.g. command X precedes command Y). Though what I would really like in the end is better prediction, in hopes that would cut down on typing. For me the prediction widget is great in certain circumstances, but other times it just gets my the way. I feel that to improve it, would require better analysis of shell history, which requires processing command lines. Or maybe another direction for prediction is needed maybe someone would like to add something like rk, reactive keyboard, as a module. That way we might be able to get prediction similar to what the various web browsers provide. -FR __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/