I didn't see a request for code folding for COBOL and since I don't see any folding going on in my .COB files, I'll assume it hasn't been implemented.

A word about matching pairs of begin/end fold keywords: Commands like 'IF' can be terminated with the matching end keyword (i.e. 'END-IF') or by a period ('.'). Since there is no line continuation character, a command like 'DISPLAY' which has no matching end keyword can span multiple lines and, if possible, should be folded when it does.

Local variables are declared in the 'WORKING-STORAGE SECTION' and are defined using 'level numbers' (e.g. 01, 02, etc.). Lines that contain these level numbers should be folded to the next line containing a level number of the same value (unless the next level number is greater than the current level number).

Since COBOL is column sensitive, any line that contains either of the words 'DIVISION' or 'SECTION', can be folded to the next line that begins in column 8 and contains either of the words 'DIVISION' or 'SECTION' (respectively). Any line that begins in column 8 and does NOT contain either of the words 'DIVISION' or 'SECTION' can be folded to the next line that begins in column 8 and does NOT contain either of the words 'DIVISION' or 'SECTION'.

Zeus rules! We've just finished our evaluation and bought licenses for the entire office. COBOL code folding would be very well received here.

I downloaded the xFolder dll and checked it out on our COBOL files:

A few observations/comments:

Lines that begin in column 8 and have the word DIVISION are wrapping to the next line that begins in column 8 and has the word SECTION. This is not correct. A DIVISION contains SECTIONs so the DIVISION line should fold to the next DIVISION line. A SECTION line should fold to the next SECTION line with that DIVISION or to the next DIVISION line (if it is the last SECTION in that DIVISION).

In the WORKING-STORAGE SECTION, the level numbers are heirarchial can be folded based on level number. A level 01 variable can encapsulate level 02 variables which in turn can encapsulate level 03 variables, etc., etc. Following this heirarchy, level 01 can fold to the next level 01. A level 02 can fold to the next level 02 within that level 01. A level 03 can fold to the next level 03 within that level 02. Another way to say it is that a level number can fold to the next level number less than or equal to itself.

Lastly, the folding based on indent levels does not work well so I would suggest throwing that away and just use the following explicit begin and end terms:

Thanks for taking suggestions on this and for your efforts in making Zeus even more useful for our staff.

The current folder only sees begin/end fold points and has no way of associating additional information with these points.

So for the mean time what do you think would be the be the best partial fix to this problem:

1. Leave it as it is
2. Fold on SECTIONs but not DIVISIONs
3. Fold on DIVISIONs but not SECTIONs
4. Remove the DIVISIONs, SECTIONs folding
5. Change the DIVISIONs, SECTIONs folding to work like the IF and use indent level

Please bear in mind that the level number heirarchy is not required to follow strict increments (i.e. 01 then 02 then 03). The heirarchy is only required to begin at level 01 and any 'child' levels must have a level number that is greater than the 'parent' level.

The code folding for COBOL works better but there are still some issues. If you want to pursue it further, I'm happy to post with issues I find.

Any feedback would be great. Making changes to the xFolder.dll is not very difficult, but knowing which changes to make is only possible with feedback from people like yourself

Fell free to post as many comments, problems or suggestions you might have to this thread.

Currently the folding based on indentation does not work well. It gives unexpected results (e.g. verbs fold to the end of the file).

If you could post a minimal code sample (ie 4 or 5 lines of code) that illustrates this or any other error, that would be great.

The folder is only based on a very small subset of COBOL code and more likely than not unusual coding construct are not be represented in this subset of COBOL code

For this reason feel free to post as many code samples as you can think of as these will get added to this subset for testing. If you use the code button found on the reply page, it is possible to maintain the code structure in the reply.

I've sent you by private email a program that illustrates the issues and
requests below. The program is copyrighted by my employer, so I can't
just post it publicly.

Issues:
1) Line 1315 shows a fold for no apparent reason. This is a minor issue.
Line 1329 is similar, and there are many others. Line 1337 is an example
of a reasonable fold in similar circumstances as line 1329.

2) Comments seem to confuse the folder. For example, line 1432 is fine,
while just above it line 1428 does not show a fold. See also the fold at
line 1593 that includes the code at 1598 instead of making it a separate
fold.

3) Multiple lines seems to confuse the folder. For example, line 1522
shows a fold point, but only 1 line instead of the many (down to 1550)
that I would expect based on indentation or level numbers. Line 2650 is
another example - there I would expect a fold down to 2832.

4) In the procedure division, each time a verb is used that has a
corresponding END- form (e.g. PERFORM/END-PERFORM, ACCEPT/END-ACCEPT, etc.), the fold extends to the end of the program if the END- terminator is not present. For an example, see line 4275. Use of the END- terminator is not required, and in older programs is uncommon. Even newer programs tend not to use them when not needed, with the possible exception of END-IF. In all of these cases, a period will serve as a terminator of all previously unterminated statements (e.g. line 5177 thru 5184.
Immediately below line 4275 are several more examples. The folder appears to work properly when the END- terminator is present, for example line 4290 with IF/ELSE/END-IF is fine. Line 4344, however, without an END-IF, folds the ELSE clause to the end of the program.

5) Again, folds are shown for no apparent reason. e.g. line 4323.

Requests
1) The ability to turn off cetain types of folding. For instance, I think
the statement folding in the PROCEDURE DIVISION will be very difficult to
get right without a syntax analysis. While this doesn't destroy the
usefulness of folding, it makes it questionable. It would be very useful
to have a working folder that is syntax-directed, but it seems pretty
costly too.

2) The ability to fold contiguous comments. As an example see the large
comment block at the beginning. Lines 4-1151 could be folded.

3) The ability to fold paragraphs, particularly in the PROCEDURE DIVISION. If I had to choose, I'd say paragraphs instead of SECTIONs or DIVISIONs would be the better choice. Outside of the PROCEDURE DIVISION, paragraphs and sections have fixed names, but inside the paragraphs or sections can have any name. A paragraph name is a single word beginning in Area A (cols 8-11) ending with a period, while a section is a word beginning in Area A followed by the word SECTION and a period. Pardon me if I'm telling you things you already know.

Of these, request #3 would be the most useful to me.

A project that I've set myself will involve building a syntax-directed parser for COBOL. I don't have any idea when I'm going to get there, but when I do, it would be nice to leverage that to address folding issue #4. Any information you can share regarding interfaces you might need would be helpful in planning this.