Sublime Forum

How to insert a new language supported in Sublime?

#1

Hi everyone:

I am new here and I would like a BIG help to insert a new language supported by the Sublime (great, or the BEST editor that I had tested).

I did a rough approach ( work around ) to insert the Picat (http://picat-lang.org/) in my Sublime, my steps were:

  1. Got the Prolog package (someone did a long time ago) … once that Prolog’s syntax is similar of Picat .

  2. Change some keywords, syntax etc … basically in TWO files
    Picat.tmLanguage and Picat.YAML-tmLanguage

  3. Everything that I did are in my Git
    https://github.com/claudiosa/CCS/tree/master/picat/sublime-text-3/Picat

  4. After I copied this directory Picat/… in ~user_home/.config/sublime-text-3/Cache/

Well, it is working fine and I am using this … but I am unsecure about my metodology …

Whose are the files I need to change to for an effective support for the Picat language?
How to become an official language supported in the Sublime?

I saw that existence of an file in XML … the xml is the pattern language to describe a language?

Thanks in advance

claudio

0 Likes
#2

Although package resources will work if they’re in the Cache folder, it’s better if you let Sublime put them there itself instead of doing it manually. Also the README in your repository mentions copying the syntax file into your User package; that works, but is also not necessary.

The easiest way to do this would be to put the Picat directory from your git repository directly into the Packages folder; for you that would be ~/.config/sublime-text-3/Packages, but you can also find it by using Preferences: Browse Packages from the command palette or main menu.

Any directory that’s inside of the Packages folder is treated as a package, so Sublime will load your syntax as well as all of the other resources from there. Having all of the resources in the same package (i.e. not having the syntax in one and the build system in another) makes the file layout more logical and makes problems easier to diagnose later.

Before you do this, you should close all Picat files that you have open; files remember the location that the syntax definition they are using is stored at, so if you move the syntax while a file is open Sublime will complain that it’s missing (which can be mildly panic inducing). If you close the files first, when you re-open them they’ll pick up the syntax from the new location.

1 Like
#4

Hi …

Thanks for your kindly answer, however which are the files
that I need edit to extend the Picat grammar?

basically there are TWO files
Picat.tmLanguage and Picat.YAML-tmLanguage

which is the main function of each one?
How their format or syntax?

Thanks once

claudio

0 Likes
#5

The Picat.tmLanguage is the only file that ST3 is using to define the grammar. The YAML file is an alternate representation of the same data because tmLanguage is hard to read.

Typically, people who made tmLanguage files would edit the YAML file (which is easier to read) and then run a command from the PackageDev package to convert it to tmLanguage (for ST3 to use).

Later, the creators of ST3 realized that everyone was doing that YAML conversion and made a new syntax definition format (sublime-syntax) based on YAML as an alternative to tmLanguage (which is based on pList).

For long-term maintenance, I recommend either including both files (tmPreferences, YAML-tmPreferences) in your package or converting to sublime-syntax and deleting the old ones.

1 Like
#6

To add to what @michaelblyons said, if you want to convert to a sublime-syntax file, while you have the one from your package opened, you can use Tools > Developer > New syntax from in the menu to automatically convert to the new format followed by saving the result.

Using sublime-syntax is generally preferred because it’s easier to edit and maintain and has more features than tmLanguage files do; mostly the only reason to maintain a tmLanguage file these days is if you want your package to be compatible with other editors that don’t support sublime-syntax files.

1 Like
#7

I did not know this. Thanks!

Agreed. My suggestion for keeping the existing format was mostly to avoid doing the conversion to sublime-syntax… but if the conversion is automatic, there’s (almost) no reason not to do it.

1 Like
#8

Thanks for everyone …

I will be improving this package soon I have a free time.
But the tips were very important to start this work

thanks once

claudio

0 Likes