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

Re: keymaps and Select mode

Expand Messages
  • Bram Moolenaar
    ... The problem here is that Vim doesn t know that the character you are typing is going to be inserted. If it was a cursor movement command, language
    Message 1 of 10 , Apr 2, 2003
    • 0 Attachment
      Benji Fisher wrote:

      > Another question about keymaps (and :lmap's). Did I miss an
      > option, or do they not apply in Select mode? After
      >
      > :lnoremap a A
      > :set iminsert
      >
      > I get "A" when I type "a" in Insert mode, but I get "a" if I type it in
      > Select mode.

      The problem here is that Vim doesn't know that the character you are
      typing is going to be inserted. If it was a cursor movement command,
      language mappings do not apply to it.

      I can fix it to make the character mapped, but that means it will also
      be mapped when it results from a ":noremap" command. Do we care about
      this? It's not very likely that a ":noremap"'ed sequence starts Select
      mode and inserts a character that should not be lmapped, is it? At
      least it's more of a problem that the first inserted character isn't
      keymapped.


      *** ../vim61.435/src/normal.c Sun Mar 23 21:06:00 2003
      --- src/normal.c Wed Apr 2 21:33:50 2003
      ***************
      *** 626,632 ****
      && VIsual_select
      && (vim_isprintc(c) || c == NL || c == CR || c == K_KENTER))
      {
      ! stuffcharReadbuff(c);
      c = 'c';
      }
      #endif
      --- 626,643 ----
      && VIsual_select
      && (vim_isprintc(c) || c == NL || c == CR || c == K_KENTER))
      {
      ! # ifdef FEAT_MBYTE
      ! char_u buf[MB_MAXBYTES + 1];
      !
      ! buf[(*mb_char2bytes)(c, buf)] = NUL;
      ! # else
      ! char_u buf[2];
      !
      ! buf[0] = c;
      ! buf[1] = NUL;
      ! # endif
      ! /* was: stuffcharReadbuff(c); */
      ! (void)ins_typebuf(buf, REMAP_YES, 0, !KeyTyped, FALSE);
      c = 'c';
      }
      #endif

      --
      Overflow on /dev/null, please empty the bit bucket.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
      \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
    • Benji Fisher
      ... [patch snipped] Sorry to take so long. I just tried the patch. It seems that not only ... typing r in Select mode replaces the selection with foo .
      Message 2 of 10 , Apr 5, 2003
      • 0 Attachment
        Bram Moolenaar wrote:
        > Benji Fisher wrote:
        >
        >
        >> Another question about keymaps (and :lmap's). Did I miss an
        >>option, or do they not apply in Select mode? After
        >>
        >>:lnoremap a A
        >>:set iminsert
        >>
        >>I get "A" when I type "a" in Insert mode, but I get "a" if I type it in
        >>Select mode.
        >
        >
        > The problem here is that Vim doesn't know that the character you are
        > typing is going to be inserted. If it was a cursor movement command,
        > language mappings do not apply to it.
        >
        > I can fix it to make the character mapped, but that means it will also
        > be mapped when it results from a ":noremap" command. Do we care about
        > this? It's not very likely that a ":noremap"'ed sequence starts Select
        > mode and inserts a character that should not be lmapped, is it? At
        > least it's more of a problem that the first inserted character isn't
        > keymapped.
        [patch snipped]

        Sorry to take so long. I just tried the patch. It seems that not only
        :lmap's get applied but also :imaps. Hm. After

        :imap r foo

        typing "r" in Select mode replaces the selection with "foo". If, in addition, I do

        :vmap r R

        then typing "r" deletes the whole selection. It looks as though the :vmap makes
        vim switch from Select mode into Visual mode before applying the R.

        I think this patch does way more than advertised. Maybe it is time to
        promote Select mode to full status, instead of keeping it as a sub-mode of
        Visual, and give it its own :smap's? (Probably not.) Anyway, Select mode is
        currently broken as far as keymaps (or :lmaps) are concerned, so I think it is
        worth trying again.

        --Benji Fisher
      • Dorai Sitaram
        Here are two patches to filetype.vim and scripts.vim respectively. Their purpose: 1. Recognize *.art files as ft=art 2. Recognize *.ss files as ft=scheme 3.
        Message 3 of 10 , Apr 5, 2003
        • 0 Attachment
          Here are two patches to filetype.vim and
          scripts.vim respectively. Their purpose:

          1. Recognize *.art files as ft=art

          2. Recognize *.ss files as ft=scheme

          3. Identify Scheme scripts as ft=scheme based on
          either having a first line with a #! line containing
          'scheme', or having either the first or second line
          contain 'scheme'.

          I've also provided ftplugin/art.vim, ftplugin/lisp.vim,
          ftplugin/scheme.vim, and syntax/art.vim in
          http://www.ccs.neu.edu/~dorai/vimplugins/vimplugins.html
          (download link is just below title).

          Patches for filetype.vim and scripts.vim follow:


          *** filetype.vim.new Sat Apr 5 22:03:40 2003
          --- filetype.vim Mon May 6 16:22:49 2002
          ***************
          *** 97,105 ****
          " Arc Macro Language
          au BufNewFile,BufRead *.aml setf aml

          - " ART-IM, ART*Enterprise
          - au BufNewFile,BufRead *.art setf art
          -
          " ASN.1
          au BufNewFile,BufRead *.asn,*.asn1 setf asn

          --- 97,102 ----
          ***************
          *** 1049,1055 ****
          au BufNewFile,BufRead .zsh*,.zlog*,.zprofile,.zfbfmarks,.zcompdump* setf zsh

          " Scheme
          ! au BufNewFile,BufRead *.scm,*.ss setf scheme

          " Screen RC
          au BufNewFile,BufRead .screenrc,screenrc setf screen
          --- 1046,1052 ----
          au BufNewFile,BufRead .zsh*,.zlog*,.zprofile,.zfbfmarks,.zcompdump* setf zsh

          " Scheme
          ! au BufNewFile,BufRead *.scm setf scheme

          " Screen RC
          au BufNewFile,BufRead .screenrc,screenrc setf screen




          *** scripts.vim.new Sat Apr 5 22:07:36 2003
          --- scripts.vim Sat Apr 5 22:04:04 2003
          ***************
          *** 114,123 ****
          elseif s:name =~ 'wml'
          set ft=wml

          - " Scheme scripts
          - elseif s:name =~ 'scheme'
          - set ft=scheme
          -
          endif
          unlet s:name

          --- 114,119 ----
          ***************
          *** 263,272 ****
          elseif s:line1 =~ '^==\d\+== valgrind'
          set ft=valgrind

          - " Scheme scripts
          - elseif s:line1 =~ 'scheme' || s:line2 =~ 'scheme'
          - set ft=scheme
          -
          " CVS diff
          else
          let lnum = 1
          --- 259,264 ----
        • Bram Moolenaar
          ... Yes, the patch makes the first typed character be mapped as if it was typed in Insert mode. That s consistent, the second character typed will be handled
          Message 4 of 10 , Apr 6, 2003
          • 0 Attachment
            Benji Fisher wrote:

            > > The problem here is that Vim doesn't know that the character you are
            > > typing is going to be inserted. If it was a cursor movement command,
            > > language mappings do not apply to it.
            > >
            > > I can fix it to make the character mapped, but that means it will also
            > > be mapped when it results from a ":noremap" command. Do we care about
            > > this? It's not very likely that a ":noremap"'ed sequence starts Select
            > > mode and inserts a character that should not be lmapped, is it? At
            > > least it's more of a problem that the first inserted character isn't
            > > keymapped.
            > [patch snipped]
            >
            > Sorry to take so long. I just tried the patch. It seems that not only
            > :lmap's get applied but also :imaps. Hm. After
            >
            > :imap r foo
            >
            > typing "r" in Select mode replaces the selection with "foo".

            Yes, the patch makes the first typed character be mapped as if it was
            typed in Insert mode. That's consistent, the second character typed
            will be handled the same way.

            > If, in addition, I do
            >
            > :vmap r R
            >
            > then typing "r" deletes the whole selection. It looks as though the
            > :vmap makes vim switch from Select mode into Visual mode before
            > applying the R.

            Visual mode mappings apply in Select mode as if it were Visual mode.
            Thus that's correct, even though it might not do what you want. I don't
            think this has anything to do with the patch though.

            > I think this patch does way more than advertised. Maybe it is time to
            > promote Select mode to full status, instead of keeping it as a sub-mode of
            > Visual, and give it its own :smap's? (Probably not.) Anyway, Select
            > mode is currently broken as far as keymaps (or :lmaps) are concerned,
            > so I think it is worth trying again.

            I don't see a big disadvantage of this change, and it does make
            keymapping work for the first typed character in Select mode.

            --
            There are three kinds of people: Those who can count & those who can't.

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
          • Bram Moolenaar
            ... The diffs were backwards, but I understand what they do. ... I already had this one. ... That second check is too generic. A normal text file with the
            Message 5 of 10 , Apr 6, 2003
            • 0 Attachment
              Dorai wrote:

              > Here are two patches to filetype.vim and
              > scripts.vim respectively. Their purpose:

              The diffs were backwards, but I understand what they do.

              > 1. Recognize *.art files as ft=art

              I already had this one.

              > 2. Recognize *.ss files as ft=scheme
              >
              > 3. Identify Scheme scripts as ft=scheme based on
              > either having a first line with a #! line containing
              > 'scheme', or having either the first or second line
              > contain 'scheme'.

              That second check is too generic. A normal text file with the word
              "scheme" somewhere in the first two lines would be recognized as a
              scheme file. You will have this check strickter.

              > I've also provided ftplugin/art.vim, ftplugin/lisp.vim,
              > ftplugin/scheme.vim, and syntax/art.vim in
              > http://www.ccs.neu.edu/~dorai/vimplugins/vimplugins.html
              > (download link is just below title).

              I'll download them this time. If you make improvements, please send
              them to me directly.

              --
              CRONE: Who sent you?
              ARTHUR: The Knights Who Say Ni!
              CRONE: Aaaagh! (she looks around in rear) No! We have no shrubberies here.
              "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
              \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
            • Benji Fisher
              ... I know that :vmap s apply; that s why I tested it. I just think that this has to be well documented, since there is potential for confusion: which
              Message 6 of 10 , Apr 6, 2003
              • 0 Attachment
                Bram Moolenaar wrote:
                > Benji Fisher wrote:
                >
                >
                >>>I can fix it to make the character mapped, but that means it will also
                >>>be mapped when it results from a ":noremap" command. Do we care about
                >>>this? It's not very likely that a ":noremap"'ed sequence starts Select
                >>>mode and inserts a character that should not be lmapped, is it? At
                >>>least it's more of a problem that the first inserted character isn't
                >>>keymapped.
                >>
                >>[patch snipped]
                >>
                >> Sorry to take so long. I just tried the patch. It seems that not only
                >>:lmap's get applied but also :imaps. Hm. After
                >>
                >>:imap r foo
                >>
                >>typing "r" in Select mode replaces the selection with "foo".
                >
                >
                > Yes, the patch makes the first typed character be mapped as if it was
                > typed in Insert mode. That's consistent, the second character typed
                > will be handled the same way.
                >
                >
                >>If, in addition, I do
                >>
                >>:vmap r R
                >>
                >>then typing "r" deletes the whole selection. It looks as though the
                >>:vmap makes vim switch from Select mode into Visual mode before
                >>applying the R.
                >
                >
                > Visual mode mappings apply in Select mode as if it were Visual mode.
                > Thus that's correct, even though it might not do what you want. I don't
                > think this has anything to do with the patch though.

                I know that :vmap's apply; that's why I tested it. I just think that this
                has to be well documented, since there is potential for confusion: which
                mapping applies if a :vmap and an :imap and an :lmap are all defined for a given
                character?

                Although, in principle, I am bothered by ignoring the "nore"
                specification, I like the way this patch works with my word-completion script,
                http://vim.sourceforge.net/scripts/script.php?script_id=73
                The script works by defining an :imap for each [a-z], automatically doing <C-P>,
                and highlighting the completion in Select mode. With unpatched vim, every other
                character is typed in Select mode, so completions are not offered. With the
                patch, the :imap's apply in Select mode, so it works much more smoothly.

                If you are willing to go ahead with such a big change, I will "make
                install" for further testing.

                --Benji Fisher
              • Bram Moolenaar
                ... I ll add a remark in the documentation, although I think most people will find out by trying it... ... It s not really a big change, although there is a
                Message 7 of 10 , Apr 6, 2003
                • 0 Attachment
                  Benji Fisher wrote:

                  > > Visual mode mappings apply in Select mode as if it were Visual mode.
                  > > Thus that's correct, even though it might not do what you want. I don't
                  > > think this has anything to do with the patch though.
                  >
                  > I know that :vmap's apply; that's why I tested it. I just think
                  > that this has to be well documented, since there is potential for
                  > confusion: which mapping applies if a :vmap and an :imap and an :lmap
                  > are all defined for a given character?

                  I'll add a remark in the documentation, although I think most people
                  will find out by trying it...

                  > If you are willing to go ahead with such a big change, I will "make
                  > install" for further testing.

                  It's not really a big change, although there is a risk that this breaks
                  something. I intend to keep this change, thus please test it.

                  --
                  There can't be a crisis today, my schedule is already full.

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                  \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                  \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                • Dorai Sitaram
                  ... Hm, I didn t see it in the cvs d filetype.vim. ... I have made it look for exec s + S*scheme instead, i.e. exec followed by somespace followed
                  Message 8 of 10 , Apr 6, 2003
                  • 0 Attachment
                    Bram wrote:
                    >
                    > Dorai wrote:
                    >
                    > > Here are two patches to filetype.vim and
                    > > scripts.vim respectively. Their purpose:
                    >
                    > > 1. Recognize *.art files as ft=art
                    >
                    > I already had this one.

                    Hm, I didn't see it in the cvs'd filetype.vim.

                    > > 3. Identify Scheme scripts as ft=scheme based on
                    > > either having a first line with a #! line containing
                    > > 'scheme', or having either the first or second line
                    > > contain 'scheme'.
                    >
                    > That second check is too generic. A normal text file with the word
                    > "scheme" somewhere in the first two lines would be recognized as a
                    > scheme file. You will have this check strickter.

                    I have made it look for exec\s\+\S*scheme instead, i.e.
                    "exec" followed by somespace followed immediately
                    by a spaceless charseq containing "scheme". Here's the new patch
                    for scripts.vim:


                    *** scripts.vim Sat Apr 5 22:04:04 2003
                    --- scripts.vim.new Sun Apr 6 09:27:01 2003
                    ***************
                    *** 114,119 ****
                    --- 114,123 ----
                    elseif s:name =~ 'wml'
                    set ft=wml

                    + " Scheme scripts
                    + elseif s:name =~ 'scheme'
                    + set ft=scheme
                    +
                    endif
                    unlet s:name

                    ***************
                    *** 259,264 ****
                    --- 263,273 ----
                    elseif s:line1 =~ '^==\d\+== valgrind'
                    set ft=valgrind

                    + " Scheme scripts
                    + elseif s:line1 =~ 'exec\s\+\S*scheme'
                    + \ || s:line2 =~ 'exec\s\+\S*scheme'
                    + set ft=scheme
                    +
                    " CVS diff
                    else
                    let lnum = 1


                    (end of patch)



                    > > I've also provided ftplugin/art.vim, ftplugin/lisp.vim,
                    > > ftplugin/scheme.vim, and syntax/art.vim in
                    > > http://www.ccs.neu.edu/~dorai/vimplugins/vimplugins.html
                    > > (download link is just below title).
                    >
                    > I'll download them this time. If you make improvements, please send
                    > them to me directly.

                    Will do so.
                  • Bram Moolenaar
                    ... That one lags behind a bit. The one on the ftp site (runtime dir) is the most recent one. ... That looks better. I ll include this. -- The war between
                    Message 9 of 10 , Apr 6, 2003
                    • 0 Attachment
                      Dorai wrote:

                      > > > 1. Recognize *.art files as ft=art
                      > >
                      > > I already had this one.
                      >
                      > Hm, I didn't see it in the cvs'd filetype.vim.

                      That one lags behind a bit. The one on the ftp site (runtime dir) is
                      the most recent one.

                      > > > 3. Identify Scheme scripts as ft=scheme based on
                      > > > either having a first line with a #! line containing
                      > > > 'scheme', or having either the first or second line
                      > > > contain 'scheme'.
                      > >
                      > > That second check is too generic. A normal text file with the word
                      > > "scheme" somewhere in the first two lines would be recognized as a
                      > > scheme file. You will have this check strickter.
                      >
                      > I have made it look for exec\s\+\S*scheme instead, i.e.
                      > "exec" followed by somespace followed immediately
                      > by a spaceless charseq containing "scheme". Here's the new patch
                      > for scripts.vim:

                      That looks better. I'll include this.

                      --
                      The war between Emacs and Vi is over. Vi has won with 3 to 1.
                      http://www.ssc.com/lg/issue30/raymond.html

                      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                      /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                      \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                    Your message has been successfully submitted and would be delivered to recipients shortly.