sent 09:13:30 03 June 2011, Friday
by ZyX:
If you are interested, <input> hack is now implemented in frawor-port branch:
http://formatvim.hg.sourceforge.net/hgweb/formatvim/formatvim/file/frawor-port.
Lots of examples are in *.ok files in directory «test/» (you should see those
that have -r1, -n1 or -oN where N>=1).
Live examples have urls like
http://formatvim.sourceforge.net/concealed.tex_C0-D0-F0-L0-c0-l_q_q-n0-r1.html
(created using
zmv -C '(*).ok' 'outs/${${${${${1//_/__}//\%/_}//$/_d}//!/_b}//>/_g}.html'
scp outs/*.html \
zyxsf,formatvim@frs.sourceforge.net:/home/groups/f/fo/formatvim/htdocs
: here following replacement are done:
_ -> __, % -> _, $ -> _d, ! -> _b, > -> _g).
It is not guaranteed that live examples were created using latest revision.
Original message:
> Reply to message «Re: non-interactive vimdiff to stdout»,
> 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