|
> My particular color choices are not ideal, but
you get the idea that it is a visual color distinction as you type based on the
number of potential matches.
This suggestion seems to be interesting. We will
think about it, thanks.
----- Original Message -----
Sent: Tuesday, April 02, 2002 8:45
PM
Subject: Re: [Eap-list] a few 614
issues
Valentin Kipiatkov wrote:
Code completion--
* For autocomplete, I assume there is no way to combine SmartType with
Basic in one keymap, but I think such a combined code completion
technique would be helpful. Ideally, SmartType would take effect if
possible but if it cannot then Basic completion would be in effect.
This is actually not that straightforward. For example in the following
code:
String s = a<code completion here>
you can either get
String s = aStringVar;
with SmartType code completion, or
String s = aNonStringVar.getSomeString();
by using normal completion. So the choice is up to you. For
your example, I do want aStringVar unless it isn't available then go for the
option that don't match the type, aNonStringVar.getSomeString(). This
combination completion would be in addition to the current Basic &
SmartType. You can also type more if you are using this combo-completion and
don't want a type match, or you can invoke Basic.
I would consider
mapping it to the Tab key. Here's one way it could work to deal with your
issue and satisfy my goal:
* 1st tab pressed-- invoke SmartType if anything
matches type else invoke Basic on 1st tab
* 2nd tab pressed-- invoke Basic
(if SmartType was successfully invoked on 1st tab)
* Another small autocomplete enhancement would be for it to use a
different color or shade for the letters (if any) before the current
caret position when there is one match compared to multiple matches (and
also different for no matches). Maybe even red (no matches), yellow
(multiple matches), and green (one match).
Do you mean letters in the editor or in the lookup list? Please explain your
suggestion with some example. In
the editor, so, here's a scenario as you are typing characters:
String
hello;
String helicopter;
String x =
............more than one
match........
String x = h
String x = he
String x = hel
............exactly one
match............
String x = hell
............no matches.................
String
x = helli
My particular color choices are
not ideal, but you get the idea that it is a visual color distinction as you
type based on the number of potential matches.
* How about an option in "Move Inner to Upper Level" that allows you to
place the class in the current java source file as a non-nested class?
Why do you need this? Isn't one-class-per-file technique much more
convenient? I
agree that default should be one-class-per-file during such a move, but there
are times when I want a subordinate non-nested, package-protected class in the
same java file. It is completely legal in java although some people may not
like to use it. Sometimes it is a transitional placement until you decide what
other package to move it, but there can be times when you want it to reside
there permanently.
Thanks,
Jon
|
