[PATCH] plugin/tohtml.vim :TOcss command
Erik Falor
command that Ben Fritz has been maintaining. Like :TOhtml, it puts
its output into a buffer which you can then edit, save or throw away.
The buffer is named for g:colors_name.
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
Ben Fritz
On Mar 7, 12:50 pm, Erik Falor <ewfa...@gmail.com> wrote:
> I've created a :TOcss command to go along with the handy :TOhtml
> command that Ben Fritz has been maintaining. Like :TOhtml, it puts
> its output into a buffer which you can then edit, save or throw away.
> The buffer is named for g:colors_name.
>
> I made a little demo of it here:
>
> http://unnovative.net/CSSDemo/
>
but I've been bogged down in implementing "unselectable regions" to
allow copy-paste without also grabbing the fold column, line numbers,
etc. (configurable by option, of course). I think I'm getting close to
finishing that up but haven't yet started coding TOcss.
Some notes:
I'd like to be able to tell TOhtml any of the following (I'm not clear
from my brief glance whether any of this is possible):
a) generate the HTML, but use an external stylesheet. Insert a
<link> tag instead of the normal <style> tag. We need a way to tell
2html.vim what path to use in the link tag.
b) generate just an external stylesheet (it looks like you do this)
c) generate the HTML along with an external stylesheet
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)
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).
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.
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. 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.
Erik Falor
> GREAT, thanks! As you noticed, I had this in the todo list for TOhtml,
> but I've been bogged down in implementing "unselectable regions" to
> allow copy-paste without also grabbing the fold column, line numbers,
> etc. (configurable by option, of course). I think I'm getting close to
> finishing that up but haven't yet started coding TOcss.
>
> Some notes:
>
> I'd like to be able to tell TOhtml any of the following (I'm not clear
> from my brief glance whether any of this is possible):
> a) generate the HTML, but use an external stylesheet. Insert a
> <link> tag instead of the normal <style> tag. We need a way to tell
> 2html.vim what path to use in the link tag.
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.
Benjamin Fritz
>> 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.
>
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.
Benjamin Fritz
>>> 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.
>
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.