Skip to content

Loading…

Suggestion:ignore case sensitive(let fmt.p==fmt.P) #91

Closed
AlexLuya opened this Issue · 15 comments

4 participants

@AlexLuya

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

@nsf
Owner
nsf commented
  1. You're repeating yourself: #51. I've heard you that first time loud and clear.
  2. In some editors autocompletion plugins just don't replace stuff behind the cursor. If you type fmt.p it will become fmt.printf if user autocompletes.
  3. Even though it is indeed true that external package cannot contain unexported fields and all entities start with a capital letter, it's not true for local structs and interfaces. If you think that adding a rule that says: "when you do autocompletion on an imported package it is case insensitive and when you do autocompletions on local entities it is case sensitive" is a good idea. I don't think so. It will be confusing.
  4. Frankly I don't understand what great benifit this feature brings? Is it hard for you to type a single upper case letter holding shift? I mean the amount of allowed programmer lazyness should be capped at some sensible value.

So, as I promised in issue 51, I actually thought about it. And such feature doesn't feel right.

@AlexLuya

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?

@nsf
Owner

No I won't give it a try. I have a deep belief that this feature is not worth it. Sorry.

@nsf nsf closed this
@kpm
kpm commented

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.

@DisposaBoy

@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

@nsf
Owner
nsf commented

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.:

fmt.pri<autocompletion>

becomes:

fmt.Print<cursor>

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.

@kpm
kpm commented

@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.

@nsf
Owner
nsf commented

@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.

@DisposaBoy

@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

@nsf
Owner
nsf commented

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 nsf reopened this
@DisposaBoy

@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.

@nsf nsf closed this in 0e46b3d
@nsf
Owner
nsf commented

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:

fmt.pri

and press C-x C-o there, it will change the text to:

fmt.Print

and show the proposed variants.

If that doesn't work for you, sorry I definitely won't do it better.

@nsf
Owner
nsf commented

@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.

@nsf
Owner
nsf commented

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

@kpm
kpm commented

Thanks, I'll try this out soon! It is true that these kind of tools can encourage bad habits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.