The following datetime-string will make give wrong syntaxhighlightning in python 2.7: "%H%M".
The last M will not be marked purple, but instead yellow like a normal string.
What version of ST are you running?
What colour scheme are you running?
What you are describing does not happen for me on my personalised scheme nor on any of the handful of the default schemes I tried.
We need to know more to pinpoint what is happening on your machine. Try and tell us as much as you think we might want to know so we can replicate your problem
(If you are a developer I am sure you have said these words many times to people reporting bugs in your code so you get what I am asking from you.)
Using sublimetext 2 with the default Python color scheme. No setting changed but setting tabs to 4 spaces instead of tab. It happends on both my computes, where one is running Windows 7 and the other Linux Mint.
The actual command that gives the visual bug looks like this:
changing it to return theTime.strftime("%H%M") gives the same bug.
I did try many of the other color-schemes. I had the same visual bug with all of them.
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.
Maybe I wasnt clear enough. In my case I have only had issues when writing the "%H%M" format. That is, the %M is directly after %H. The following string will not give the visual bug: "%H:%M"
While i tested some more I found the problem to be more generic, it seems to be that any character that follows "%H%" will be colored as a normal string, not a part of the time-format. In other words, it does not seem like the %M is the actual problem, but rather the %H which was in front of it.
The placement does not seem to matter. The problem is consistent wheter it is the only part of the string, at the end or in the beginning of the string.
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.
Customer support service by UserEcho