Is there some way to tell the formatter to skip part of the code? For example let's say I have this code:
CREATE OR REPLACE PACKAGE BODY aa IS
PROCEDURE aa
IS
BEGIN
DBMS_OUTPUT.put_line ('aa');
END aa;
$if false $then
bad code!!!
$end
end;
Toad and the formatter will freak out when it sees the bad code and it will do weird things if you try to use autoformat for this document. So I was wondering if there is for example a comment hint you can use to tell toad to at least ignore that part of the code when using the formatter. e.g.
-- Close your eyes Toad!
bad code!!!
-- You can open your eyes Toad!
This could be useful for code that isn't completed or if you want to use embeded templates with a library like GitHub - osalvador/tePLSQL: PL/SQL Template engine . Also sometimes there can be disagreements between the formatter and the developer so in those cases the developer might want to overrule Toad for a specific part of the code.
I'm also interested if the same can be done with Toad syntax checking so that errors are ignored (e.g. new features not yet implemented in Toad or code that is not compiled as in above example).
Actually, any code that is commented out within the Toad Editor will not be parsed by the Formatter, and the code inside the commented block remains as is. And, with Toad's shortcut keys to mass-comment blocks of code (Ctl-B) or mass-uncomment (Shift-Ctl-B) it's pretty easy to control the formatting of different code sections.
This is also true of the Toad parser (Ctl-F9)... commented portions are ignored.
Hope this helps.
Sure, yes it would be weird if Toad didn't ignore comments and in some cases that is a solution. However some of the examples I gave could benefit from a "bypass hint" for the formatter and maybe syntax checker.
Let me describe a bit further, if you for the most part is happy with the automatic formatting and want to keep using it but in some edge cases you want to do some manual formatting. Then being able to exclude part of the code would be helpful. Also when new features get released Toad is not able to format them so you might want to keep using this new feature but then you will not be able to use autoformat until Toad implements the new syntax.
Not sure if the library I mentioned supports using comments instead of conditional compiling but one advantage of the conditional compile approach is that you still get color coding instead as opposed to if you where to comment out all the code.
But I assume from your reply that I didn't just miss this feature as it does not exist. So maybe it's something to consider in the future.
Our parser will parse conditional compilation directives as follows:
-
In a first pass , it will parse $IF/$ELSIF/$ELSE/$END constructs assuming that they are "structured" and that a syntax tree can be built containing both $THEN and $ELSE branches. QP5 tries to create parse info by treating these branches (perhaps declarations or statements) as nodes, just like regular statements, so that a parse info tree can be built reflecting all IF/ELSE branches.
Sometimes this is not possible because the $-directives can include/exclude any portion of text.
The cases where "structured code" is recognized are described below.
-
If the above parse yields errors, probably due to the presence of conditional compilation directives and $IF/$ELSE clauses which are not at all symmetrical, then a new second pass parse (fallback parse) will be attempted with the assumption that all $IF predicates have the value TRUE , and all $ELSIF/$ELSE branches are FALSE. The $IF...$THEN span (the actual condition, that is) and all $ELSIF...$END or $ELSE...$END spans will then be turned into comments. This means that a syntax check will only check the code in the $IF branch, between the $THEN and the next $ish token.
So you could obtain what you want by turning $if false into $if true $then $else.
Here's a formatted output I just made:
CREATE OR REPLACE PACKAGE BODY aa
IS
PROCEDURE aa
IS
BEGIN
DBMS_OUTPUT.put_line ('aa');
END aa;
$if true $then
$else
To be, or not to be, that is the question:
Whether tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles
$end
PROCEDURE aa
IS
BEGIN
DBMS_OUTPUT.put_line ('aa');
END aa;
END;
There's one caveat, though: inside the $else branch there should not be any unbalanced quotes, I mean every quote should be "balanced" by another one to form valid literals or identifiers.
It is, however, a bit surrealistic that $if false is interpreted as true. Therefore I made a change to have the "default" interpretation of $IF-branch is true overriden by $IF-branch is false in that particular case (only).
To show up asap in some next beta.
Then your original example would work fine.
And Gary thanks for chiming in, leading a new enhancement (be it a little one) 
Cool! That means you can do something like this when you want to use new functions early:
CREATE OR REPLACE PACKAGE BODY aa_test
IS
PROCEDURE aa
IS
gff CLOB;
BEGIN
DBMS_OUTPUT.put_line ('aa');
$if false $then
$else
SELECT json_mergepatch('{}', '{}' RETURNING CLOB) INTO gff FROM dual;
$end
END aa;
END;
And also it can be used for custom formatting if needed
PROCEDURE bb
IS
BEGIN
NULL;
$if false $then
$else
Select
1
inTO nn
From
DUAL;
$end
END bb;
However to actually make the above work you also need to include something like this somewhere in your code:
$if true $then
$else
allow skipping formatting inside noncompile clause
$end
I believe this means Toad formatting fails for in that specific step and gives up on formatting all code placed inside these blocks. So I can have custom formatting in these blocks while still being able to use autoformat for the normal code placed outside the conditional compile blocks. A bit of a hack doing it this way but it works and that's more than I expected so thanks
If it became a common request I guess it would be better to implement something more like my initial example with "comment hints" but for now this will probably be enough.
As it stands today you could do snippets #1 and #2 indeed. But it has a smell of hacking all over it.
Disabling formatting for selected chunks of code would better be done using comment hints, specifying that the next statement is to be left alone, or two hints defining a range of statements.
Andreas if I implement my mod (making "if false" really false) then that'll probably break your game. I'm willing to bundle that together with the no-format comment hints, for your convenience. Then, whenever the latter gets done (no promise!) then both will be done at once.
How does that sound?
Sounds good to me, most of the time I'm happy with Toads formatting but occasionally there are times where I would like to make a small manual adjustment. Thanks for the help!