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

Re: Regression: After startup, first message output is swallowed.

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.