From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH and Re: simulation of dabbrev-expand
Date: Thu, 23 Sep 1999 16:23:53 +0200 (MET DST) [thread overview]
Message-ID: <199909231423.QAA24746@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Adam Spiers's message of Thu, 23 Sep 1999 14:44:53 +0100
[ Last mail from me for the next two weeks... ]
Adam Spiers wrote:
> Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> > *But* words
> > from the same line are inserted left-to-right. Since the C-code walks
> > up maybe we should add the words from the end of the line to the
> > beginning.
> >
> > We should then use the hunk for `zle_tricky.c' below.
>
> Nice touch. Reminds me of another feature I've wanted in
> _history_complete_word for ages - would it be possible to modify
> compgen -H to include words from the currently edited line?
Not that simple because we don't have it in parsed form yet. We could
make `get_comp_string()' save them but then we still would only get
the words for the current command and all commands before it.
> Hmm. I'm still puzzled why compadd -X ... -n '' throws away the old
> list though, since compwidget == lastcompwidget and
> compstate[old_list] is set to keep.
If I understood you correclty: it doesn't. It only looks like that
because of the compstate[insert]='' in _message.
> - Doesn't cope with numeric arguments yet.
> - Whenever duplicates get removed, it breaks. It looks like
> compstate[nmatches] corresponds with the number of matches
> /including/ duplicates, even if some/all duplicates have been
> removed.
At the time where you can look at `compstate', it is `...will be
removed'. Remember that all the sorting and uniquifying is only done
after the widget has returned (and for performance reasons we should
probably only do it then). Although... we could do it whenever someone
looks at `compstate[*nmatches]', set a flag if the list is sorted and
clear the flag when another match is added. Hm. No time now...
> - The error message given when unknown keys are bound to the
> widget doesn't work. Should I be using zle -R here?
No, `zle -R' will only flash the message (and only one line).
Ignore that? Beep? Use `_message' or similar code?
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~1999-09-23 14:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-23 14:23 Sven Wischnowsky [this message]
1999-09-25 14:45 ` Adam Spiers
-- strict thread matches above, loose matches on Subject: below --
1999-10-11 11:12 Sven Wischnowsky
1999-10-11 21:44 ` Adam Spiers
1999-09-23 8:38 Sven Wischnowsky
1999-09-23 13:44 ` Adam Spiers
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=199909231423.QAA24746@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/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).