Multiselect via ctrl+d case insensitivity makes it useless

[ds0nt]

• VSCode Version: Code 1.8.1 (ee428b0, 2016-12-19T14:41:20.664Z)
• OS Version: Linux x64 4.4.38-1-MANJARO
• Extensions:

Extension	Author	Version
Go	lukehoban	0.6.51

---

Steps to Reproduce:

consider this block of code:

	accountQryConn   *grpc.ClientConn
	accountQryClient proto.AccountQueryClient

when I select 'account' and hit alt+d a few times it will select it like this.

this is fine, but when I do this, I am doing it to replace it with something else. So I'll start typing:

but now my case is broken for my second string.

This is fine in a small example, but very annoying.

Currently the case matches whatever is highlighted in the search widget. Behold what happens if I turn off case sensitivity:

This is incredibly annoying. I can't think of a time when you would want to multiselect case-insensitively with ctrl+d. It simply selects the wrong stuff, because in code it's always case sensitive. So depending on whatever I did last with ctrl+f, my ctrl+d either works or is annoying.

I think ctrl+d should always be case sensitive, or have a button that's not search-tied that does a case sensitive string selection match across the file

My two cents.

[ds0nt]

These are my atom habits, btw. :)

[ds0nt]

but vscode has good golang support so I'm giving it a chance.

[ds0nt]

I'd prefer it if I could select all the instances of 'account' one by one, and then type something else to replace it.. like 'voucher'. Following which, I'll select the "Account" and replace it as well with "Voucher". This makes sense to me, as Voucher != voucher in terms of what a compiler thinks

[sirgallifrey]

+ 1 to this request.
My case is similar, but I make a selection and the vscode makes a case insensitive highlight, so I can press ctrl + shit + L and select all de occurrences (case insensitive). Then I have, lets say RateField and ratefield selected, and those are not the same thing, which makes this feat less useful.
I was thinking as this function is related to the "editor.selectionHighlight" we could have a "editor.selectionHighlightCaseMatch" to choose from sensitive or insensitive, in that fashion the default behavior won't change.

[nicolasg-da]

I have the same issue in Haskell, where value and Value are two very different things.

Maybe it would be possible to set a language specific option for this?
So keep the current behaviour but add an option to overwrite it for certain languages where casing matters?

[leocaseiro]

Try Alt+C(pc) or Option+Command+C(mac) to toogleFindCaseSensitive

[sirgallifrey]

Thank you so much!!
That is the most obscure config ever! I would never find it on my own... Thanks again, you made my vscode so mush better!

[msageryd]

Please make findCaseSensitive a setting so we can have case sensitivity by default. Everytime VSCode is restarted the case sensitivity toggles back to the default, ie. not case sensitive.

This has bitten me many times when using cmd-d for multiselecting in "refactoring sessions"

[altla]

findCaseSensitive really needs to be a setting. Without case sensitivity, "next match" is pretty much useless.

[ViggoV]

+1! I very much agree! This bugs me every day!

[leocaseiro]

GUYSSSSS!

I'm so happy, so so happy!

The new release 1.13 now preserves the settings of toogleFindCaseSensitive state.

👍 🍻 🎉 🎈 ❤️ 😃 🍷 👍 🍻 🎉 🎈 ❤️ 😃 🍷 👍 🍻 🎉 🎈 ❤️ 😃 🍷

[msageryd]

Great news!
This was the first thing I looked for in the change log. Must have missed it. Thank you for letting us know.

[rebornix]

@leocaseiro @msageryd thanks for calling it out. I added this for half a month in Insider but forgot to mention it in release note :)

[altla]

@rebornix do you have a link to that commit?

[alexdima]

PR #36682 (for #8869) makes it that when starting with a collapsed selection, Command+D/Control+D will now search with wholeWords: true and caseSensitive: true.

Command+D/Control+D will still respect the find widget settings when starting with a non-collapsed selection.

[ViggoV]

@alexandrudima I'm not sure what you mean by collapsed selection? I don't see why the cmd+d/ctrl+d selection can't just have its own, permanent settings. There is absolutely no scenario where I would do a case insensitive multiselect and I would personally like to keep wholeWords set to false (eg. if I copy multiple vars with the same prefix and want to replace that)..

[alexdima]

@ViggoV I see your point. But the problem is that what works well for one person will not necessarily work well for a large set of other people. Not everyone would like to have permanent settings for Ctrl-D.

This is what I call a collapsed selection:

This is what I call a non-collapsed selection:

Please try out the latest release in the Insiders Channel and provide feedback after you have tried it out.

[jakedarc]

I agree with @ViggoV here - a case-insensitive Ctrl+D is literally useless to me. At least the option of setting its case sensitivity would be good. I can't think of another text editor that handles this the way Code does; both Atom and Sublime are case-sensitive for this operation and with good reason. The new behavior is better but still isn't great.

That said, I think my extension is a pretty good bandaid. The highlighting doesn't match because it still shows the default Ctrl+D behavior but otherwise I tried to make the command my extension adds work like you would want this functionality to behave. I have my editor set up so my extension's action overrides Ctrl+D and the default is Ctrl+Shift+D.

[ViggoV]

Thanks @JakeKantzer! Works like a charm.. As for the question on whether multiselect should be case-insensitive in the first place I will stop arguing against it as soon as anyone shows me a valid and non-edge use case for it, where you would actually want to replace matches of differing case with text of the same case. The collapsed/non-collapsed solution simply doesn't cut it, since you might want to copy { momName: "Mommy", momAge: "Really old" } and replace mom with dad. In my opinion that solution just puts more confusion into the mix, which may well annoy a lot of other people. But but but, I'll shut up about it as soon as someone shows me a reasonable use case to justify case-sensitivity being the default option and the one it reverts to.. ;)

[maranomynet]

"I think ctrl+d should always be case sensitive"

+1

...or at the very least it should NOT be tied in with the Ctrl+F state, as their use-cases/-patterns are normally very different.

[garajo]

@leocaseiro toogleFindCaseSensitive gives me 'Unknown configuration setting'. Is that the full namespace?

[leocaseiro]

Hi @garajo, I don't think there's a setting for that. It's a shortcode only.

You can also click to toggle the case sensitive while searching Ctrl+F(pc) or Cmd+F(mac) which will work on Ctrl+d(pc) and Cmd+d(mac):

PS: It works on Global Search to Ctrl+Shift+F(pc) or Cmd+Shit+F(mac).

[alvitawa]

@leocaseiro So is this toggle supposed to be preserved after exiting vscode? I see that you said last year that version 1.13 would make toogleFindCaseSensitive a setting, but when I restart vscode it forgets whether it was set to case sensitive or case insensitive.

[mjpizz]

I'm having a similar issue - it seems I have to toggle case insensitivity pretty often. Maybe it's just per-workspace? I interact with a lot of different repositories and it has surprised me every time.

Would definitely put +1 behind having my case-sensitivity toggle persisted globally, rather than having to toggle it again for each workspace.

[tannerbaum]

So If I understand the original issue, if I want to replace Account with Profile in Daniel's code images it is impossible to do so without them all being written in the same case ("Profile" or "profile").

If the argument is that it would be better if that cmd+d operation adjusted to the case of what it is replacing, I agree. But maybe I am misreading the comments here and that is already possible somehow 😅

[greenais]

+100 for separtion of ctrl-D and ctrl-F spaces.
Really other proven_to_be_good editors keep ctrl-D case-sensitive for the good reasons (already clearly stated abowe). Why MS should be different in a bad way?
I personnaly don't care about default setting - choose whatever you like - since I will be able to set desired behaviour for ctrl-D separately.
Otherwise after each ctrl-F I have to remember to fire alt-C again in order to be safe from "nice surprises".

[kanlukasz]

It is true that it should be definitely separated.
toogleFindCaseSensitive is not a solution, because when I am looking for something (ctrl + f), in most cases i would like to see all words with all case sensitives. Unlike when text is selected (ctrl+d)

[fnky]

I also vouch for a better user experience in this regard. If the editor would remember the settings that I have selected during Find, Find & Replace and Multiple Occurrences across sessions, then it would less confusing.

At the moment it defaults back to no settings being selected when you open a new editor.

[McNerdius]

Agreed, it needs to be a persisted setting. Or a new default, or decoupled from ctrl+F, or any/all of the above.

Ctrl+D ... oops it was case insensitive ... Ctrl+U, Alt+C, start over... Every time ? Probably not quite, but it feels like it.

Case insensitive as a default here is just odd/unintuitive IMO.

[pmarreck]

Chiming in to vouch for Control-D case sensitivity as a permanent option that defaults to "case-sensitive"

[tj]

👍 this default is never what I actually want, I'm not even sure it would be a good default for textual documents like markdown

[msageryd]

What's the status of this issue? It seemed to have been solved, but it really isn't. Or have I missed something?

As long as this setting is not a permanent setting it's of no use. I don't know when it happens, but now and then my ctrl-d gets case insensitive. Is it still connected to the ctrl-f setting?

Oh, how great this worked back in the SublimeText days. I simply don't trust ctrl-d in VSCode, and that's a bad thing in an editor.

[McNerdius]

@msageryd and everyone else - in the meantime: Case-Sensitive Add Next Occurrence extension. It's bound to ctrl+shift+d by default, but i went all in...

  {
     "key": "ctrl+d",
     "command": "-editor.action.addSelectionToNextFindMatch",
     "when": "editorFocus"
  },
  {
     "key": "ctrl+d",
     "command": "extension.caseSensitiveAddNext",
     "when": "editorFocus"
  }

[Radivarig]

There is an extension multi-cursor-case-preserve which keeps capital cases while typing in replacement string.

[initplatform]

I don't want to have to add an extension.. how about a setting that just lets me specify the defaults.

When I add new projects I always get bit by this.

There was a good suggestion a couple years ago in another thread ->

#4309 (comment)

[initplatform]

BTW.... is there even anyone lobbying to keep ctrl+d case insensitive as default?
Was it a conscious choice to make it insensitive in the first place?

Not being difficult, seriously curious as to what advantage case insensitive ctrl+d gives?

I can't think of a case insensitive programming language, though I'm sure there may be one.

[tj]

Please :D the default doesn't make much sense in a programming context

[hediet]

Related: #106502