sent 06:22:11 06 April 2011, Wednesday
by Benjamin Fritz:
> 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.
They are now copied as displayed. It is in TODO list.
> 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!
> 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.
If you implement that <input> hack it would not wrap between the line numbers.
> 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.
I wonder why you use non-utf8 encodings at all: if one wants different encoding
it is not too difficult to add a <meta> (which is ignored unless host does not
send any encoding in HTTP headers) and do `w ++enc='.
Original message:
> On Tue, Apr 5, 2011 at 1:08 PM, ZyX <zyx.vim@gmail.com> wrote:
> >> 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.
No comments:
Post a Comment