Sublime Forum

Shebang Syntax

#1

Hi All,

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

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 :smile:

0 Likes

#2

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

0 Likes

#3

Hi Phillip,

I didnā€™t try it, but I found your plugin about halfway through developing mine so thought Iā€™d finish it anyway :smile:

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

0 Likes

#4

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.

0 Likes

#5

[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.

0 Likes

#6

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).

0 Likes

#7

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?

0 Likes

#8

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 ?

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

0 Likes

#9

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 :smile:

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.

0 Likes

#10

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.

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ā€¦

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ā€¦ :wink:

Cheers,
Dominique

0 Likes

#11

Hi Dominique,

Ah, thanks for clarifying :smile:

[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 :smile:

[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 :smile:

0 Likes

#12

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 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.

0 Likes

#13

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!

0 Likes

#14

That was meant in jest - donā€™t worry :smile:

Nick - thanks, itā€™s appreciated!

0 Likes

#15

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 :smile: ), 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 :wink: , 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.

0 Likes