I'm v. happy with my code but I think I'll explore a couple of ideas tomorrow evening - just for my own Python education:

1. I'm storing the spans in a temporary string before writing to the file. If, instead, I store a list of tuples (tidied_text, the_colour) then I can perform the entity-escaping, etc., in one fell swoop, perhaps with a list comprehension.

2. I'd like to gain a better understanding of generators. It's screaming at me that processing spans within a line could be a good example for this. (This is probably an alternative to 1.)

BTW A while ago (yesterday? can't remember) I did notice '\r' popping up on occasion, but presumably split_by_newlines has removed this issue. Personally, I'm using:

agibsonsw wrote:@facelessuser: Signing off now, you'll be pleased to hear.

I'm v. happy with my code but I think I'll explore a couple of ideas tomorrow evening - just for my own Python education:

1. I'm storing the spans in a temporary string before writing to the file. If, instead, I store a list of tuples (tidied_text, the_colour) then I can perform the entity-escaping, etc., in one fell swoop, perhaps with a list comprehension.

2. I'd like to gain a better understanding of generators. It's screaming at me that processing spans within a line could be a good example for this. (This is probably an alternative to 1.)

BTW A while ago (yesterday? can't remember) I did notice '\r' popping up on occasion, but presumably split_by_newlines has removed this issue. Personally, I'm using:

I think the \r is a non-issue, but as stated earlier, it hurts nothing to try to strip them.

I went ahead and posted the last currently planned features.-color and black and white default color schemes.-quick panel access to configurations stored in settings file.-multi-select available-option to turn off gutter styling (mainly for when you want to print)-code cleanup

At this point I just need to do some good testing and write up the documentation.

@facelessuser: I came across encode() the other day and was considering 'xmlcharrefreplace', although I wasn't sure how it fitted in to the project. The Python docs don't indicate that encode() takes varargs - must be out of date.

BTW, and out of interest, I conquered adding comments last night (in my head ). Here's my outline, but I'm not sure if it's worth doing. Nevertheless, it's interesting :

1. Create a shortcut to store the current view, point, word under the point - and a comment read from the input panel - in a dictionary of tuples, using the view as key. If there isn't a proper a-z word under the point, then bail, and it cannot be a selection (just a single point).

Allowing a selection is too messy, as it would cover a number of spans. Similarly, extending the comment across the current span could be messy, particularly if within a comment line. (Why would someone put a comment in a comment, Doh!)

2. Add CSS rule(s) to a tag such as 'b' or 'tt', or possibly a little bit of JS, based on a class that would create the tooltip on hover. (JS might use ids instead: e.g. 'comment' + pt)2b. Format the tag so it stands out. Can't really use a colour, so perhaps underline or italic. (But perhaps allow yet another setting for 'comment_colour'.)2c. Might need another styled-span, that JS would use to display the tooltip.3. During parsing of the lines/spans - but after entity escaping the HTML - examine the comment-points to see if any fall within the current region/span.4. If so, compare the word-under-point. If it's not the same, then bail - they've added more code and the comment is no longer relevant.5. Find the same word in tidied_text, and replace it with '<b class=\"comment\" title=\"The comment text\">word</b>".6. If using JS for the tooltip, would need to insert the (new) styled-span just inside this b-tag, containing the comment text. (It could be positioned to display underneath the line.)

I recall/believe that tooltips can be created with just CSS, particularly CSS3. They could even just be <a> links, but a little JS might be better.

He, he, I was looking at this yesterday, and wondered why ST didn't offer the second, default, argument. But it does - must have been in my blind-spot when I glanced at the docs.

Curious as to why you created theme files, rather than just creating a dictionary? Perhaps you feel users would be more comfortable modifying the plist.

My idiom (notice the Python reference there?) would be to delete all the ' self.bground = '' ' as they are now always assigned a value, but we had a similar discussion before

Are 'activeGuide', etc., standard pList items in ST? Or have you made them up for the plug-in? (I've struggled to find a list of the possible items.)

Andy.

I just took the Monokai Bright Color Scheme file and modified it. I figured it needed to be in accordance with other scheme files. People can modify them if they want. I left everything in the settings section so it would be functional if some used it (I can't imagine people using the grayscale one though). In the gray scale one, I gutted everything scope wise because everything is black accept comments which is gray. If something was italic or something, I left it in.

'activeGuide' controls the color of the stippled tab guides.

People can use my other plugin and convert the plist to a JSON file if they like that better for modifications. But I wanted to be universal with how I handle all input colors schemes.