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

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

Expand Messages
  • 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 1 of 17 , Jul 2, 2013
    View Source
    • 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.
    • 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 2 of 17 , Jul 3, 2013
      View Source
      • 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 3 of 17 , Jul 3, 2013
        View Source
        • 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 4 of 17 , Jul 3, 2013
          View Source
          • 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 5 of 17 , Jul 5, 2013
            View Source
            • 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.