zsh-workers
 help / color / mirror / code / Atom feed
From: Zefram <A.Main@dcs.warwick.ac.uk>
To: P.Stephenson@swansea.ac.uk
Subject: Re: Revised dohistexpand()
Date: Thu, 10 Aug 1995 13:54:54 +0100 (BST)	[thread overview]
Message-ID: <25700.199508101327@stone.dcs.warwick.ac.uk> (raw)
In-Reply-To: <23407.9508091711@pyro.swan.ac.uk> from "P.Stephenson@swansea.ac.uk" at Aug 9, 95 06:11:33 pm

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 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?

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).

Magic-space also ought to do no history expansion immediately after a
backslash.  This is already fixed in the hzoli releases.

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.

-zefram


  reply	other threads:[~1995-08-10 13:34 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
1995-08-09 17:11   ` P.Stephenson
1995-08-10 12:54     ` Zefram [this message]
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=25700.199508101327@stone.dcs.warwick.ac.uk \
    --to=a.main@dcs.warwick.ac.uk \
    --cc=P.Stephenson@swansea.ac.uk \
    /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).