[Lazarus] Collapsible try...finally...except...end blocks idea

el_es el.es.cr at gmail.com
Wed Jul 18 10:12:21 CEST 2018


On 17/07/18 10:43, Martin Frb via Lazarus wrote:
> On 17/07/2018 10:34, el_es via Lazarus wrote:
>> 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).
>>
> I dont think the code editor will change the indent, for that there
> are code formatters. (jedi)

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

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

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.

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

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

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



More information about the Lazarus mailing list