Re: VimDiff printing - close but no cigar

447 views
Skip to first unread message

Philip Rhoades

unread,
Oct 12, 2012, 7:02:47 AM10/12/12
to vim...@googlegroups.com
Ben,


On 2012-10-11 02:51, Ben Fritz wrote:
> On Wednesday, October 10, 2012 10:51:09 AM UTC-5, Philip Rhoades
> wrote:
>> People,
>>
>>
>> I love Vim and VimDiff is perfect for nearly all my diff needs -
>> however I need a script/method now that will produce a PS or PDF
>> file
>> from the vimdiff comparison. I tried printing to Cups-PDF but of
>> course
>> I just get the individual files printed - not what I am seeing on
>> the
>> screen . . is there a way to print the nice screen stuff? For some
>> comparisons a screen capture would work but that is clumsy and does
>> not
>> cover the situation when the comparison is more than one screen of
>> stuff.
>>
>>
>
> Recent version of TOhtml will convert a side-by-side diff into HTML
> as you would expect. You can event tell it to use javascript to allow
> showing/hiding context. See :help :TOhtml.
>
> Probably you can then print the resulting HTML file to get your final
> desired result.


The problem is that the files contain long lines - after the HTML
conversion, the long lines in the browser are viewable by using the
scroll bars at the bottom of each panel but when printed, the lines are
truncated ie only the stuff on the screen with the scroll bars at hard
left are printed.

Thanks,

Phil.
--
Philip Rhoades

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: ph...@pricom.com.au

Ben Fritz

unread,
Oct 12, 2012, 10:56:36 AM10/12/12
to vim...@googlegroups.com, ph...@pricom.com.au
Oh yuck. I don't know of a good way around that. Either you accept truncated lines, or you turn on word wrapping and risk a misaligned diff. If you're lucky the diff will still align correctly and the word wrapping will solve your problem. Try converting again after doing a ":let g:html_pre_wrap=1". Normally it defaults to the same value as your 'wrap' option, which is off for good reason during a diff, but this will force it on.

Philip Rhoades

unread,
Oct 12, 2012, 12:15:39 PM10/12/12
to vim...@googlegroups.com, Ben Fritz
Ben,


On 2012-10-13 01:56, Ben Fritz wrote:
> On Friday, October 12, 2012 6:02:57 AM UTC-5, Philip Rhoades wrote:
>>
>> On 2012-10-11 02:51, Ben Fritz wrote:
>> >
>> > Recent version of TOhtml will convert a side-by-side diff into
>> HTML
>> > as you would expect. You can event tell it to use javascript to
>> allow
>> > showing/hiding context. See :help :TOhtml.
>> >
>> > Probably you can then print the resulting HTML file to get your
>> final
>> > desired result.
>>
>> The problem is that the files contain long lines - after the HTML
>> conversion, the long lines in the browser are viewable by using the
>> scroll bars at the bottom of each panel but when printed, the lines
>> are
>> truncated ie only the stuff on the screen with the scroll bars at
>> hard
>> left are printed.
>>
>
> Oh yuck. I don't know of a good way around that. Either you accept
> truncated lines, or you turn on word wrapping and risk a misaligned
> diff. If you're lucky the diff will still align correctly and the
> word
> wrapping will solve your problem.


I should have said - I did try that but the output in html is still
long lines.


> Try converting again after doing a
> ":let g:html_pre_wrap=1". Normally it defaults to the same value as
> your 'wrap' option, which is off for good reason during a diff, but
> this will force it on.


I still get long lines in the output . .

Ben Fritz

unread,
Oct 12, 2012, 1:13:04 PM10/12/12
to vim...@googlegroups.com, ph...@pricom.com.au
On Friday, October 12, 2012 11:15:51 AM UTC-5, Philip Rhoades wrote:
> >>
> >> The problem is that the files contain long lines - after the HTML
> >> conversion, the long lines in the browser are viewable by using the
> >> scroll bars at the bottom of each panel but when printed, the lines
> >> are
> >> truncated ie only the stuff on the screen with the scroll bars at
> >> hard
> >> left are printed.
> >>
> >
> > Oh yuck. I don't know of a good way around that. Either you accept
> > truncated lines, or you turn on word wrapping and risk a misaligned
> > diff. If you're lucky the diff will still align correctly and the
> > word
> > wrapping will solve your problem.
>
> I should have said - I did try that but the output in html is still
> long lines.
>
> > Try converting again after doing a
> > ":let g:html_pre_wrap=1". Normally it defaults to the same value as
> > your 'wrap' option, which is off for good reason during a diff, but
> > this will force it on.
>
> I still get long lines in the output . .
>

If by "long lines in the output" you mean, you printed from your browser, and lines got truncated rather than wrapped, this is very surprising. This is a very simple feature and should work.

I just tested with a diff HTML file generated by Vim with long lines in the file.

On Opera, the print preview shows wrapped lines regardless of the html_pre_wrap setting. In IE8 and Chrome, without html_pre_wrap, the long lines are truncated. With html_pre_wrap, the lines wrap as expected.

What are you seeing? Can you attach some sample output, or at least the <meta> lines in the generated output? What version of what browser are you printing from?

Philip Rhoades

unread,
Oct 12, 2012, 3:30:18 PM10/12/12
to vim...@googlegroups.com, fritzo...@gmail.com
Ben,
I do:

vimdiff file1.txt file2.txt
:se wrap
CTRL-w-w
:se wrap
:let g:html_pre_wrap=1
:TOhtml
ENTER
:w t.html
:q!
:q!
:q!
google-chrome ./t.html

but the long lines are still long and I have to use the scroll bars to
see the rest of the lines and when printed the lines are truncated after
the first ~80 chars.


> I just tested with a diff HTML file generated by Vim with long lines
> in the file.
>
> On Opera, the print preview shows wrapped lines regardless of the
> html_pre_wrap setting. In IE8 and Chrome, without html_pre_wrap, the
> long lines are truncated. With html_pre_wrap, the lines wrap as
> expected.


?? Am I doing something wrong above?


> What are you seeing? Can you attach some sample output, or at least
> the <meta> lines in the generated output?


<meta http-equiv="content-type" content="text/html;
charset=iso-8859-1">
<title>diff</title>
<meta name="Generator" content="Vim/7.3">
<meta name="plugin-version" content="vim7.3_v6">
<meta name="settings" content="use_css,whole_filler">


> What version of what browser
> are you printing from?


google-chrome-stable-18.0.1025.162-131933.x86_64

Ben Fritz

unread,
Oct 12, 2012, 3:45:49 PM10/12/12
to vim...@googlegroups.com, fritzo...@gmail.com, ph...@pricom.com.au
On Friday, October 12, 2012 2:30:29 PM UTC-5, Philip Rhoades wrote:
>
> > What are you seeing? Can you attach some sample output, or at least
> > the <meta> lines in the generated output?
>
> <meta http-equiv="content-type" content="text/html;
> charset=iso-8859-1">
> <title>diff</title>
> <meta name="Generator" content="Vim/7.3">
> <meta name="plugin-version" content="vim7.3_v6">
> <meta name="settings" content="use_css,whole_filler">
>

This explains it, thanks.

You're missing several updates to the TOhtml plugin, including the version which adds html_pre_wrap:

" 7.3_v12 (this version): Fix modeline mangling to also work for when multiple
" highlight groups make up the start-of-modeline text.
" Improve render time of page with uncopyable regions
" by not using one-input-per-char. Change name of
" uncopyable option from html_unselectable to
" html_prevent_copy. Added html_no_invalid option and
" default to inserting invalid markup for uncopyable
" regions to prevent MS Word from pasting undeletable
" <input> elements. Fix 'cpo' handling (Thilo Six).
" 7.3_v12b1: Add html_unselectable option. Rework logic to
" eliminate post-processing substitute commands in
" favor of doing the work up front. Remove unnecessary
" special treatment of 'LineNr' highlight group. Minor
" speed improvements. Fix modeline mangling in
" generated output so it works for text in the first
" column. Fix missing line number and fold column in
" diff filler lines. Fix that some fonts have a 1px
" gap (using a dirty hack, improvements welcome). Add
" "colorscheme" meta tag. Does NOT include support for
" the new default foldtext added in v11, as the patch
" adding it has not yet been included in Vim.
" 7.3_v11 ( unreleased ): Support new default foldtext from patch by Christian
" Brabandt in
" http://groups.google.com/d/topic/vim_dev/B6FSGfq9VoI/discussion.
" This patch has not yet been included in Vim, thus
" these changes are removed in the next version.
" 7.3_v10 (fd09a9c8468e): Fix error E684 when converting a range wholly inside
" multiple nested folds with dynamic folding on.
" Also fix problem with foldtext in this situation.
" 7.3_v9 (0877b8d6370e): Add html_pre_wrap option active with html_use_css
" and without html_no_pre, default value same as
" 'wrap' option, (Andy Spencer). Don't use
" 'fileencoding' for converted document encoding if
" 'buftype' indicates a special buffer which isn't
" written.
" 7.3_v8 (85c5a72551e2): Add html_expand_tabs option to allow leaving tab
" characters in generated output (Andy Spencer).
" Escape text that looks like a modeline so Vim
" doesn't use anything in the converted HTML as a
" modeline. Bugfixes: Fix folding when a fold starts
" before the conversion range. Remove fold column when
" there are no folds.
" 7.3_v7 (840c3cadb842): see betas released on vim_dev below:
" 7.3_v7b3: Fixed bug, convert Unicode to UTF-8 all the way.
" 7.3_v7b2: Remove automatic detection of encodings that are not
" supported by all major browsers according to
" http://wiki.whatwg.org/wiki/Web_Encodings and
" convert to UTF-8 for all Unicode encodings. Make
" HTML encoding to Vim encoding detection be
" case-insensitive for built-in pairs.
" 7.3_v7b1: Remove use of setwinvar() function which cannot be
" called in restricted mode (Andy Spencer). Use
" 'fencoding' instead of 'encoding' to determine by
" charset, and make sure the 'fenc' of the generated
" file matches its indicated charset. Add charsets for
" all of Vim's natively supported encodings.

You can fix it in three different ways:

1. Install the latest Vim (probably from source) including the latest runtime file updates.
2. Get the latest runtime files for just TOhtml and stick them in ~/.vim to override the old ones in your distribution (just remember to remove them when you upgrade you distribution). They are intended to work with older Vims as well. You will need:
http://code.google.com/p/vim/source/browse/runtime/autoload/tohtml.vim
http://code.google.com/p/vim/source/browse/runtime/plugin/tohtml.vim
http://code.google.com/p/vim/source/browse/runtime/syntax/2html.vim
and optionally (for the documentation):
http://code.google.com/p/vim/source/browse/runtime/doc/syntax.txt
3. Use the html_no_pre option instead of html_pre_wrap. This will remove the <pre> tag from the output, which will allow text wrapping. But it can also cause it to not look as nice. With an appropriate colorscheme and font, it should not be too much of a problem.

ping

unread,
Mar 21, 2013, 9:14:03 AM3/21/13
to vim...@googlegroups.com, Ben Fritz, ph...@pricom.com.au
sorry to bring this old thread back.
but looks I just find a new issue (maybe old/known?), this is reproducible:
if the 2 buffer in vimdiff haven't been saved to files yet, the
converted html output are the same one in the 2 panels -- they are just
2 copies of one of the files.
but if I save the 2 buffers into files, then it's perfectly OK.
I can provide an example file if required to check the issue...

regards
ping

Ben Fritz

unread,
Mar 21, 2013, 11:07:06 AM3/21/13
to vim...@googlegroups.com, Ben Fritz, ph...@pricom.com.au

Thanks, I've reproduced it. This is a bug unrelated to the original post, please create a new thread if you find more.

Christian Brabandt

unread,
Mar 21, 2013, 4:10:14 PM3/21/13
to vim...@googlegroups.com
Hi Ben!
I think, this patch fixes it:
diff --git a/runtime/syntax/2html.vim b/runtime/syntax/2html.vim
--- a/runtime/syntax/2html.vim
+++ b/runtime/syntax/2html.vim
@@ -607,7 +607,7 @@
let s:orgbufnr = winbufnr(0)
let s:origwin_stl = &l:stl
if expand("%") == ""
- exec 'new Untitled.'.(s:settings.use_xhtml ? 'x' : '').'html'
+ exec 'new +enew Untitled.'.(s:settings.use_xhtml ? 'x' : '').'html'
else
exec 'new %.'.(s:settings.use_xhtml ? 'x' : '').'html'
endif


regards,
Christian
--
Letzte Worte eines Architekten:
"Da f�llt mir noch was ein."

Ben Fritz

unread,
Mar 22, 2013, 11:16:41 AM3/22/13
to vim...@googlegroups.com

On Thursday, March 21, 2013 3:10:14 PM UTC-5, Christian Brabandt wrote:
> Hi Ben!
>
> On Do, 21 M�r 2013, Ben Fritz wrote:
>
> > On Thursday, March 21, 2013 8:14:03 AM UTC-5, ping wrote:
> > > but looks I just find a new issue (maybe old/known?), this is reproducible:
> > >
> > > if the 2 buffer in vimdiff haven't been saved to files yet, the
> > > converted html output are the same one in the 2 panels -- they are just
> > > 2 copies of one of the files.
> > > but if I save the 2 buffers into files, then it's perfectly OK.
> > >
> >
> > Thanks, I've reproduced it. This is a bug unrelated to the original post,
> > please create a new thread if you find more.
> >
>
> I think, this patch fixes it:
>
> diff --git a/runtime/syntax/2html.vim b/runtime/syntax/2html.vim
> --- a/runtime/syntax/2html.vim
> +++ b/runtime/syntax/2html.vim
> @@ -607,7 +607,7 @@
> let s:orgbufnr = winbufnr(0)
> let s:origwin_stl = &l:stl
> if expand("%") == ""
> - exec 'new Untitled.'.(s:settings.use_xhtml ? 'x' : '').'html'
> + exec 'new +enew Untitled.'.(s:settings.use_xhtml ? 'x' : '').'html'
> else
> exec 'new %.'.(s:settings.use_xhtml ? 'x' : '').'html'
> endif
>

Thanks, Christian! This should fix it for diff mode, but for single file
conversions now the converted buffer will not have a name. We need to find a
unique buffer name instead of always using "Untitled.html", at least during
converting files in diff mode.

Now that you found the problem, I think the better solution would be to add a
number or something to the buffer name when converting untitled buffers. Since
the problem only occurs in diff mode I think we could make use of
g:html_diff_win_num to make sure it is unique across diff buffers without
requiring complicated logic to find an unused buffer name.

If somebody wants to come up with something to find an unused buffer name,
that's fine too. That would fix that if you happen to be editing a file called
Untitled.html in the current directory already, :TOhtml on an unnamed buffer
will wipe out the existing buffer. But I don't think this is common enough to
spend a lot of effort on a fix.
Reply all
Reply to author
Forward
0 new messages