Skip to content

Should comments be treated as whitespaces? #54

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

Open
igordejanovic opened this issue Feb 13, 2018 · 7 comments
Open

Should comments be treated as whitespaces? #54

igordejanovic opened this issue Feb 13, 2018 · 7 comments
Labels

Comments

@igordejanovic
Copy link
Member

textX/Arpeggio treat comments in a special way. More specifically, noskipws rule modifier will disable whitespace skipping but will leave comments skipping in place which may lead to some gotchas.

If comments should be treated like whitespaces than noskipws would mean don't skip whitespaces and comments. This would be a backward incompatible change. This would also mean that comments should be handled manually in noskipws rules.

This issue is created as a poll to gather feedback from the community. Please vote with emoji thumbs up/down.

@igordejanovic igordejanovic changed the title Should comments be treated as whitespaces Should comments be treated as whitespaces? Feb 13, 2018
@Aluriak
Copy link
Contributor

Aluriak commented Mar 22, 2018

Whitespaces and comments are different things. Why handling them as the same object ? Is it not simpler (user-side) to have options for both ? noskipws would retain his actual meaning, and commentaswhitespace would allow for both behaviors.

Note that in most languages, comments are handled per rule. This is an example in C, where two comments have different side-effects:

int main() {
    int a/*break the identifier rule*/b = /*no side effect*/ 2;
    printf("%i", ab);
}

I do not know if it is possible at all, but letting user provides a set of rule names indicating which rules may (not) be broken by a comment seems to fix a lot of problems too.
Maybe this rule may be simplified to: any raw data/regex rule can't be broken by comments.

@igordejanovic
Copy link
Member Author

igordejanovic commented Mar 22, 2018

Note that in most languages, comments are handled per rule.

Can you elaborate more on this please. Not sure that I follow.

If I understand the example with C you are implying that comment between a and b breaks the identifier. That happens also if you put whitespace at that position. So, is there any difference in handling. I agree that comments and whitespaces are different in a sense that comments provide some useful information to the reader (and Arpeggio does collect comments) but is their handling any different? If you replace all comments in source code with whitespaces, would it make any difference?

Maybe this rule may be simplified to: any raw data/regex rule can't be broken by comments.

This is the default behaviour. Regex can't be broken by a comment or whitespace. It is in a sense atomic.

@dkrikun
Copy link
Contributor

dkrikun commented Nov 14, 2018

Please do not treat comments as whitespace:

  1. Sometimes whitespace is significant (e.g. python) but comments aren't
  2. Sometimes comments are significant and need be preserved -- aka docstrings in python, but whitespace isn't

@fzipi
Copy link

fzipi commented Jun 19, 2019

@igordejanovic In fact, one of the things that I miss the most is not having access to the comments, for example, when transpiling things. We just lose the comments.

I would like to have a flag to conserve them.

@igordejanovic
Copy link
Member Author

@fzipi Totally agree. Actually, that is something I had been planning for quite some time. It requires some work in the Arpeggio. I thought that the issue for this is already registered in the tracker but it seems that I was wrong. Please feel free to register the feature request.

@fzipi
Copy link

fzipi commented Jun 19, 2019

@igordejanovic Super, will do! Thanks for your support :)

@fzipi
Copy link

fzipi commented Jun 19, 2019

Created textX/Arpeggio#56.

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

No branches or pull requests

4 participants