Skip to content
New issue

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

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

Already on GitHub? Sign in 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.

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

No branches or pull requests

2 participants