Ah ha. I misunderstood what you meant by 'rename'.

I agree I can replicate this on ST2 and ST3 on OS X.

Not the biggest annoyance in the world but I agree that if the file extension was rechecked on a rename through the side bar that would be a nice addition to fit and polish.

Nice pickup!

I had a quick look around Package Control http://wbond.net/sublime_packages/community and couldn't find anything around the Lilypond syntax.

One of the nice things about ST is the 'relatively' easy ability to build your own syntax highlighting package.

From looking at the link you supplied I think you have an excellent syntax guide to work off from the site documentation. I also think that anyone who can use Lilypond has all the skills needed to make your own syntax package. 

Apart from time (the universal constraint) all you will need is the knowledge and the best place to start is to install the AAAPackageDev package (available at the link above) and then follow the short tutorial supplied on how to create a new language syntax. It is just a matter of developing the regular expressions that match the various syntax elements.

If you have never done any regular expression work it is a little bit of a learning curve buy there are heaps of sites that will guide you and once you get over the initial hump it is fairly easy to do the basics.

If you get stuck somewhere the ST community is here to help.

I'd like to offer to do the work for you but I simply don't have the time and motivation. You have the motivation, if you also have the time then that would be great. If you do get something fairly nice set up then I am sure the ST community and the Lilypond community would love to see you make it accessible. But walking first, running later is the plan here.

Ah cool. So my hypothesis was off on the wrong track. Thanks for the research, few things more pointless in life than trying to so solve the wrong problem.

Okay I'll put looking at that in my list of things to do and see if I can work out what is happening around %H%.

If I learn anything interesting I'll post here so we can sort out a workaround and so Jon has a chance to do the deep fix when he can.

With any luck someone else, smarter than me, will work it out and post here before I get my tired broken brain onto the subject.

Ah I am sorry, I thought you were suggesting a change rather than what you were really suggesting. I get what you are saying now. My bad.

I agree with you that these guides are almost a requirement to keep sane when working with some languages.

You can be sure that if you are having difficulties you are not alone so good to get the subject out in the open where it can be discussed and others having the same trouble can benefit from the discussion. All good stuff.

If you have a look in [Preferences -> Settings - Default] you should find some entries like the following:

    // Set to false to turn off the indentation guides.

    // The color and width of the indent guides may be customized by editing

    // the corresponding .tmTheme file, and specifying the colors "guide",

    // "activeGuide" and "stackGuide"

    "draw_indent_guides": true,

    // Controls how the indent guides are drawn, valid options are

    // "draw_normal" and "draw_active". draw_active will draw the indent

    // guides containing the caret in a different color.

    "indent_guide_options": ["draw_normal"],

Copy those lines and then open  [Preferences -> Settings - User] and paste them into that file (these are your personal settings - never edit the [Settings - Default] directly. You can edit it directly but it is a 'bad idea' for reasons we won't go into here.

As the comments in the [Settings - Default] suggest the presentation of the guides is dependant on their being settings in the relevant syntax colour file (e.g. "Packages/Color Scheme - Default/Monokai.tmTheme") that support the guides. If you have selected a tmTheme that does not supply the required values the guides will not display.

So a quick test would be to try reverting to the default Monokai theme and seeing what happens. 

Did the guides appear?

If they did then the problem is just in the theme you were using and you can either choose a theme where the guides display or edit the theme you do like to use to add the missing values.

These are the settings from my own personalised theme so you can see the area where the keys and values referred to above go. See 'guide', 'activeGuide', and 'stackGuide' towards the end of the list? I had to manually add them to the theme. I have chosen to have the guide for the active guide different to the other guides by enabling  "indent_guide_options": ["draw_active"] in my  [Preferences -> Settings - User] and supplying the relevant colours that I like it the .tmTheme file I use.

<dict>

<key>background</key>

<string>#000000</string>

<key>caret</key>

<string>#FFFF00</string>

<key>foreground</key>

<string>#FFA500</string>

<key>invisibles</key>

<string>#FFFFFF40</string>

<key>lineHighlight</key>

<string>#00FF00</string>

<key>selection</key>

<string>#424242</string>

<key>gutterForeground</key>

<string>#424242</string>

<key>guide</key>

<string>#FFFFFF</string>

<key>activeGuide</key>

<string>#00FF00</string>

<key>stackGuide</key>

<string>#424242</string>

</dict>

Hope this is helpful and you can get the guides showing. If you are still having trouble getting it to work don't hesitate to ask for help. One of the many cool things about ST is the great community of people willing to help one another get the best out of the freedom and power ST gives us. 

The syntax changes on 'Save As' changes of extension on my ST2 (2220) and ST3 (3021) installations on OSX.

So I am not replicating your issue.

Can you give us a lot more details of:

- what your environment is

- what ST2 build you are running?

- the exact steps you take to produce the issue

    - what is the filename and extension?

    - how do you do the renaming?

    - what is the new filename and extension?

I am not saying there is not an issue here just that your report does not describe it in enough detail for it to be replicated and unless we can see it happening on our machine the support for a 'fix' is going to be limited.

Okay putting together a language syntax definition to allow syntax highlighting is something that is within the capacity of the community.

In fact if you have even basic programming skills (and you clearly have more than that) you could do it yourself.

But it would be impossible without a definition of the language syntax.

What is a keyword?

What are the operators?

etc. etc. etc.

So your next step is to track down some language documentation that defines the syntax elements of the language you are interested in.

Then I would suggest that since you are clearly motivated to have this done more than those of us who don't use those languages you would probably be the best person to have a go at implementing the syntax definition yourself.

Have a look at the documentation for the AAAPackageDev package for a short tutorial on how to do this. It is simple in concept, just painstakingly building correct regular expressions for each language element.

If you give it a try and need help with specific issues you will probably find more help than asking people who don't really care about the issue to do it from scratch.

I think we are failing to communicate.

I am trying to help get a clear contrast what the difference is between 'what is' and 'what you want'.

Since we have indentation highlighting in place already following one set of design rules then the clearest way for you to describe the change you are seeking is to highlight, in as exact detail as you can, what is different between what is happening now and what you want to see instead.

While you may think your highlighting design is better there may not be universal agreement with you. Opinions are like noses, everyone's got one.

The best way to sell your idea is to make it very clear you fully understand what the current situation is and how your design is different and superior. Without showing a change is better then it is just different and very few people are interested in implementing and enduring change just because it is a change.

Okay so I reverted my ST install and have what I think is your issue replicated.

From my quick experiments the issue is around %M.

From a very sketchy run of tests it seems that regardless of where %M appears in a datetime format string the M is not getting the same syntax colouring as the rest of the % format items.

My original glance at your issues made me wonder if it was an issue around the placement (i.e. it was the last format item in the string that was having the issue) but in an inadequately broad set of trials that seems to not be the case and the last format item is okay if it is not M and M is different regardless of where it appears.

Is that your experience?

Is there any placement of %M where the colouring of M is as you expect?

Can you find any other % format item that behaves the same as M?

I haven't tried resolving the issue because deconstructing other people's regular expressions is something that I need to be rested, motivated and have a whack of time to deal with and want to do it as few times as I have to with the best set of tests I can reasonably have.

Before I start I would really like to have the best description of the issue set that needs attention that we can, collectively, put together. 

As the person I know that is the most motivated to see this fixed I am hoping you have the drive to run a wide set of experiments to try and nail down exactly what the issue is and is not.

Are you interested?

If you are then please let us know what you find out in your trials in as much detail as you can.

It is build into core ST.

Right click on the body of the open file (not the tab the bit with the text in it).

There is what you want right there on the menu and it has been there for years.

No need for all the argby bargy in this thread - it is already supplied

Have you tried this package?

https://github.com/hoest/sublimetext-fsharp

Been around for a while so probably quite stable and the provider says s/he is looking for feedback so would probably welcome yours