I made a little demo of it here:
http://unnovative.net/CSSDemo/
Each time you reload the page it will link to a random stylesheet
generated from colorschemes on my computer. Now we can more easily
decouple HTML source-code snippets from the colorschemes used to
render them.
(In doing this project I noticed that Vim has colorschemes called
"twilight" and "eclipse", but not "new moon" or "breaking dawn". Does
somebody want to get on that, or are we not too concerned about
reaching out to the 14-year-old-girl demographic?)
--
Erik Falor http://unnovative.net
Registered Linux User #445632 http://linuxcounter.net
Having played with :TOhtml together with :TOcss, I couldn't agree
more.
> b) generate just an external stylesheet (it looks like you do this)
Yep, this is exactly what the :TOcss command achieves.
> c) generate the HTML along with an external stylesheet
So, do a) above and at the same time do b)? I imagine that this
command would open two buffers, one for each output file. Seems
straightforward enough.
> d) generate the HTML but put all style definitions inline (i.e.
> with style='...' attributes) rather than using a <style> tag or an
> external stylesheet. I though overloading the html_use_css to take a
> string (either "inline", "external", or "embedded") would be a good
> way to do this, with a numeric 1 meaning "embedded" for backwards
> compatibility. This would deprecate use_css=0, I see no real reason to
> keep that around (but I will at least through Vim 7.4).
> e) Generate CSS containing ALL the major names, even linked names,
> so that loading a new colorsheme with the same HTML works better
> (because what if one colorscheme defines Constant, and links String to
> it, then another colorscheme defines both directly? the HTML will only
> include definitions for Constant and therefore switching between them
> won't work)
I hadn't noticed that happening in colorschemes, before, but now that
I review one of my favorite colors I see that very thing happening!
I'll follow up with a new patch to address this soon.
> f) related to (e), generate HTML which contains all the major names
> g) related to (a) and (c), if the stylesheet already exists, 2html
> can do less work (and hopefully be faster). We need a way to tell
> TOhtml whether to generate the stylesheet or assume it already exists
> (or give it a path on-disk to decide for itself).
With a little bit of refactoring within syntax/2html.vim, this should
be very do-able.
> I thought (e) and (f) could use a g:html_global_css flag or similar,
> which should default to true when g:html_use_css = "external".
>
> I also toyed with the following but they may be more complicated than
> needed:
> h) provide definitions for ALL groups (even those defined by syntax
> highlighting rules, so we get things like cComment). This would make
> the CSS definition huge, but would provide maximum accuracy when
> switching between stylesheets generated with the same options but
> different colorschemes. Probably the html_global_css flag could be
> numeric, 0 = use only what is defined directly, 1 = define all major
> names, 2 = define all names. I think this could be done simply by
> unlinking all linkded names and replacing them with explicit
> definitions of the name they are linked to, prior to HTML/CSS
> generation.
> i) "merge" existing CSS definitions, but this was based on the idea
> of generating CSS from the buffer rather than a redirection of
> the :highlight output (which I think is a better method) so is
> probably not needed. The idea was you could convert several files and
> end up with a CSS file containing all needed definitions.
>
> Finally, CSS does allow specifying the encoding. It is probably a good
> idea to do this, it doesn't look (with my brief glance) like you do.
I did leave that out. I can throw it in with the aforementioned patch
I'll make.
> Thanks again, I hope to get a beta version of what I'm currently
> working on out by the end of this weekend (I've said that to myself
> for the last month or so) and then I'll jump right into
> incorporating :TOcss! Nice work. The preview looks just like I
> envisioned.
>
> By the way, I notice in my default font in IE8, that the line number
> column has 1px gaps between some of the lines. I am trying to fix this
> in the current version, but it is being a pain in the ass to figure
> out. If you happen upon a fix, do let me know.
Isn't IE always a PITA? I think my blog looks like garbage on that
browser.
> Also, I mostly do
> development on a branch on a clone listed on Vim's google code site.
> Let me know if you want commit access instead of just mailing patches
> around, I'll probably be pretty liberal about it as long as nobody
> tries to update/establish tagged versions.
I'd like access. I saw mentions in the comments about looking at Hg
logs and history, but never found the URL or name of the clone. I'll
look closer at the google code site. Let me know if you need me to
send my SSH pubkey or other credentials.
It is, but actually I noticed the problem first in Firefox with my
"unselectable areas" changes. Further investigation shows all browsers
seem to be affected with at least some fonts. My current workaround
I'm playing with is to add a 1px padding to the elements which have
background. I first tried experimenting with lineheight, but that just
makes wrapped lines look stupid and sometimes causes other problems (I
don't remember what precisely).
>> Also, I mostly do
>> development on a branch on a clone listed on Vim's google code site.
>> Let me know if you want commit access instead of just mailing patches
>> around, I'll probably be pretty liberal about it as long as nobody
>> tries to update/establish tagged versions.
>
> I'd like access. I saw mentions in the comments about looking at Hg
> logs and history, but never found the URL or name of the clone. I'll
> look closer at the google code site. Let me know if you need me to
> send my SSH pubkey or other credentials.
After some web searching it looks like sadly you cannot add committers
to server-side clones of a project. You could create a server-side
clone of my clone and we could pull back and forth as needed, or I can
create a new full-blown project, but I'd rather go for the former
option rather than creating a new project on google code or BitBucket.
The revision numbers listed in the change log comments refer to Vim's
"default" branch, they are the revision where Bram actually
incorporates the version. I do development on the 2html-dev branch in
my clone, and add a tag for each release I send to Bram. There's
significant work in the server-side clone for the unselectable regions
feature, but it's not yet quite ready. The regions rely on using
readonly <input> blocks, which sadly don't have well-defined width,
causing problems in Chrome and Safari for the foldcolumn. You should
be able to apply your patch to the tag for 2html_v7.3.10.
Oops, I meant to include the clone location:
http://code.google.com/r/fritzophrenic-vim-clone/
And I suppose I should probably move to vim_dev for further development talk.