From: "Bart Schaefer" <schaefer@brasslantern.com>
To: zsh-workers@math.gatech.edu
Subject: Re: new completion behaviour version 2
Date: Mon, 9 Nov 1998 15:09:37 -0800 [thread overview]
Message-ID: <981109150938.ZM19408@candle.brasslantern.com> (raw)
In-Reply-To: <199811090904.KAA07856@beta.informatik.hu-berlin.de>
On Nov 9, 10:04am, Sven Wischnowsky wrote:
} Subject: Re: new completion behaviour version 2
}
} Bart Schaefer wrote:
} >
} > That is, the widget can say "here are the completions, and here is where
} > you insert them" but then let hardwired code take over cycling through
} > the menu if there are multiple matches.
}
} Interesting point of view. I thought we wanted to give the user the
} possibility to build widgets that have full control
Well, yes, that's why I said I could easily be convinced otherwise; but:
} > Listambiguous can be a flag attached to the generated
} > list of matches, can it not?
}
} Yes. The question is: should the completion code do this automatically
} or should the user request it explicitly.
It's quite a burden on the widget writer to check for LISTAMBIGUOUS and
spit out the listing if so. On the other hand, the widget ought to be
able to emit a listing (and have zle deal with it properly) even when
the LISTAMBIGUOUS is not set.
It seems to me there are three ways to deal with this:
1. The widget function always produces the entire list of matches, with
an annotation for how and where to insert them.
+ Returning a single value forces recexact.
+ The function always executes in the same way and always returns
the same values, so its easier to write.
+ Efficient, compiled builtin code handles menus and listings, and
tests for menucomplete, automenu, autolist, and listambiguous.
+ There's only one call to interpreted user code per set of results.
- The annotations have to describe prefix/suffix removal, replacement,
or addition for correct insertion on the command line.
- It may be unclear exactly what to display in a listing, i.e., what
if any prefix/suffix changes to perform on the returned strings.
2. The widget function always produces one match at a time, with an
annotation for how and where to insert it.
+ Builtin code still tests for menucomplete, automenu, autolist, and
listambiguous.
+ The function can change the insertion annotations on every match.
- The function has to be told which match to produce; it's harder to
write efficient functions because it's necessary e.g. to branch on
whether the full list has previously been generated and on whether
the prefix has changed.
- Lots of calls to interpreted code when generating listings and when
cycling through menus.
- It requires either an annotation or two calls to the function to
force recexact.
- It still may be difficult to determine what to display for a listing.
3. The widget function not only produces the matches, but also either
inserts them or produces a listing as appropriate.
+ The function can drive zle directly (e.g., through $BUFFER) to do
complex insertions/changes.
+ No annotations are needed.
+ The function can produce exactly what should appear in the listing.
- The function has to be told what match to produce or to produce a
complete list of possible matches; it's even harder to write simple
efficient functions.
- Lots of calls to interpreted code when generating menus.
- The widget writer has to figure out all the prefix/suffix changes
to perform on every insertion, including dealing with menus (but an
implicit "undo" of the last insertion before calling the function
for the next item could make that easier).
- The widget itself has to test automenu, autolist, and listambiguous.
There are of course points somewhere in between each of these choices, but
they all have something of those flavors. I think the choice of which to
provide depends on what we can come up with in terms of the annotations
needed by the first two.
} > compadd $disabled
} > instead of
} > compadd -dFB
}
} I like this. But I wouldn't like to have to do
}
} compadd $(compinfo -disabled)
I agree; if the choice is between that and something like
compadd disabled
then I'd take the latter.
} > [[ ]] to mean "test completions", e.g., [[ -C index -1 / ]] for the
} > above.)
}
} I didn't think about changing [[...]], interesting. (Although that
} would require changes in completely differnt parts of the code, of
} course.)
Yes, but I've been thinking that perhaps the tests supported by [[ ]]
should be extensible through the modules mechanism anyway.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~1998-11-09 23:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-11-09 9:04 Sven Wischnowsky
1998-11-09 23:09 ` Bart Schaefer [this message]
-- strict thread matches above, loose matches on Subject: below --
1998-11-02 10:36 completion behaviour (was: zsh-workers: zsh-3.1.5 released) Sven Wischnowsky
1998-11-02 11:29 ` Zefram
1998-11-02 12:00 ` Sven Wischnowsky
1998-11-02 12:31 ` Zefram
1998-11-02 13:48 ` Sven Wischnowsky
1998-11-03 15:58 ` new completion behaviour version 2 Sven Wischnowsky
1998-11-03 17:15 ` Bart Schaefer
1998-11-06 19:02 ` Bart 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=981109150938.ZM19408@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--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).