Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Revised dohistexpand()
- X-seq: zsh-workers 303
- From: P.Stephenson@xxxxxxxxxxxxx
- To: zsh-workers@xxxxxxxxxxxxxxx (Zsh hackers list)
- Subject: Re: Revised dohistexpand()
- Date: Thu, 10 Aug 95 15:08:04 +0100
- In-reply-to: "A.Main@xxxxxxxxxxxxxxxxx"'s message of "Thu, 10 Aug 95 13:54:55 BST." <24456.199508101254@xxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxx 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<magic-space>" 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<magic-space>). 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 <P.Stephenson@xxxxxxxxxxxxx> 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.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author