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

undercurl (spelling), scrolling speed

Expand Messages
  • georgeharker@googlemail.com
    Hi Björn, I noticed that the spelling undercurl was very tight to the baseline of the text (and hence mostly invisible most of the time). I tweaked that
    Message 1 of 15 , Oct 4, 2007
    • 0 Attachment
      Hi Björn,

      I noticed that the spelling undercurl was very tight to the baseline
      of the text (and hence mostly invisible most of the time). I tweaked
      that code, and put a baseline offset of 2 in place - this seems to do
      the right thing with different text sizes etc.

      I also took a look at the scrolling (insertLines and deleteLines)
      routines which I figured could be made a little faster in the case
      where width=maxColumns are being scrolled. In this case, some faster
      manipulation is possible. This seems to improve scrolling speed for
      me (though I still get quite a few updates for a very fast scroll).
      Perhaps a throttle on the scroll wheel events might actually make this
      feel faster. At any rate, the tweak (which only matters when in full-
      column scrolling) seems to make things smoother for me.

      The patch is here:

      http://george-graphics.co.uk/macvim-undercurl-scroll.patch

      Cheers

      George


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Nico Weber
      ... About drawing speed: I m having the impression that if you tell a NSTextView to redraw a line, it also redraws all lines below it (because if descenders in
      Message 2 of 15 , Oct 4, 2007
      • 0 Attachment
        > I also took a look at the scrolling (insertLines and deleteLines)
        > routines which I figured could be made a little faster in the case
        > where width=maxColumns are being scrolled. In this case, some faster
        > manipulation is possible. This seems to improve scrolling speed for
        > me (though I still get quite a few updates for a very fast scroll).
        > Perhaps a throttle on the scroll wheel events might actually make this
        > feel faster. At any rate, the tweak (which only matters when in full-
        > column scrolling) seems to make things smoother for me.

        About drawing speed: I'm having the impression that if you tell a
        NSTextView to redraw a line, it also redraws all lines below it
        (because if descenders in letters like 'g' I guess). I guess vim
        tells the NSTextView to redraw each line of text one at a time,
        causing n lines to be redrawn for the first, n-1 for the 2nd, ...,
        yielding .5*n*(n+1) \approx n^2 redraws (where n is the number of
        visible lines). That's *just a guess*, though. This could be fixed by
        letting vim send a "redraw a whole bunch of lines" message -- I don't
        know how involved this would be either).

        Nico

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • georgeharker@googlemail.com
        This may well be true - but I think because of the way vim drives updates, you re pretty much guaranteed to redraw large chunks of the screen with the current
        Message 3 of 15 , Oct 4, 2007
        • 0 Attachment
          This may well be true - but I think because of the way vim drives
          updates, you're pretty much guaranteed to redraw large chunks of the
          screen with the current scheme. Scrolling for example needs either a
          scroll rect on the screen, or to redraw the affected lines..

          To be honest, when I ran MacVim under Shark, the majority of the time
          was spent in mach_send_port and recieve_port calls - so it looks like
          the IPC was the costly part.

          Cheers

          George

          On Oct 4, 8:52 am, Nico Weber <nicolaswe...@...> wrote:
          > > I also took a look at the scrolling (insertLines and deleteLines)
          > > routines which I figured could be made a little faster in the case
          > > where width=maxColumns are being scrolled. In this case, some faster
          > > manipulation is possible. This seems to improve scrolling speed for
          > > me (though I still get quite a few updates for a very fast scroll).
          > > Perhaps a throttle on the scroll wheel events might actually make this
          > > feel faster. At any rate, the tweak (which only matters when in full-
          > > column scrolling) seems to make things smoother for me.
          >
          > About drawing speed: I'm having the impression that if you tell a
          > NSTextView to redraw a line, it also redraws all lines below it
          > (because if descenders in letters like 'g' I guess). I guess vim
          > tells the NSTextView to redraw each line of text one at a time,
          > causing n lines to be redrawn for the first, n-1 for the 2nd, ...,
          > yielding .5*n*(n+1) \approx n^2 redraws (where n is the number of
          > visible lines). That's *just a guess*, though. This could be fixed by
          > letting vim send a "redraw a whole bunch of lines" message -- I don't
          > know how involved this would be either).
          >
          > Nico


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • björn
          Hi George, I ll take a look at your patch soon (I am busy at the moment though, as I mentioned in another thread). ... It is nice that you looked in to this.
          Message 4 of 15 , Oct 4, 2007
          • 0 Attachment
            Hi George,

            I'll take a look at your patch soon (I am busy at the moment though,
            as I mentioned in another thread).

            > > > I also took a look at the scrolling (insertLines and deleteLines)
            > > > routines which I figured could be made a little faster in the case
            > > > where width=maxColumns are being scrolled. In this case, some faster
            > > > manipulation is possible. This seems to improve scrolling speed for
            > > > me (though I still get quite a few updates for a very fast scroll).
            > > > Perhaps a throttle on the scroll wheel events might actually make this
            > > > feel faster. At any rate, the tweak (which only matters when in full-
            > > > column scrolling) seems to make things smoother for me.

            It is nice that you looked in to this. However, when Jiang finishes
            merging his drawing code all the MMTextStorage stuff will become
            extinct, so you probably shouldn't worry too much about that stuff at
            the moment.


            > > About drawing speed: I'm having the impression that if you tell a
            > > NSTextView to redraw a line, it also redraws all lines below it
            > > (because if descenders in letters like 'g' I guess). I guess vim
            > > tells the NSTextView to redraw each line of text one at a time,
            > > causing n lines to be redrawn for the first, n-1 for the 2nd, ...,
            > > yielding .5*n*(n+1) \approx n^2 redraws (where n is the number of
            > > visible lines). That's *just a guess*, though. This could be fixed by
            > > letting vim send a "redraw a whole bunch of lines" message -- I don't
            > > know how involved this would be either).

            I don't want to get into a guessing argument, but I doubt that
            NSTextView is that badly optimized. It seems that the biggest problem
            with NSTextView is that it gets really sluggish when you start adding
            color (as in syntax highlighting).

            As for the "fix"...MacVim does batch draw stuff at the moment so this
            that part of the code is about as optimized as it will ever get. (Or
            did I misinterpret your idea?)


            > To be honest, when I ran MacVim under Shark, the majority of the time
            > was spent in mach_send_port and recieve_port calls - so it looks like
            > the IPC was the costly part.

            Hmmm...interesting. Last time I did some profiling a lot of the time
            was spent inside the Cocoa text drawing routines, and in Vim's syntax
            highlighting routines. (Though I have to admit that I'm not used to
            Apple's profiling tools yet.)


            /Björn

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Brian McKee
            ... Just a +1 for the concept - I ve noticed the too tight undercurl too. Brian --~--~---------~--~----~------------~-------~--~----~ You received this message
            Message 5 of 15 , Oct 4, 2007
            • 0 Attachment
              On 04/10/2007, georgeharker@... <georgeharker@...> wrote:
              >
              > Hi Björn,
              >
              > I noticed that the spelling undercurl was very tight to the baseline
              > of the text (and hence mostly invisible most of the time). I tweaked
              > that code, and put a baseline offset of 2 in place - this seems to do
              > the right thing with different text sizes etc.

              Just a +1 for the concept - I've noticed the too tight undercurl too.

              Brian

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Nico Weber
              ... As far as I understand, the batch drawing your talking about means sending several drawing commands in one chunk. Still, each drawing command is sent to
              Message 6 of 15 , Oct 5, 2007
              • 0 Attachment
                >>> About drawing speed: I'm having the impression that if you tell a
                >>> NSTextView to redraw a line, it also redraws all lines below it
                >>> (because if descenders in letters like 'g' I guess). I guess vim
                >>> tells the NSTextView to redraw each line of text one at a time,
                >>> causing n lines to be redrawn for the first, n-1 for the 2nd, ...,
                >>> yielding .5*n*(n+1) \approx n^2 redraws (where n is the number of
                >>> visible lines). That's *just a guess*, though. This could be
                >>> fixed by
                >>> letting vim send a "redraw a whole bunch of lines" message -- I
                >>> don't
                >>> know how involved this would be either).
                >
                > I don't want to get into a guessing argument, but I doubt that
                > NSTextView is that badly optimized. It seems that the biggest problem
                > with NSTextView is that it gets really sluggish when you start adding
                > color (as in syntax highlighting).
                >
                > As for the "fix"...MacVim does batch draw stuff at the moment so this
                > that part of the code is about as optimized as it will ever get. (Or
                > did I misinterpret your idea?)

                As far as I understand, the batch drawing your talking about means
                sending several drawing commands in one chunk. Still, each drawing
                command is sent to the text storage in isolation, and as far as I
                understand the code, each ReplaceStringDrawType message causes the
                text view to be redrawn. I have no idea how the text system works,
                but perhaps it's possible to send only a single edited: message at
                the end, or to prevent that edited: calls processEditing directly
                after each changed line.

                If you set MM_DEBUG_DRAWING to 1 and do `:set gcr=a:blinkon0`, you'll
                see that you get a ReplaceStringDrawType message for each mono-
                colored string. If syntax is off, that's one string per line. If
                syntax is on, this can be a lot, and as far as I understand code and
                documentation (mainly for `edited:range:changeInLength:`) the text
                view is redrawn after each of these messages.

                But it's still only guessing ;-)

                Nico

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • georgeharker@googlemail.com
                Given that the text stuff may be rewritten, I ll not spend much time on that. However, I think it s actually not too bad efficiency wise. The most costly ops
                Message 7 of 15 , Oct 5, 2007
                • 0 Attachment
                  Given that the text stuff may be rewritten, I'll not spend much time
                  on that. However, I think it's actually not too bad efficiency wise.
                  The most costly ops will be scrolling / where large portions of the
                  screen must be redrawn.

                  The way NSView / MMTextStorage works, you tell it which ranges you
                  have edited, and the collation of these will be drawn next event
                  dispatch (I believe).

                  I did some progiling again (use All Thread States in Shark.app) and
                  80% is spent in the mach messaging. This actually can be cut down.
                  There seems to be a 10-20% saving if the queue NSArray is changed to
                  be bycopy. This is against the modification I posted above, with
                  scrolling up and down using the wheel / trackpad (which seems to be
                  the most expensive op).

                  There is also an improvement in responsivity if the queue is flushed
                  if drawData > say 40*80 or some such other metric.

                  But I really do think it's worth looking at that part before looking
                  to gain efficiency from the text routines, which I don't think are
                  that bad anyway.

                  Cheers

                  George

                  On Oct 4, 6:27 pm, "Brian McKee" <brian.mc...@...> wrote:
                  > On 04/10/2007, georgehar...@... <georgehar...@...> wrote:
                  >
                  >
                  >
                  > > Hi Björn,
                  >
                  > > I noticed that the spelling undercurl was very tight to the baseline
                  > > of the text (and hence mostly invisible most of the time). I tweaked
                  > > that code, and put a baseline offset of 2 in place - this seems to do
                  > > the right thing with different text sizes etc.
                  >
                  > Just a +1 for the concept - I've noticed the too tight undercurl too.
                  >
                  > Brian


                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • björn
                  ... Ok, I understand you now. It is a bit unclear whether edited:range:changeInLength: causes immediate update to the text storage, but I thought it did not.
                  Message 8 of 15 , Oct 5, 2007
                  • 0 Attachment
                    > > As for the "fix"...MacVim does batch draw stuff at the moment so this
                    > > that part of the code is about as optimized as it will ever get. (Or
                    > > did I misinterpret your idea?)
                    >
                    > As far as I understand, the batch drawing your talking about means
                    > sending several drawing commands in one chunk. Still, each drawing
                    > command is sent to the text storage in isolation, and as far as I
                    > understand the code, each ReplaceStringDrawType message causes the
                    > text view to be redrawn. I have no idea how the text system works,
                    > but perhaps it's possible to send only a single edited: message at
                    > the end, or to prevent that edited: calls processEditing directly
                    > after each changed line.

                    Ok, I understand you now. It is a bit unclear whether
                    edited:range:changeInLength: causes immediate update to the text
                    storage, but I thought it did not. When I said that drawing is done
                    in batch, I meant that it is done in between [textStorage
                    beginEditing] and [textStorage endEditing]. I am guessing that once
                    you call beginEditing, the text storage won't update until endEditing
                    is called. This would be logical, but I am also only guessing (I seem
                    to remember reading somewhere that begin/end editing were no-ops by
                    default, whatever "default" means here).

                    One thing to try would be to return the union of ranges modified in
                    replaceString/deleteLinesFromRow/clearBlockFromRow/insertLinesAtRow
                    and then take the union of the returned ranges and pass it on to
                    edited:range:changeInLength: at the end of performBatchDrawWithData
                    (and not call edited::: in the text storage methods at all, except
                    clear all which is a special case). This would be easy to do...maybe
                    you could give it a go? (Tip: use NSUnionRect).


                    > If you set MM_DEBUG_DRAWING to 1 and do `:set gcr=a:blinkon0`, you'll
                    > see that you get a ReplaceStringDrawType message for each mono-
                    > colored string. If syntax is off, that's one string per line. If
                    > syntax is on, this can be a lot, and as far as I understand code and
                    > documentation (mainly for `edited:range:changeInLength:`) the text
                    > view is redrawn after each of these messages.

                    This should be apparent after testing my above suggestion...if indeed
                    edited::: causes redraws, then things should become much faster with
                    syntax on.


                    /Björn

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • björn
                    ... This is what I thought as well as I mentioned in my previous post. ... I don t know why it isn t already bycopy...admittedly, I should read up a bit more
                    Message 9 of 15 , Oct 5, 2007
                    • 0 Attachment
                      > The way NSView / MMTextStorage works, you tell it which ranges you
                      > have edited, and the collation of these will be drawn next event
                      > dispatch (I believe).

                      This is what I thought as well as I mentioned in my previous post.


                      > I did some progiling again (use All Thread States in Shark.app) and
                      > 80% is spent in the mach messaging. This actually can be cut down.
                      > There seems to be a 10-20% saving if the queue NSArray is changed to
                      > be bycopy. This is against the modification I posted above, with
                      > scrolling up and down using the wheel / trackpad (which seems to be
                      > the most expensive op).

                      I don't know why it isn't already bycopy...admittedly, I should read
                      up a bit more on the DO aspects of Cocoa; at this point in time I
                      know how to use it, but I'm not 100% on how it works (e.g. I don't
                      understand why adding bycopy would provide at 10-20% speedup).


                      > There is also an improvement in responsivity if the queue is flushed
                      > if drawData > say 40*80 or some such other metric.

                      Yeah, flushing too often is a real killer...we should make such a test
                      permanent (at the moment I only make sure not to flush too often in
                      time, just as a remark).


                      > But I really do think it's worth looking at that part before looking
                      > to gain efficiency from the text routines, which I don't think are
                      > that bad anyway.

                      It is really good that you look into profiling the IPC stuff...at the
                      moment I really need to sit down and learn more about the tools in
                      order to be able to do any real profiling, so it is a great help that
                      you are looking at it (saves me a lot of time). Please let me know
                      about any more findings. Will you integrate all this stuff into one
                      patch (maybe you already have)?

                      Oh, I forgot to say that I also appreciate you fixing the underlining stuff!


                      /Björn

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • björn
                      ... Oh, and since it often happens that Vim updates something on the first few lines and then on the very last line (to update the statusline), it would
                      Message 10 of 15 , Oct 5, 2007
                      • 0 Attachment
                        > One thing to try would be to return the union of ranges modified in
                        > replaceString/deleteLinesFromRow/clearBlockFromRow/insertLinesAtRow
                        > and then take the union of the returned ranges and pass it on to
                        > edited:range:changeInLength: at the end of performBatchDrawWithData
                        > (and not call edited::: in the text storage methods at all, except
                        > clear all which is a special case). This would be easy to do...maybe
                        > you could give it a go? (Tip: use NSUnionRect).

                        Oh, and since it often happens that Vim updates something on the first
                        few lines and then on the very last line (to update the statusline),
                        it would probably be a good idea to call edited::: if two
                        consecutively returned ranges are "too disjoint". E.g. range1, range2
                        are the returned ranges (from the text storage methods) and

                        range2.location - NSMaxRange(range1) > value

                        or

                        range1.location - NSMaxRange(range1) > value

                        where "value" is something of the order of "maxColumns".


                        /Björn

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • George Harker
                        ... I ve done a test along these lines. The screen updates still are from the cursor to the bottom of the screen. However, it does feel a bit more
                        Message 11 of 15 , Oct 7, 2007
                        • 0 Attachment
                          > > One thing to try would be to return the union of ranges modified in
                          > > replaceString/deleteLinesFromRow/clearBlockFromRow/insertLinesAtRow
                          > > and then take the union of the returned ranges and pass it on to
                          > > edited:range:changeInLength: at the end of performBatchDrawWithData
                          > > (and not call edited::: in the text storage methods at all, except
                          > > clear all which is a special case). This would be easy to do...maybe
                          > > you could give it a go? (Tip: use NSUnionRect).

                          I've done a test along these lines. The screen updates still are from
                          the cursor to the bottom of the screen. However, it does feel a bit
                          more responsive. I can upload the patch if you'd like.

                          > Oh, and since it often happens that Vim updates something on the first
                          > few lines and then on the very last line (to update the statusline),
                          > it would probably be a good idea to call edited::: if two
                          > consecutively returned ranges are "too disjoint". E.g. range1, range2
                          > are the returned ranges (from the text storage methods) and

                          I did exactly that, then I perform the intersection of the region so
                          far, with the last command's rect. Having done that I check to see if
                          it would expand the region 'too much' - that is more than 5 line
                          longer than the last command's region's size, or more than 40 char (in
                          width) wider than the last command's region size.

                          If so, I flush the update and continue.


                          The patch is at:

                          http://george-graphics.co.uk/macvim-undercurl-drawspeed.patch

                          It includes:

                          * Rectangle-tracked calls to [NSTextStorage edited:]
                          * Responsiveness improvements in the backend (flush the queue prior to
                          timeout if [drawData length] > 80*40) - the constant is arbitrary,
                          perhaps not the best choice
                          * The queue is passed from the backend as a bycopy parameter which
                          means it doesn't have a proxy rerpresentation in the frontend (so
                          operations are a bit more efficient)

                          Cheers

                          George

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_mac" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • björn
                          ... Thanks George, it looks good. I tested it (very briefly) and it seems to make a slight difference...will include it in the next snapshot. /Björn
                          Message 12 of 15 , Oct 8, 2007
                          • 0 Attachment
                            > The patch is at:
                            >
                            > http://george-graphics.co.uk/macvim-undercurl-drawspeed.patch
                            >
                            > It includes:
                            >
                            > * Rectangle-tracked calls to [NSTextStorage edited:]
                            > * Responsiveness improvements in the backend (flush the queue prior to
                            > timeout if [drawData length] > 80*40) - the constant is arbitrary,
                            > perhaps not the best choice
                            > * The queue is passed from the backend as a bycopy parameter which
                            > means it doesn't have a proxy rerpresentation in the frontend (so
                            > operations are a bit more efficient)

                            Thanks George, it looks good. I tested it (very briefly) and it seems
                            to make a slight difference...will include it in the next snapshot.


                            /Björn

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_mac" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • George Harker
                            I think I m getting some instability caused by the rect updates at the moment. Actually I m not totally sure they are worth it.I ll put back up a patch with
                            Message 13 of 15 , Oct 8, 2007
                            • 0 Attachment
                              I think I'm getting some instability caused by the rect updates at the
                              moment. Actually I'm not totally sure they are worth it.

                              I'll put back up a patch with the other stuff.

                              Cheers

                              George

                              On 08/10/2007, bj�rn <bjorn.winckler@...> wrote:
                              >
                              > > The patch is at:
                              > >
                              > > http://george-graphics.co.uk/macvim-undercurl-drawspeed.patch
                              > >
                              > > It includes:
                              > >
                              > > * Rectangle-tracked calls to [NSTextStorage edited:]
                              > > * Responsiveness improvements in the backend (flush the queue prior to
                              > > timeout if [drawData length] > 80*40) - the constant is arbitrary,
                              > > perhaps not the best choice
                              > > * The queue is passed from the backend as a bycopy parameter which
                              > > means it doesn't have a proxy rerpresentation in the frontend (so
                              > > operations are a bit more efficient)
                              >
                              > Thanks George, it looks good. I tested it (very briefly) and it seems
                              > to make a slight difference...will include it in the next snapshot.
                              >
                              >
                              > /Bj�rn
                              >
                              > >
                              >

                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_mac" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • björn
                              ... Ok. Is this the patch? http://george-graphics.co.uk/macvim-undercurl-drawspeed.patch I had a look and it still contains the rect tracking so I wasn t sure
                              Message 14 of 15 , Oct 11, 2007
                              • 0 Attachment
                                > I think I'm getting some instability caused by the rect updates at the
                                > moment. Actually I'm not totally sure they are worth it.
                                >
                                > I'll put back up a patch with the other stuff.

                                Ok. Is this the patch?

                                http://george-graphics.co.uk/macvim-undercurl-drawspeed.patch

                                I had a look and it still contains the rect tracking so I wasn't sure
                                if you had put it somewhere else?

                                Let me know which patch is your latest (you can attach it to your
                                post) and I'll merge it.


                                /Björn

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_mac" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • George Harker
                                Sorry, I got distracted by some other things.It s attached. This one has the rect stuff removed (but has drawData length-based flushing).cheersGeorge
                                Message 15 of 15 , Oct 11, 2007
                                • 0 Attachment
                                  Sorry, I got distracted by some other things.

                                  It's attached. This one has the rect stuff removed (but has drawData
                                  length-based flushing).

                                  cheers

                                  George

                                  On 11/10/2007, björn <bjorn.winckler@...> wrote:
                                  >
                                  > > I think I'm getting some instability caused by the rect updates at the
                                  > > moment. Actually I'm not totally sure they are worth it.
                                  > >
                                  > > I'll put back up a patch with the other stuff.
                                  >
                                  > Ok. Is this the patch?
                                  >
                                  > http://george-graphics.co.uk/macvim-undercurl-drawspeed.patch
                                  >
                                  > I had a look and it still contains the rect tracking so I wasn't sure
                                  > if you had put it somewhere else?
                                  >
                                  > Let me know which patch is your latest (you can attach it to your
                                  > post) and I'll merge it.
                                  >
                                  >
                                  > /Björn
                                  >
                                  > >
                                  >

                                  --~--~---------~--~----~------------~-------~--~----~
                                  You received this message from the "vim_mac" maillist.
                                  For more information, visit http://www.vim.org/maillist.php
                                  -~----------~----~----~----~------~----~------~--~---
                                Your message has been successfully submitted and would be delivered to recipients shortly.