Shebang Syntax

[vxnick]

Hi All,

This is my first post as well as my first Sublime plugin, so please be gentle

This plugin is pretty straightforward - it sets a file’s syntax based on a shebang line during file load and save (i.e. ‘#!/usr/bin/env python’ to Python). From what I’ve seen, this already exists in the core, but not to the extent that it handles ‘env’ as the binary, with the actual binary (such as ‘python’) as an argument to env.

Essentially, the plugin capitalises the first character of the binary it finds and matches that against syntax directories and files in the Packages directory. In some cases, this won’t work (‘PHP’ is all upper-case, Bash is ‘ShellScript/Shell-Unix-Generic.tmLanguage’) - when this is the case, simply add those to the plugin settings file. This also works if you have additional binaries that need to use the same syntax - an example being ‘python2’ and ‘python3’ needing to use the Python syntax.

More info can be found here - I’m currently waiting for the plugin to be added to Will Bond’s Package Control.

Any issues, please raise them on GitHub

[phillip.koebbe]

Hi vxnick,

I definitely don’t want this to come across the wrong way, but did you give DetectSyntax [1] a try before writing your own plugin? Identifying syntax by a shebang was one of the things I wanted to accomplish with DetectSyntax, and if you tried it and it doesn’t work for you, I’d like the chance to fix it.

On the other hand, if you just wanted to write your own plugin, that’s great! The more people writing quality plugins the better! So please don’t take this the wrong way.

[1] github.com/phillipkoebbe/DetectSyntax

[vxnick]

Hi Phillip,

I didn’t try it, but I found your plugin about halfway through developing mine so thought I’d finish it anyway

It was more an experiment with the Sublime plugin API than anything serious, so no offence taken!

[tito]

If something is going wrong with Phillip package you better try to fix it by communicating, there is no gain into having two packages doing “the same”.
Confuse people and is a waste of valuable resources and time.

[bizoo]

[quote=“tito”]If something is going wrong with Phillip package you better try to fix it by communicating, there is no gain into having two packages doing “the same”.
Confuse people and is a waste of valuable resources and time.[/quote]

+1000
There are more and more package in Package Control that do almost the same things.

[vxnick]

There are more and more package in Package Control that do almost the same things.

Any examples? I’ve looked and can’t find anything similar other than DetectSyntax. I’ve already given my reasons why I finished developing this plugin (I hadn’t found DetectSyntax at the time).

[tito]

The point is to try to unite efforts to get the problems solved. Not 123234 ways to resolve it. This community seems to not understand that.
If your package is not doing nothing that DetectSyntax can’t do, then why you submitted the package to package control?

[bizoo]

I’ve looked and can’t find anything similar other than DetectSyntax. I’ve already given my reasons why I finished developing this plugin (I hadn’t found DetectSyntax at the time).

Nobody prevent you to write your plugins and use them, the problem is when you want to publish them on Package Control.

The Package Control repository grow very quickly, and having dozen of plugins with almost the same functionality is bad for both new and confirmed users.
Searching and testing plugins is time consuming…

Github make collaborative coding simpler than it ever was, it’s a pity that people don’t use it more often.

I use a bunch of plugins from Package Control and a dozen of my own plugins.
When I think something missing on a plugin from Package Control, I write an issue on github or send a pull request.
If you think that something missing on the DetectSyntax plugin, as already asked by phillip.koebbe write an issue or make a pull request.

The reasons why you wrote your plugin and ask to publish it on Package Control is perfectly fine, but now you know that DetectSyntax exist, do you still think that your plugin must be published ?

Any examples?

Code Alignment:
github.com/khiltd/Abacus
wbond.net/sublime_packages/alignment
github.com/wbond/package_contro … l/pull/226

Files ‘management’:
github.com/belike81/Sublime-File-Navigator
github.com/wbond/package_contro … l/pull/229

Code execution:
github.com/darinmorrison/sublime-meta
github.com/technocoreai/SublimeExternalCommand
github.com/wbond/package_contro … l/pull/227

[vxnick]

Hi,

Sorry, those plugins don’t look related at all to mine or DetectSyntax unless I’m missing something.

Either way, people don’t have to use my plugin - I developed it as a fun sideline and it does just one thing pretty well. I think it’s fair to say that some people don’t know regex and don’t want to have to learn it in order to detect a file’s syntax based upon a shebang line. For others, like us, it’s not a problem adding that to DetectSyntax’s settings.

To answer your question though - I feel my plugin meets the needs of end-users who aren’t necessarily proficient enough (or can’t be bothered) to write the regex for detecting this as part of DetectSyntax. Phillip’s plugin is clearly better than mine, but I think they serve different purposes. If I was emulating pretty much everything that DetectSyntax was, then I’d agree with you

Anyway, if Will Bond decides that my plugin isn’t suitable for Package Control then that’s fine - if nobody uses it other than me, that’s fine too. I just wanted the opportunity to let other people know it existed in case they were looking for something simple.

P.S. I expect this plugin to be a stop-gap solution anyway, until Sublime properly interprets shebang lines.

[bizoo]

Sorry, those plugins don’t look related at all to mine or DetectSyntax unless I’m missing something.

Sorry maybe I wasn’t clear (or maybe my poor english), these examples was not related to your package, but to illustrate the point that there is already kind of duplicate packages in Package Control.
And I’m not saying there is something wrong with any of these packages.

I feel my plugin meets the needs of end-users who aren’t necessarily proficient enough (or can’t be bothered) to write the regex for detecting this as part of DetectSyntax. Phillip’s plugin is clearly better than mine, but I think they serve different purposes. If I was emulating pretty much everything that DetectSyntax was, then I’d agree with you

So your issue with DetectSyntax is that it use regex, right ?
I’m pretty sure that phillip.koebbe can add something like “first_line_noregex” to is config file in less that five minutes… if he want… and if you ask him…

Anyway, if Will Bond decides that my plugin isn’t suitable for Package Control then that’s fine

I totally disagree with this view.
It’s not the job of wbond to check every package that people want to be added to Package Control, with the current trend it will a full time job in a few months…
This is a community driven repository so people could and have to give their opinions about its content, and this is why three people already ask you to think about it’s inclusion in Package Control.

And don’t get me wrong, I’ve nothing personal against you or your code, actually your code is very good and well commented.
I expect to see more of your plugins in Package Control in future, simply not this one…

Cheers,
Dominique

[vxnick]

Hi Dominique,

Ah, thanks for clarifying

[quote]So your issue with DetectSyntax is that it use regex, right ?
I’m pretty sure that phillip.koebbe can add something like “first_line_noregex” to is config file in less that five minutes… if he want… and if you ask him…[/quote]

I don’t have a problem with regex, but I know some people don’t know it at all or aren’t very confident with it. I’m sure Phillip could do that, but the difference is that my plugin checks if ‘env’ is specified as part of the shebang (and ignores it). This allows for things like ‘#!/usr/bin/python’ as well as ‘#!/usr/bin/env python’. That could be done with regex with DetectSyntax, but again it comes down to what the user is able to do. There would also be a lot of duplication - you would need the same regex for each language (PHP, Python, Ruby, Bash, etc) - it’d get quite messy

[quote]I totally disagree with this view.
It’s not the job of wbond to check every package that people want to be added to Package Control, with the current trend it will a full time job in a few months…
This is a community driven repository so people could and have to give their opinions about its content, and this is why three people already ask you to think about it’s inclusion in Package Control.[/quote]

Sorry, I probably didn’t phrase it right - I said that as I’ve noticed Will commenting on some other pull requests to that effect.

OK - I know when I’m defeated, so I’ll remove my pull request from Package Control. As I said previously, I don’t expect this plugin to last very long anyway, as it’s likely to be fixed soon (if not already, in a dev build) in Sublime core.

I appreciate all your feedback everyone, even though we may not agree - slightly disappointing reception for my first plugin, but such is life

[bizoo]

OK - I know when I’m defeated, so I’ll remove my pull request from Package Control. As I said previously, I don’t expect this plugin to last very long anyway, as it’s likely to be fixed soon (if not already, in a dev build) in Sublime core.

Please, don’t take it that way, it was not a battle and there is no winner or loser. Simply people with different opinion.
I’m sure phillip.koebbe will read this topics and add something to his plugin for non regex guru user.

I appreciate all your feedback everyone, even though we may not agree - slightly disappointing reception for my first plugin, but such is life

I appreciate this discussion and really hope to see others plugins coming from you soon, the mixed reception with this plugin is unrelated to the plugin itself (again with a really clean and well commented code).

See you soon.

[nick1]

I can appreciate the stances of both “sides”, and I’m not going to push the discussion about what should be done any further except to say that this was one of the most well handled disagreements I’ve ever encountered on the internet. Kudos to you all!

[vxnick]

Please, don’t take it that way

That was meant in jest - don’t worry

Nick - thanks, it’s appreciated!

[phillip.koebbe]

I’m sure phillip.koebbe will read this topics and add something to his plugin for non regex guru user.

Ah, you put me on the spot! Heh heh.

Actually, what vxnick wanted makes a ton of sense. It has been just within the past two or three years that I’ve been using regular expressions, and I’m far from being a guru with them. But I decided to rely on them to make the plugin less complicated and brittle. The first pass I made at it was not regexp dependent and it was a nightmare. Once I had the “Aha!” moment of being able to handle just about everything with regexps, the code became considerably simpler.

Anyway, I just pushed a change that adds support for a “binary” rule type which works by taking whatever you supply and making a shebang regexp for you. So you can now do this:

{"binary": "ruby"}

instead of

{"first_line": "^#\\!(?:.+)ruby"}

I haven’t tested this extensively, but this should allow one to catch any variation of a base binary, such as ruby18, ruby19, php, php4, php5, etc.

Regarding the proliferation of plugins, I can see both sides. It is very frustrating when multiple plugins do essentially the same thing, but at the same time, I wouldn’t want to see people not try to solve a problem in a slightly different way. One thing I’ve learned over the years is we don’t all think the same way (this is true for most, if not all, areas of life, not just plugin development ), so one person’s neato solution to a problem isn’t going to ring bells with everyone. Besides, choice is good.

I don’t want to stir this debate up again, but I figured since I got pulled into it , I might as well toss in a penny or two while I’m here. Oh, and I wholeheartedly agree that the difference of opinion was handled very well.

Cheers and peace to all!

P.S. And just for posterity, the “first_line” rule type is a consolidation of what originally was “first_line” and “shebang”. In my earliest attempts at this plugin, I was trying to handle shebangs separately from things like the first line of an XML file. When I decided to handle everything with regular expressions, I didn’t think “shebang” was generic enough to reasonably apply to all situations. shrug I don’t really like “first_line”, but it works.