Autocomplete

Some initial thoughts on auto-complete.

I like it in general.  I suspect that I'll end up switching it off by default
(but see below), and using the complete-on-demand feature instead.  But that's
just a guess based on first impressions, I haven't done any real code-smithing
yet, so we'll see.

It seems to me that the auto-complete is a bit too eager.  For instance typing
<2> <space> will pop up a list of 336 possible selectors -- which is no real
use to anyone.  Perhaps there could be a (user-configurable, but defaulting to
two) minimum on the number of characters that were already typed before it
would attempt to auto-complete (after all, how many 1 or 2 character
identifiers are there in the image that we don't already know by heart ?).   It
turns out that reducing the max-auto-complete from its default of 500 to 50
reduces the problem significantly, and I suggest making the default lower (and
user-settable).

Related to this,  typing <2> <space> <plus> will result in an auto-complete box
with just one entry, which also seems pointless and distracting.  The above
reduction may be necessary to see this particular example.

(I've raised all the above as a single ER)

I've noticed that auto-complete doesn't seem to be aware of cascades, and gives
the wrong suggestions.  Unfortunately I can't find an example where
auto-complete can be persuaded to suggest /anything/ in a cascade now, so I
can't give an example :-(   I haven't (yet) raised this as a bug, because I
suspect that the behaviour is be-design, and that cascades as simply Too Hard
(tm) to get right.

I think that doits (<crtl>e, <ctrl>d, etc) should cancel the auto-complete box.
(Raised as a bug)

Since the appropriateness of auto-complete depends somewhat on context
(sometimes it's invaluable, at other times its a distraction), it would be nice
to be able to toggle it on/off, for each workspace separately from that WS's
toolbar.  (Raised as an ER)

That all...

    ... for now ;-)

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Some initial thoughts on auto-complete.
>

Thanks Chris, all good suggestions.

> I like it in general.  I suspect that I'll end up switching it off by
> default
> (but see below), and using the complete-on-demand feature instead.  But
> that's
> just a guess based on first impressions, I haven't done any real
> code-smithing
> yet, so we'll see.

As I've said elsewhere, I've found it tends to be more useful in virgin
territory.

>
> It seems to me that the auto-complete is a bit too eager.  For instance
> typing
> <2> <space> will pop up a list of 336 possible selectors -- which is no
> real
> use to anyone.

Actually I was in two minds as to whether to remove the feature of showing a
completion list after a space has been typed. I'm still not sure about it.

Its true that you are unlikely to make a selection from a list that large,
but sometimes having a fuller list for incremental search is useful in that
you can see what is around the current selection.

Good idea.

>
> Related to this,  typing <2> <space> <plus> will result in an
> auto-complete box
> with just one entry, which also seems pointless and distracting.  The
> above
> reduction may be necessary to see this particular example.
>

I've not been terribly happy about that myself. The auto-completion can be
configured to trigger automatic selection of a single item from the list,
but I didn't like that mode either. I think what is really needed here is to
avoid showing the list if there is only one choice and it is a precise match
to what has already been typed.

You're right - it was deemed too hard for now. There are some other cases
that also fall into that category which you'll no doubt encounter as you go
along.

>
> I think that doits (<crtl>e, <ctrl>d, etc) should cancel the auto-complete
> box.
> (Raised as a bug)

That was the intention; in fact any command should cancel the
auto-completion list. Unfortunately while investigating this prior to the
beta release I discovered that there was nowhere generic to hook such an
operation into the command framework, so it had to be delayed.

>
> Since the appropriateness of auto-complete depends somewhat on context
> (sometimes it's invaluable, at other times its a distraction), it would be
> nice
> to be able to toggle it on/off, for each workspace separately from that
> WS's
> toolbar.  (Raised as an ER)

Good idea. There was supposed to be an entry on the workspace context
(options) menu for this, but it didn't quite make it in.

Regards

Blair

Blair McGlashan wrote:
> "Chris Uppal" <[hidden email]> wrote in message
> news:[hidden email]...

Would it be possible to highlight the most likely choice? For example,
if it is looking for a message and I type "no", I'd like it to select
"notNil" in the list since that is likely to be the most frequently used
message that starts with "no". You could also combine this with the
user's history. For example, if last time I complete "no" with
"noSelection" then "noSelection" should be the one selected. If you used
such a scheme, then I wouldn't mind the large list.


John Brant

Chris,

Excellent point, but I would suggest building the list in the background
and presenting it only when the number of choices is below a threshold
set by the user, and perhaps modified (#max:) by the number of matches
when the context is clear.  By the latter, I am trying to avoid having
it refuse to offer options due to an unrealistically small threshold value.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"John Brant" <[hidden email]> wrote in message
news:[hidden email]...
John, these are good ideas, but may not be feasible with the current
Scintilla implementation - certainly it is possible to control the initial
selection, but subsequently to that Scintilla performs the incremental
search and as far as I recall it doesn't send a notification of intermediate
"selections". Of course such a notification could be added.

Regards

Blair

Blair McGlashan wrote:

> John, these are good ideas, but may not be feasible with the current
> Scintilla implementation - certainly it is possible to control the initial
> selection, but subsequently to that Scintilla performs the incremental
> search and as far as I recall it doesn't send a notification of intermediate
> "selections". Of course such a notification could be added.

It is possible -- SCI_AUTOCSELECT. For example, adding the following to
ScintillaView will have it automatically select notNil when an $o is typed:

onKeyTyped: aKeyEvent
   ^[super onKeyTyped: aKeyEvent]
     ensure:
       [self isAutoCompletionActive
         ifTrue:
           [aKeyEvent code = $o asInteger
             ifTrue:
               [self
                 sendMessage: SCI_AUTOCSELECT
                 wParam: nil
                 lpParam: 'notNil']]]


John Brant