Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fold issue in verilog with nested MACRO and nested if #212

Closed
ramamk opened this issue Nov 18, 2023 · 3 comments
Closed

Fold issue in verilog with nested MACRO and nested if #212

ramamk opened this issue Nov 18, 2023 · 3 comments
Labels
invalid This doesn't seem right verilog Caused by the Verilog lexer

Comments

@ramamk
Copy link

ramamk commented Nov 18, 2023

#204 (comment)

Hi Team,
Found one more issue regarding same fold issue :( .

line number 7 fold should end at 12 but it is ending at 16. ifdef at 14 fold is closing with normal end keyword at 15 which should close with endif at 16 only. begin fold line number 11 is closing with endif line 12 which should close only with end at line 15.

image

@nyamatongwe nyamatongwe added the verilog Caused by the Verilog lexer label Nov 18, 2023
@nyamatongwe
Copy link
Member

The behaviour appears to be in accordance with the design.

Folding is based strictly on fold level which increments for fold start points "(", "begin", "`ifdef" and decrements for fold end points ")", "end", "`endif". There is no matching of fold feature types, so keyword "begin" may match pre-processor "`endif".

If you want folding to match feature types then you should describe in detail the mechanics of how that would work, particularly with overlapping ranges such as in this example.

@ramamk
Copy link
Author

ramamk commented Nov 18, 2023

if it encounters a fold end point if it matches to fold start point then it should decrement so that it wont create issue, if it decrements to any fold end point for a fold start point it will be an issue i guess, i know it is complicated to implement just letting know the problem.

@nyamatongwe nyamatongwe added the invalid This doesn't seem right label Nov 18, 2023
@nyamatongwe
Copy link
Member

if it encounters a fold end point if it matches to fold start point then it should decrement so that it wont create issue, if it decrements to any fold end point for a fold start point it will be an issue i guess

If you decrement on only matching ends then you will see an elevated level for the rest of the file so folding a previous start will fold the rest of the file.

i know it is complicated to implement just letting know the problem

It appears to me unworkable which is why folding does not differentiate between fold point types. You could try to implement your desired behaviour in your application, possibly as a script.

Since I cannot see a way to reasonably constrain folds to matching types, I do not consider this a bug. Its just how folding works for Scintilla and Lexilla. So I am marking this issue as 'invalid' and will close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right verilog Caused by the Verilog lexer
Projects
None yet
Development

No branches or pull requests

2 participants