>
>> 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.
>
Certainly this would be ideal, but the diff filler (for example) is
already copyable when ideally it should not be either. I don't know if
we can do this in all case. For example do you make 'listchars' stuff
copy as the actual character or as the substituted text? I'd rather do
a element with a background and 100% width though.
>> 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.
>
I hadn't thought of the effect of wrapping. The update I mention that
is coming soon turns on wrapping in the pre sections. I'll need to be
careful!
>> 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.
>
Yuck, I certainly would not like to include it in the HTML but I
suppose that would work. For a stand-alone email-able file it might
even be the best case.
>> 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.
>
> Some questions:
> 1. What is `pre-wrap'?
Sorry, I briefly forgot the actual property used. I'm just applying a
"white-space: pre-wrap" rule to the pre block containing the code is
all. Nothing fancy and really useful for the text files with long
lines I sometimes work with. It wraps between the line numbers and
'showbreak' doesn't apply but it is a lot better than the results from
g:html_no_pre. I actually got a patch including this from someone on
#vim but wasn't sure I wanted to include that portion at first.
> 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?
>
TOhtml uses the fileencoding of the buffer it is converting to store
the generated HTML, if set and if it can find an appropriate
IANA-approved name to use for it. Otherwise it uses encoding, or
failing that defaults to UTF-8. The problem I ran into is as follows:
1. In my .vimrc, I have "setglobal fileencoding=latin1" because most
of the files I work are code which needs to be in this encoding
2. I have encoding=utf-8 to allow fancy Unicode characters in various
options and in plugins
3. I recently started using the CCTree plugin (
http://www.vim.org/scripts/script.php?script_id=2368 ) which uses
CScope to give you a nice call tree of your C code. I wanted to
convert this to HTML to share with someone.
4. CCTree uses a new buffer with buftype=nofile, but does not bother
setting the fileencoding. Probably because with buftype=nofile, the
buffer is never intended to be written, so as long as 'encoding' can
represent the characters used, it does not matter at all.
5. Because CCTree does not set fenc, it defaults to the global value:
latin1. Therefore TOhtml tried to create an HTML file encoded as
ISO-8859-1.
6. The special Unicode characters in the CCTree cannot be converted to
latin1. I had to either regenerate with an override or edit the
...charset=... line and save in the correct encoding.
I saw this problem specifically on CCTree, but I imagine that many
other plugins act in the same way, since their buffers are never
intended to be written. So I am simply adding a check that buftype is
either blank or 'help', and if not, skipping the 'fileencoding' and
starting with 'encoding' for the HTML document.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment