Hi,

this idea may need further refining, but it may be easier to handle in Lazarus source editor, than in the compiler, where it was originally posted.

In short, to have the nested try...finally/except...end; blocks display in a single tier flatter manner, like

try
  try
    code block 1;
  finally
    code block 2;
  end;
except
  code block 3;
end;

display in Lazarus like

try
  code block 1;
finally
  code block 2;
except
  code block 3;
end;

with similar handling like the collapsible code blocks (e.g. a [+] or [-] on the gutter next to all the try's, depending on what the default setting is, to display or not to display nested try blocks) and handling of more 'sophisticated' nests like try...except...finally...except...end;

(that means, in raw source code, this still will display like nested try blocks, not flat, and as such be fed into the compiler).

This being handled in Lazarus would mean, that it would work in ANY compiler mode selected (regardless if it's Delphi or not) and the benefits of flatter display of the code blocks would really show (like making it harder to enter code blocks where they normally don't go in such constructs, and helping to catch errors made like that - e.g. if someone consciously needed to put code in places it does not normally go, collapsing the construct would not work).

It was met with resistance in the FPC mailing lists, and then it was dropped there;
I can't say I don't agree with /some/ of their arguments actually.

Hope this would actually make more sense here :) as a coding tool.

Kind Regards

el es

I dont think the code editor will change the indent, for that there are code formatters. (jedi)

Display a different indent from what is actually in the text brings up new issues, such as what happens if you edit spaces in the virtual indent. Where to they go in the real text?
Despite this, I am not convinced it is should be included. But if someone wants to do a package that install such a feature.....

Anyway the compiler already supports the indent you want (the compiler does not care about indent), so you can actually write it like this.

try try
   code block 1;
finally
   code block 2;
end;
except
   code block 3;
end;

All you have to deal with are:
- the double "try".
- the extra "end"

Several solutions

** 1)
Use fpc macro support (look up exact syntax, I am writing this from (distant) memory) (this of course will trouble the editors folding detecting and outlining-markup)

{$macro on}
{$define try2:= try try}
{$define thenExcept := end; except}
try2
   code block 1;
finally
   code block 2;
thenExcept
   code block 3;
end;

The macro solution also makes it visually clear that you did not forget an opening try. After all it could be that there is an except block that covers a wider amount of code...

** 2)
Or (and that could be added to the editor):
Have a /hide option for {%region} (same as the current /fold). With /hide the region would be default disappear.

try
{%region /hide}try{%endregion}
   code block 1;
finally
   code block 2;
{%region /hide}end;{%endregion}
except
   code block 3;
end;

Code formatters would always work on the 'unfolded'/'raw' code anyway. This feature would only be about how to display it.

Display a different indent from what is actually in the text brings up new issues, such as what happens if you edit spaces in the virtual indent. Where to they go in the real text?

If we treat the left-most column of the code block in question as base line, then I think adding spaces to other lines in the block would not be that much of a problem.

Despite this, I am not convinced it is should be included. But if someone wants to do a package that install such a feature.....

This is merely an idea submission in hope that someone likes it enough to make it, and take all the credit for it (I do not mind).

And the possibility that someone might insert code between end; and except; Or anywhere in between the 'try' keywords.
Now this is not a big problem in this case, because there may be valid usage of that.

If the code display formatter finds this one out, it will refuse to fold and reindent the block, that should then be enough of an indication for the programmer, that this has happened.

I'd name that last macro 'endExcept' maybe, but...

... I guess I like the second ({%region hide}) way better than the macros, because with macros you're inventing the whole new set of keywords for this; The only problem with this region directive is that it would mess up the formatting for non-Lazarus editors, and also, how will it behave after the JCF is used?

Thanks for your reply :)

el_es