Uppercase/Lowercase quoted text

[Worker]

I just discovered that version 11 added this new feature: "Selection > Uppercase/Lowercase no longer affects quoted text" And I kind of hate it. It's counter-intuitive because no other editor does this.

I had an email address copied from somewhere and pasted it into a script. Then I tried to convert the address to lowercase and this new feature wouldn't let me. (I know I can add "LOWER()" to my script. That's not the point.)

Can I ask that the old functionality is brought back, maybe in addition to the new functionality? All I'd really need is to be able to bind Ctrl-U and Ctrl-L to the old functionality.

Am I missing something that explains why the new functionality is much better than the old functionality?

 

[Theod]

Hi,

my first shot is.

SELECT NVL(NULL,'N') COL_Y_N FROM DUAL;

=>

select nvl(null,'N') col_y_n from dual;

The 'N' goes (right now) not to lowercase, if i mark all. But if i would have quotet text lowercase also, i can now mark the text beetween the quotes and lower it itself.

 

[Hilarion]

I understand that not everyone can like the new behavior so I'd see it as a configurable option or give us separate commands with old and new behavior.

I do like the new behavior as it's a bit more code aware, so I can safely mark blocks of code and what is case sensitive (the quoted text) will remain as it is when I have it lowercased or uppercased and it still will allow me to change case of the quoted text as long as I select this quoted text.

What is a bit confusing is when the selection starts inside the quoted text and spans outside - in this case the PL/SQL Developer treats the quote in the selection as an opening quote and behaves incorrectly. Another case is when my quoted text contains other quoted text (e.g. when I have a string literal enclosed in a single quotes and it contains double quoted text), then it also behaves incorrectly, treating the internal quote as it was a quoted identifier.
This is probably a result of only parsing the selection content, and not the entire window text, to determine the behavior. I'd suggest to make it behave depending on the whole window text (or block of text in case of the SQL Window or Command Window editor) - which would allow proper identification of what is quoted and what not - and on the selection location - to still allow operating on the quoted text if the selection is starting inside it.

 

[William Robertson]

Actually TOAD has done this for a while and it's one of the few things I like about it. Most of the time I want to lowercase the code (because someone has used uppercase randomly or failed to set his autocompletion preferences and it bugs the hell out of me) but - in the old days - I couldn't just select the block and Ctrl-L without risking turning a 'Y' to a 'y' or something and breaking it.

I appreciate there may be some edge cases though. Perhaps an alternative version you could map to Control-Shift-U/L might be good.

 

[William Robertson]

I've just come across a bug with this. If a comment contains an odd number of single quotes, it loses track of which text to preserve:

select * -- comment with a quotation - that's the issue
from   dual
where  dummy = 'X'

When you select and lowercase, the 'X' gets lowercased too.