From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gatech.edu (gatech.edu [130.207.244.244]) by werple.mira.net.au (8.6.12/8.6.9) with SMTP id AAA00941 for ; Fri, 11 Aug 1995 00:44:05 +1000 Received: from math (math.skiles.gatech.edu) by gatech.edu with SMTP id AA13771 (5.65c/Gatech-10.0-IDA for ); Thu, 10 Aug 1995 10:40:01 -0400 Received: by math (5.x/SMI-SVR4) id AA04878; Thu, 10 Aug 1995 10:07:47 -0400 Resent-Date: Thu, 10 Aug 95 15:08:04 +0100 Old-Return-Path: Message-Id: <27071.9508101408@pyro.swan.ac.uk> To: zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: Revised dohistexpand() In-Reply-To: "A.Main@dcs.warwick.ac.uk"'s message of "Thu, 10 Aug 95 13:54:55 BST." <24456.199508101254@stone.dcs.warwick.ac.uk> Date: Thu, 10 Aug 95 15:08:04 +0100 From: P.Stephenson@swansea.ac.uk X-Mts: smtp Resent-Message-Id: <"lS7aV1.0.8C1.oAXAm"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/303 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Thanks for the comments, but Zoltan's objections about magic space with single quotes probably mean this patch won't get used. (I realise now there's another problem: I haven't arranged for !" to be handled. That's another thing that's hard without the lexer.) Still, A.Main@dcs.warwick.ac.uk wrote: > Peter wrote: > >Still, now I've found out what all this code does, maybe I can work > >around it some other way. I'm hoping, eventually, to modify the > >history code so that only the lines actually typed are stored, with > >the word separation in a list of numbers > > I like this idea. Much of the expansion/completion code could benefit > from having the parser point out word beginnings to it. This would be > a great aid to consistency in complex quoting (e.g. "a b" "`a b`" "`'a > b'`" etc.). It would similarly help to have nesting indicated in this > way, to help with command/process substitution. I hadn't thought of that, but you're right, it might help simplify the some other of the lexical horrors in zle_tricky.c. I don't think I'm going to be tackling that myself, but there's no point crossing that bridge yet. > I note that you confine history expansion to the current word. This > has the rather nice effect that typing "!!^V abc" won't > expand the initial !!, which is helpful for those of us using > magic-space. However, it has some problems associated with it. Does > extended completion work after (in a separate word from) a history > reference, bearing in mind that the history reference could expand to > several words? I believe this wouldn't a problem since the line that returns to the completion code from the lexical already can have all manner of changes to it (e.g. alias expansion, which is treated very much like history expansion), but I haven't investigated in detail. > On magic-space: it shouldn't expand history when the cursor is in a > history reference (e.g. !{a). At the moment > doexpandhist() removes the word; it should feep and leave the word > unchanged. The same applies to expand-history, which also calls > doexpandhist(). I also think an error should be flagged when > attempting to expand an invalid history reference, rather than removing > it (this would accurately reflect how zsh treats the bad history > reference in a completed line). This actually works in my patch (though I didn't get magicspace to feep), since the error status from the history expansion is looked at. (There's a problem with substitutions which actually comes from the history code itself, since something like "!!:s/f" doesn't cause an error, so if you magic-space after it it gets expanded straight away. Changing the history code to flag an error on this kind of thing would fix it.) > Magic-space also ought to do no history expansion immediately after a > backslash. This is already fixed in the hzoli releases. I didn't try that, but it could be added. > Finally, I think this new patch reintroduces an old bug. (I don't have > hzoli10.2 to check it, but I'm fairly certain.) Prior to the patch the > code contains a statement that resets the vi beginning-of-insertion > pointer to the beginning of the line when expanding history, because > that's where expansion starts from. After the patch, there is no such > code. The pointer ought to move back to the beginning of the word > being expanded, as it is with other forms of expansion. I don't use vi-mode, but I was careful in the patch to do all the line changing with existing editor commands (backdel, spaceinline), so that only the expanded code is changed. This should mean that all this kind of thing is automatically satisfied. The current code just copies the expanded line to the editor line, which is why it needs extra code. That's the kind of thing that made me take against the current code (but don't take all my hyperbole too seriously). -- Peter Stephenson Tel: +44 1792 205678 extn. 4461 WWW: http://python.swan.ac.uk/~pypeters/ Fax: +44 1792 295324 Department of Physics, University of Wales, Swansea, Singleton Park, Swansea, SA2 8PP, U.K.