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

"^[[2;2R" printed in messages area on BufEnter autocommand

Expand Messages
  • Patrick Brisbin
    Hello, When I launch vim, I see [[^2;2R in the message area. Any form of redraw clears it and beginning to type an exe command will type over it. From some
    Message 1 of 10 , Nov 12, 2013
    • 0 Attachment
      Hello,

      When I launch vim, I see "[[^2;2R" in the message area. Any form of
      redraw clears it and beginning to type an exe command will type over it.

      From some googling, it may have something to do with vim requesting the
      terminal's cursor position and the terminal printing an unexpected
      escape code.

      The bug only occurs under the following conditions:

      * Terminal is urxvt (does not occur in xterm or screen)
      * First time executing vim in the specific terminal instance
      * Vim is *not* opened with the `-u` option

      I can't explain the last point, but it's important for reproducing the
      bug. I have to place the example at ~/.vimrc and open vim normally.

      Here is the minimal ~/.vimrc which reproduces for me:

      function RegenerateCtags()
      " the shell command invoked doesn't matter
      silent! execute '!true'
      endfunction

      autocmd BufEnter * call RegenerateCtags()

      Please find the attached bugreport.txt for version info. I can of course
      provide any other details if needed.

      Thanks!
      Pat

      --
      patrick brisbin
    • Tony Mechelynck
      ... Hm. VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 3 2013 19:58:40) Included patches: 1-16 Compiled by Arch Linux Huge version with GTK2 GUI. Features
      Message 2 of 10 , Nov 12, 2013
      • 0 Attachment
        On 12/11/13 23:50, Patrick Brisbin wrote:
        > Hello,
        >
        > When I launch vim, I see "[[^2;2R" in the message area. Any form of
        > redraw clears it and beginning to type an exe command will type over it.
        >
        > From some googling, it may have something to do with vim requesting the
        > terminal's cursor position and the terminal printing an unexpected
        > escape code.
        >
        > The bug only occurs under the following conditions:
        >
        > * Terminal is urxvt (does not occur in xterm or screen)
        > * First time executing vim in the specific terminal instance
        > * Vim is *not* opened with the `-u` option
        >
        > I can't explain the last point, but it's important for reproducing the
        > bug. I have to place the example at ~/.vimrc and open vim normally.
        >
        > Here is the minimal ~/.vimrc which reproduces for me:
        >
        > function RegenerateCtags()
        > " the shell command invoked doesn't matter
        > silent! execute '!true'
        > endfunction
        >
        > autocmd BufEnter * call RegenerateCtags()
        >
        > Please find the attached bugreport.txt for version info. I can of course
        > provide any other details if needed.
        >
        > Thanks!
        > Pat
        >

        Hm.

        VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 3 2013 19:58:40)
        Included patches: 1-16
        Compiled by Arch Linux
        Huge version with GTK2 GUI. Features included (+) or not (-):

        Archlinux seems a bit slow to react to fixes. It's only partly their
        fault: there are several new bugfixes practically every week. For
        comparison, here are the corresponding lines to the above from the
        version I use, and I checked a few minutes ago that it is still the very
        latest:

        VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 12 2013 19:15:18)
        Included patches: 1-91
        Compiled by antoine.mechelynck@...
        Huge version with GTK2-GNOME GUI. Features included (+) or not (-):

        On September 3, Vim 7.4.16 was indeed the latest version, but it didn't
        remain so very long: 7.4.17 arrived on September 5. You can see a
        summary of Vim 7.4's changelog at
        http://ftp.vim.org/pub/vim/patches/7.4/README (or alternatively by FTP
        which is sometimes more convenient if you decide to open that file in Vim).

        Compiling your own Vim is not really hard, and it would allow you to
        stay afloat with the latest bugfixes; for details, see
        http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
        http://users.skynet.be/antoine.mechelynck/vim/compunix.htm

        At startup, Vim determines the terminal's characteristics (not the
        cursor position etc. since it clears the screen) by sending the sequence
        shown in the output of ":set termcap" as t_RV (see ":help xterm-codes")
        if it is defined in that terminal's termcap, which usually means "only
        for xterm", and — this may explain why it doesn't happen with -u — only
        when started in 'nocompatible' mode, which means that either it was
        invoked with the -N command-line switch, or the -u command-line option
        was *not* present *and* Vim found a "user vimrc" or a "user gvimrc" — on
        Linux the normal place for a user vimrc would be ~/.vimrc but, if that
        isn't found, ~/_vimrc and (usually) ~/.vim/vimrc are also checked;
        similarly for gvimrc. If the file is named .exrc or _exrc OTOH, Vim
        remains in 'compatible' mode and doesn't ask anything to the terminal.
        My konsole terminal, which pretends that it is an xterm, has t_RV set to
        ^[[>c (where ^[ means <Esc>) and a "real" xterm has the same. So Vim
        sends that at startup and expects the terminal to eventually send
        (asynchronously) a reply starting with either CSI (i.e. Alt-Esc) or Esc
        followed by [ and ending in a lowercase c with only digits, dots and
        semicolons in between (see ":help termresponse-variable"). If the
        response never comes back, I don't think it's an error, but if the
        terminal sends back ^[[2;2R as yours seems to do, *that's* a wrong
        response and the best Vim can do, I think, is display it. (This is a
        guess, however, and I'm not sure what Vim does before and after
        executing a shell command. Swapping the terminal's display buffers, maybe.)

        So, finally, a question to you: when you issue the command ":set
        termcap" (without quotes of course) in Vim in that urxvt terminal of
        yours, do you see a value (and which one) for t_RV ?


        Best regards,
        Tony.
        --
        This week only, all our fiber-fill jackets are marked down!

        --
        --
        You received this message from the "vim_dev" 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

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Patrick Brisbin
        Thank you very much for your thorough response. ... I apologize that you got that impression. Arch is actually quite quick in updates; much more so than any
        Message 3 of 10 , Nov 12, 2013
        • 0 Attachment
          Thank you very much for your thorough response.

          On Wed, Nov 13, 2013 at 03:19:37AM +0100, Tony Mechelynck wrote:
          > On 12/11/13 23:50, Patrick Brisbin wrote:
          > VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 3 2013 19:58:40)
          > Included patches: 1-16
          > Compiled by Arch Linux
          > Huge version with GTK2 GUI. Features included (+) or not (-):
          >
          > Archlinux seems a bit slow to react to fixes. It's only partly their fault:
          > there are several new bugfixes practically every week. For comparison, here
          > are the corresponding lines to the above from the version I use, and I
          > checked a few minutes ago that it is still the very latest:
          >
          > VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 12 2013 19:15:18)
          > Included patches: 1-91
          > Compiled by antoine.mechelynck@...
          > Huge version with GTK2-GNOME GUI. Features included (+) or not (-):

          I apologize that you got that impression. Arch is actually quite quick in
          updates; much more so than any other distro I've found. It was I who was out of
          date, as I don't update my work system as often as the packages are made
          available.

          I've since updated and now get:

          VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 10 2013 20:26:12)
          Included patches: 1-86
          Compiled by Arch Linux
          Huge version with GTK2 GUI. Features included (+) or not (-):

          So only a few patch levels behind you, but newer, and newer than 7.4.17. The
          problem persists at this patch level.

          > On September 3, Vim 7.4.16 was indeed the latest version, but it didn't
          > remain so very long: 7.4.17 arrived on September 5. You can see a summary of
          > Vim 7.4's changelog at http://ftp.vim.org/pub/vim/patches/7.4/README (or
          > alternatively by FTP which is sometimes more convenient if you decide to
          > open that file in Vim).
          >
          > Compiling your own Vim is not really hard, and it would allow you to stay
          > afloat with the latest bugfixes; for details, see
          > http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
          > http://users.skynet.be/antoine.mechelynck/vim/compunix.htm

          Thank you for those resources. I believe I'm well capable of compiling my own
          software; I just usually prefer not to. As far as I can tell, nothing between
          86 and 91 looks like it may fix this, though I will compile and test 91 as soon
          as I get a chance.

          > At startup, Vim determines the terminal's characteristics (not the cursor
          > position etc. since it clears the screen) by sending the sequence shown in
          > the output of ":set termcap" as t_RV (see ":help xterm-codes") if it is
          > defined in that terminal's termcap, which usually means "only for xterm",
          > and — this may explain why it doesn't happen with -u — only when started in
          > 'nocompatible' mode, which means that either it was invoked with the -N
          > command-line switch, or the -u command-line option was *not* present *and*
          > Vim found a "user vimrc" or a "user gvimrc" — on Linux the normal place for
          > a user vimrc would be ~/.vimrc but, if that isn't found, ~/_vimrc and
          > (usually) ~/.vim/vimrc are also checked; similarly for gvimrc. If the file
          > is named .exrc or _exrc OTOH, Vim remains in 'compatible' mode and doesn't
          > ask anything to the terminal. My konsole terminal, which pretends that it is
          > an xterm, has t_RV set to ^[[>c (where ^[ means <Esc>) and a "real" xterm
          > has the same. So Vim sends that at startup and expects the terminal to
          > eventually send (asynchronously) a reply starting with either CSI (i.e.
          > Alt-Esc) or Esc followed by [ and ending in a lowercase c with only digits,
          > dots and semicolons in between (see ":help termresponse-variable"). If the
          > response never comes back, I don't think it's an error, but if the terminal
          > sends back ^[[2;2R as yours seems to do, *that's* a wrong response and the
          > best Vim can do, I think, is display it. (This is a guess, however, and I'm
          > not sure what Vim does before and after executing a shell command. Swapping
          > the terminal's display buffers, maybe.)
          >
          > So, finally, a question to you: when you issue the command ":set termcap"
          > (without quotes of course) in Vim in that urxvt terminal of yours, do you
          > see a value (and which one) for t_RV ?

          As you can see in the previously attached bugreport.txt, vim has a value
          of ^[[>c for t_RV. I've also confirmed that the output of ":set termcap"
          shows the same.

          Thanks again,
          Pat

          --
          patrick brisbin
        • Tony Mechelynck
          ... My pleasure. [...] ... Before you do: I notice that there is a system vimrc on your system, or rather two of them: /etc/vimrc and
          Message 4 of 10 , Nov 12, 2013
          • 0 Attachment
            On 13/11/13 04:07, Patrick Brisbin wrote:
            > Thank you very much for your thorough response.

            My pleasure.
            [...]
            > Thank you for those resources. I believe I'm well capable of compiling my own
            > software; I just usually prefer not to. As far as I can tell, nothing between
            > 86 and 91 looks like it may fix this, though I will compile and test 91 as soon
            > as I get a chance.

            Before you do: I notice that there is a "system vimrc" on your system,
            or rather two of them: /etc/vimrc and
            /usr/share/vim/vimfiles/archlinux.vim — IIUC, the -u command-line
            argument also skips these, so that's one more place to check for a
            possible culprit. If they are, using an own-compiled Vim with default
            settings would check /usr/local/share/vim/vimrc instead, and find of
            course nothing, so if the problem is there it would rid you of it.

            [...]
            >
            > As you can see in the previously attached bugreport.txt, vim has a value
            > of ^[[>c for t_RV. I've also confirmed that the output of ":set termcap"
            > shows the same.

            Ah, yes, I should have checked that attachment in more detail than I
            did. And on second thought, if you get that ^[[2;2R display at every
            BufEnter it cannot be the termresponse string, which Vim receives only
            once per session.

            Since your "problematic" BufEnter invokes a subshell (bash or similar
            called by Vim) I think the options with names starting with "shell"
            should be attentively scrutinized. Let's see what you have:
            shell=/bin/zsh
            shellcmdflag=-c
            shellpipe=2>&1| tee
            shellquote=
            shellredir=>%s 2>&1 not the Vim default when 'shell' is zsh
            shelltemp
            shellxquote=
            shellxescape=

            Nothing seems glaringly suspect to me, but then again, I don't know zsh
            very well — my default shell is bash.

            OK, another possibility: BufEnter autocommands. I'm not considering
            those which are about file type detection, but there are a few which
            puzzle me:

            CtrlPMRUF BufEnter
            * cal s:record(expand('<abuf>', 1))
            BufEnter
            * call s:RegenerateCtags()
            railsPluginDetect BufEnter
            * if exists("b:rails_root")|silent doau User
            BufEnterRails|endif
            FileExplorer BufEnter
            * sil! call s:LocalBrowse(expand("<amatch>"))

            Ah, that last one (FileExplorer) I've also got; I suppose it must be
            from the netrw plugin. But the others aren't familiar to me.
            >
            > Thanks again,
            > Pat
            >
            Best regards,
            Tony.
            --
            hundred-and-one symptoms of being an internet addict:
            43. You tell the kids they can't use the computer because "Daddy's got
            work to
            do" and you don't even have a job.

            --
            --
            You received this message from the "vim_dev" 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

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • PaulLeoNerd Evans
            On Wed, 13 Nov 2013 03:19:37 +0100 ... What? When is it /ever/ the right thing to do to blindly echo back to the terminal a CSI sequence that was just received
            Message 5 of 10 , Nov 13, 2013
            • 0 Attachment
              On Wed, 13 Nov 2013 03:19:37 +0100
              Tony Mechelynck <antoine.mechelynck@...> wrote:

              > If the
              > response never comes back, I don't think it's an error, but if the
              > terminal sends back ^[[2;2R as yours seems to do, *that's* a wrong
              > response and the best Vim can do, I think, is display it.

              What?

              When is it /ever/ the right thing to do to blindly echo back to the
              terminal a CSI sequence that was just received from it?

              --
              Paul "LeoNerd" Evans

              leonerd@...
              ICQ# 4135350 | Registered Linux# 179460
              http://www.leonerd.org.uk/
            • Patrick Brisbin
              ... That explains some things. Seems nocompatible is required for the bug to reproduce, and that (and not much else) was in archlinux.vim. Here s a new truly
              Message 6 of 10 , Nov 13, 2013
              • 0 Attachment
                On Wed, Nov 13, 2013 at 06:49:48AM +0100, Tony Mechelynck wrote:
                > On 13/11/13 04:07, Patrick Brisbin wrote:
                > >Thank you very much for your thorough response.
                >
                > My pleasure.
                > [...]
                > >Thank you for those resources. I believe I'm well capable of compiling my own
                > >software; I just usually prefer not to. As far as I can tell, nothing between
                > >86 and 91 looks like it may fix this, though I will compile and test 91 as soon
                > >as I get a chance.
                >
                > Before you do: I notice that there is a "system vimrc" on your system, or
                > rather two of them: /etc/vimrc and /usr/share/vim/vimfiles/archlinux.vim —
                > IIUC, the -u command-line argument also skips these, so that's one more
                > place to check for a possible culprit. If they are, using an own-compiled
                > Vim with default settings would check /usr/local/share/vim/vimrc instead,
                > and find of course nothing, so if the problem is there it would rid you of
                > it.

                That explains some things. Seems nocompatible is required for the bug to
                reproduce, and that (and not much else) was in archlinux.vim.

                Here's a new truly minimal case, which can indeed be triggered with vim
                -u example.vim:

                " example.vim
                set nocompatible

                function RegenerateCtags()
                silent! execute '!true'
                endfunction

                autocmd BufEnter * call RegenerateCtags()

                > >As you can see in the previously attached bugreport.txt, vim has a value
                > >of ^[[>c for t_RV. I've also confirmed that the output of ":set termcap"
                > >shows the same.
                >
                > Ah, yes, I should have checked that attachment in more detail than I did.
                > And on second thought, if you get that ^[[2;2R display at every BufEnter it
                > cannot be the termresponse string, which Vim receives only once per session.
                >
                > Since your "problematic" BufEnter invokes a subshell (bash or similar called
                > by Vim) I think the options with names starting with "shell" should be
                > attentively scrutinized. Let's see what you have:
                > shell=/bin/zsh
                > shellcmdflag=-c
                > shellpipe=2>&1| tee
                > shellquote=
                > shellredir=>%s 2>&1 not the Vim default when 'shell' is zsh
                > shelltemp
                > shellxquote=
                > shellxescape=
                >
                > Nothing seems glaringly suspect to me, but then again, I don't know zsh very
                > well — my default shell is bash.
                >
                > OK, another possibility: BufEnter autocommands. I'm not considering those
                > which are about file type detection, but there are a few which puzzle me:
                >
                > CtrlPMRUF BufEnter
                > * cal s:record(expand('<abuf>', 1))
                > BufEnter
                > * call s:RegenerateCtags()
                > railsPluginDetect BufEnter
                > * if exists("b:rails_root")|silent doau User BufEnterRails|endif
                > FileExplorer BufEnter
                > * sil! call s:LocalBrowse(expand("<amatch>"))
                >
                > Ah, that last one (FileExplorer) I've also got; I suppose it must be from
                > the netrw plugin. But the others aren't familiar to me.

                I apologize, I generated bugreport.txt from my normal environment, not
                the one with the minimal reproducing case loaded. I've attached a new
                file which should have less and more default settings -- but still
                produces the bug.

                Thanks,
                Pat

                --
                patrick brisbin
              • Nazri Ramliy
                ... I can reproduce the bug using example.vim above, and multiple times in the same terminal window. I can also (sort of) see the ^[[2;2R flashing by without
                Message 7 of 10 , Nov 13, 2013
                • 0 Attachment
                  On Thu, Nov 14, 2013 at 12:24 AM, Patrick Brisbin <pbrisbin@...> wrote:
                  > Here's a new truly minimal case, which can indeed be triggered with vim
                  > -u example.vim:
                  >
                  > " example.vim
                  > set nocompatible
                  >
                  > function RegenerateCtags()
                  > silent! execute '!true'
                  > endfunction
                  >
                  > autocmd BufEnter * call RegenerateCtags()

                  I can reproduce the bug using example.vim above, and multiple times in
                  the same terminal window.

                  I can also (sort of) see the ^[[2;2R "flashing by" without example.vim.

                  Here's my "Now you see it, now you don't" scenario:

                  $ cd $HOME
                  $ rm -rf .vim .vimrc # WARNING: You may need adult supervision to do this.
                  $ touch .vimrc
                  $ for i in 1 2 3 4 5; do vi -c q; done
                  # Tada!!! (You should see ^[[2;2R flashing at the bottom left of you terminal)

                  $ rm -f .vimrc
                  $ for i in 1 2 3 4 5; do vi -c q; done
                  # Now it's gone!

                  With an empty .vimrc, "vi -u example.vim" seems to always result in ^[[2;2R

                  nazri

                  --
                  --
                  You received this message from the "vim_dev" 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

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Nazri Ramliy
                  ... Versions: $ xterm -version XTerm(278) ... VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 14 2013 08:14:53) Included patches: 1-91 nazri -- -- You
                  Message 8 of 10 , Nov 13, 2013
                  • 0 Attachment
                    On Thu, Nov 14, 2013 at 9:28 AM, Nazri Ramliy <ayiehere@...> wrote:
                    > I can reproduce the bug using example.vim above, and multiple times in
                    > the same terminal window.

                    Versions:

                    $ xterm -version
                    XTerm(278)

                    :ver
                    VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 14 2013 08:14:53)
                    Included patches: 1-91

                    nazri

                    --
                    --
                    You received this message from the "vim_dev" 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

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Nazri Ramliy
                    ... hg bisect tells me: The first bad revision is: changeset: 5090:8b7baf39a345 ... $ hg log -v -r 5090 changeset: 5090:8b7baf39a345 tag: v7-3-1288
                    Message 9 of 10 , Nov 13, 2013
                    • 0 Attachment
                      On Thu, Nov 14, 2013 at 10:07 AM, Nazri Ramliy <ayiehere@...> wrote:
                      > On Thu, Nov 14, 2013 at 9:28 AM, Nazri Ramliy <ayiehere@...> wrote:
                      >> I can reproduce the bug using example.vim above, and multiple times in
                      >> the same terminal window.
                      >
                      > Versions:
                      >
                      > $ xterm -version
                      > XTerm(278)
                      >
                      > :ver
                      > VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 14 2013 08:14:53)
                      > Included patches: 1-91

                      hg bisect tells me:

                      The first bad revision is:
                      changeset: 5090:8b7baf39a345
                      ...

                      $ hg log -v -r 5090
                      changeset: 5090:8b7baf39a345
                      tag: v7-3-1288
                      user: Bram Moolenaar <bram@...>
                      date: Wed Jul 03 12:45:31 2013 +0200
                      files: src/proto/screen.pro src/screen.c src/term.c src/version.c
                      description:
                      updated for version 7.3.1288
                      Problem: The first ":echo 'hello'" command output doesn't show. Mapping
                      for <S-F3> gets triggered during startup.
                      Solution: Add debugging code for the termresponse. When receiving the "Co"
                      entry and when setting 'ambiwidth' redraw right away if possible.
                      Add redraw_asap(). Don't set 'ambiwidth' if it already had the
                      right value. Do the 'ambiwidth' check in the second row to avoid
                      confusion with <S-F3>.

                      nazri

                      --
                      --
                      You received this message from the "vim_dev" 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

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • Patrick Brisbin
                      ... Nice catch -- thank you for putting in this effort. Hopefully with this info, it can be addressed easily. Thanks, Pat -- patrick brisbin
                      Message 10 of 10 , Nov 14, 2013
                      • 0 Attachment
                        On Thu, Nov 14, 2013 at 11:07:42AM +0800, Nazri Ramliy wrote:
                        > hg bisect tells me:
                        >
                        > The first bad revision is:
                        > changeset: 5090:8b7baf39a345
                        > ...
                        >
                        > $ hg log -v -r 5090
                        > changeset: 5090:8b7baf39a345
                        > tag: v7-3-1288
                        > user: Bram Moolenaar <bram@...>
                        > date: Wed Jul 03 12:45:31 2013 +0200
                        > files: src/proto/screen.pro src/screen.c src/term.c src/version.c
                        > description:
                        > updated for version 7.3.1288
                        > Problem: The first ":echo 'hello'" command output doesn't show. Mapping
                        > for <S-F3> gets triggered during startup.
                        > Solution: Add debugging code for the termresponse. When receiving the "Co"
                        > entry and when setting 'ambiwidth' redraw right away if possible.
                        > Add redraw_asap(). Don't set 'ambiwidth' if it already had the
                        > right value. Do the 'ambiwidth' check in the second row to avoid
                        > confusion with <S-F3>.

                        Nice catch -- thank you for putting in this effort. Hopefully with this
                        info, it can be addressed easily.

                        Thanks,
                        Pat

                        --
                        patrick brisbin
                      Your message has been successfully submitted and would be delivered to recipients shortly.