Zeus IDE

1) Line 1315 shows a fold for no apparent reason. This is a minor issue.
Line 1329 is similar, and there are many others.

If you add a line break after line 1315 the fold will go away:

So this: becomes this:

2) Comments seem to confuse the folder.
3) Multiple lines seems to confuse the folder.

I think one major problem with the current folder is that it is not ignoring the text in the first 7 columns. I think this logic is added a lot of these ghost folds would go away

Is there any significance to the 5 digit numbers at the start of these lines. Can they be ignored

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.

The problem here is there are many PERFORM with out a matching END-PERFORM.

For example this code will not fold correctly: but this code will:

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.

Unfortunately due to limitations of the Zeus folder all folds must have matching begin/end fold points otherwise it will get confused

The best thing to do would be to remove things like PERFORM as a fold points.

So of these current fold points: Are there any other that should possibly be removed

In all of these cases, a period will serve as a terminator of all
previously unterminated statements

Unfortunately the period really can't be used as a fold point because it depends heavily on context.

For example in the code below the period would be an end of fold point: But for this code the period would not an end of fold point: To determine this sort of context requires compiler type syntax information and the folder just doesn't have this sort of knowledge.

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.

I'm definitely open to any suggestions

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

I'll have to think about this, but my first impression is this will be difficult.

The reason is, for this type of pattern to be folded the file would need to be parsed from top to bottom. But to do top to bottom parsing on every key press would make the program far too slow.

3) The ability to fold paragraphs, particularly in the PROCEDURE DIVISION.

This might be possible. I'll have a closer look at this.

Any information you can share regarding interfaces you might need would be helpful in planning this.

The major issue for Zeus in terms of folding is the speed. Because it only takes on one character to be added or remove to change the fold state of the line, the fold checking must be done on ever key press and as such it has to be fast.

Zeus achieves this by only ever checking the current line for folds.

But this approach will only work for languages that have clearly defined matching begin/end fold points.

Cheers Jussi

Is there any significance to the 5 digit numbers at the start of these lines. Can they be ignored ?

Yes. The standard layout of a COBOL program has an optional sequence number in columns 1-6, a comment/continuation indicator is column 8, and text from 8 thru 72, with 73-80 containing some identification string. Some compilers bend these rules by permitting either longer lines and/or a "free format" version where there are no sequence numbers, but I've outlined the standard format.

Are there any other that should possibly be removed ?

I'd probably get rid of all of them, since that list is the list of verbs with the optional END- scope terminators. The key word is optional. I agree that telling the difference between a period as a end fold point and as a simple period is rather complex, especially since the same period could be the end of several fold points. Since it's so hard to do right, I'd probably just not try, although this is what I was thinking of when I asked about making certain types of folding optional.

Another possibility is to drop just the ones that rarely use a scope terminator, although that list might be subjective. In my case, I would use END-IF & END-EVALUATE all the time, END-READ, END-WRITE, END-REWRITE, END-START, END-RETURN, and END-DELETE most of the time, END-PERFORM only with an inline PERFORM (one of 4 variations), and END-ADD, END-COMPUTE, END-DIVIDE, END-SUBTRACT, END-MULTIPLY, END-CALL quite rarely.

While the list might be different for other programmers, I'd guess that even in the most well-written app, the scope terminators are used only if there is a good reason, not all the time. I'm not sure what this says about what should be done. Ideally, each one would be optional I guess. If the program was well-written, having folding for IF statements and EVALUATE statements is very useful, but if the END-IFs aren't present, the folding is just annoying.

Another fold point that would be useful is WHEN clauses in the EVALUATE statement (corresponds to the case statement). The end point of this fold is either the next WHEN or END-EVALUATE (assuming there is one).