Generic Configuration Language


#1

I created a generic configuration language package for those config files that basically are just lines of stuff or single-line comments beginning with a hash character. By default, it only recognizes .gitignore (which is what I made it for), but I hope to soon create a package or add functionality to Atom that will allow you to configure a mapping of file path patterns to grammars.


#2

Just yesterday I was editing an nginx config file and wished it had some coloring. I’ll try it with your package.


#3

Some quick comments.

On my Atom Light theme the difference isn’t very noticeable, at least to my eyes.

Can you please add .conf to list of suffixes? Or is the standard for everyone to select what they want?


#4

It just uses your standard colorization for comments and text. I’ll check it out in the Atom Light themes, but I don’t think there’s anything I can do about it because grammars don’t control colors, that’s up to the themes.

I’ll add it, but it won’t be until later tonight :cry:


#5

Please support richer pattern matching than just the extension. I have a need to make doc_*.xml files be different than other *.xml files.

Thanks for listening :smile:


#6

I just pushed v0.1.1 with the .conf extension added.


#7

Completely missed this thread. This is really a nice package :), adopted!


#8

Yeah, I see what you mean …

The best I found of the default light themes was Base16 Tomorrow Light … but not by much :confused:

And Fizzy, the recommended syntax theme was a little better:

I dunno, it just looks like light themes aren’t very good at differentiating comments from just plain text. But again, this is the purview of the theme, not the grammar.


#9

Thanks. This is very useful as I regularly edit things like /etc/hosts. Just one thing that would be nice, the grammar recognises what is and what is not a comment, but cmd-/ does not toggle comments off and on.

I would have thought that if a language grammar defined what was and was not a comment then editor:toggle-line-comment would work automatically. Is that not how it works?


#10

Not quite how it works, no. Just because a grammar can say “from here to there is a comment” doesn’t mean it knows necessarily how to mark that space as a comment. But I had thought I added the bit of definition that taught it how to do the second part. Turns out, there is a bug in it.

Shouldn’t take me long to fix it, but just in case I can’t in the next ten minutes before I have to run off to work, here’s the bug tracking this issue:

Just published v0.1.2 which fixes this issue.


#11

Thanks! That seems to be working great at my end.


#12

This is a good excuse for me to learn how to customize themes.


#13

I compared my normal code comments to the comments in your generic language. I see what the difference is. In code almost everything is bold or colored garishly. The comments really stand out for their blandness. This is perfect because the comments are very readable without being annoying,

You don’t have enough colors. :smile:

Seriously though, maybe you should make the non-comments some other color, but not garish.


#14

The grammar can’t control the colors directly. The division of labor looks like this:

  • Grammar - responsible for the rules that say which parts of the file are what type of token
  • Syntax Theme - responsible for the rules that say which types of token are what color

Currently, the things that aren’t comments are just marked as “text” because that’s what they are as far as this grammar is concerned. The solution here is for the syntax theme to add more colors or differentiate better between “text” and “comment” (like my syntax theme does already as can be seen in my screenshot).


#15

Surely you could mark the text as some other part of the grammar. Who is to say what “text” is.

BTW, there are other things you could color. Numbers and quoted strings come to mind. I’m sure I could think of other things.


#16

True, there are plenty of things I could color if I wanted to make assumptions about the kinds of things that are being stored in the config. The point of the grammar though, or at least my vision for it, was to have a very simple one that just differentiated between “comments” and “everything else” … because I figured that, over time, anything that had any sort of real structure would have its own specific grammar a la .gitconfig.


#17

There is also a language-nginx package that might be better at supporting its specific format.


#18

Thanks for this package @leedohm, I use it often. Do you know if there is something straightforward I could add to either my config.cson or my init.coffee files to overwrite the regexp used to match the comment character? I’m not proposing any change to your package, but for me personally I only want to match “#” as a comment character, and the matching “;” actually gives many false positives in the files I edit.


#19

No, the regular expressions used to determine what is a comment character are built into the grammar file and there is no easy way to override definitions in grammar files currently in Atom. Perhaps I could create alternate grammars for hash-only, semicolon-only and both.

Added an Issue:

Not sure when I’ll get to it though.