sent 20:59:38 05 April 2011, Tuesday
by Ben Fritz:
> I see. TOhtml does not use an element to span the whole line. Perhaps
> it should for this case. The alternative would be to pad with spaces I
> guess, to the maximum line length similar to what you say you do for
> diff lines, below.
Element for spanning the whole line is useful when you add tags as hyperlinks:
in this case you know that if a page was created by format.vim then each line
will have id `line{LineNR}-0' (0 is here to save my time writing code for side-
by-side diff: if SbSD wes active then lines would have given id's
`line{LineNR}-2' for first buffer, `line{LineNR}-3' for second and so on).
> I see. TOhtml does not use an element to span the whole line. Perhaps
> it should for this case. The alternative would be to pad with spaces I
> guess, to the maximum line length similar to what you say you do for
> diff lines, below.
If you will pad lines with spaces you will have to do something to make them
uncopyable.
> That makes sense. I thought about doing this at one point but never
> got around to it. I was hoping for a more clever solution, which would
> show to the width of the browser window if the browser window is much
> larger than the longest line. Maybe some CSS hackery with a span or
> div surrounding the entire line with overflow: hidden might work. It
> might be trickier to make it also work inside the diff view table
> cell.
I saw something like that, but don't remember where exactly. In any case it does
not make much sense until you make lines wrappable which are not currently.
> Good idea. Can't the user supply images though in signs? How do you
> intend to do this nicely?
I see two different possibilities:
1. Make `signs' key call a function that will save image somewhere and return
its filename.
2. Just embed image as a binary base64 encoded blob inside HTML file.
Second possibility will definitely be implemented, but maybe I will create
something like `html-splitted' with images, CSS and javascript in different
files.
> One thing I'm (very slowly) working on for a future TOhtml version is
> generating external CSS instead of inline, and also allowing automated
> unlinking of highlight groups and copying of the previously linked
> style to allow generic stylesheets to be made. This would allow
> restyling existing generated HTML by applying a new stylesheet just
> like Vim would simply apply another color scheme. It's mostly just the
> concept and notes jotted down on paper at this point. Sadly I haven't
> found much time to work on it. In a day or two I'm sending out a minor
> update with pre-wrap support and better treatment of buffers with a
> special buftype (not using fenc for these). Is external CSS at all
> supported by your plugin? I'd be interested in your solution if it is,
> but I don't see it listed on the plugin page as an extra feature.
Implementing this in my plugin is simple:
1. Purge `%:' from `begin' value (it is an atom that inserts all generated
styles).
2. Add `<link rel=stylesheet ...>' to `begin' value.
3. Replace `style' value: `%>{code}' with
`%>writefile(readfile({filename}, "b")+[{code}], {filename}, "b")'.
It won't be much useful because I use numbers as style IDs, not human-readable
names (though it is trivial to fix in specifications and even simpler to fix in
style dictionary generation code, I just don't think someone will want to edit
these).
Some questions:
1. What is `pre-wrap'?
2. What is the problem with buffers with special `buftype'? Do you have in mind
generated file name (so I won't have such problems because I don't supply any
filename at all) or something else?
Original message:
> On Apr 4, 11:02 pm, ZyX <zyx....@gmail.com> wrote:
> > Reply to message «Re: non-interactive vimdiff to stdout»,
> > sent 07:19:31 05 April 2011, Tuesday
> > by Ben Fritz:
> >
> > signature.asc
> > < 1KViewDownload
> >
> > > 1. "Normal special character coloring": what does this mean?
> >
> > That mean that special characters are highlighted with SpecialKey
> > highlighting, not with surrounding syntax group highlighting. TOHtml
> > just calls `strtrans()' in `s:HtmlFormat', it does not highlight with
> > SpecialKey.
>
> Ah yes, that would be a good thing to do. I will probably add that to
> the TOHtml todo list.
>
> > > 2. "Background color for the whole line with differencies and folds,
> > > not just for text": how is this accomplished? This sounds nice.
> >
> > If I remember correctly, it is just a style of the outer div that
> > contains the whole line. It is implemented only for html specification:
> > BBCode on unixforum does not support background colors and LaTeX
> > specification is low priority for me.
>
> I see. TOhtml does not use an element to span the whole line. Perhaps
> it should for this case. The alternative would be to pad with spaces I
> guess, to the maximum line length similar to what you say you do for
> diff lines, below.
>
> > > Item (2) above also reminded me of an annoying quirk of TOhtml, that
> > > deleted lines in a diff fill out to the width of the Vim application
> > > window or something huge like that, so that there are always
> > > horizontal scroll bars on a side-by-side diff.
> >
> > Nothing special: I just made difffiller length by default equal to length
> > of the longest line. It is overridable.
>
> That makes sense. I thought about doing this at one point but never
> got around to it. I was hoping for a more clever solution, which would
> show to the width of the browser window if the browser window is much
> larger than the longest line. Maybe some CSS hackery with a span or
> div surrounding the entire line with overflow: hidden might work. It
> might be trickier to make it also work inside the diff view table
> cell.
>
> > There are some additional items in my TODO list:
> > 2. signs support
>
> Good idea. Can't the user supply images though in signs? How do you
> intend to do this nicely?
>
> > 3. Make foldcolumn, linenr and signs columns use <input> hack so that
> > they will be uncopyable
> > (demo:http://basis.et-lab.ru/habrahabr/copy/index.html,
> > article:http://habrahabr.ru/blogs/webdev/114322/(Russian)). Unlike other
> > solutions that does not require JavaScript and does not break if lines
> > wrap.
>
> Very nice! I looked at the demo, I had no idea this was even possible.
> Do you know if there is an english version of this somewhere? I
> suppose I could try running it through google translator. But even the
> comments in the CSS in the demo are in Russian (I assume, I don't read
> the language). This will definitely go in unless it's hugely
> incompatible with some browser or another. Maybe as (yet another)
> configurable option, probably on by default. I'll look into the
> details at some point.
>
> One thing I'm (very slowly) working on for a future TOhtml version is
> generating external CSS instead of inline, and also allowing automated
> unlinking of highlight groups and copying of the previously linked
> style to allow generic stylesheets to be made. This would allow
> restyling existing generated HTML by applying a new stylesheet just
> like Vim would simply apply another color scheme. It's mostly just the
> concept and notes jotted down on paper at this point. Sadly I haven't
> found much time to work on it. In a day or two I'm sending out a minor
> update with pre-wrap support and better treatment of buffers with a
> special buftype (not using fenc for these). Is external CSS at all
> supported by your plugin? I'd be interested in your solution if it is,
> but I don't see it listed on the plugin page as an extra feature.
No comments:
Post a Comment