Since package_name+"."+small_letter will never get suggestion,why not just ignore case sensitive?I mean whatever p or P provided after "fmt.",gocode,show same suggestions .If I missed something to consider,please let me know,thanks
So, as I promised in issue 51, I actually thought about it. And such feature doesn't feel right.
1,Sorry for repeating,
2,I don't know that
4 first,from design perspective,any stuff that is not related to core business should be removed,even an action to press "shift".I am a programmer and a product designer also.From designer perspective,my first feeling is that ignore it will be better.
Back to 3,it may cause some confusing,but some distinguishing info(icon,color..etc.) can be added.I think that the value of (timesToPressShift - timesOfMistakeCauseByConfusing) should be big,if so,it is worth ignoring it.But I am not sure,can you give it a try?
No I won't give it a try. I have a deep belief that this feature is not worth it. Sorry.
I use visual studio in my day job, and I think the case-insensitive completion it uses is really handy. You might argue it makes one lazy, but in terms of speed, it is faster to type without hitting a shift button as well.
On the other hand, if you feel the feature is not worth the effort, then I respect that. I'm just adding a "vote" for this feature.
@kpm, Just use a proper text editor. Also, the plugin or whatever integrates with your editor shouldn't have any trouble providing the feature at least in that case things can be tuned to the particular editor and its customs
I'm still not convinced enough to make it in. And as DisposaBoy noted, it is possible to implement it on the editor side. The thing is, if I'm adding it right now, many editors that work with gocode won't necessary be able to use that feature. Because that feature requires from an editor an ability to change the code behind the cursor position on autocompletion event, e.g.:
Believe it or not, there are not so many editors which can do that at all. I know vim can for example. Both emacs gocode plugins don't do that, they filter things on their own. In other words it's a tricky issue. If it makes you think that if I'm adding case-insensitive filtering to the gocode and all the editors are suddenly able to do case-insensitive filtering, that's a mistake.
@DisposaBoy do you have a particular text editor in mind which is a "Proper" text editor? Which editors do non-case sensitive matching?
@nsf I guess I was thinking more along the lines of if gocode provides it, then editor plugin writers will eventually support it. It could even be a command line option to gocode, as I understand some editors launch gocode. But as I said, I'm fine with your choice not to provide this. Thanks. I might check the Liteide issue tracker for opinions on doing it from their end.
@kpm, that's the point, nothing prevents to implement that case-insensitive filtering right now on the editor side. Implementing it on the gocode side gives no benefit at all.
@kpm, http://www.sublimetext.com/2 and https://github.com/DisposaBoy/GoSublime also IIRC gedit does as well but it's been a very long time since I used it so I might be wrong
Surprisingly, one guy convinced me to reconsider my view on this feature. Here's what I think now:
1. If an editor does filtering on its own, it doesn't use gocode filtering and sends request on '.' cursor location. It means if I add or remove something to the gocode filtering logic, these editors see no change.
2. Doing case-insensitive filtering always doesn't make sense to me. However, when case-sensitive filtering gives no results it makes sense to fallback to case-insensitive filtering. This also removes the ambiguity of choice.
So.. perhaps I will implement it actually, soon.
@nsf, Interestingly, I do pt.1 in GoSublime and let ST2 do the filtering. In the future I plan to allow the user to configure whether to make it case-sensitive by the first letter only. So if you typed fmt.Pr that's case-sensitive but only on the first letter. The reason for that is: I personally often type gibberish like fmt.pf and let the completion system figure out that I most likely want fmt.Printf this works great in ST2 with its adaptive completion. The case-sensitivity then reduces the number of entries in the completion list without preventing ST2 from doing its job.
Use case-insensitive filtering as a fallback, if no proposals were fo…
Ok, it will work now in some editors like vim. But only in special cases, what I mean is that when filtering is done by the gocode and not an editor. A typical example would be a vim configured to do manual autocompletion. And when you type:
and press C-x C-o there, it will change the text to:
and show the proposed variants.
If that doesn't work for you, sorry I definitely won't do it better.
@DisposaBoy, I'm not a GoSublime user, so.. do whatever you want, this change shouldn't affect you as most other editors who figure out the dot position themselves and ask gocode to give the results from that point. Some editors like vim for example allow you to do requests from any position. This change was for these editors, because it's the only case when gocode has to do filtering on its own. And the editor I'm working on (the https://github.com/nsf/godit) will use that as well.
What ST2 does seems reasonable. I definitely won't do fuzzy matching in the gocode though. Or who knows maybe I'll reconsider it one day.
Although I should add that I'm a bit religious about autocompletion in a sense of user experience. It's a bad idea getting a habit of typing gibberish. Because once you're in an environment with no autocompletion, you have problems typing text. I would suggest using autocompletion as a reminder mostly, not as a typing assistance. Unless the word is really huge and takes some time to type. "Printf" isn't from that category certainly. :D
Thanks, I'll try this out soon! It is true that these kind of tools can encourage bad habits.