Re: non-interactive vimdiff to stdout

Reply to message «Re: non-interactive vimdiff to stdout»,
sent 18:14:22 04 June 2011, Saturday
by ZyX:

Signs are also implemented now, including icons.

Original message:
> Reply to message «Re: non-interactive vimdiff to stdout»,
> 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.h
> tml (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.