COBOL Comment lines are not displaying correctly if there is a character in Column 6

[Robert Plagge]

I noticed it helps when you add a space between whatever is before the leading asterisk, and then add a > after.

* Notepad++ "claims" the next line is not a comment even though it is.
* Therefore, Notepad++ does not mark it as a comment.
1234* I really am a comment.

* Notepad++ thinks the next line is a comment, so it marks accordingly
1234 *> I be a comment.

But I agree, the language definition should be updated to correct the defect.

[PeterJones]

@Robert-Plagge said in COBOL Comment lines are not displaying correctly if there is a character in Column 6:

But I agree, the language definition should be updated to correct the defect.

As I described in May, the problem is in the Scintilla library, which is not under Notepad++-developer’s control. The update process needs to start on the Scintilla end. Until someone starts that process by filing a bug report with Scintilla, nothing will happen.

[Alan Kilborn]

@Will-Lamers

Peter said:

Sorry that I don’t have better news for you.

And the news gets worse, regarding :

you will have to ask the Notepad++ developers (start here) to update to the new version of Scintilla, and wait for that to be done

This type of update is sadly done very infrequently. You may be waiting a long time.

[Xuân-Thơ HOÀNG]

This bug is still not fixed in Scinitlla/Notepad++ :(

I prefer using Notepad++ to read COBOL code in multi-tabs because of its lightweight.

[Alan Kilborn]

@xuân-thơ-hoàng said in COBOL Comment lines are not displaying correctly if there is a character in Column 6:

This bug is still not fixed in Scinitlla/Notepad++

Have you freshened a similar complaint on the Scintilla site?

[mpheath]

@xuân-thơ-hoàng

An open bug report at Scintilla:

#1893 Bug comments Language Cobol columns 7

Note:

Maintenance of particular languages depends on contributions from users of that language. Reporting a problem here may result in a fix but its possible that no fix is forthcoming or it may be some time before a fix.

If you can contribute, then perhaps it can be fixed.

Lexilla now handles lexers so contribute there.

[Paul Baker]

I know this is an old post but maybe this will help someone. I recently started programming in Unisys COBOL and noticed the issue you are referring to. To fix it, you will need to rebuild NPP. It is open source on Git.

LexCOBOL.cxx is the program that needs to be updated. Around line 210 is an if statement that starts if (isCOBOLwordstart(ch) || … You need to add an additional condition that checks if the column number is 7 or greater. The new if statement starts like this:

if (column > 6 && (isCOBOLwordstart(ch) || ....)

This may break some code that works with other compilers like Microfocus COBOL. For me, this change worked perfectly.

[PeterJones]

@Paul-Baker ,

Thanks for sharing that.

As the Scintilla developer said in the original report about this, lexer updates in the Scintilla/Lexilla base code are more likely to happen if a user of that language submits a PR in the Lexilla repo to get it fixed.

You seem to have the skills to provide such a PR. As a service to Notepad++ (and all users of the Scintilla/Lexilla libraries), you might consider making that PR.

In an ideal world, there might be an added bit of logic to include a lexer-specific option that can turn it on or off, which would then avoid “breaking” other people’s use of the COBOL; such things are controlled by scintilla “properties” – you can look for the DefineProperty and similar code in other of the lexers to see how that’s done; LexCOBOL itself doesn’t have any properties yet. Of course, if it’s an option, then after the new Lexilla was released with that LexCOBOL implementation, then after Notepad++ updated to use the newest Lexilla, you’d have to ask Notepad++ to also give access to that property (maybe similarly to the SQL backslash-as-escape in the Language Preferences), or you’d have to use PythonScript or another plugin to edit the property value.

[Paul Baker]

@PeterJones said in COBOL Comment lines are not displaying correctly if there is a character in Column 6:

As the Scintilla developer said in the original report about this , lexer updates in the Scintilla/Lexilla base code are more likely to happen if a user of that language submits a PR in the Lexilla repo to get it fixed.

Hi Peter, Thanks for the PR info. I looked at the site. I’ll read up on the steps on how to create a PR. There is one more small change I made to LexCOBOL.cxx. That was to handle the keyword “Varying”. LexCOBOL looks for a “V” as in PIC 99V99 and does not check if it is followed by an alphabetic character. So basically keywords that starts with a “V” are not highlighted as such.

Thanks again!
-PB

[mpheath]

3 commits at Lexilla fixes some COBOL issues including the OP issue.

1. COBOL: Stop string literal continuing over line end. Issue #229 .
2. COBOL: Recognize keywords that start with ‘V’. Issue #230 .
3. COBOL: Recognize comments after tag or that start with ‘/’. Issue #231 .

1 = fix for https://community.notepad-plus-plus.org/topic/25575/cobol-syntax-and-wrap-strings mentioned by @RiaanPretoriusRIP
2 = fix for V issue with keywords mentioned by @Paul-Baker
3 = fix for the OP issue with comment lines with * and added support for / in column 7 mentioned by @Will-Lamers .

So when Lexilla releases a new version and is committed into Notepad++ repository for Notepad++ release, then hopefully COBOL editing will be more enjoyable. Probably expect in Notepad++ around mid-year 2024.

[Xuân-Thơ HOÀNG]

@mpheath
Thanks!
Checked! These fixes are included in version 8.6.6 (currently in the RC2 phase).