Ctrl-D/W working in other editors?

I know I can probably configure this manually, but is there any reason that
some Resharper keystrokes, like Duplicate Line (Ctrl-D) can't be made to
work in all text editors within VS? When I flip over to other files in my
solution, like SQL files and Text files and such, I sometimes find myself
really missing Ctrl-W, Ctrl-D, and some others... I know Ctrl-W isn't likely
(it has too many language-specific smarts), but even there, there are basic
"generic" boundries that are bound to be the same for most other files (like
parens and quotes (single and double) providing natural "blocks" ... braces
and angle brackets and BEGIN/END as well could be added for generic block
markers, etc).

Just wondering if this is even possible (or desirable)?

2 comments
Comment actions Permalink

Hello Paul,

Ctrl-D works in any file, just checked in 3.0 for TXT file not in solution.
Do you have specific case when it doesn't work?

Ctrl-W indeed requires semantic structure and thus only works in the source
code we understand - C#, VB, XML, XAML, ASP, NAnt and MSBuild files. I agree
that we can make it work for other files in some simple manner, but I afraid
it will annoy quite often. If you see Extend Selection working in SQL files,
you may pretend it should understand column list in SELECT statement :)

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


PB> I know I can probably configure this manually, but is there any
PB> reason that some Resharper keystrokes, like Duplicate Line (Ctrl-D)
PB> can't be made to work in all text editors within VS? When I flip
PB> over to other files in my solution, like SQL files and Text files
PB> and such, I sometimes find myself really missing Ctrl-W, Ctrl-D, and
PB> some others... I know Ctrl-W isn't likely (it has too many
PB> language-specific smarts), but even there, there are basic "generic"
PB> boundries that are bound to be the same for most other files (like
PB> parens and quotes (single and double) providing natural "blocks" ...
PB> braces and angle brackets and BEGIN/END as well could be added for
PB> generic block markers, etc).
PB>
PB> Just wondering if this is even possible (or desirable)?
PB>


0
Comment actions Permalink

I'm using 2.5.2, and it's never worked in any non-C# file I've tried (mostly
SQL files and *.cmd batch files). I'm forever pressing it out of habit and
watching as absolutely nothing happens. These files are "solution items" in
the solution.


"Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
news:9f6b3e2913c7e38c9781db47f6815@news.intellij.net...

Hello Paul,

>

Ctrl-D works in any file, just checked in 3.0 for TXT file not in
solution. Do you have specific case when it doesn't work?

>

Ctrl-W indeed requires semantic structure and thus only works in the
source code we understand - C#, VB, XML, XAML, ASP, NAnt and MSBuild
files. I agree that we can make it work for other files in some simple
manner, but I afraid it will annoy quite often. If you see Extend
Selection working in SQL files, you may pretend it should understand
column list in SELECT statement :)

>

Sincerely,
Ilya Ryzhenkov

>

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>
>

PB> I know I can probably configure this manually, but is there any
PB> reason that some Resharper keystrokes, like Duplicate Line (Ctrl-D)
PB> can't be made to work in all text editors within VS? When I flip
PB> over to other files in my solution, like SQL files and Text files
PB> and such, I sometimes find myself really missing Ctrl-W, Ctrl-D, and
PB> some others... I know Ctrl-W isn't likely (it has too many
PB> language-specific smarts), but even there, there are basic "generic"
PB> boundries that are bound to be the same for most other files (like
PB> parens and quotes (single and double) providing natural "blocks" ...
PB> braces and angle brackets and BEGIN/END as well could be added for
PB> generic block markers, etc).
PB> PB> Just wondering if this is even possible (or desirable)?
PB>


0

Please sign in to leave a comment.