zsh-workers
 help / color / mirror / code / Atom feed
From: Zoltan Hidvegi <hzoli@cs.elte.hu>
To: zsh-workers@math.gatech.edu (zsh-workers)
Subject: Re: Revised dohistexpand()
Date: Wed, 9 Aug 1995 17:21:01 +0200 (MET DST)	[thread overview]
Message-ID: <199508091521.RAA02428@bolyai.cs.elte.hu> (raw)
In-Reply-To: <22497.9508091344@pyro.swan.ac.uk> from "P.Stephenson@swansea.ac.uk" at Aug 9, 95 02:44:36 pm

Peter Stephenson wrote:
> One of the bits I like least about the history code (and that's a bold
> statement) is the zle history expansion.  The problem is that it
> relies on calling the lexer, and via that the history code, and those
> together build up a new editing line directly.  This is one more
> reason why the history code is hard to maintain, and is also very
> wasteful:  neither the resulting tokens nor the resulting history line
> are used.

I think that these few additional line for building the expanded line do not
make the history code much more difficult to maintain.  I agree that it is a
bit tricky, but once you understand it it is quite obvious.  And after your
history rearrangement it become a bit simpler that it used to be.  Also I
wrote long comments about this staff in hist.c to make understanding easier.
If something is still unclear ask me and hopefully I can explain it.

> This revised version eliminates the lexer and uses hgetc() to get
> history expansion directly.  As most of the work is now done specially
> in doexpandhist(), it was possible to rewrite it so that only history
> expansions in the current word are expanded, which is now in keeping
> with other forms of expansion and completion.  This alone should make
> it all worthwhile.  For example,
>   % cmd !!:1 z<TAB>
> will now do completion on the second argument, as you would expect;
> formerly it would expand the previous history reference first.

This doesn't really a problem if you use magic-space.  !!:1 is already
expanded when you try to expand z.

> There are a couple of drawbacks: single quotes don't hide this form of
> expansion (though again that's just like glob expansion: try typing
> '*' and then tab), and complex substitutions like !:s/a b/c d/ will
> sometimes be mishandled (though usually you get what you deserve,
> particularly if you've just finished typing the whole expression).  I
> don't think either of these is at all significant.  I have also made
> sure that magic-space still works.

That's my main problem.  Magic space is unusable if it expands single quoted
history references.  E.g. you couldn't type 'Hello!' (followed by a space).
And without the lexer there is no way to get it right as there are so many
cases: '!$', "'!$'", "`'!$'`" etc.  The other thing you mention that '*' is
turned to * after TAB is an other bug and it does not justify the bogous
behaviour of single-quoted bangs.

Also before beta5 (or beta6) doexpandhist() did not call the lexer.  But
before beta4 (as I remember) single quotes did not quote history references
either.  doexpandhist() was changed by Sven exactly because single quotes
disabled history expansion.

> There is still some small collusion with the history code: when
> expanding, the history line is not modified and the pair \! is left as
> it is instead of being turned into !.  These are algorithmically

That is the way it should work.  \! should remain unchanged.  Otherwise if you
type \!$<magic-space> it would turn to !$ and after RETURN it would change to
the last word of the previous line.

> simple and self-contained, however.  It may also be possible to
> simplify the qbang logic in hist.c (it's now not needed at all when
> expanding), but I don't know enough about that (yet).

This qbang is not too important in the stock beta10 as I remember, but it is
important for my releases to fix a bug when >\!foo expanded history (or
something like that).

To summarize my opinion, I do not like this patch very much.  It doesn't fixes
any bugs but it introduces one.  I normally bind magic-space to space so each
time I hit space the whole line I typed so far goes through the lexer but the
time spet there is unnoticable even on a slow 386/DX40 system (which I still
use at home).

Zoltan


  parent reply	other threads:[~1995-08-09 15:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-08-09 13:44 P.Stephenson
1995-08-09 14:35 ` P.Stephenson
1995-08-09 15:21 ` Zoltan Hidvegi [this message]
1995-08-09 17:11   ` P.Stephenson
1995-08-10 12:54     ` Zefram
1995-08-10 20:19       ` Zoltan Hidvegi
     [not found] <24456.199508101254@stone.dcs.warwick.ac.uk>
1995-08-10 14:08 ` P.Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199508091521.RAA02428@bolyai.cs.elte.hu \
    --to=hzoli@cs.elte.hu \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).