Blaizer
Colours
I'm really happy to see someone trying to make a better highlighter for Perl, but there's one reason why I haven't used it much yet, and it's that it looks completely different from the default highlighter using built-in colour schemes. Way too colourful, and it feels like everything is different.
I'm using Twilight, so any colours mentioned below are from there.
One of the nice things about the old highlighter was that inside qq, the variables would be subtly coloured a different shade of green, with the new highlighter it's the same purple as outside variables. Also, why that colour in the first place, when in the default highlighter they ended up blue (the same colour as 'my' in ModernPerl). In comparison, the PHP highlighter also uses blue for variables and the shaded green for variables inside double quotes. Though then again, looking at JS and Py stuff, it's all a mess.
Interestingly, PHP (just like ModernPerl) also colours functions yellow, whereas Perl would leave them white — I personally prefer the way the old Perl highlighter does things here, even though it doesn't match the PHP highlighter: at least not everything is coloured. White also stands out better. But I guess this is just a personal preference at this point.
I messed that up with the current version! Variables outside of everything were always supposed to be white. Variables interpolated inside strings were meant to have that subtle colour change. my/our etc. were meant to have a unique colour, so they they can be seen easily. Thanks for the feedback.
I'm working on a lot of changes all at once, so I can't push anything before it's all done. Not the best way of doing things, I know, but I just had to overhaul all of the original definitions before I could go any further. Might be a week or two before you see my fixes to this.
Took a bit longer than 2 weeks, but I've finally pushed the new update! Check it out when it updates and give me any feedback. If there aren't any further problems, I'll close the issue.
Nice update, great job on the quote stuff.
I still see my being variable-coloured (blue in my case) and variables white, though. I would think it's a keyword just like if and while, so it should instead be that colour (orange in my case). I just checked ruby and wherever they can be sure it's a variable (has the @ or @@ sigil, or is named between the |…| operator), they too colour variables blue, just like the PHP and the original Perl highlighter.
It is a keyword just like if and while, but I find it visually useful for just these particular keywords to be a different colour. Makes it easy to track where your variables are defined.
I actually quite like variables being white. Means things like $_[0] are all white, since all punctuation and numbers are white too. Maybe give it some time?
I'll try. My problem is that this makes it inconsistent with other highlighters, and visually, it's much harder (for me at least) to see where the variable name ends — exactly because punctuation is the same colour.
It's the same as C/C++/Java or any language that doesn't have a way of determining what's a variable... In all of those variables are white.
I've just pushed an update that makes it easy to tweak the scopes of ModernPerl. Changing the scopes of the entire document is as easy as modifying a YAML config file (which is currently at the top of ModernPerl.tmLanguage.yaml.ep, but it could easily be moved to its own file).
The hard part is then compiling ModernPerl.tmLanguage yourself with parseplist.pl and getting Sublime to use it... But maybe someone will give it a go. The dependencies are currently YAML::XS and Mojolicious. But right now I'm thinking of packaging (cut-down versions of) them with ModernPerl, so that there are no deps.
I'm thinking a user config file to modify the language isn't possible, given how languages work. But I'm thinking a kind of plugin system that swaps in and out different "plugin" language files that I've generated myself with different scope configurations would be the end goal of this.
My other line of thinking is to make parseplist.pl have no deps. Then I could add a .sublime-build file to ModernPerl which would build ModernPerl.tmLanguage for you in a pretty user-friendly way. All you would need is Perl interpreter. And I'd say it's pretty likely for a user of ModernPerl to have a Perl interpreter...
I've come to terms with the fact that it's impossible to please everyone with the one set of rules...
Just pushed with the new highly experimental scope and build system. It needs some more testing, so I haven't put it into the README, or made an update message about it.
Need people like you to try it out!
Once ModernPerl has updated, you'll have two new options in Preferences > Package Settings > Modern Perl. You'll also have two ModernPerl commands in your command palette. One is the default scope file which you shouldn't edit, but use as a reference. The other opens up a blank file where you can make changes.
Remeber to build one of the scope files when you've made your changes. The default scope file has all the instructions on this. This system isn't ideal, but it works well enough for now!
Once your modified ModernPerl has successfully been built, you may need to restart Sublime to see your changes. If you do, tell me. This is a bug with Sublime, but it can be fixed so that you see the changes immediately.
I just tried it, but the moment I tried to save the user config I got the following
Unable to save ~/.config/sublime-text-3/Packages/ModernPerl/ModernPerl-scopes-user.yaml.ep
Error: No such file or directory
Because the …/ModernPerl directory also doesn't exist. I created it and now it does.
During build, I received the following error:
[Finished in 0.0s with exit code 2]
[cmd: ['perl', 'yaml2plist.pl']]
[dir: /home/henrik/.config/sublime-text-3/Packages/ModernPerl]
[path: /usr/lib/qt4/bin:/home/henrik/bin:/usr/local/bin:/bin:/usr/lib/ccache:/usr/bin:/usr/lib/java/jre/bin]Can't open perl script "yaml2plist.pl": No such file or directory
Google says that file is part of facelessuser/SerializedDataConverter, which I didn't have installed (gonna try to fetch it somehow). That module does seem to mention Sublime Text 2 a lot though and not 3 which I am using.
Woah. Hmm.
yaml2plist.pl is a file I wrote, and it's included with ModernPerl. facelessuser's script just happens to have the same name.
The problem you're seeing is caused by the ModernPerl directory not being where it is for me. I'm using sublime-2. Could you look around in ~/.config/sublime-text-3/ for the ModernPerl folder with yaml2plist.pl in it?
Are you sure it's installed? How could it not be there?
I'm sorry but this is tough for me because I don't have a copy of ST3.
Did you use Package Control to install ModernPerl? If not, then there's your problem.
It's odd, the syntax highlighter is definitely installed, because I'm using it and all :)
As for ST3, I'm using it in nagware mode, switched to it during the first public beta, you can freely download it too.
I did use Package Control, and I regularly get update messages from your package because of it.
Well this is the issue:
http://stackoverflow.com/questions/18754473/sublime-text-3-plugin-development-access-own-files
Seems like I'm gonna have to write some Python... Yeah... Not doing that any time soon...
FWIW I agree with @ralesk about colours; the default ST Perl syntax has it right.
I gave ModernPerl a good try but I can't get on with it - particularly the all-white variables which are no longer distinct from operators / punctuation / numerics.
Thanks anyway!
You can actually add a couple rules to your ST Theme to get the colours you want. Simply add a rule for support.function.perl and make that white. Then add a rule for punctuation.definition.var.perl and make that whatever colour variable should be. That's it.
The next time I work on ModernPerl I will attempt to address this issue, but for now it's easy enough to get around so that you can keep using the less-buggy highlighting that ModernPerl provides.
There's a couple ways I could go about addressing this issue properly, though. The first is to fix the problem I had with the build process not working in ST3, so that you can build your own ModernPerl syntax with different colour options. This gives a lot of control over the colours, but it's not very user-friendly.
The second is to ship ModernPerl with 2 syntaxes, one with hilighting like the default Perl syntax, and the other with the current style. This may be easier for the user, but it might be more difficult to get files to associate with the right syntax.
The third option is to come up with some Python ST plugin that can do that swapping for you, and just have one syntax, eliminating that problem. This is probably the best solution, but it would require some good code to get it right, and I'm not experienced at all in Python.