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. >...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). 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. > (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. 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]... >>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. 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 |
In reply to this post by Chris Uppal-3
Chris,
> 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 ?). 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] |
In reply to this post by John Brant
"John Brant" <[hidden email]> wrote in message
news:[hidden email]... > Blair McGlashan wrote: >> "Chris Uppal" <[hidden email]> wrote in message >> news:[hidden email]... > >>>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. > > 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, 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 |
Free forum by Nabble | Edit this page |