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

Should we build the grammars from a different format than .tmLanguage? #25

Open
sgtoj opened this issue Oct 10, 2016 · 11 comments
Open
Projects
Milestone

Comments

@sgtoj
Copy link

sgtoj commented Oct 10, 2016

Is it possible to switch YAML for editing language syntax? This idea came after visiting Microsoft/TypeScript-TmLanguage.

Short List of Reasons
  • Easier to read and edit
  • Comments would be allowed
  • Consistent formatting via a Build script
@daviwil
Copy link
Contributor

daviwil commented Oct 10, 2016

Damn, I didn't realize they had done this, that's awesome! Thanks for bringing it to our attention. I'm sure @vors and others would certainly be interested in doing something similar.

@gravejester
Copy link
Collaborator

This is nice, I'll take a look into this, if it's ok @daviwil :)

@daviwil
Copy link
Contributor

daviwil commented Oct 11, 2016

Go for it!

@gravejester
Copy link
Collaborator

For your information, v2 of the EditorSyntax package will generate grammar files in the following formats:

  • plist (.tmLanguage)
  • JSON
  • CSON
  • YAML

Editing the grammars are done using the YAML-version, and the build task will generate the other formats.

@gravejester gravejester self-assigned this Sep 4, 2017
@gravejester gravejester added this to the v2 milestone Sep 4, 2017
@gravejester gravejester added this to Enhancement - Open in v2 Sep 4, 2017
@omniomi
Copy link
Collaborator

omniomi commented May 21, 2018

I am not married to .tmLanguage as the base from which grammars are built but I am opposed to yaml. Would prefer to use json if we want to switch.

@omniomi omniomi changed the title Build tmLanguage from YAML Should we build the grammars from a different format than .tmLanguage? May 21, 2018
@vors
Copy link
Collaborator

vors commented May 26, 2018

Since there are a lot of projects that are taking a dependency (thru git submodule or otherwise), I think it's better to stick with the current format to avoid any additional cross-project coordination. I know that some of them support both json and yaml, but I'm not sure about the original TextMate for example.

For local development, people can easily convert back and forth between the xml and their preferred format.

@rjmholt
Copy link

rjmholt commented Oct 15, 2019

For local development, people can easily convert back and forth between the xml and their preferred format.

I would actually take that as an argument in the opposite direction. We should pick the format easiest to develop in and generate the others.

For a consumer, things like ordering and line indentation aren't important, but generating an XML to check in based on working in JSON is likely to cause unnecessary diffs.

The plist format is not very well documented and I'm finding it difficult to work with, compared to the JSON I've seen generated.

@msftrncs
Copy link
Contributor

I purposely created PowerShell scripts to convert between XML and JSON. I work in the JSON file, and convert to XML for the purpose of making PR's to this repo. JSON isn't the best, but its a lot easier than XML.

@vors
Copy link
Collaborator

vors commented Oct 16, 2019

toml ftw

@rjmholt
Copy link

rjmholt commented Oct 16, 2019

I purposely created PowerShell scripts to convert between XML and JSON. I work in the JSON file, and convert to XML for the purpose of making PR's to this repo. JSON isn't the best, but its a lot easier than XML

Yeah JSON would be my preference after looking at the alternatives. TOML would be nice, but it's not as well documented or supported as a TM format as JSON. The VSCode TM grammar extension supports pretty seamless conversion.

@msftrncs have you experienced any issues with the XML -> JSON -> XML rearranging the XML and causing bad diffs (e.g. moving sections around so changes are harder to identify)? I've had this in other automated JSON manipulation scenarios because JSON keys are unordered, and presume that transforming through formats would only exacerbate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
v2
Enhancement - Open
Development

No branches or pull requests

7 participants