Add Liquid Templating Language

[parkr]

Hi! I'm a maintainer of Jekyll and we're using highlight.js via our Discourse instance, Jekyll Talk.

We use the Liquid templating language and often want to share examples in Discourse. Alas, the liquid lexer doesn't exist. There is plenty of prior art for highlighting Liquid, such as vim-liquid.

Is there a guide that could help someone get started with this task?

[Sannis]

Hi @parkr,

we have Language definition guide and Mode reference that can help.

But it looks like Liquid for Ruby is like Django for Python so you can copy&past django.js and just actualize keywords lists.

[isagalaev]

I'd say Django's template syntax is too idiosyncratic to actually copy it over but it's certainly good as a guide. In fact, I'd say most of new language contributors do it this way: take a similar language and modify it, and then we direct people to documentation to finish it off :-)

[cargix1]

Hey guys, i've actually started work on Liquid lexer today. But unfortunately my laptop is been a douche bag and having a nightmare building. Hopefully I can resolve that soon and get something up and running for us to use :)

[isagalaev]

@cargix1 don't worry, there's never any rush :-)

[Cam]

Yes please!

[isagalaev]

Closing this, as there's no actual issue. We'll be happy to work with the PR whenever it shows up.

[parkr]

Closing this, as there's no actual issue. We'll be happy to work with the PR whenever it shows up.

@isagalaev It's ok if this is your strongly-preferred style to not have tracking issues, but ultimately I considered it an "issue" that there isn't a Liquid lexer. It makes it easier for others to know that this is a desired feature when it's left open. But if this is only for bugs, then is there a forum or a README TODO list where I can add this?

[isagalaev]

I'm perfectly okay with tracking issues that track some progress happening. The issue of not having a certain lexer is not useful to keep in the issue tracker as there are hundreds (if not thousands) of languages out there, and new ones appear every day. We certainly don't want to automatically register every one here simply saying "it's nice to have it". It would have been useful only if we had a concrete plan of implementing them and needed to prioritize work, which is not how it works. Closing this issue doesn't mean we don't want a Liquid lexer. It also doesn't make it less likely to be implemented because it's not like there's a bunch of people out there eagerly watching our issue tracker to have an opportunity to implement something :-).

P.S. (It's actually a FAQ: http://highlightjs.readthedocs.org/en/latest/language-requests.html)

[parkr]

It also doesn't make it less likely to be implemented because it's not like there's a bunch of people out there eagerly watching our issue tracker to have an opportunity to implement something :-).

You never know! Folks new to open source do this frequently. More than that, though, you can prevent duplicate filings by leaving a master one available.

The issue of not having a certain lexer is not useful to keep in the issue tracker as there are hundreds (if not thousands) of languages out there, and new ones appear every day.

If I were filing for something that wasn't used as much, I'd agree with you. But Liquid is the language of Jekyll and GitHub Pages which is used by many thousands of people at least. I think the prevalence of this is what makes it worth keeping open.

Just wanted to voice my concern about it. It feels like a way to bury the feature request and there is no alternative way to submit a feature request for other contributors to work on.

This means that there’s no point in requesting a new language without providing an implementation for it.

From the FAQ you mentioned, this is removing the possibility that someone else would come by and implement it. That happens a lot in Jekyll, where there's an open issue for some request and someone else will have some free time and submit a PR. It feels like that quote ignores that some people would implement someone else's idea.

Thanks!

[isagalaev]

You never know!

Well, actually I do :-) The project is turning 10 this year, and I'm more or less familiar with how things happen around it.

I think the prevalence of this is what makes it worth keeping open.

Why is it useful to keep it open? It does not in any way "enables" the implementation. It will only sit in the tracker and make it harder to look for issues that we could actually work on. Lexers don't come out of highlight.js, they come from their respective language communities when someone finds time and desire to implement them.

It feels like a way to bury the feature request and there is no alternative way to submit a feature request for other contributors to work on.

You're looking at it from a wrong angle. There's no such a thing as a pool of contributors implementing languages in highlight.js. The correct way of making it happen faster is going to the Liquid community and raising the request there (though I suspect the rule of making a request being equal to volunteering at implementing it works over there as well).

[Cam]

Wouldn't this be a legitimate feature request? Liquid is very quickly becoming a major language. I have read the concept in the FAQ, but it seems more sensible to have some kind of feature request support so that people who are comfortable creating the PR for each language can see how much desire there is for support for a particular language. I respect your decision, but I think you may actually be missing the point of tracking feature requests.

[isagalaev]

@Cam please read my two answers to @parkr above, I think they address you questions almost point by point.

I think you may actually be missing the point of tracking feature requests.

No, I simply know how to keep the issue tracker useful.

[Cam]

They are what I am responding to. As I said, I understand your position, but I just don't think you are right. To make what I am saying more clear, it helps to consider "feature requests" as seperate to "issues". Once you do that, you open up a new set of useful opportunities and engagement with the development community.

[isagalaev]

I'm not arguing about terms. I'm stating the fact that having an open feature request for a language implementation does not lead to implementing it. It's not a position, it's an observation.

Let's stop this conversation.

[Cam]

"I'm stating the fact that having an open feature request for a language implementation does not lead to implementing it" that's an observation, not a fact. I can guarantee that having a feature request often does lead to implementation, as I have seen that, and have been involved in that process, first hand.

But as this is your personal project, we do of course need to respect your personal quirks. So I agree, no point in continuing the conversation.

[jf990]

The policy is clearly documented, I don't understand the need to carry on about it. It's not personal, we all agreed to it participating here.

[Cam]

As I said, I read the documented policy. This appears to be going around in unhelpful circles.

[ghost]

I would also love to see liquid made available. Regardless of how you want to label or tag it, I'd suggest keeping this issue open for visibility if a duplicate has not already arisen.

[ghost]

@isagalaev ignore my comment. I landed here thinking I was not able to format liquid using fenced code blocks on GitHub but I proved myself incorrect by simply placing liquid after my backticks.