Tags and COBOL

[pwdiener]

Jussi,

After having it turned off for a while when it looked like it might be giving me a problem, I've started using tags again, with COBOL. You may remember that you implemented some customized tag type mappings for COBOL some time ago.

Anyway, I discovered that in the Classes window, when I drill in to project files and expand a particular file, I get a list of the structures and variables in that file. For COBOL, it would also be very useful be able to see the prototypes, which I've re-labeled as paragraphs. Is that option available? Paragraphs shows up in the workspace-level tree, but not at the file level. Any ideas?

[jussij]

For COBOL, it would also be very useful be able to see the prototypes, which I've re-labeled as paragraphs. Is that option available?

This should be easy enough to do, but since it has been over a decade since I did any COBOL, you are going to have to help me out

What I would need is a sample COBOL file that contained all the required COBOL tags and some COBOL line comments describing in which part of the class browser you would expect to see each of the tags to be displayed.

The file could also include things that are currently not tagged, but once again describe where in the class browser tree you would expect to see them.

With this sort of information I would be more than happy to have a go a tweaking the COBOL tagger

Cheers Jussi

[pwdiener]

Jussi,

I thought I had replied to this, but I must not have posted it.

Anyway, I think my issue is in the class browser, not the tagger. When I expand the workspace, I get expandable nodes for Records, File Descriptions, Variables, Sections, and Paragraphs, along with an expandable Project Files folder. These labels are customized. When I expand any of them, I see a list of all the tags of that type in the entire workspace. So far, so good. Since all the tags are shown when I expand, and I get taken to the appropriate spot in the right program when I double-click on one, I take this to mean that the tagger is producing all the right tags for each program.

When I expand the Project files node, I get expandable nodes showing each file in the workspace. Expanding a file name node shows me a list of records and variables defined in that file. This is where I'd like a change.

What I'd like when I expand a project file node is a list of nodes for each tag TYPE (or at least each tag type that is contained in the file). These would be expandable, just like at level 1 (counting the root as 0), only they should show only the tags of that type defined in that file. Maybe it's a consequence of how tag types are mapped for COBOL, but I can't see any of the paragraph names (mapped from prototypes) by file, just the list of all the paragraphs in the whole workspace.

While I'm writing, another enhancement that would be helpful for COBOL is to group all tags of the same name in to an expandable tree node at level 2, with the expansion showing the project file in which the tag is defined. Again, this may be more of a COBOL issue than for other languages, but it's common practice to use the same paragraph names in multiple programs, which makes the list of paragraph nodes quite long and less useful than it might be. For example, instead of:

root
paragraphs
PARA-1
PARA-1
PARA-2

I'd like to see:

root
paragraphs
PARA-1
file1
file2
PARA-2


Bill Diener

[jussij]

When I expand the Project files node, I get expandable nodes showing each file in the workspace. Expanding a file name node shows me a list of records and variables defined in that file. This is where I'd like a change.

But what gets displayed here is dependent on the ctags data that was produced.

For example if you open this workspace: c:\Program Files\Zeus\zOxygen\example\xOxygen.zwi

In the Projects section of this workspace you will notice the xOxygen.cpp is pretty much flat, yet the xOxygen.hpp is displayed like a tree.

The difference in structure is due entirely to the differences in the tags files produced for these two files.

What I'd like when I expand a project file node is a list of nodes for each tag TYPE

For this to happen each file must define one of more tag TYPE entries.

Then when a tag item is added it TYPE has to be stored as one of the attributes (i.e. probably as in the class attribute) of the tag line.

To see how this works if you open the c:\Program Files\Zeus\xTags.ini file and add in the debug option:

Code: Select all

[xTags]
Debug=1

With this option set, the tags file will not be delete after the tags file is rebuilt (i.e. the tags files should be saved to the TEMP folder location).

Maybe it's a consequence of how tag types are mapped for COBOL, but I can't see any of the paragraph names (mapped from prototypes) by file, just the list of all the paragraphs in the whole workspace.

Send me a few of those tags files produced and I will take a look

While I'm writing, another enhancement that would be helpful for COBOL is to group all tags of the same name in to an expandable tree node at level 2, with the expansion showing the project file

Now I don't know whether this is possible or not

But to know what should be possible consider this test1.cs code file:

Code: Select all

namespace Namespace1
{
    enum Enumeration1
    {
        enum1,
        enum2,
        enum3,
        enum4,
        enum5
    }

    public class Class1
    {
        public Variable var1;
        public Variable var2;

        public Class1()
        {
        }

        private void Method1()
        {
        }

        private void Method2()
        {
        }
    }
}

and this test2.cs code file:

Code: Select all

namespace Namespace2
{
    enum Enumeration1
    {
        enum1,
        enum2,
        enum3,
        enum4,
        enum5
    }

    public class Class2
    {
        public Variable var1;
        public Variable var2;

        public Class2()
        {
        }

        private void Method1()
        {
        }

        private void Method2()
        {
        }
    }
}

If you create a new Workspace and add these two file to the workspace, their contents will be displayed in the class browser.

The resulting structure displayed in the Zeus class browser comes entirely from the contents of the tag files produced for these two files.

So theoretically if ctags.exe was changed to produce a similarly structured tags file based on COBOL source code, then naturally a similar tree structure would also be displayed.

So, the answer to the question as to what is possible comes down to whether a similar COBOL tags file can also be produced by ctags.exe

Cheers Jussi

[pwdiener]

Jussi,

I've sent some files via E-Mail. I set up a small workspace, added to programs/projects, and ran the tag rebuild. The tag files and the .ZBD are included.

What I don't understand is the kind:paragraph handling. These show up under prototypes (I didn't bother relabeling them). When I expand prototypes off the top level, I get what I expect - all the paragraphs defined in both source files, listed in alphabetical order. The same applies to variables and structures. When I expand the Project Files node, then EPLOT.cbl, I only see structures and variables defined in that file, not paragraphs.

Is this as expected?

Bill

[jussij]

I only see structures and variables defined in that file, not paragraphs.

Is this as expected?

Only these tags get displayed on this node:

Code: Select all

Tag_Class    
Tag_Function 
Tag_Interface
Tag_Macro    
Tag_Structure
Tag_Variable

To make the items appear on the tree, the tagger has been changed to mark the COBOL paragraphs as a Tag_Function and not a Tag_Prototype as before

Just download this new dll and remember to rebuild you tag database: http://www.zeusedit.com/z300/xtags.zip

Cheers Jussi

[pwdiener]

Jussi,

I'd vote for extending the list of tag types that display, possibly making it configurable, instead of changing the mapping. The change you made would solve the immediate problem (as well as addressing one of my questions from yesterday). However, while reading your response to my functions question, it occurred to me that COBOL does indeed have functions (subroutines) , and they don't have any real relationship to paragraphs (prototypes). In most of the shops I've worked in, a subroutine was the same thing as a program, i.e. 1 program = 1 subroutine, so I didn't see much value in the whole "function" tag idea for COBOL. Here, however, we exploit the COBOL concept of ENTRY points and package multiple related functions together in one compilable program, sorta kinda object like. My plan coming in this morning was to add some patterns to the COBOL module of CTags to get those tags defined. I can also pull out references to functions using CTags, and use that to explore the possibilities for reference displays. Remapping the tag types kind of messes that up but is actually more in keeping with the general concept of functions in other languages.

On the other hand, it's quite possible that the function tags (and potential references in the future) would be more valuable, especially at a project level, than paragraphs. Paragraphs are probably only useful at the program/file level, not the project level.

What I started off trying to do was to get a list of paragraphs displayed for the source file I was working with. As you pointed out, I can get this with the View->Functions List command. The downside of that, however, is that it requires window arrangement for it to hang around. If it was in the class browser it would stay visible, and (I realize now) would be shown with the variables defined in the file as well, also a good thing and one that I frequently use split windows to accomplish. All of this implies, to me, that being able to configure which tags types show up at which level would be a good thing.

I think I'll pass on the tag remapping in favor of exploring the usefulness of real COBOL function tags, and see if I can make the function list work for me. Being able to put it in an always-on-top, semi-transparent window like the find dialog might help, but that's just another change request. Long term, I'd like to see:
1) The ability to configure tag type mapping by language
2) The ability to configure which tag types appear at the project and file level.
3) The ability to create tool and compiler output windows that are always on top and semi-transparent went they don't have the focus.

Bill

[jussij]

Hi Bill,

I'd vote for extending the list of tag types that display, possibly making it configurable, instead of changing the mapping.

I'm not keen to add yet more configuration. Zeus is already way too configurable.

Because the current project file node is displayed flat, I also not too keen to add everything into the node as it just adds noise.

I'll have a look at taking this flatness out of the file node by displaying each item in its own node. If that is possible, then I will just add all the items to the project node.

My plan coming in this morning was to add some patterns to the COBOL module of CTags to get those tags defined.

These are the available tags:

Code: Select all

Tag_Class
Tag_Enum
Tag_Function
Tag_Import
Tag_Interface
Tag_Macro
Tag_Method
Tag_Package
Tag_Prototype
Tag_Structure
Tag_Typedef
Tag_Variable

And this is how the COBOL tagger currently uses some of these items:

Code: Select all

d - data items - maps to Tag_Variable
f - file descriptions - maps to Tag_Interface
g - group items - maps to Tag_Structure
p - paragraphs - maps to Tag_Function
P - program ids - maps to Tag_Package
s - sections - maps to Tag_Macro

Any or all to these can be change.

Code: Select all

Remapping the tag types kind of messes that up  but is actually more in keeping with the general concept of functions in other languages.

It is always good idea to try and stay consistent as possible with the other languages like C#, C/C++ and Java.

Unfortunately one of the major failings of ctags is most of the languages supported are very inconsistent in their mapping definitions

Code: Select all

On the other hand, it's quite possible that the function tags (and potential references in the future) would be more valuable, especially at a project level, than paragraphs.  Paragraphs are probably only useful at the program/file level, not the project level.

There are still a few Tags left over (i.e. Tag_Import, Tag_Enumm, Tag_Prototype, Tag_Typedef)

Code: Select all

All of this implies, to me, that being able to configure which tags types show up at which level would be a good thing.

As I said, I am not at all keen on adding this sort of extra configuration.

IMHO to get the best out of the class browser, the ctag language definition really has to try and map to something like the C#, C/C++ and Java mappings, because the class browser was designed to work with these languages.

Being able to put it in an always-on-top, semi-transparent window like the find dialog might help, but that's just another change request.

Even though it is not semi-transparent, you can already undock the navigator to and always-on-top window. Right click mouse button, undock

Cheers Jussi