microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
163.64k stars 29.04k forks source link

Multiselect via ctrl+d case insensitivity makes it useless #18239

Open ds0nt opened 7 years ago

ds0nt commented 7 years ago
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.

2017-01-06-150041_626x115_scrot

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

2017-01-06-150136_731x106_scrot

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:

2017-01-06-150329_1605x153_scrot

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 commented 7 years ago

These are my atom habits, btw. :)

ds0nt commented 7 years ago

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

ds0nt commented 7 years ago

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 commented 7 years ago

+ 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 commented 7 years ago

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 commented 7 years ago

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

sirgallifrey commented 7 years ago

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!

272185fa61322668c896868518f3a8ef_feels-good-man-meme-feels-good-man_430-397

msageryd commented 7 years ago

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 commented 7 years ago

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

ViggoV commented 7 years ago

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

leocaseiro commented 7 years ago

GUYSSSSS!

I'm so happy, so so happy!

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

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

msageryd commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@rebornix do you have a link to that commit?

alexdima commented 7 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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: image

This is what I call a non-collapsed selection: image

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

jakedarc commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

"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 commented 6 years ago

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

leocaseiro commented 6 years ago

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

gthjvar730

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

alvitawa commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

+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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

tj commented 4 years ago

👍 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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

initplatform commented 4 years ago

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

https://github.com/microsoft/vscode/issues/4309#issuecomment-276530055

initplatform commented 4 years ago

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 commented 4 years ago

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

hediet commented 3 years ago

Related: #106502