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

Regression: After startup, first message output is swallowed.

Expand Messages
  • Ingo Karkat
    Hello Vim developers, I noticed a regression: $ vim -N -u NONE ... The intro message is cleared, the (now empty) UI does not show foo . Expected behavior:
    Message 1 of 17 , Jul 1, 2013
    • 0 Attachment
      Hello Vim developers,

      I noticed a regression:

      $ vim -N -u NONE
      :echo "foo"
      " The intro message is cleared, the (now empty) UI does not show "foo".
      " Expected behavior: The intro message stays visible, the command-line
      shows "foo".

      This happens with any command that echoes a single line, e.g. also with
      :set ic?, or :nmap. Only the very first command (output) is affected;
      subsequent commands (after the intro message was cleared) show up fine.
      I see this in Vim 7.3.1280 (huge build on Ubuntu 13.04/x64), but not in
      Vim 7.3.712. It also doesn't happen in GVIM, only in the terminal UI.

      -- regards, ingo

      --
      --
      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.
    • Manuel Ortega
      ... I can confirm the problem on OSX 10.8.4. Also, I have found that the offending commit is the one for 7.3.859. Version 7.3.858 doesn t exhibit this buggy
      Message 2 of 17 , Jul 1, 2013
      • 0 Attachment
        On Mon, Jul 1, 2013 at 11:45 AM, Ingo Karkat <swdev@...> wrote:
        Hello Vim developers,

        I noticed a regression:

        $ vim -N -u NONE
        :echo "foo"
        " The intro message is cleared, the (now empty) UI does not show "foo".
        " Expected behavior: The intro message stays visible, the command-line
        shows "foo".

        This happens with any command that echoes a single line, e.g. also with
        :set ic?, or :nmap. Only the very first command (output) is affected;
        subsequent commands (after the intro message was cleared) show up fine.
        I see this in Vim 7.3.1280 (huge build on Ubuntu 13.04/x64), but not in
        Vim 7.3.712. It also doesn't happen in GVIM, only in the terminal UI.

        -- regards, ingo


        I can confirm the problem on OSX 10.8.4.  Also, I have found that the offending commit is the one for 7.3.859.  Version 7.3.858 doesn't exhibit this buggy behavior.

        -Manny 

        --
        --
        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.
         
         
      • Bram Moolenaar
        ... Yes, I have also seen this. No idea why yet. -- BLACK KNIGHT: Come on you pansy! [hah] [parry thrust] [ARTHUR chops the BLACK KNIGHT s right arm off]
        Message 3 of 17 , Jul 1, 2013
        • 0 Attachment
          Ingo Karkat wrote:

          > Hello Vim developers,
          >
          > I noticed a regression:
          >
          > $ vim -N -u NONE
          > :echo "foo"
          > " The intro message is cleared, the (now empty) UI does not show "foo".
          > " Expected behavior: The intro message stays visible, the command-line
          > shows "foo".
          >
          > This happens with any command that echoes a single line, e.g. also with
          > :set ic?, or :nmap. Only the very first command (output) is affected;
          > subsequent commands (after the intro message was cleared) show up fine.
          > I see this in Vim 7.3.1280 (huge build on Ubuntu 13.04/x64), but not in
          > Vim 7.3.712. It also doesn't happen in GVIM, only in the terminal UI.

          Yes, I have also seen this. No idea why yet.

          --
          BLACK KNIGHT: Come on you pansy!
          [hah] [parry thrust]
          [ARTHUR chops the BLACK KNIGHT's right arm off]
          ARTHUR: Victory is mine! [kneeling]
          We thank thee Lord, that in thy merc-
          [Black Knight kicks Arthur in the head while he is praying]
          The Quest for the Holy Grail (Monty Python)

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ an exciting new programming language -- http://www.Zimbu.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --
          --
          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.
        • tooth pik
          ... is there any chance this is the same thing preventing ... from showing when it s the first thing you do on an empty new vim? I m guessing it is... -- _|_ _
          Message 4 of 17 , Jul 1, 2013
          • 0 Attachment
            On Mon, Jul 01, 2013 at 10:03:19PM +0200, Bram Moolenaar wrote:

            > Ingo Karkat wrote:

            > > Hello Vim developers,
            > >
            > > I noticed a regression:
            > >
            > > $ vim -N -u NONE
            > > :echo "foo"
            > > " The intro message is cleared, the (now empty) UI does not show "foo".
            > > " Expected behavior: The intro message stays visible, the command-line
            > > shows "foo".
            > >
            > > This happens with any command that echoes a single line, e.g. also with
            > > :set ic?, or :nmap. Only the very first command (output) is affected;
            > > subsequent commands (after the intro message was cleared) show up fine.
            > > I see this in Vim 7.3.1280 (huge build on Ubuntu 13.04/x64), but not in
            > > Vim 7.3.712. It also doesn't happen in GVIM, only in the terminal UI.

            > Yes, I have also seen this. No idea why yet.

            is there any chance this is the same thing preventing

            :py print "hello"

            from showing when it's the first thing you do on an empty new vim?

            I'm guessing it is...

            --
            _|_ _ __|_|_ ._ o|
            |_(_)(_)|_| ||_)||<
            |

            --
            --
            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.
          • Christian Brabandt
            ... I don t see this for vim -u NONE -N (and I suspect, this is terminal related), but for me this happens, because I have a plugin, that resets some
            Message 5 of 17 , Jul 1, 2013
            • 0 Attachment
              On Mon, July 1, 2013 17:45, Ingo Karkat wrote:
              > Hello Vim developers,
              >
              > I noticed a regression:
              >
              > $ vim -N -u NONE
              > :echo "foo"
              > " The intro message is cleared, the (now empty) UI does not show "foo".
              > " Expected behavior: The intro message stays visible, the command-line
              > shows "foo".
              >
              > This happens with any command that echoes a single line, e.g. also with
              > :set ic?, or :nmap. Only the very first command (output) is affected;
              > subsequent commands (after the intro message was cleared) show up fine.
              > I see this in Vim 7.3.1280 (huge build on Ubuntu 13.04/x64), but not in
              > Vim 7.3.712. It also doesn't happen in GVIM, only in the terminal UI.

              I don't see this for vim -u NONE -N (and I suspect, this is terminal
              related), but for me this happens, because I have a plugin, that resets
              some highlighting groups whenever the statusline is drawn. This triggers
              a do_highlight() call, which in turn calls redraw_win_later() and resets
              must_redraw, although it has been set to zero earlier in update_screen()

              This patch fixes it for me, but I am not sure, this also fixes your
              issue:

              diff --git a/src/screen.c b/src/screen.c
              --- a/src/screen.c
              +++ b/src/screen.c
              @@ -327,6 +327,7 @@
              {
              win_T *wp;
              static int did_intro = FALSE;
              + int cur_must_redraw = must_redraw;
              #if defined(FEAT_SEARCH_EXTRA) || defined(FEAT_CLIPBOARD)
              int did_one;
              #endif
              @@ -335,16 +336,16 @@
              if (!screen_valid(TRUE))
              return;

              - if (must_redraw)
              - {
              - if (type < must_redraw) /* use maximal type */
              - type = must_redraw;
              + if (cur_must_redraw)
              + {
              + if (type < cur_must_redraw) /* use maximal type */
              + type = cur_must_redraw;

              /* must_redraw is reset here, so that when we run into some weird
              * reason to redraw while busy redrawing (e.g., asynchronous
              * scrolling), or update_topline() in win_update() will cause a
              * scroll, the screen will be redrawn later or in win_update(). */
              - must_redraw = 0;
              + cur_must_redraw = 0;
              }

              /* Need to update w_lines[]. */
              @@ -356,7 +357,7 @@
              if (!redrawing() || updating_screen)
              {
              redraw_later(type); /* remember type for next time */
              - must_redraw = type;
              + cur_must_redraw = type;
              if (type > INVERTED_ALL)
              curwin->w_lines_valid = 0; /* don't use w_lines[].wl_size now */
              return;
              @@ -594,6 +595,7 @@
              gui_update_scrollbars(FALSE);
              }
              #endif
              + must_redraw = cur_must_redraw;
              }

              #if defined(FEAT_CONCEAL) || defined(PROTO)


              --
              --
              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.
            • Ingo Karkat
              ... Correct, this doesn t happen in GVIM, and also doesn t happen in the Windows console version, only in a Linux terminal. ... No, unfortunately not, but
              Message 6 of 17 , Jul 2, 2013
              • 0 Attachment
                On 01-Jul-2013 23:29 +0200, Christian Brabandt wrote:

                > On Mon, July 1, 2013 17:45, Ingo Karkat wrote:
                >> Hello Vim developers,
                >>
                >> I noticed a regression:
                >>
                >> $ vim -N -u NONE
                >> :echo "foo"
                >> " The intro message is cleared, the (now empty) UI does not show "foo".
                >> " Expected behavior: The intro message stays visible, the command-line
                >> shows "foo".
                >>
                >> This happens with any command that echoes a single line, e.g. also with
                >> :set ic?, or :nmap. Only the very first command (output) is affected;
                >> subsequent commands (after the intro message was cleared) show up fine.
                >> I see this in Vim 7.3.1280 (huge build on Ubuntu 13.04/x64), but not in
                >> Vim 7.3.712. It also doesn't happen in GVIM, only in the terminal UI.
                >
                > I don't see this for vim -u NONE -N (and I suspect, this is terminal
                > related), ...

                Correct, this doesn't happen in GVIM, and also doesn't happen in the
                Windows console version, only in a Linux terminal.

                > ...but for me this happens, because I have a plugin, that resets
                > some highlighting groups whenever the statusline is drawn. This triggers
                > a do_highlight() call, which in turn calls redraw_win_later() and resets
                > must_redraw, although it has been set to zero earlier in update_screen()
                >
                > This patch fixes it for me, but I am not sure, this also fixes your
                > issue:
                >
                > diff --git a/src/screen.c b/src/screen.c
                > --- a/src/screen.c
                > +++ b/src/screen.c
                > @@ -327,6 +327,7 @@
                > {
                > win_T *wp;
                > static int did_intro = FALSE;
                > + int cur_must_redraw = must_redraw;
                > #if defined(FEAT_SEARCH_EXTRA) || defined(FEAT_CLIPBOARD)
                > int did_one;
                > #endif
                > @@ -335,16 +336,16 @@
                > if (!screen_valid(TRUE))
                > return;
                >
                > - if (must_redraw)
                > - {
                > - if (type < must_redraw) /* use maximal type */
                > - type = must_redraw;
                > + if (cur_must_redraw)
                > + {
                > + if (type < cur_must_redraw) /* use maximal type */
                > + type = cur_must_redraw;
                >
                > /* must_redraw is reset here, so that when we run into some weird
                > * reason to redraw while busy redrawing (e.g., asynchronous
                > * scrolling), or update_topline() in win_update() will cause a
                > * scroll, the screen will be redrawn later or in win_update(). */
                > - must_redraw = 0;
                > + cur_must_redraw = 0;
                > }
                >
                > /* Need to update w_lines[]. */
                > @@ -356,7 +357,7 @@
                > if (!redrawing() || updating_screen)
                > {
                > redraw_later(type); /* remember type for next time */
                > - must_redraw = type;
                > + cur_must_redraw = type;
                > if (type > INVERTED_ALL)
                > curwin->w_lines_valid = 0; /* don't use w_lines[].wl_size now */
                > return;
                > @@ -594,6 +595,7 @@
                > gui_update_scrollbars(FALSE);
                > }
                > #endif
                > + must_redraw = cur_must_redraw;
                > }
                >
                > #if defined(FEAT_CONCEAL) || defined(PROTO)

                No, unfortunately not, but thanks for trying. The behavior is exactly
                the same: The intro message disappears (it should not), and this screen
                refresh probably also removes the message.

                -- regards, ingo

                --
                --
                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.
              • Christian Brabandt
                ... What is your terminal, your $TERM variable and what does vim set the term option to? As I said, I don t see it neither on screen-256color nor on
                Message 7 of 17 , Jul 2, 2013
                • 0 Attachment
                  On Tue, July 2, 2013 09:26, Ingo Karkat wrote:
                  > Correct, this doesn't happen in GVIM, and also doesn't happen in the
                  > Windows console version, only in a Linux terminal.

                  What is your terminal, your $TERM variable and what does vim set the term
                  option to?

                  As I said, I don't see it neither on screen-256color nor on xterm-256color
                  nor on linux (e.g. standard non-X11 terminal).

                  regards,
                  Christian

                  --
                  --
                  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.
                • Kazunobu Kuriyama
                  ... Sadly, the bug is still alive with this patch... In addition to those unexpected behaviors that have been reported so far, the bug looks to manifest
                  Message 8 of 17 , Jul 2, 2013
                  • 0 Attachment
                    On Jul 2, 2013, at 6:29 AM, "Christian Brabandt" <cblists@...> wrote:

                    > On Mon, July 1, 2013 17:45, Ingo Karkat wrote:
                    >> Hello Vim developers,
                    >>
                    >> I noticed a regression:
                    >>
                    >> $ vim -N -u NONE
                    >> :echo "foo"
                    >> " The intro message is cleared, the (now empty) UI does not show "foo".
                    >> " Expected behavior: The intro message stays visible, the command-line
                    >> shows "foo".
                    >>
                    >> This happens with any command that echoes a single line, e.g. also with
                    >> :set ic?, or :nmap. Only the very first command (output) is affected;
                    >> subsequent commands (after the intro message was cleared) show up fine.
                    >> I see this in Vim 7.3.1280 (huge build on Ubuntu 13.04/x64), but not in
                    >> Vim 7.3.712. It also doesn't happen in GVIM, only in the terminal UI.
                    >
                    > I don't see this for vim -u NONE -N (and I suspect, this is terminal
                    > related), but for me this happens, because I have a plugin, that resets
                    > some highlighting groups whenever the statusline is drawn. This triggers
                    > a do_highlight() call, which in turn calls redraw_win_later() and resets
                    > must_redraw, although it has been set to zero earlier in update_screen()
                    >
                    > This patch fixes it for me, but I am not sure, this also fixes your
                    > issue:
                    >
                    > diff --git a/src/screen.c b/src/screen.c
                    > --- a/src/screen.c
                    > +++ b/src/screen.c
                    > @@ -327,6 +327,7 @@
                    > {
                    > win_T *wp;
                    > static int did_intro = FALSE;
                    > + int cur_must_redraw = must_redraw;
                    > #if defined(FEAT_SEARCH_EXTRA) || defined(FEAT_CLIPBOARD)
                    > int did_one;
                    > #endif
                    > @@ -335,16 +336,16 @@
                    > if (!screen_valid(TRUE))
                    > return;
                    >
                    > - if (must_redraw)
                    > - {
                    > - if (type < must_redraw) /* use maximal type */
                    > - type = must_redraw;
                    > + if (cur_must_redraw)
                    > + {
                    > + if (type < cur_must_redraw) /* use maximal type */
                    > + type = cur_must_redraw;
                    >
                    > /* must_redraw is reset here, so that when we run into some weird
                    > * reason to redraw while busy redrawing (e.g., asynchronous
                    > * scrolling), or update_topline() in win_update() will cause a
                    > * scroll, the screen will be redrawn later or in win_update(). */
                    > - must_redraw = 0;
                    > + cur_must_redraw = 0;
                    > }
                    >
                    > /* Need to update w_lines[]. */
                    > @@ -356,7 +357,7 @@
                    > if (!redrawing() || updating_screen)
                    > {
                    > redraw_later(type); /* remember type for next time */
                    > - must_redraw = type;
                    > + cur_must_redraw = type;
                    > if (type > INVERTED_ALL)
                    > curwin->w_lines_valid = 0; /* don't use w_lines[].wl_size now */
                    > return;
                    > @@ -594,6 +595,7 @@
                    > gui_update_scrollbars(FALSE);
                    > }
                    > #endif
                    > + must_redraw = cur_must_redraw;
                    > }
                    >
                    > #if defined(FEAT_CONCEAL) || defined(PROTO)
                    >
                    >
                    > --

                    Sadly, the bug is still alive with this patch...

                    In addition to those unexpected behaviors that have been reported so far, the "bug" looks to manifest itself only when vim runs on an xterm for the first time. In other words, if you invoke vim on a newly opened xterm and follow the instructions to reproduce the bug, you'll see it. But after quitting that vim and then invoking another vim process there, the bug's gone somewhere...

                    The behavior I've just mentioned happens independently of the options -N -u NONE. Also, it happens not only with a 'huge' vim but also with 'normal' and 'big' ones.

                    Interestingly, vim running on Terminal.app (an xterm variant tailored for Mac(?)) doesn't show such behaviors at all. Furthermore, a non-GUI version that depends on darwin shows the same problematic behaviors, but a non-GUI version that *doesn't* depend on darwin (in other words, a non-GUI but *X11 dependent* version) works well. (The problem might be relevant to ICC and/or SM...?)

                    That said, the vim shipped with MacOS X 10.8.4, the version of which is 7.3 and looks no patch applied, not linked against X11, works well. This suggests that the early patch-levels of 7.3 are free from this particular bug.

                    So it looks the problem lies in (lack of) some interaction between the terminal initialization done by vim and that of xterm.

                    Hopefully, this partial observation could save someone's time and labor (I'm also trying to fix it, but can't find a good solution to it till now.)

                    - KK

                    --
                    --
                    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.
                  • Ingo Karkat
                    ... I m observing the bug in gnome-terminal. My TERM is gnome-256color, but I also see the bug with the following values: xterm-256color, xterm. Vim reports
                    Message 9 of 17 , Jul 2, 2013
                    • 0 Attachment
                      On 02-Jul-2013 09:41 +0200, Christian Brabandt wrote:

                      > On Tue, July 2, 2013 09:26, Ingo Karkat wrote:
                      >> Correct, this doesn't happen in GVIM, and also doesn't happen in the
                      >> Windows console version, only in a Linux terminal.
                      >
                      > What is your terminal, your $TERM variable and what does vim set the term
                      > option to?
                      >
                      > As I said, I don't see it neither on screen-256color nor on xterm-256color
                      > nor on linux (e.g. standard non-X11 terminal).

                      I'm observing the bug in gnome-terminal. My TERM is gnome-256color, but
                      I also see the bug with the following values: xterm-256color, xterm. Vim
                      reports the same values with :set term?

                      I DO NOT see the bug within screen (TERM=screen), or in an xterm (with
                      TERM=xterm).

                      In contrast to what Kazunobu Kuriyama reports, I see the bug not only on
                      first startup, but also repeatedly in the same terminal (but not in
                      xterm itself).

                      With the dependency to particular terminal settings, this seems to be a
                      tricky one...

                      -- regards, ingo

                      --
                      --
                      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.
                    • Manuel Ortega
                      On Tue, Jul 2, 2013 at 3:44 AM, Kazunobu Kuriyama
                      Message 10 of 17 , Jul 2, 2013
                      • 0 Attachment
                        On Tue, Jul 2, 2013 at 3:44 AM, Kazunobu Kuriyama <kazunobu.kuriyama@...> wrote:
                        That said, the vim shipped with MacOS X 10.8.4, the version of which is 7.3 and looks no patch applied, not linked against X11, works well.  This suggests that the early patch-levels of 7.3 are free from this particular bug.


                        Did my earlier message not go through?  I bisected.  The offending commit is 7.3.859.  7.3.858 is just fine on OSX 10.8.4.

                        I see this in iTerm.app with xterm-256color, and in Terminal.app with xterm-256color.

                        If I switch it to "xterm" or "xterm-16color", the bug goes away.

                        If I switch it to "xterm-color" the bug reappears.

                        -Manny

                        --
                        --
                        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.
                         
                         
                      • h_east
                        Hi, Manuel and Vimmers. ... Thank you for your investigation. My investigation result: I reproduced. 7.3.1287 on fedora 17 via PuTTY(term=putty-256color). If
                        Message 11 of 17 , Jul 2, 2013
                        • 0 Attachment
                          Hi, Manuel and Vimmers.

                          2013/7/3(Wed) 0:27:51 UTC+9 Manuel Ortega:
                          > On Tue, Jul 2, 2013 at 3:44 AM, Kazunobu Kuriyama <kazunobu...@...> wrote:
                          >
                          >
                          > That said, the vim shipped with MacOS X 10.8.4, the version of which is 7.3 and looks no patch applied, not linked against X11, works well.  This suggests that the early patch-levels of 7.3 are free from this particular bug.
                          >
                          >
                          >
                          >
                          >
                          > Did my earlier message not go through?  I bisected.  The offending commit is 7.3.859.  7.3.858 is just fine on OSX 10.8.4.
                          >
                          >
                          > I see this in iTerm.app with xterm-256color, and in Terminal.app with xterm-256color.
                          >
                          >
                          >
                          > If I switch it to "xterm" or "xterm-16color", the bug goes away.
                          >
                          >
                          > If I switch it to "xterm-color" the bug reappears.
                          >
                          >
                          >
                          > -Manny

                          Thank you for your investigation.

                          My investigation result:
                          I reproduced.
                          7.3.1287 on fedora 17 via PuTTY(term=putty-256color).

                          If may_req_ambiguous_character_width() function call is commented, then This regression is not occurred.
                          (main.c: 815)

                          Best regards
                          Hirohito Higashi

                          --
                          --
                          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.
                        • Bram Moolenaar
                          ... I can reproduce it even when the may_req_ambiguous_character_width() stuff is skipped. That s when using an xterm and t_Co is different from the expected
                          Message 12 of 17 , Jul 2, 2013
                          • 0 Attachment
                            Hirohito Higashi wrote:

                            > Hi, Manuel and Vimmers.
                            >
                            > 2013/7/3(Wed) 0:27:51 UTC+9 Manuel Ortega:
                            > > On Tue, Jul 2, 2013 at 3:44 AM, Kazunobu Kuriyama <kazunobu...@...> wrote:
                            > >
                            > >
                            > > That said, the vim shipped with MacOS X 10.8.4, the version of which
                            > > is 7.3 and looks no patch applied, not linked against X11, works
                            > > well.  This suggests that the early patch-levels of 7.3 are free
                            > > from this particular bug.
                            > >
                            > > Did my earlier message not go through?  I bisected.  The offending
                            > > commit is 7.3.859.  7.3.858 is just fine on OSX 10.8.4.
                            > >
                            > > I see this in iTerm.app with xterm-256color, and in Terminal.app
                            > > with xterm-256color.
                            > >
                            > > If I switch it to "xterm" or "xterm-16color", the bug goes away.
                            > > If I switch it to "xterm-color" the bug reappears.
                            > >
                            > > -Manny
                            >
                            > Thank you for your investigation.
                            >
                            > My investigation result:
                            > I reproduced.
                            > 7.3.1287 on fedora 17 via PuTTY(term=putty-256color).
                            >
                            > If may_req_ambiguous_character_width() function call is commented, then This regression is not occurred.
                            > (main.c: 815)

                            I can reproduce it even when the may_req_ambiguous_character_width()
                            stuff is skipped. That's when using an xterm and t_Co is different from
                            the expected value, causing a redraw.

                            I'm working on a patch, but it's grown a bit large...

                            --
                            LAUNCELOT: I am, sir. I am a Knight of King Arthur.
                            FATHER: 'Mm ... very nice castle, Camelot ... very good pig country....
                            "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                            \\\ an exciting new programming language -- http://www.Zimbu.org ///
                            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                            --
                            --
                            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.
                          • Bram Moolenaar
                            ... Yes, AFAIK it only happens when the termresponse causes a redraw. For xterm that is when t_CO is received. ... Hmm, changing highlighting while busy
                            Message 13 of 17 , Jul 2, 2013
                            • 0 Attachment
                              Christian Brabandt wrote:

                              > On Mon, July 1, 2013 17:45, Ingo Karkat wrote:
                              > > Hello Vim developers,
                              > >
                              > > I noticed a regression:
                              > >
                              > > $ vim -N -u NONE
                              > > :echo "foo"
                              > > " The intro message is cleared, the (now empty) UI does not show "foo".
                              > > " Expected behavior: The intro message stays visible, the command-line
                              > > shows "foo".
                              > >
                              > > This happens with any command that echoes a single line, e.g. also with
                              > > :set ic?, or :nmap. Only the very first command (output) is affected;
                              > > subsequent commands (after the intro message was cleared) show up fine.
                              > > I see this in Vim 7.3.1280 (huge build on Ubuntu 13.04/x64), but not in
                              > > Vim 7.3.712. It also doesn't happen in GVIM, only in the terminal UI.
                              >
                              > I don't see this for vim -u NONE -N (and I suspect, this is terminal
                              > related),

                              Yes, AFAIK it only happens when the termresponse causes a redraw. For
                              xterm that is when t_CO is received.

                              > but for me this happens, because I have a plugin, that resets
                              > some highlighting groups whenever the statusline is drawn. This triggers
                              > a do_highlight() call, which in turn calls redraw_win_later() and resets
                              > must_redraw, although it has been set to zero earlier in update_screen()

                              Hmm, changing highlighting while busy redrawing is bad. I'm not sure if
                              we would care to make this work. Generally it would require a redraw.
                              Vim doesn't know only the status line would be affected.

                              > This patch fixes it for me, but I am not sure, this also fixes your
                              > issue:

                              This basically ignores the problem: If anything sets must_redraw while
                              redrawing it gets discarded. I suspect this will cause trouble in some
                              situations. There already is a flag to prevent recursion, weird
                              things do happen. E.g. a resize while redrawing.


                              --
                              FATHER: You only killed the bride's father - that's all -
                              LAUNCELOT: Oh dear, I didn't really mean to...
                              FATHER: Didn't mean to? You put your sword right through his head!
                              LAUNCELOT: Gosh - Is he all right?
                              "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                              \\\ an exciting new programming language -- http://www.Zimbu.org ///
                              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                              --
                              --
                              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.
                            • Lech Lorens
                              ... There are more problems introduced by 7.3.859. I have a problem with mappings. When I try to set mappings up in my .vimrc, one of the mappings is executed.
                              Message 14 of 17 , Jul 3, 2013
                              • 0 Attachment
                                On 02-Jul-2013 Manuel Ortega <mannyvimdev@...> wrote:
                                > On Tue, Jul 2, 2013 at 3:44 AM, Kazunobu Kuriyama <
                                > kazunobu.kuriyama@...> wrote:
                                >
                                > > That said, the vim shipped with MacOS X 10.8.4, the version of which is
                                > > 7.3 and looks no patch applied, not linked against X11, works well. This
                                > > suggests that the early patch-levels of 7.3 are free from this particular
                                > > bug.
                                > >
                                > >
                                > Did my earlier message not go through? I bisected. The offending commit
                                > is 7.3.859. 7.3.858 is just fine on OSX 10.8.4.
                                >
                                > I see this in iTerm.app with xterm-256color, and in Terminal.app with
                                > xterm-256color.
                                >
                                > If I switch it to "xterm" or "xterm-16color", the bug goes away.
                                >
                                > If I switch it to "xterm-color" the bug reappears.
                                >
                                > -Manny

                                There are more problems introduced by 7.3.859. I have a problem with
                                mappings. When I try to set mappings up in my .vimrc, one of the
                                mappings is executed. I minimised the setup to the following two files:
                                Makefile:
                                #v+
                                .PHONY: foo bar

                                foo bar:
                                echo This is target $@!
                                #v-
                                vimrc
                                #v+
                                set nocompatible

                                nnoremap <S-F3> :lmake bar<CR>
                                nmap [1;2R <S-F3>

                                " This is what <S-F3> looks like in my terminal: O1;2R
                                #v-

                                I don't know what my vimrc will look like after going through Google
                                groups, so I am attaching the files as well.

                                When I run:
                                $ ~/devel/73/vim-git/src/vim -u vimrc -U NONE --noplugin

                                I get:
                                #v+
                                echo This is target bar!
                                This is target bar!

                                Press ENTER or type command to continue
                                #v-

                                which clearly indicates that ":lmake bar" is executed.

                                --
                                Lech Lorens

                                --
                                --
                                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.
                              • Bram Moolenaar
                                ... There is something weird going on: The terminal uses [1;2R both for function key 3 shifted and for the cursor position report. So what happens is that
                                Message 15 of 17 , Jul 3, 2013
                                • 0 Attachment
                                  Lech Lorens wrote:

                                  > On 02-Jul-2013 Manuel Ortega <mannyvimdev@...> wrote:
                                  > > On Tue, Jul 2, 2013 at 3:44 AM, Kazunobu Kuriyama <
                                  > > kazunobu.kuriyama@...> wrote:
                                  > >
                                  > > > That said, the vim shipped with MacOS X 10.8.4, the version of which is
                                  > > > 7.3 and looks no patch applied, not linked against X11, works well. This
                                  > > > suggests that the early patch-levels of 7.3 are free from this particular
                                  > > > bug.
                                  > > >
                                  > > >
                                  > > Did my earlier message not go through? I bisected. The offending commit
                                  > > is 7.3.859. 7.3.858 is just fine on OSX 10.8.4.
                                  > >
                                  > > I see this in iTerm.app with xterm-256color, and in Terminal.app with
                                  > > xterm-256color.
                                  > >
                                  > > If I switch it to "xterm" or "xterm-16color", the bug goes away.
                                  > >
                                  > > If I switch it to "xterm-color" the bug reappears.
                                  > >
                                  > > -Manny
                                  >
                                  > There are more problems introduced by 7.3.859. I have a problem with
                                  > mappings. When I try to set mappings up in my .vimrc, one of the
                                  > mappings is executed. I minimised the setup to the following two files:
                                  > Makefile:
                                  > #v+
                                  > .PHONY: foo bar
                                  >
                                  > foo bar:
                                  > echo This is target $@!
                                  > #v-
                                  > vimrc
                                  > #v+
                                  > set nocompatible
                                  >
                                  > nnoremap <S-F3> :lmake bar<CR>
                                  > nmap [1;2R <S-F3>
                                  >
                                  > " This is what <S-F3> looks like in my terminal: O1;2R
                                  > #v-
                                  >
                                  > I don't know what my vimrc will look like after going through Google
                                  > groups, so I am attaching the files as well.
                                  >
                                  > When I run:
                                  > $ ~/devel/73/vim-git/src/vim -u vimrc -U NONE --noplugin
                                  >
                                  > I get:
                                  > #v+
                                  > echo This is target bar!
                                  > This is target bar!
                                  >
                                  > Press ENTER or type command to continue
                                  > #v-
                                  >
                                  > which clearly indicates that ":lmake bar" is executed.

                                  There is something weird going on: The terminal uses <Esc>[1;2R both for
                                  function key 3 shifted and for the cursor position report.

                                  So what happens is that for the 'ambiwidth' option to be set
                                  automatically it requests the cursor position, and your mapping eats it.

                                  I think we can void the problem by doing the 'ambiwidth' check in the
                                  second row instead of the first one. The returned sequence will then be
                                  <Esc>[2;2R.

                                  --
                                  If your life is a hard drive,
                                  Christ can be your backup.

                                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                  \\\ an exciting new programming language -- http://www.Zimbu.org ///
                                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                                  --
                                  --
                                  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.
                                • Ingo Karkat
                                  ... I can confirm that patch 7.3.1288 fixes the redraw for me. Thanks! -- regards, ingo -- -- You received this message from the vim_dev maillist. Do not
                                  Message 16 of 17 , Jul 3, 2013
                                  • 0 Attachment
                                    On 02-Jul-2013 23:16 +0200, Bram Moolenaar wrote:

                                    > Hirohito Higashi wrote:
                                    >
                                    >> Hi, Manuel and Vimmers.
                                    >>
                                    >> 2013/7/3(Wed) 0:27:51 UTC+9 Manuel Ortega:
                                    >>> On Tue, Jul 2, 2013 at 3:44 AM, Kazunobu Kuriyama <kazunobu...@...> wrote:
                                    >>>
                                    >>>
                                    >>> That said, the vim shipped with MacOS X 10.8.4, the version of which
                                    >>> is 7.3 and looks no patch applied, not linked against X11, works
                                    >>> well. This suggests that the early patch-levels of 7.3 are free
                                    >>> from this particular bug.
                                    >>>
                                    >>> Did my earlier message not go through? I bisected. The offending
                                    >>> commit is 7.3.859. 7.3.858 is just fine on OSX 10.8.4.
                                    >>>
                                    >>> I see this in iTerm.app with xterm-256color, and in Terminal.app
                                    >>> with xterm-256color.
                                    >>>
                                    >>> If I switch it to "xterm" or "xterm-16color", the bug goes away.
                                    >>> If I switch it to "xterm-color" the bug reappears.
                                    >>>
                                    >>> -Manny
                                    >>
                                    >> Thank you for your investigation.
                                    >>
                                    >> My investigation result:
                                    >> I reproduced.
                                    >> 7.3.1287 on fedora 17 via PuTTY(term=putty-256color).
                                    >>
                                    >> If may_req_ambiguous_character_width() function call is commented, then This regression is not occurred.
                                    >> (main.c: 815)
                                    >
                                    > I can reproduce it even when the may_req_ambiguous_character_width()
                                    > stuff is skipped. That's when using an xterm and t_Co is different from
                                    > the expected value, causing a redraw.
                                    >
                                    > I'm working on a patch, but it's grown a bit large...

                                    I can confirm that patch 7.3.1288 fixes the redraw for me. Thanks!

                                    -- regards, ingo

                                    --
                                    --
                                    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.
                                  • Lech Lorens
                                    ... Just wanted to confirm that this problem indeed has been solved. Thanks! -- Lech Lorens -- -- You received this message from the vim_dev maillist. Do not
                                    Message 17 of 17 , Jul 5, 2013
                                    • 0 Attachment
                                      On 03-Jul-2013 Bram Moolenaar <Bram@...> wrote:
                                      >
                                      > There is something weird going on: The terminal uses <Esc>[1;2R both for
                                      > function key 3 shifted and for the cursor position report.
                                      >
                                      > So what happens is that for the 'ambiwidth' option to be set
                                      > automatically it requests the cursor position, and your mapping eats it.
                                      >
                                      > I think we can void the problem by doing the 'ambiwidth' check in the
                                      > second row instead of the first one. The returned sequence will then be
                                      > <Esc>[2;2R.

                                      Just wanted to confirm that this problem indeed has been solved. Thanks!

                                      --
                                      Lech Lorens

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