zsh-workers
 help / color / mirror / code / Atom feed
From: wischnow@informatik.hu-berlin.de (Sven Wischnowsky)
To: zsh-workers@math.gatech.edu
Subject: Re: couple of zsh features
Date: Fri, 8 Dec 1995 08:20:31 +0100 (MET)	[thread overview]
Message-ID: <199512080720.IAA18489@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Richard Coleman's message of Thu, 07 Dec 1995 15:22:42 -0500


Richard Coleman wrote:

> 
> > I do think correctall would be more usable if you could actually enter
> > the corrected spelling at the SPROMT, rather than merely accepting or
> > rejecting the guess and then having to go back to zle to edit the line.
> > 
> > } Maybe some kind of compctl-based matching could be used to determine 
> > } which word in the previous command was a likely mismatch.
> > 
> > It might be useful to have the word or character position of the last
> > failed correction available to compctl, and to have a history reference
> > for the last unknown command or syntax error.
> 
> I've also been thinking about similar things.  A lot of the recent
> work in zsh has moved more of the intelligence in the code into
> the hashtable code.  To use an overused buzz-word, the internals
> of zsh have become more `object-oriented' in some sense.  This is
> a trend I would like to continue.  The next thing would be to move
> some of the command completion and spelling correction code into
> hashtable.c.  So (in some sense) each type of object (alias, builtin,
> etc...) would know how to complete itself, or spell check itself.
> Once this is done, I think we could generalize the code so that both
> spelling correction and command completion would be  programmable
> in similar ways.
> 
> Just a thought.
> 

Oh yes. I thought about that a lot when I was working on
zle_tricky. It would be nice to turn that completion code into a
general `produce a list of what we need here'-code. The main problem
(I think) is that we would need a good internal representation for
lexed (and parsed) command lines that would be used throughout the
whole code. Once we had this, it wouldn't be too complicated to turn
the completion code (and merge it with the correction code) into the
above mentioned list-generator (we probably would also have to add
some more possibilities for describing command arguments).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


             reply	other threads:[~1995-12-08  7:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-12-08  7:20 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
1995-12-16  0:52 Thomas Pierre Schweikle
1995-12-07 16:31 Matt Liggett
     [not found] ` <mliggett@seven.ucs.indiana.edu>
1995-12-07 17:29   ` Barton E. Schaefer
1995-12-07 17:59     ` Matt Liggett
1995-12-08  9:07       ` Bas V. de Bakker
1995-12-07 20:22     ` Richard Coleman
1995-12-07 19:02   ` Barton E. Schaefer

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=199512080720.IAA18489@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --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).