Fold Issue in Verilog mode

RAMA KRISHNA

Attached image i am seeing anomaly in verilog mode in notepad++. begin-end blocks in verilog are same as {…} in C. Adding a comment in 3rd line in the shown style is causing issue in fold map, when i removed the comment it resolved. May i know is it known issue ?

Screenshot 2023-09-08 164105.png

rdipardo

Syntax highlighting and folding are not functions of the main application; they’re provided by this third-party library: https://www.scintilla.org/Lexilla.html

If you send the issue to the library’s maintainer, and a fix is committed, then a future version of Notepad++ will benefit, whenever its third-party components get updated.

In the meantime, try rewriting the comment text without using array literal syntax (i.e. remove the curly braces {...{...}}) just to see if that makes a difference.

RAMA KRISHNA

@rdipardo yeah 13-21 lines are without the comment , it is looking good. as mentioned by u i have reported the issue in github.

https://github.com/ScintillaOrg/lexilla/issues/204

RAMA KRISHNA

@RAMA-KRISHNA there is a reply in that thread kindly have a look so that we can update in next version of notepad++.
for now workaround is to insert the space between

//{.....}

so that it becomes

// {....}

and the fold disappeared.

RAMA KRISHNA

observed one more issue regarding the folds and pasted same in the above scintilla thread . ifdef is closing with end and begin is closing with endif.

RAMA KRISHNA

@RAMA-KRISHNA
Hi Team,
any help on the below issue.
`ifdef condition is closing with end keyword and begin is closing with `endif keyword.

PeterJones

@RAMA-KRISHNA said in Fold Issue in Verilog mode:

any help on the below issue.

As @rdipardo told you a month ago, if you want changes in the way that Notepad++ handles folding of Verilog code, you will have to ~~create an issue with the third-party library “Lexilla”~~, get your issue accepted, wait for them to implement a fix (assuming it was accepted), wait for them to publish the fix, and wait for Notepad++ to incorporate the updated Lexilla library into a future version of Notepad++. If ~~you haven’t even done step1~~ they haven’t accepted your issue, you will never see any differences.

update: realized you had linked to an issue already; sorry. you will still have to wait for them to fix it before it will ever work right in Notepad++; and re-reading, because it’s weird imbalanced nesting between the directives and the normal syntax, it might require a separate issue at Lexilla for the mixed `ifdef vs if/begin/else begin/end syntaxes, because I don’t know if a fix for the first problem would affect the second or not. Either way, the Lexilla folks are the folks you have to deal with first.

update 2: after reading through the thread over there, it appears that they are now ignoring your additional comments in that issue. That’s unfortunate for you. However, it doesn’t change the fact that neither we in the Notepad++ Community nor the Notepad++ developers can force them to fix the problems. I would be tempted to suggest that you restructure the code and repeat the one line, which should allow it to fold correctly (or, if not “correctly”, at least more reasonably):

always @*
    if(sig1
        `ifdef MACRO1
        || sig2
        `endif
        ) begin
            `ifdef MACRO2
                if(sig3) begin
                    sig4 = 1'b1;
                end
                else begin
                    sig4 = 1'b0;
                end
            `else
                sig4 = 1'b0;
            `endif
        end

sorry that we cannot fix the folding for you.

mkupper

@RAMA-KRISHNA

I agree with what @PeterJones wrote but am also thinking that if your code confuses a parser then it likely also confuses humans reading and maintaining the code. It’s only a 17 line snippet but it sure uses a lot of mental bandwidth checking that the resulting code seems syntactically correct regardless on if MACRO1 and/or MACRO2 are defined. By the time I was done I realized I did not know if the code would do what the developer hopes or thinks it does.

I did not think the parsers in Notepad++ have a pre-processor pass that would first deal with things such as `ifdef … `endif directives before then processing the if(..) begin ... end of a text file. If it’s a one-pass parser then it’s unlikely they will ever be able to fully parse the example provided in this snippet.

rdipardo

@PeterJones said in Fold Issue in Verilog mode:

after reading through the thread over there, it appears that they are now ignoring your additional comments in that issue.

Lexilla’s maintainer is more familiar with the old-school mailing list approach to open source development. If an issue doesn’t have a clearly stated work item, ideally with a git patch ready for review, it isn’t likely to get attention. You especially want to avoid the faux pas of attaching a picture without a sample of the text that produces the bug.

My advice to @RAMA-KRISHNA is to spend some time analysing the problem before attempting to report it. Issues with any of Lexilla’s lexers will be reproducible in other editors that use it, for example SciTE.

Make sure to download a “full” Windows version with all the *.properties configurations included. Extract the wscite archive, open SciTEGlobal.properties, find the imports.exclude property, and delete verilog from the list.

In the same folder as the source code, create a file named SciTE.properties and paste the following into it:

fold.flags=64
fold.symbols=2
line.margin.width=12
view.indentation.guides=1

; turn off the option to "grey out" code that follows an undefined preprocessor symbol;
; not needed for Notepad++ as it does not even know this option exists
lexer.verilog.track.preprocessor=0

When SciTE opens the source code, make sure that View > Line Numbers is selected. The margin with display each line’s “fold level”, which is a positive offset from SC_FOLDLEVELBASE, an interface constant defined as 1024 (the margin numbers are in hexadecimal). The previous fold level, in the left column, is the fold level at the start of the line; the next fold level, in the right column, is the value at the end of the line:

A balanced fold structure must begin and end at the base level; if you see a level > 0x400 in the last line, there’s definitely a problem. No offset should ever be negative (i.e. fold level <= 0x3FF), so values in that range are also good indicators of an error condition (000 is valid as some lexers use that for the base level instead of the magic SC_FOLDLEVELBASE constant).

Assuming I copied the code correctly, I can’t see anything to suggest the fold levels are wrong. The structure may not be what you expected, but it’s a well-formed structure nonetheless.

rdipardo

I said in Fold Issue in Verilog mode:

The previous fold level, in the right column . . .

It’s the other way around, sorry. This table will hopefully make it a bit clearer.

previous fold level	next fold level	Δ	text	meaning
0x400	0x400	0	`always@*`	no change
0x400	0x401	+1	`if(sig1`	start of outermost fold region
…	…	…	…	…
0x401	0x402	+2	\`ifdef MACRO2	start of nested fold region
…	…	…	…	…
0x402	0x401	+1	\`endif	close of nested fold region
0x401	0x400	0	`end`	close of outermost fold region
…	…	…	…	…
0x400	0x000	0	`EOF`	end of docment

PeterJones

@mkupper said,

if your code confuses a parser then it likely also confuses humans reading and maintaining the code.

That was a good way of putting it. I couldn’t think of a good phrasing, so I just suggested my workaround (which was conceptually easier for me to understand than the original).

@rdipardo said in Fold Issue in Verilog mode:

Assuming I copied the code correctly, I can’t see anything to suggest the fold levels are wrong. The structure may not be what you expected, but it’s a well-formed structure nonetheless.

Your test screenshot was done on my suggested edit to the structure, rather than the original structure from the screenshot. This discrepancy convinced me to try the SciTE experiment myself, to see what the results would be. Here’s a SciTE screenshot showing both the original and my edited version:

The original also creates a balanced set of folding, so from the “balance” perspective, it “works”.

In general:

Without having multiple trackers for open/close pairs, I don’t see how Scintilla or anything else could be expected to properly track overlapping rather than nested fold-groups. (nested: OPEN1 ... OPEN2 ... CLOSE2 ... CLOSE1 ; overlapping: OPEN1 ... OPEN2 ... CLOSE1 ... CLOSE2) So if they wanted to allow 2 overlapped folds, they would have to have 2 trackers; 3 overlapped folds would need 3 trackers; N overlaps would need N trackers. Since someone could always come along with a “but I wanted to overlap N+1, not just N folds”, they would have to make it handle an arbitrary amount of overlapping, not just a fixed amount of overlapping, and that would be even more complex. I highly doubt that anything would ever come of such a request, even if it met all of the requirements that @rdipardo mentioned for a Lexilla request.

mkupper

@PeterJones said in Fold Issue in Verilog mode:

Without having multiple trackers for open/close pairs, I don’t see how Scintilla or anything else could be expected to properly track overlapping rather than nested fold-groups. (nested: OPEN1 … OPEN2 … CLOSE2 … CLOSE1 ; overlapping: OPEN1 … OPEN2 … CLOSE1 … CLOSE2) So if they wanted to allow 2 overlapped folds, they would have to have 2 trackers; 3 overlapped folds would need 3 trackers; N overlaps would need N trackers. Since someone could always come along with a “but I wanted to overlap N+1, not just N folds”, they would have to make it handle an arbitrary amount of overlapping, not just a fixed amount of overlapping, and that would be even more complex.

The number of trackers seems bounded by the number of overlapped languages supported by the file. In this case it’s two languages, the pre-processor and Verilog. Overlapping pairs within one language seems to be syntactic nonsense.

I had a couple more thoughts after my previous post on this thread. The first is that pre-processors evaluate expressions and have flow control. The expressions may well be dependent on information in include files. Both the expressions and dealing with include files is far beyond the scope of what I would expect of a code highlighter or folder within Notepad++. The second thought, related to the first, is that preprocessor directives are sometimes used to exclude invalid code. For example, within C or C++ I sometimes have done:

#if 0
    Something that is not syntactically valid C or C++ code.
#endif

Maybe I’m copy/pasting in code from somewhere else to use as an example or prototype. If it’s a fragment that includes unbalanced pairs I know it won’t bother a compiler that fully evaluates the preprocessor language flow. However, I should keep in mind that it likely will bother something like a Notepad++ highlighter or folder and so should make sure it’s fully commented out or at least is well formed enough that a highlighter and folder are happy.