Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

source-format auto does not work #398

Open
GitMensch opened this issue Jan 26, 2025 · 3 comments
Open

source-format auto does not work #398

GitMensch opened this issue Jan 26, 2025 · 3 comments

Comments

@GitMensch
Copy link
Contributor

GitMensch commented Jan 26, 2025

Opening the following code the syntax highlighting looks strange and the outline is broken if source-format "auto" is enabled:

*> --- Server ---
*> This is the entrypoint for starting a CobolCraft server.
IDENTIFICATION DIVISION.
PROGRAM-ID. Server.

DATA DIVISION.
WORKING-STORAGE SECTION.
    *> File names
    01 FILE-REGISTRIES              PIC X(255)              VALUE "data/generated/reports/registries.json".
    01 FILE-BLOCKS                  PIC X(255)              VALUE "data/generated/reports/blocks.json".
    01 FILE-PACKETS                 PIC X(255)              VALUE "data/generated/reports/packets.json".
    01 FILE-DATAPACK-ROOT           PIC X(255)              VALUE "data/generated/data/".

manually switching to "free" leads to everything working as expected

@nberth
Copy link
Collaborator

nberth commented Jan 27, 2025

I remember mimicking cobc's behavior on that. What does cobc -fformat=auto do with this file?

(EDIT: with a 3.3 from last December, I get a server.cob:2: error: invalid indicator 's' at column 7.)

Not saying that shouldn't be fixed; but maybe both tools need a fix. A possible fix probably being, being (more) sensitive to *>.

@GitMensch
Copy link
Contributor Author

Yes, we should possibly improve both ppopen_get_file() and the LSP.

The "gotcha" is: space (or any valid marker, for example "-") in column 7 - assumes fixed form (like in this case, then aborts at line 2).
If I change that to an "a", then both cobc and the LSP see it as free-form.

We could increase the lookahead (currently only 20 bytes, but in this case we'd likely have to not consider a single "last_pos_7", but multiple ones.

As an alternative, we could also check for a directive >> or comment *>` in col 1-6 (after only space/tab) and opt to free-form; I'd think there are more positives than false-positives covered that way and the change would be easy in pplex and the LSP as well.

What do you think?

@nberth
Copy link
Collaborator

nberth commented Jan 27, 2025

As an alternative, we could also check for a directive >> or comment *> in col 1-6 (after only space/tab) and opt to free-form; I'd think there are more positives than false-positives covered that way and the change would be easy in pplex and the LSP as well.

Yes that's a directions that makes sense, what I meant by "being more sensitive to *>" (and >> may be a good idea indeed), restricted to columns 1-6.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants