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

Re: Delay when Insert mode is left

Expand Messages
  • Jens Paulus
    Hi Bram, ... by the way I think it would be useful to add a paragraph like this to the descriptian of the timout or ttimeout option because there may be lots
    Message 1 of 14 , Jan 4, 2005
    • 0 Attachment
      Hi Bram,

      On Tue, Jan 04, 2005 at 20:29:16 +0100, Jens Paulus wrote:
      > > > The reason is that in a terminal there are key codes that start with
      > > > Esc. When Vim receives an Esc in Insert mode it can't be sure if it is
      > > > the Esc key or the start of a key code (e.g., for a cursor key). Vim
      > > > then pretents to go out of Insert mode, but only really does so after
      > > > 'ttimeoutlen'.
      > > >
      > > > You can fix this by using a terminal that uses CSI for special keys.

      by the way I think it would be useful to add a paragraph like this to
      the descriptian of the timout or ttimeout option because there may be
      lots of people that suffer from this delay.

      Best regards

      Jens
    • Jens Paulus
      Hi developers, ... [....] ... awaiting your comments about this suggestion. To me this looks like a possible solution. Best regards Jens
      Message 2 of 14 , Jan 7, 2005
      • 0 Attachment
        Hi developers,

        On Tue, Jan 04, 2005 at 20:29:16 +0100, Jens Paulus wrote:
        > > > The reason is that in a terminal there are key codes that start with
        > > > Esc. When Vim receives an Esc in Insert mode it can't be sure if it is
        > > > the Esc key or the start of a key code (e.g., for a cursor key). Vim
        > > > then pretents to go out of Insert mode, but only really does so after
        > > > 'ttimeoutlen'.
        > > >
        > > > You can fix this by using a terminal that uses CSI for special keys.
        > >
        [....]
        >
        > what I also tried is this.
        > imap <Esc> <C-]><C-C>
        > The idea is to expand the abbreviation and then leave Insert mode.
        > However, this only works after entering an abbreviation. If <C-]> would
        > be a <Nop> if normal text and no abbreviation is entered then the
        > problem with the <Esc> delay could easily be solved with this mapping.
        > Then if someone wants to insert CTRL-] into the text, this person would use
        > CTRL-V instead.

        awaiting your comments about this suggestion. To me this looks like a
        possible solution.

        Best regards

        Jens
      • Bram Moolenaar
        ... Did you really not understand that recognizing the of the mapping is exactly the same problem as recognizing special keys? You still have no clue
        Message 3 of 14 , Jan 8, 2005
        • 0 Attachment
          Jens Paulus wrote:

          > On Tue, Jan 04, 2005 at 20:29:16 +0100, Jens Paulus wrote:
          > > > > The reason is that in a terminal there are key codes that start with
          > > > > Esc. When Vim receives an Esc in Insert mode it can't be sure if it is
          > > > > the Esc key or the start of a key code (e.g., for a cursor key). Vim
          > > > > then pretents to go out of Insert mode, but only really does so after
          > > > > 'ttimeoutlen'.
          > > > >
          > > > > You can fix this by using a terminal that uses CSI for special keys.
          > > >
          > [....]
          > >
          > > what I also tried is this.
          > > imap <Esc> <C-]><C-C>
          > > The idea is to expand the abbreviation and then leave Insert mode.
          > > However, this only works after entering an abbreviation. If <C-]> would
          > > be a <Nop> if normal text and no abbreviation is entered then the
          > > problem with the <Esc> delay could easily be solved with this
          > > mapping. Then if someone wants to insert CTRL-] into the text, this
          > > person would use CTRL-V instead.
          >
          > awaiting your comments about this suggestion. To me this looks like a
          > possible solution.

          Did you really not understand that recognizing the <Esc> of the mapping
          is exactly the same problem as recognizing special keys? You still have
          no clue whether an <Esc> is typed or the start of a special key. Only
          avoiding the use of <Esc> for special keys can avoid that.

          --
          In war we're tough and able.
          Quite indefatigable
          Between our quests
          We sequin vests
          And impersonate Clark Gable
          It's a busy life in Camelot.
          I have to push the pram a lot.
          "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/ \\\
          \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
          \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
        • Jens Paulus
          Hi Bram, ... alright, I did not have the right understanding of the problem. Now I agree that there is really no other solution. Let me ask a little question.
          Message 4 of 14 , Jan 10, 2005
          • 0 Attachment
            Hi Bram,

            On Sat, Jan 08, 2005 at 13:35:30 +0100, Bram Moolenaar wrote:
            > Did you really not understand that recognizing the <Esc> of the mapping
            > is exactly the same problem as recognizing special keys? You still have
            > no clue whether an <Esc> is typed or the start of a special key. Only
            > avoiding the use of <Esc> for special keys can avoid that.

            alright, I did not have the right understanding of the problem. Now I
            agree that there is really no other solution.
            Let me ask a little question. When being in command line I am looking
            for a way to figure out if the command line has been entered from Visual
            mode or from Normal mode. Neither visualmode() nor mode() help because
            the first one is for something else and the second one does not react
            how I want it.

            Best regards

            Jens
          • Bram Moolenaar
            ... You need to use another method. For example by using :vmap or invoking mode() before leaving Visual mode. -- TALL KNIGHT: We shall say Ni! again to you
            Message 5 of 14 , Jan 10, 2005
            • 0 Attachment
              Jends Paulus wrote:

              > Let me ask a little question. When being in command line I am looking
              > for a way to figure out if the command line has been entered from Visual
              > mode or from Normal mode. Neither visualmode() nor mode() help because
              > the first one is for something else and the second one does not react
              > how I want it.

              You need to use another method. For example by using ":vmap" or
              invoking mode() before leaving Visual mode.

              --
              TALL KNIGHT: We shall say Ni! again to you if you do not appease us.
              ARTHUR: All right! What do you want?
              TALL KNIGHT: We want ... a shrubbery!
              "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/ \\\
              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
              \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
            • Jens Paulus
              Hi Bram, ... yes I know, but it seems impossible to invoke mode() before leaving Visual mode. To invoke mode() it requires that a function call from the
              Message 6 of 14 , Jan 10, 2005
              • 0 Attachment
                Hi Bram,

                On Mon, Jan 10, 2005 at 19:14:53 +0100, Bram Moolenaar wrote:
                > > Let me ask a little question. When being in command line I am looking
                > > for a way to figure out if the command line has been entered from Visual
                > > mode or from Normal mode. Neither visualmode() nor mode() help because
                > > the first one is for something else and the second one does not react
                > > how I want it.
                >
                > You need to use another method. For example by using ":vmap" or
                > invoking mode() before leaving Visual mode.

                yes I know, but it seems impossible to invoke mode() before leaving
                Visual mode. To invoke mode() it requires that a function call from the
                command line is done and this always deliveres the information that
                Normal mode is the current mode, also if the last mode was Visual mode.
                The reason I want to know what the previous mode was is because I create
                a function that makes changes on the text depending on if the text was
                from a visual selection or if a range was specified.

                Best regards

                Jens
              • Antoine J. Mechelynck
                ... If it was from a visual selection, then a range was specified; and that range is
                Message 7 of 14 , Jan 10, 2005
                • 0 Attachment
                  Jens Paulus wrote:
                  > Hi Bram,
                  >
                  > On Mon, Jan 10, 2005 at 19:14:53 +0100, Bram Moolenaar wrote:
                  >
                  >>>Let me ask a little question. When being in command line I am looking
                  >>>for a way to figure out if the command line has been entered from Visual
                  >>>mode or from Normal mode. Neither visualmode() nor mode() help because
                  >>>the first one is for something else and the second one does not react
                  >>>how I want it.
                  >>
                  >>You need to use another method. For example by using ":vmap" or
                  >>invoking mode() before leaving Visual mode.
                  >
                  >
                  > yes I know, but it seems impossible to invoke mode() before leaving
                  > Visual mode. To invoke mode() it requires that a function call from the
                  > command line is done and this always deliveres the information that
                  > Normal mode is the current mode, also if the last mode was Visual mode.
                  > The reason I want to know what the previous mode was is because I create
                  > a function that makes changes on the text depending on if the text was
                  > from a visual selection or if a range was specified.
                  >
                  > Best regards
                  >
                  > Jens
                  >
                  >
                  >
                  >
                  >
                  If it was from a visual selection, then a range was specified; and that
                  range is '<,'>

                  Regards,
                  Tony.
                • Jens Paulus
                  Hi Antoine, ... yes, but this range could also have been entered manually in the command line to specify a range. And from inside a function it is unknow how
                  Message 8 of 14 , Jan 11, 2005
                  • 0 Attachment
                    Hi Antoine,

                    On Tue, Jan 11, 2005 at 07:03:44 +0100, Antoine J. Mechelynck wrote:
                    > >>>Let me ask a little question. When being in command line I am looking
                    > >>>for a way to figure out if the command line has been entered from Visual
                    > >>>mode or from Normal mode. Neither visualmode() nor mode() help because
                    > >>>the first one is for something else and the second one does not react
                    > >>>how I want it.
                    > >>
                    > >>You need to use another method. For example by using ":vmap" or
                    > >>invoking mode() before leaving Visual mode.
                    > >
                    > >yes I know, but it seems impossible to invoke mode() before leaving
                    > >Visual mode. To invoke mode() it requires that a function call from the
                    > >command line is done and this always deliveres the information that
                    > >Normal mode is the current mode, also if the last mode was Visual mode.
                    > >The reason I want to know what the previous mode was is because I create
                    > >a function that makes changes on the text depending on if the text was
                    > >from a visual selection or if a range was specified.
                    > >
                    > If it was from a visual selection, then a range was specified; and that
                    > range is '<,'>

                    yes, but this range could also have been entered manually in the command
                    line to specify a range. And from inside a function it is unknow how the
                    range was specified, only the start and end of it is known.

                    Best regards

                    Jens
                  • Jens Paulus
                    Hi Bram, ... what can be observed is that when starting with -u NONE there is no delay. So it is obviously no problem with the terminal in this case. When
                    Message 9 of 14 , Jan 14, 2005
                    • 0 Attachment
                      Hi Bram,

                      On Thu, Dec 30, 2004 at 11:26:14 +0100, Bram Moolenaar wrote:
                      > > what I do not understand is why the ruler cursor position gets updated
                      > > after a timeoutlen delay when leaving Insert mode in vim but in gvim it
                      > > there is no such delay. The same is also when for example doing
                      > > 4iabcd<Esc> and the repeated text is inserted after this delay. In gvim
                      > > there are the same settings for timeoutlen, timeout, ttimeout but it
                      > > happens immediately. Starting vim with -u NONE or setting it to
                      > > nocompatible makes it work immediately and without delay. But with same
                      > > settings gvim has no delay but vim has this delay.
                      >
                      > The reason is that in a terminal there are key codes that start with
                      > Esc. When Vim receives an Esc in Insert mode it can't be sure if it is
                      > the Esc key or the start of a key code (e.g., for a cursor key). Vim
                      > then pretents to go out of Insert mode, but only really does so after
                      > 'ttimeoutlen'.
                      >
                      > You can fix this by using a terminal that uses CSI for special keys.

                      what can be observed is that when starting with -u NONE there is no
                      delay. So it is obviously no problem with the terminal in this case.
                      When starting with -u empty.filerc and empty.filerc is an empty file
                      then there is also no delay and then doing :source .vimrc there is still
                      no delay and :scriptnames shows all files which are loaded as usual.
                      Please help me to find the cause and fix it.

                      Best regards

                      Jens
                    • Jens Paulus
                      Hi Bram, ... although I do not know why this helps, my solution is to start with the option -u .vimrc and then there is no delay anymore and everything works
                      Message 10 of 14 , Jan 22, 2005
                      • 0 Attachment
                        Hi Bram,

                        On Fri, Jan 14, 2005 at 20:02:07 +0100, Jens Paulus wrote:
                        > > > what I do not understand is why the ruler cursor position gets updated
                        > > > after a timeoutlen delay when leaving Insert mode in vim but in gvim it
                        > > > there is no such delay. The same is also when for example doing
                        > > > 4iabcd<Esc> and the repeated text is inserted after this delay. In gvim
                        > > > there are the same settings for timeoutlen, timeout, ttimeout but it
                        > > > happens immediately. Starting vim with -u NONE or setting it to
                        > > > nocompatible makes it work immediately and without delay. But with same
                        > > > settings gvim has no delay but vim has this delay.
                        > >
                        > > The reason is that in a terminal there are key codes that start with
                        > > Esc. When Vim receives an Esc in Insert mode it can't be sure if it is
                        > > the Esc key or the start of a key code (e.g., for a cursor key). Vim
                        > > then pretents to go out of Insert mode, but only really does so after
                        > > 'ttimeoutlen'.
                        > >
                        > > You can fix this by using a terminal that uses CSI for special keys.
                        >
                        > what can be observed is that when starting with -u NONE there is no
                        > delay. So it is obviously no problem with the terminal in this case.
                        > When starting with -u empty.filerc and empty.filerc is an empty file
                        > then there is also no delay and then doing :source .vimrc there is still
                        > no delay and :scriptnames shows all files which are loaded as usual.
                        > Please help me to find the cause and fix it.

                        although I do not know why this helps, my solution is to start with the
                        option -u .vimrc and then there is no delay anymore and everything works
                        how it should work. Creating an alias like alias vim vim -u .vimrc is
                        also helpful.

                        Best regards

                        Jens
                      Your message has been successfully submitted and would be delivered to recipients shortly.