Loading ...
Sorry, an error occurred while loading the content.

Progress indicator for :TOhtml command

Expand Messages
  • Benjamin Fritz
    I love using the :TOhtml command, and I keep finding more ways to use it. Recently, I had a large-ish log file (several thousand lines), in which I wanted to
    Message 1 of 14 , May 31 1:47 PM
    • 0 Attachment
      I love using the :TOhtml command, and I keep finding more ways to use
      it. Recently, I had a large-ish log file (several thousand lines), in
      which I wanted to call attention to a few groups of lines, but I
      figured people may want the context as well. So, I set up some folds
      and some quick syntax highlighting, and went to go create an html copy
      of it using the "dynamic folding" feature of the command.

      Unfortunately, I discovered that processing such a large file, even
      with no syntax highlighting, takes a *very* long time. I probably
      should have selected just a smaller area of interest but...

      I waited quite a while, and finally hit CTRL-C to stop it. Luckily it
      hadn't actually gotten that far (probably about 30%), but I was
      worried that it may have been almost done, and all I needed to do was
      wait a bit longer.

      So anyway, for future use, I wanted to be able to see quickly whether
      the conversion was worth waiting for. Therefore, I have written a
      patch to add a progress indicator. When I opened the file, I noticed
      that indentation is quite a mess (a mix of tabs and spaces, sometimes
      in the same line), so I also fixed that up (by using gg=G with noet,
      sw=2, sts=2, and ts=2). For clarity, I ran the diff on the file
      *after* fixing the ident.

      Since the indentation patch is actually *larger* than the file itself,
      I have just attached the fully patched file instead of a patch. This
      will also make it easier for Windows users to try :-)

      Please comment...especially if you know of a better way to accomplish
      something similar. I tried using :echon to draw the progress bar, but
      the echo was being cleared each time through the main loop, so I
      switched to using :echo with a string that is gradually built as the
      script processes.

      --
      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
    • Yongwei Wu
      ... I tried it on Windows, and the display was too flashy and intrusive. I can t say I like it. And there was nothing to fix about the tabs. They were
      Message 2 of 14 , May 31 8:50 PM
      • 0 Attachment
        On 1 June 2010 04:47, Benjamin Fritz <fritzophrenic@...> wrote:
        > I love using the :TOhtml command, and I keep finding more ways to use
        > it. Recently, I had a large-ish log file (several thousand lines), in
        > which I wanted to call attention to a few groups of lines, but I
        > figured people may want the context as well. So, I set up some folds
        > and some quick syntax highlighting, and went to go create an html copy
        > of it using the "dynamic folding" feature of the command.
        >
        > Unfortunately, I discovered that processing such a large file, even
        > with no syntax highlighting, takes a *very* long time. I probably
        > should have selected just a smaller area of interest but...
        >
        > I waited quite a while, and finally hit CTRL-C to stop it. Luckily it
        > hadn't actually gotten that far (probably about 30%), but I was
        > worried that it may have been almost done, and all I needed to do was
        > wait a bit longer.
        >
        > So anyway, for future use, I wanted to be able to see quickly whether
        > the conversion was worth waiting for. Therefore, I have written a
        > patch to add a progress indicator. When I opened the file, I noticed
        > that indentation is quite a mess (a mix of tabs and spaces, sometimes
        > in the same line), so I also fixed that up (by using gg=G with noet,
        > sw=2, sts=2, and ts=2). For clarity, I ran the diff on the file
        > *after* fixing the ident.
        >
        > Since the indentation patch is actually *larger* than the file itself,
        > I have just attached the fully patched file instead of a patch. This
        > will also make it easier for Windows users to try :-)
        >
        > Please comment...especially if you know of a better way to accomplish
        > something similar. I tried using :echon to draw the progress bar, but
        > the echo was being cleared each time through the main loop, so I
        > switched to using :echo with a string that is gradually built as the
        > script processes.

        I tried it on Windows, and the display was too flashy and intrusive.
        I can't say I like it.

        And there was nothing to "fix" about the tabs. They were perfectly
        fine. Tabstop was set to the default (8), and only shiftwidth was set
        to 2 (along with sts, which does not affect the saved file). You
        seemed to have confused them. The original version is easier to view
        (using type/cat/more/less or nearly anything).

        --
        Wu Yongwei
        URL: http://wyw.dcweb.cn/

        --
        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
      • Christian J. Robinson
        ... I tried it too--on Windows and on Linux--and it was flashy and unusable on both, plus about 15 to 20 percent slower than the original on both. I would be
        Message 3 of 14 , May 31 9:11 PM
        • 0 Attachment
          On Tue, 1 Jun 2010, Yongwei Wu wrote:

          > I tried it on Windows, and the display was too flashy and intrusive.
          > I can't say I like it.

          I tried it too--on Windows and on Linux--and it was flashy and
          unusable on both, plus about 15 to 20 percent slower than the original
          on both.

          I would be for having a progress meter, if it could be implemented in
          a better way without slowing the script down.

          My best suggestion is just to output one line every 5 to 10 percent
          through processing with the current progress, e.g.:

          0%
          5%
          10%
          15%
          [...]
          95%
          Done

          - Christian

          --
          Abdominos... sit-ups & pizza.
          Christian J. Robinson <heptite@...> http://christianrobinson.name/

          --
          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
        • Ben Fritz
          On May 31, 11:11 pm, Christian J. Robinson ... On May 31, 11:11 pm, Christian J. Robinson ... Hmm, strange. I did
          Message 4 of 14 , Jun 1, 2010
          • 0 Attachment
            On May 31, 11:11 pm, "Christian J. Robinson" <hept...@...>
            wrote:
            > On Tue, 1 Jun 2010, Yongwei Wu wrote:
            > > I tried it on Windows, and the display was too flashy and intrusive.
            > > I can't say I like it.


            On May 31, 11:11 pm, "Christian J. Robinson" <hept...@...>
            wrote:
            > I would be for having a progress meter, if it could be implemented in
            > a better way without slowing the script down.
            >
            > My best suggestion is just to output one line every 5 to 10 percent
            > through processing with the current progress, e.g.:
            >
            >   0%
            >   5%
            >   10%
            >   15%
            >   [...]
            >   95%
            >   Done
            >

            Hmm, strange. I did not notice a slow-down from the original script,
            but then I also set 'nomore' and fdm=manual as a way to speed things
            up a little in addition to the progress bar changes. On my dinosaur of
            a computer, processing 2html.vim took about 40 seconds LESS with the
            patched version that with the unpatched version, according to the
            before/after times returned by localtime(). What did you do to see the
            slowdown?

            I also dislike the flashiness, but couldn't find a way around it. The
            echo'd text gets cleared every pass through the main processing loop.
            For this reason, a periodic (5, 10, 20%, etc.) message wasn't going to
            work. I would certainly prefer this method...my first attempt used
            echon to display one "tick" every few lines processed (a tick being
            calculated to almost fill the current &columns setting). Does someone
            have an idea of how I might accomplish this?

            --
            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
          • Ben Fritz
            ... Hmm, interesting...and thanks! These two plugins seem to use the statusline for the progress indicator. I thought of that, and abandoned the idea when I
            Message 5 of 14 , Jun 1, 2010
            • 0 Attachment
              On Jun 1, 7:21 am, Andy Wokula <anw...@...> wrote:
              >
              > I'd suggest to try one of the existing progress bars (sorry,  didn't try
              > them myself yet):
              >
              > http://github.com/tomtom/vimtlib/blob/master/autoload/tlib/progressba...http://www.vim.org/scripts/script.php?script_id=2006
              >

              Hmm, interesting...and thanks! These two plugins seem to use the
              statusline for the progress indicator. I thought of that, and
              abandoned the idea when I noticed that the status lines weren't being
              populated all the way during processing...but later investigation
              showed me that's because 'ruler' gets reset from one of the speed-up
              options set by the plugin (I don't remember which). At the time, I was
              still hoping to use :echon to output the progress indicator, which I
              also had to abandon. My eventual goal is to use the full screen width
              (or pretty close to it) for the progress bar. Is there a good way to
              get this for an individual status line? I didn't think so, whereas
              using an ":echo" type command, &columns basically does the trick.

              I'll give it a shot using the status line (maybe making use of a
              plugin, but I'm hoping for eventual inclusion into the upstream, so
              maybe just pulling code from them). Hopefully it will be more usable.
              For me, the screen flashes quite a bit *without* the progress
              indicator, so I'm not certain it will be, but perhaps the somewhat
              static status line will be more readable than a quickly flashing
              message at the bottom of the window.

              --
              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
            • Christian J. Robinson
              ... Time elapsed about 39 seconds. ... Time elapsed about 31 seconds. So the first is over 20% slower. This morning I tried it under a vim -u NONE --noplugin
              Message 6 of 14 , Jun 1, 2010
              • 0 Attachment
                On Tue, 1 Jun 2010, Ben Fritz wrote:

                > What did you do to see the slowdown?

                In two separate Vim instances ("vim 2html.vim"--not at the same time):

                :let timestart=join(reltime(), ' ') | exe 'so ' . expand('%') | let timefinish=join(reltime(), ' ')
                :echo timestart | echo timefinish

                Time elapsed about 39 seconds.

                :let timestart=join(reltime(), ' ') | exe 'TOhtml' | let timefinish=join(reltime(), ' ')
                :echo timestart | echo timefinish

                Time elapsed about 31 seconds.

                So the first is over 20% slower.

                This morning I tried it under a "vim -u NONE --noplugin 2html.vim"
                instance and your version was actually four seconds faster than the
                original. Odd.

                I do have a fairly complex vimrc, as well as a number of plugins
                installed.

                - Christian

                --
                Christian J. Robinson <heptite@...>

                --
                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
              • Benjamin Fritz
                ... I like this look a lot better! I made a few improvements: - Change the color of StatusLineNC to match StatusLine (and restore it at the end) to reduce
                Message 7 of 14 , Jun 1, 2010
                • 0 Attachment
                  >
                  > Here is an experimental version, in which I included the essential part
                  > from the mentioned vim.org/script into the script from Ben.
                  >
                  > Bugs: - currently only works well with a big enough window.
                  > - progressbar requires redrawing the window, while processing
                  > the 2html.vim script. This means, it slows it down.
                  > - requires a +float (no check yet)
                  >

                  I like this look a lot better! I made a few improvements:

                  - Change the color of StatusLineNC to match StatusLine (and restore it at the
                  end) to reduce flashing of the statusline.
                  - Draw the progress bar in the new window instead of the original window, to
                  reduce the amout of time from the screen clear to the redraw when redrawing
                  the windows, reducing the flashing effect.
                  - Set the size of the new window to only 2 lines, so that only 1 line of the
                  buffer actually appears. The intent of this was to further reduce the flashing
                  effect, but it also has the nice side affect of making the conversion MUCH
                  faster, since less of the expensive html syntax highlighting needs to be
                  completed every redraw.
                  - Added a second progress bar for the attributes processing (previously I was
                  doing this with a %d/%d printf).
                  - Fixed bug in progress bar incr function that prevented incrementing by large
                  amounts, that are still less than the maximum value.
                  - Fixed bug where progress bar would not fill all the way when doing non-dynamic
                  folds.
                  - Fixed off-by-one error in progress bar initialization.

                  I also removed the "redrawstatus" commands. They did not seem to be necessary,
                  and only served to increase the processing time. Did you have a particular
                  reason to include them?

                  --
                  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
                • Benjamin Fritz
                  ... And one more bugfix, to prevent throwing errors in the cleanup commands at the end. With the attached script on fairly recent hardware, I get the following
                  Message 8 of 14 , Jun 1, 2010
                  • 0 Attachment
                    On Tue, Jun 1, 2010 at 6:04 PM, Benjamin Fritz <fritzophrenic@...> wrote:
                    >
                    > I like this look a lot better! I made a few improvements:
                    >

                    And one more bugfix, to prevent throwing errors in the cleanup
                    commands at the end.

                    With the attached script on fairly recent hardware, I get the
                    following timings (in seconds) when converting the 2html.vim script to
                    html, several times and discarding the first few trials (these were
                    outliers...around 100 seconds, probably while getting the cache all
                    ironed out or something):

                    with progress bar:
                    34
                    34
                    35
                    32
                    32
                    without progress bar (using let html_no_progress=1):
                    33
                    33
                    33
                    33
                    32
                    32
                    33
                    30
                    unmodified "official" script (with autocmds to set winsize and
                    foldmethod to prevent syntax highlighting to screw with the results):
                    31
                    32
                    31
                    31

                    For me anyway, the difference made by the progress bar, with the
                    optimizations in the attached version of 2html.vim, is negligible.

                    So...is the screen flashing still too distracting? I think the version
                    attached handles it well enough, at least for my purposes.

                    Any additional comments or fixes?

                    --
                    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
                  • Christian Brabandt
                    ... Yes. I can t see the progressbar otherwise. It is not updating for me. So I suggest, enabling it again. regards, Christian. -- You received this message
                    Message 9 of 14 , Jun 2, 2010
                    • 0 Attachment
                      On Wed, June 2, 2010 1:04 am, Benjamin Fritz wrote:
                      > - Added a second progress bar for the attributes processing (previously I
                      > was
                      > doing this with a %d/%d printf).
                      > I also removed the "redrawstatus" commands. They did not seem to be
                      > necessary,
                      > and only served to increase the processing time. Did you have a particular
                      > reason to include them?

                      Yes. I can't see the progressbar otherwise. It is not updating for me. So
                      I suggest, enabling it again.

                      regards,
                      Christian.



                      --
                      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
                    • Ben Fritz
                      ... Interesting. Is this true, even with the progress bar on the top window as in the latest version? If it is on the bottom, the screen clears again for a
                      Message 10 of 14 , Jun 2, 2010
                      • 0 Attachment
                        On Jun 2, 3:13 am, "Christian Brabandt" <cbli...@...> wrote:
                        > On Wed, June 2, 2010 1:04 am, Benjamin Fritz wrote:
                        > > - Added a second progress bar for the attributes processing (previously I
                        > > was
                        > >   doing this with a %d/%d printf).
                        > > I also removed the "redrawstatus" commands. They did not seem to be
                        > > necessary,
                        > > and only served to increase the processing time. Did you have a particular
                        > > reason to include them?
                        >
                        > Yes. I can't see the progressbar otherwise. It is not updating for me. So
                        > I suggest, enabling it again.
                        >

                        Interesting. Is this true, even with the progress bar on the top
                        window as in the latest version? If it is on the bottom, the screen
                        clears again for a redraw immediately after the bottom status line is
                        drawn, making it very hard to see the progress bar...which is why I
                        put it on the top.

                        I see from :help :redrawstatus,

                        Useful to update the status line(s) when 'statusline'
                        includes an item that doesn't cause automatic
                        updating.

                        But we're setting the statusline to a new (static) value...surely the
                        statusline is redrawn when 'statusline' is set to something new?

                        If we leave the progress bar on the top window (which I like...any
                        disagreements?) we need to find the appropriate place to put
                        the :redrawstatus command, so that we redraw the correct window's
                        status line. I don't think it's a great idea to use redrawstatus!,
                        although a "normal" use case is probably just the two windows, so
                        maybe it's not that much more expensive?

                        I toyed with the idea of only updating the 'statusline' option and
                        calling :redrawstatus if the progress bar has changed position in a
                        visible way, but on my system (Windows XP, gvim 7.2.437) this wasn't
                        needed.

                        On an unrelated note...should we continue this on vim_use, vim_dev, or
                        both? I original posted to both groups so that I could potentially get
                        more comments, but now it seems we're deep in developer mode.

                        --
                        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
                      • Ben Fritz
                        ... This got me thinking...so tried the following: gvim -N -u NONE -i NONE filetype indent plugin on syntax on ... I do not see the progress bars! The status
                        Message 11 of 14 , Jun 2, 2010
                        • 0 Attachment
                          On Jun 2, 8:43 am, Ben Fritz <fritzophre...@...> wrote:
                          > On Jun 2, 3:13 am, "Christian Brabandt" <cbli...@...> wrote:
                          >
                          > > On Wed, June 2, 2010 1:04 am, Benjamin Fritz wrote:
                          > > > - Added a second progress bar for the attributes processing (previously I
                          > > > was
                          > > >   doing this with a %d/%d printf).
                          > > > I also removed the "redrawstatus" commands. They did not seem to be
                          > > > necessary,
                          > > > and only served to increase the processing time. Did you have a particular
                          > > > reason to include them?
                          >
                          > > Yes. I can't see the progressbar otherwise. It is not updating for me. So
                          > > I suggest, enabling it again.
                          >
                          > Interesting. Is this true, even with the progress bar on the top
                          > window as in the latest version? If it is on the bottom, the screen
                          > clears again for a redraw immediately after the bottom status line is
                          > drawn, making it very hard to see the progress bar...which is why I
                          > put it on the top.
                          >

                          This got me thinking...so tried the following:

                          gvim -N -u NONE -i NONE
                          filetype indent plugin on
                          syntax on
                          :help intro
                          :source $HOME/vimfiles/syntax/2html.vim

                          I do not see the progress bars! The status lines never get drawn at
                          all (and the conversion is lightning fast). It appears I have
                          something in my Vim setup that slows things down enough, or redraws
                          the window, or something, that causes the status lines to appear when
                          normally they would not.

                          Any ideas? I don't see anything suspicious in my usual Buf/Win Enter/
                          Leave autocmds:


                          --- Auto-Commands ---
                          style_highlight WinEnter
                          * if !exists('w:created') | call
                          matchadd('WhitespaceError','\S\@<=\s\+\%#\@<!$') | endif
                          if &filetype=~'\v<%(c|vim|dosbatch)>' && !
                          exists('w:tabs_are_bad') | let w:tabs_are_bad =
                          matchadd('WhitespaceError',"\t") | endif
                          misc WinEnter
                          * if !exists('w:created') && &ft!='qf' | setlocal nowrap
                          | endif
                          matchparen WinEnter
                          * call s:Highlight_Matching_Pair()
                          misc WinEnter
                          * let w:created=1

                          --- Auto-Commands ---
                          insertmode WinLeave
                          * if exists('w:last_fdm') | let &l:foldmethod=w:last_fdm |
                          unlet w:last_fdm | endif

                          --- Auto-Commands ---
                          filetypedetect BufEnter
                          *.xpm if getline(1) =~ "XPM2" | setf xpm2 | else | setf
                          xpm | endif
                          *.xpm2 setf xpm2
                          misc BufEnter
                          * if (&ft=='qf' || &previewwindow || bufname('%') ==#
                          "__Tag_List__") && !exists('s:scrolloff_sav') | let
                          s:scrolloff_sav=&scrolloff | set scrolloff=0 | endif
                          repeatPlugin BufEnter
                          * if g:repeat_tick == 0|let g:repeat_tick = b:changedtick|
                          endif
                          FileExplorer BufEnter
                          * silent! call s:LocalBrowse(expand("<amatch>"))
                          .* silent! call s:LocalBrowse(expand("<amatch>"))
                          BufEnter
                          *.vba setlocal bt=nofile fmr=[[[,]]] fdm=marker|if &ff !=
                          'unix'| setlocal ma ff=unix noma |endif|call
                          vimball#ShowMesg(0,"Source this file to extract it! (:so %)")
                          *.vba.gz setlocal bt=nofile fmr=[[[,]]] fdm=marker|if &ff !=
                          'unix'| setlocal ma ff=unix noma |endif|call
                          vimball#ShowMesg(0,"Source this file to extract it! (:so %)")
                          *.vba.bz2 setlocal bt=nofile fmr=[[[,]]] fdm=marker|if &ff !=
                          'unix'| setlocal ma ff=unix noma |endif|call
                          vimball#ShowMesg(0,"Source this file to extract it! (:so %)")
                          *.vba.zip setlocal bt=nofile fmr=[[[,]]] fdm=marker|if &ff !=
                          'unix'| setlocal ma ff=unix noma |endif|call
                          vimball#ShowMesg(0,"Source this file to extract it! (:so %)")

                          --- Auto-Commands ---
                          misc BufLeave
                          * if (&ft=='qf' || &previewwindow || bufname('%') ==#
                          "__Tag_List__") && exists('s:scrolloff_sav') | let
                          &scrolloff=s:scrolloff_sav | unlet s:scrolloff_sav | endif
                          repeatPlugin BufLeave
                          * let g:repeat_tick = (g:repeat_tick == b:changedtick ||
                          g:repeat_tick == 0) ? 0 : -1

                          --
                          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
                        • David Fishburn
                          ... ... I have a plugin (WhatsMissing) which flips repeatedly back and forth between different buffers. To address my issues with slow performance I changed
                          Message 12 of 14 , Jun 2, 2010
                          • 0 Attachment
                            On 02/06/2010 9:55 AM, Ben Fritz wrote:
                            >
                            > On Jun 2, 8:43 am, Ben Fritz<fritzophre...@...> wrote:
                            >
                            >> On Jun 2, 3:13 am, "Christian Brabandt"<cbli...@...> wrote:
                            >>
                            >>
                            >>> On Wed, June 2, 2010 1:04 am, Benjamin Fritz wrote:
                            >>>
                            >>>> - Added a second progress bar for the attributes processing (previously I
                            >>>> was
                            >>>> doing this with a %d/%d printf).
                            >>>> I also removed the "redrawstatus" commands. They did not seem to be
                            >>>> necessary,
                            >>>> and only served to increase the processing time. Did you have a particular
                            >>>> reason to include them?
                            >>>>
                            >>
                            >>> Yes. I can't see the progressbar otherwise. It is not updating for me. So
                            >>> I suggest, enabling it again.
                            >>>
                            >> Interesting. Is this true, even with the progress bar on the top
                            >> window as in the latest version? If it is on the bottom, the screen
                            >> clears again for a redraw immediately after the bottom status line is
                            >> drawn, making it very hard to see the progress bar...which is why I
                            >> put it on the top.
                            >>
                            >>
                            > This got me thinking...so tried the following:
                            >
                            > gvim -N -u NONE -i NONE
                            > filetype indent plugin on
                            > syntax on
                            > :help intro
                            > :source $HOME/vimfiles/syntax/2html.vim
                            >
                            > I do not see the progress bars! The status lines never get drawn at
                            > all (and the conversion is lightning fast). It appears I have
                            > something in my Vim setup that slows things down enough, or redraws
                            > the window, or something, that causes the status lines to appear when
                            > normally they would not.
                            >
                            > Any ideas? I don't see anything suspicious in my usual Buf/Win Enter/
                            > Leave autocmds:
                            >
                            >
                            ...

                            I have a plugin (WhatsMissing) which flips repeatedly back and forth
                            between different buffers.
                            To address my issues with slow performance I changed the function to do
                            this:

                            let l:old_eventignore = &eventignore
                            set eventignore+=BufNewFile,BufReadPre,BufRead,BufReadPost,BufReadCmd
                            set eventignore+=BufFilePre,BufFilePost,FileReadPre,FileReadPost
                            set
                            eventignore+=FileReadCmd,FilterReadPre,FilterReadPost,FileType,Syntax
                            set eventignore+=StdinReadPre,StdinReadPost,BufWrite,BufWritePre
                            set eventignore+=BufWritePost,BufWriteCmd,FileWritePre,FileWritePost
                            set
                            eventignore+=FileWriteCmd,FileAppendPre,FileAppendPost,FileAppendCmd
                            set eventignore+=FilterWritePre,FilterWritePost,FileChangedShell
                            set eventignore+=FileChangedRO,FocusGained,FocusLost,FuncUndefined
                            set eventignore+=CursorHold,BufEnter,BufLeave,BufWinEnter,BufWinLeave
                            set eventignore+=BufUnload,BufHidden,BufNew,BufAdd,BufCreate,BufDelete
                            set eventignore+=BufWipeout,WinEnter,WinLeave,CmdwinEnter,CmdwinLeave
                            set eventignore+=GUIEnter,VimEnter,VimLeavePre,VimLeave,EncodingChanged
                            set eventignore+=FileEncoding,RemoteReply,TermChanged,TermResponse,User

                            something ...

                            Then restored the &eventignore when complete.

                            The performance was dramatic.

                            Perhaps you could put that in yours and see what you get.

                            Dave

                            --
                            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
                          • Benjamin Fritz
                            ... Found it. I have the following in my .vimrc: Highlight trailing whitespace, unless it is being entered now autocmd WinEnter,VimEnter * if
                            Message 13 of 14 , Jun 2, 2010
                            • 0 Attachment
                              On Wed, Jun 2, 2010 at 8:55 AM, Ben Fritz <fritzophrenic@...> wrote:
                              > It appears I have
                              > something in my Vim setup that slows things down enough, or redraws
                              > the window, or something, that causes the status lines to appear when
                              > normally they would not.
                              >
                              > Any ideas? I don't see anything suspicious in my usual Buf/Win Enter/
                              > Leave autocmds:
                              >

                              Found it. I have the following in my .vimrc:

                              " Highlight trailing whitespace, unless it is being entered now
                              autocmd WinEnter,VimEnter *
                              \ if !exists('w:created') |
                              \ call matchadd('WhitespaceError','\S\@<=\s\+\%#\@<!$') |
                              \ endif
                              " necessary to have it highlight a just-entered trailing space
                              autocmd InsertLeave * redraw!

                              The InsertLeave command is triggering because 2html works using
                              normal! a... commands. I have the autocmd because of the following
                              text in :help /\%# :

                              WARNING: When the cursor is moved after the pattern was used, the
                              result becomes invalid. Vim doesn't automatically update the matches.
                              This is especially relevant for syntax highlighting and 'hlsearch'.
                              In other words: When the cursor moves the display isn't updated for
                              this change. An update is done for lines which are changed (the whole
                              line is updated) or when using the |CTRL-L| command (the whole screen
                              is updated).

                              So anyway, it looks like we need to do the redrawstatus. It would be
                              easiest to just use redrawstatus! right after calling the incr
                              function. I wonder how much of a performance impact this has? If it is
                              significant, we should probably call it only sometimes, perhaps after
                              a progress bar position update (which would mean the number of
                              processed lines would not be updated in real-time on large files). Any
                              thoughts/input?

                              It appears we also need to ignore some events; at least BufEnter,
                              WinEnter, InsertEnter, BufLeave, WinLeave, and InsertLeave. Syntax
                              seems like a good idea as well, but then we'd want to do the syntax
                              highlight when done, so perhaps we can leave this one in. Thoughts on
                              this? Is this really needed as part of the same patch or would this be
                              a future, performance-enhancing-only, patch?

                              --
                              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
                            • Benjamin Fritz
                              ... Very nice. This is a huge performance boost, and the times are similar with and without the progress bar even with my big 33000 line C file which I used
                              Message 14 of 14 , Jun 7, 2010
                              • 0 Attachment
                                On Sun, Jun 6, 2010 at 5:10 AM, ZyX <zyx.vim@...> wrote:
                                >
                                > Yes, buffer switching is the problem: attached patch uses my technique (save
                                > everything in a list, not in a buffer) and here are the results:
                                >
                                > My script:
                                > 1:05,09 w/o progress
                                > 1:08,40 ShowProgress=1
                                > 1:20,59 ShowProgress=2
                                > Your 2html:
                                > 1:19,67 w/o progress
                                > 1:44,74 with progress
                                > Patched 2html:
                                > 1:03,51 w/o progress
                                > 1:05,08 with progress
                                >

                                Very nice. This is a huge performance boost, and the times are similar
                                with and without the progress bar even with my big 33000 line C file
                                which I used previously.

                                I think it's about ready now. I've added another progress bar for the
                                time taken to collect fold information for dynamic folding, and
                                corrected a few minor bugs in the patch related to dynamic folding. I
                                did end up adding back in a :sleep to the class processing loop, but I
                                reduced the time it sleeps. I'm certainly open to removing this.

                                I've attached the whole file so we don't get into a "which patches do
                                I need?" quagmire.

                                --
                                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
                              Your message has been successfully submitted and would be delivered to recipients shortly.