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

Vim 6.0r alpha available

Expand Messages
  • Bram Moolenaar
    The first Vim in 2001! Major changes ... foldtext is now an expression instead of a strange substitute-like thing. It s more consistent with other options
    Message 1 of 25 , Jan 1, 2001
      The first Vim in 2001!


      Major changes
      -------------

      'foldtext' is now an expression instead of a strange substitute-like thing.
      It's more consistent with other options and allows more complicated
      processing.

      ":mksession" now also works fine with vertical splits. It has been further
      improved and restores the View of each window. Also works properly with
      preview and quickfix windows. Also store the argument list(s) in the session
      file.

      Added the "mkview" command: Store the settings, mappings etc. of the current
      window, so that they can be restored later. It's like ":mksession" for one
      window. It also contains manually created, opened and closed folds.

      Added "curdir" and "sesdir" to 'sessionoptions'. Allows selection of what
      the current directory will be restored to. 'sessionoptions' now includes
      "curdir" by default. This means that restoring a session will result in the
      current directory being restored, instead of going to the directory where the
      session file is located.

      Added a debugging mode. Useful to see what happens in sourced scripts and
      executed user functions.
      - ":debug" command to debug a single command.
      - "-D" argument to debug while starting up.
      - ":breakadd", ":breakdel" and ":breaklist" to set breakpoints at a line in a
      script or user function.

      GUI: When a vertically split window doesn't touch the scrollbar, it will get a
      scrollbar when it becomes the current window. Windows above and below it then
      also get a scrollbar. Now it's possible to scroll every vertically split
      window, not just the ones next to a scrollbar.


      Other changes
      -------------

      On Unix glob(".*") returned "." and "..", on Windows it didn't. On Windows
      glob("*") also returned files starting with a dot. Made this work like Unix
      on all systems.

      Added inputsecret(): Ask the user to type a string without showing the typed
      keys. (Charles Campbell)

      In the verbose message about returning from a function, also show the return
      value.

      Added 'previewwindow' option: Set in the preview window. Used in a session
      file to mark a window as the preview window.

      When a swap file already exists, and the user selects "Delete" at the
      ATTENTION prompt, use the same ".swp" swapfile, to avoid creating a ".swo"
      file which won't always be found.

      Added Debian Control file and Debian Changelog syntax files. (Wichert
      Akkerman)

      Added filewritable(). (Ron Aaron)

      Added Italian message translations. (Antonio Colombo)

      When 'modifiable' isn't set, show a '-' in the window title.

      Evaluate 'includeexpr' and 'statusline' in the sandbox, for extra safety.


      Fixes
      -----

      When making a change in the first line of the window, all lines would be
      redisplayed. This leads to errors when "$" is in 'cpoptions'.

      There was an absolute path in the Makefile for the dependency on if_perl.o.
      Put patchlevel.h in <> instead of "".

      GUI Motif: Creating a toolbar item for which there is no icon would cause an X
      error. The "pixmap" variable was not initialized.

      ":echomsg" and ":echoerr" did not check for a following "|" separated command
      when not being executed in an "if 0". (Mark Wagonner)

      Win32: Removed old code to open a console. Vimrun is now used and works fine.

      Compute the room needed by the intro message accurately, so that it also fits
      on a 25 line console. (Craig Barkhouse)

      ":ptnext" was broken. Now remember the last tag used in the preview window
      separately from the tagstack.

      Didn't check for "-display" being the last argument. (Wichert Akkerman)

      GTK GUI: When starting "gvim" under some conditions there would be an X error.
      Don't replace the error handler when creating the xterm clipboard. (Wichert
      Akkerman)

      Adding a space after a help tag caused the tag not to be found. E.g., ":he
      autoindent ".

      Was trying to expand a URL into a full path name. On Windows this resulted in
      the current directory to be prepended to the URL. Added vim_isAbsName() and
      vim_FullName() to avoid that various machine specific functions do it
      differently.

      When reading a UTF-8 file an error would be detected when there was an
      incomplete byte sequence at the end of the read bytes. Now ignore that and
      check after reading more characters.

      UTF-8: made a few regexp things working. (Alexey Marinichev)

      Multi-byte: linewise Visual selection highlighting stopped at the cursor when
      it was on a double-wide character.
      Yanking a Visual selection that includes a character past the end of the line
      could allocate zero bytes, which caused an error message.

      ":n *.c" ":cd .." ":n" didn't use the original directory of the file. Vi only
      does it for the current file (looks like a bug). Now remember the buffer used
      for the entry in the argument list and use it's name (adjusted when doing
      ":cd"), unless it's deleted.

      The scrollbar didn't work properly with closed folds. When moving the
      scrollbar in one direction text moved up and down. When the last lines of a
      file are folded, the cursor went to below it.


      Epilogue
      --------

      WARNING: This is really an unstable version. Many things have been added
      without proper testing. It does crash. It may destroy your work.

      This version is for developers, thus it comes as source code only.
      If you run into something that doesn't work, please try to figure out why,
      try to solve it and send me a patch. If you can't do that, at least send me
      precise information to save me time.

      If you don't like the syntax of a command, the name of an option or how the
      new features work, let's discuss this in the vim-dev maillist.


      More info for the new 6.0 features at ":help version6".

      Lots of things are not working yet. Check ":help todo" for known items.

      I NEED YOUR HELP: There is still a lot of work to be done. If I have to do it
      all by myself it will take a very long time until Vim.6.0 is ready. Please
      give a hand by implementing one of the items in the todo list.


      You can find it here: ftp://ftp.vim.org/pub/vim/unreleased/

      unix/vim-6.0r-rt.tar.gz runtime files
      unix/vim-6.0r-src.tar.gz sources

      extra/vim-6.0r-extra.tar.gz extra files
      extra/vim-6.0r-lang.tar.gz multi-language files

      Happy Vimming!

      --
      hundred-and-one symptoms of being an internet addict:
      165. You have a web page burned into your glasses

      /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
      ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
      \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
    • Johannes Zellner
      ... this breaks my /beautiful/ KeyPressedHandler() fun! KeyPressedHandler() let m = mode() if i != m && R != m return endif let col = col( . ) - 1 if
      Message 2 of 25 , Jan 1, 2001
        On Mon, Jan 01, 2001 at 08:52:01PM +0100, Bram Moolenaar wrote:
        > Evaluate 'includeexpr' and 'statusline' in the sandbox, for extra safety.

        this breaks my /beautiful/ KeyPressedHandler()

        fun! KeyPressedHandler()
        let m = mode()
        if 'i' != m && 'R' != m
        return ''
        endif
        let col = col('.') - 1
        if !col || getline('.')[col - 1] !~ '\k'
        if '' != mapcheck('<tab>', 'i')
        iunmap <tab>
        endif
        elseif '' == mapcheck('<tab>', 'i')
        imap <tab> <c-p>
        endif
        if '' != mapcheck('<tab>', 'i')
        return '<complete>'
        else
        return '<tab>'
        endif
        endfun

        set statusline=%<[%n]%f%y%r%1*%m%*%w%4(%)%2*%{KeyPressedHandler()}%*%=%(C\ %c%V%)%4(%)%-10(L\ %l(%L)%)%4(%)%p%%

        :-(

        as 'imap' and iunmap are not allowed in a 'sandbox'.
        Does anyone have any idea how I could get back the
        functionality of this handler:

        - <tab> works like ins-complete, if the cursor is behind a keyword char.
        - <tab> just inserts a tab, if the cursor is behind anything else.

        --
        Johannes
      • Michael Geddes
        modifiable has a couple of holes: ... u undo and redo still work even though modifiable is not set. also: i :set
        Message 3 of 25 , Jan 1, 2001
          modifiable has a couple of holes:

          <edit a file>
          <change some stuff>
          :set noma
          u<c-r>

          undo and redo still work even though modifiable is not set.

          also:

          i<c-o>:set noma<cr>blahblahblah


          setting noma from <c-o> still allows you to type stuff. Not good if you are
          using insertmode


          //.ichael G.


          -----Original Message-----
          From: Bram Moolenaar [SMTP:Bram@...]
          Sent: Tuesday, 2 January 2001 6:52
          To: vim-dev@...
          Subject: Vim 6.0r alpha available


          The first Vim in 2001!


          Major changes
          -------------

          'foldtext' is now an expression instead of a strange substitute-like
          thing.
          It's more consistent with other options and allows more complicated
          processing.

          ":mksession" now also works fine with vertical splits. It has been
          further
          improved and restores the View of each window. Also works properly
          with
          preview and quickfix windows. Also store the argument list(s) in
          the session
          file.

          Added the "mkview" command: Store the settings, mappings etc. of the
          current
          window, so that they can be restored later. It's like ":mksession"
          for one
          window. It also contains manually created, opened and closed folds.

          Added "curdir" and "sesdir" to 'sessionoptions'. Allows selection
          of what
          the current directory will be restored to. 'sessionoptions' now
          includes
          "curdir" by default. This means that restoring a session will
          result in the
          current directory being restored, instead of going to the directory
          where the
          session file is located.

          Added a debugging mode. Useful to see what happens in sourced
          scripts and
          executed user functions.
          - ":debug" command to debug a single command.
          - "-D" argument to debug while starting up.
          - ":breakadd", ":breakdel" and ":breaklist" to set breakpoints at a
          line in a
          script or user function.

          GUI: When a vertically split window doesn't touch the scrollbar, it
          will get a
          scrollbar when it becomes the current window. Windows above and
          below it then
          also get a scrollbar. Now it's possible to scroll every vertically
          split
          window, not just the ones next to a scrollbar.


          Other changes
          -------------

          On Unix glob(".*") returned "." and "..", on Windows it didn't. On
          Windows
          glob("*") also returned files starting with a dot. Made this work
          like Unix
          on all systems.

          Added inputsecret(): Ask the user to type a string without showing
          the typed
          keys. (Charles Campbell)

          In the verbose message about returning from a function, also show
          the return
          value.

          Added 'previewwindow' option: Set in the preview window. Used in a
          session
          file to mark a window as the preview window.

          When a swap file already exists, and the user selects "Delete" at
          the
          ATTENTION prompt, use the same ".swp" swapfile, to avoid creating a
          ".swo"
          file which won't always be found.

          Added Debian Control file and Debian Changelog syntax files.
          (Wichert
          Akkerman)

          Added filewritable(). (Ron Aaron)

          Added Italian message translations. (Antonio Colombo)

          When 'modifiable' isn't set, show a '-' in the window title.

          Evaluate 'includeexpr' and 'statusline' in the sandbox, for extra
          safety.


          Fixes
          -----

          When making a change in the first line of the window, all lines
          would be
          redisplayed. This leads to errors when "$" is in 'cpoptions'.

          There was an absolute path in the Makefile for the dependency on
          if_perl.o.
          Put patchlevel.h in <> instead of "".

          GUI Motif: Creating a toolbar item for which there is no icon would
          cause an X
          error. The "pixmap" variable was not initialized.

          ":echomsg" and ":echoerr" did not check for a following "|"
          separated command
          when not being executed in an "if 0". (Mark Wagonner)

          Win32: Removed old code to open a console. Vimrun is now used and
          works fine.

          Compute the room needed by the intro message accurately, so that it
          also fits
          on a 25 line console. (Craig Barkhouse)

          ":ptnext" was broken. Now remember the last tag used in the preview
          window
          separately from the tagstack.

          Didn't check for "-display" being the last argument. (Wichert
          Akkerman)

          GTK GUI: When starting "gvim" under some conditions there would be
          an X error.
          Don't replace the error handler when creating the xterm clipboard.
          (Wichert
          Akkerman)

          Adding a space after a help tag caused the tag not to be found.
          E.g., ":he
          autoindent ".

          Was trying to expand a URL into a full path name. On Windows this
          resulted in
          the current directory to be prepended to the URL. Added
          vim_isAbsName() and
          vim_FullName() to avoid that various machine specific functions do
          it
          differently.

          When reading a UTF-8 file an error would be detected when there was
          an
          incomplete byte sequence at the end of the read bytes. Now ignore
          that and
          check after reading more characters.

          UTF-8: made a few regexp things working. (Alexey Marinichev)

          Multi-byte: linewise Visual selection highlighting stopped at the
          cursor when
          it was on a double-wide character.
          Yanking a Visual selection that includes a character past the end of
          the line
          could allocate zero bytes, which caused an error message.

          ":n *.c" ":cd .." ":n" didn't use the original directory of the
          file. Vi only
          does it for the current file (looks like a bug). Now remember the
          buffer used
          for the entry in the argument list and use it's name (adjusted when
          doing
          ":cd"), unless it's deleted.

          The scrollbar didn't work properly with closed folds. When moving
          the
          scrollbar in one direction text moved up and down. When the last
          lines of a
          file are folded, the cursor went to below it.


          Epilogue
          --------

          WARNING: This is really an unstable version. Many things have been
          added
          without proper testing. It does crash. It may destroy your work.

          This version is for developers, thus it comes as source code only.
          If you run into something that doesn't work, please try to figure
          out why,
          try to solve it and send me a patch. If you can't do that, at least
          send me
          precise information to save me time.

          If you don't like the syntax of a command, the name of an option or
          how the
          new features work, let's discuss this in the vim-dev maillist.


          More info for the new 6.0 features at ":help version6".

          Lots of things are not working yet. Check ":help todo" for known
          items.

          I NEED YOUR HELP: There is still a lot of work to be done. If I
          have to do it
          all by myself it will take a very long time until Vim.6.0 is ready.
          Please
          give a hand by implementing one of the items in the todo list.


          You can find it here: ftp://ftp.vim.org/pub/vim/unreleased/

          unix/vim-6.0r-rt.tar.gz runtime files
          unix/vim-6.0r-src.tar.gz sources

          extra/vim-6.0r-extra.tar.gz extra files
          extra/vim-6.0r-lang.tar.gz multi-language files

          Happy Vimming!

          --
          hundred-and-one symptoms of being an internet addict:
          165. You have a web page burned into your glasses

          /// Bram Moolenaar -- Bram@... --
          http://www.moolenaar.net \\\
          ((( Creator of Vim - http://www.vim.org --
          ftp://ftp.vim.org/pub/vim )))
          \\\ Help me helping AIDS orphans in Uganda -
          http://iccf-holland.org ///
        • Rafael Garcia-Suarez
          It doesn t compile with +eval and without +crypt. Quick patch attached. -- Rafael Garcia-Suarez ... +++ ex_getln.c Tue Jan 2 09:07:29 2001 @@ -1836,7 +1836,7
          Message 4 of 25 , Jan 2, 2001
            It doesn't compile with +eval and without +crypt. Quick patch attached.

            --
            Rafael Garcia-Suarez
          • Rafael Garcia-Suarez
            ... An idea : Make KeyPressedHandler just return the string or and store it in a variable g:keypressedhandlerstatus. Map to a small
            Message 5 of 25 , Jan 2, 2001
              Johannes Zellner wrote:
              >
              > On Mon, Jan 01, 2001 at 08:52:01PM +0100, Bram Moolenaar wrote:
              > > Evaluate 'includeexpr' and 'statusline' in the sandbox, for extra safety.
              >
              > this breaks my /beautiful/ KeyPressedHandler()
              >
              > fun! KeyPressedHandler()
              > let m = mode()
              > if 'i' != m && 'R' != m
              > return ''
              > endif
              > let col = col('.') - 1
              > if !col || getline('.')[col - 1] !~ '\k'
              > if '' != mapcheck('<tab>', 'i')
              > iunmap <tab>
              > endif
              > elseif '' == mapcheck('<tab>', 'i')
              > imap <tab> <c-p>
              > endif
              > if '' != mapcheck('<tab>', 'i')
              > return '<complete>'
              > else
              > return '<tab>'
              > endif
              > endfun
              >
              > set statusline=%<[%n]%f%y%r%1*%m%*%w%4(%)%2*%{KeyPressedHandler()}%*%=%(C\ %c%V%)%4(%)%-10(L\ %l(%L)%)%4(%)%p%%
              >
              > :-(
              >
              > as 'imap' and iunmap are not allowed in a 'sandbox'.
              > Does anyone have any idea how I could get back the
              > functionality of this handler:
              >
              > - <tab> works like ins-complete, if the cursor is behind a keyword char.
              > - <tab> just inserts a tab, if the cursor is behind anything else.

              An idea :
              Make KeyPressedHandler just return the string <complete> or <tab> and
              store it in a variable g:keypressedhandlerstatus. Map <tab> to a small
              function that checks the value of g:keypressedhandlerstatus and that
              does <c-p> or the regular <tab> depending on this value.

              --
              Rafael Garcia-Suarez
            • Bram Moolenaar
              ... It s good that you check this. It has been implemented in a way that preparing for undo fails, which should cause the change to be cancelled. But not all
              Message 6 of 25 , Jan 2, 2001
                Michael Geddes wrote:

                > modifiable has a couple of holes:

                It's good that you check this. It has been implemented in a way that
                preparing for undo fails, which should cause the change to be cancelled. But
                not all places check the return value of the save-for-undo function. That had
                to be fixed anyway.

                > <edit a file>
                > <change some stuff>
                > :set noma
                > u<c-r>
                >
                > undo and redo still work even though modifiable is not set.

                I'll fix that.

                > also:
                >
                > i<c-o>:set noma<cr>blahblahblah
                >
                > setting noma from <c-o> still allows you to type stuff. Not good if you are
                > using insertmode

                Aha, the insert functions never checked if undo really worked. I also
                discovered that inserting a special key as its name could not be undone (e.g.,
                hitting <F7> in Insert mode after moving around with the cursor keys).

                Interesting how adding a new feature reveals bugs in older features...

                --
                "Hit any key to continue" is very confusing when you have two keyboards.

                /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
              • Bram Moolenaar
                ... Thanks, I ll include this patch. -- Did you ever see a Hit any key to continue message in a music piece? /// Bram Moolenaar -- Bram@moolenaar.net --
                Message 7 of 25 , Jan 2, 2001
                  Rafael Garcia-Suarez wrote:

                  > It doesn't compile with +eval and without +crypt. Quick patch attached.

                  Thanks, I'll include this patch.

                  --
                  Did you ever see a "Hit any key to continue" message in a music piece?

                  /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                  ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                  \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                • Bram Moolenaar
                  ... [...] ... Hmm, you are using the fact that the custom statusline is redrawn after each typed character. It works, although it wasn t really intended for
                  Message 8 of 25 , Jan 2, 2001
                    Johannes Zellner wrote:

                    > On Mon, Jan 01, 2001 at 08:52:01PM +0100, Bram Moolenaar wrote:
                    > > Evaluate 'includeexpr' and 'statusline' in the sandbox, for extra safety.
                    >
                    > this breaks my /beautiful/ KeyPressedHandler()
                    [...]
                    > as 'imap' and iunmap are not allowed in a 'sandbox'.
                    > Does anyone have any idea how I could get back the
                    > functionality of this handler:
                    >
                    > - <tab> works like ins-complete, if the cursor is behind a keyword char.
                    > - <tab> just inserts a tab, if the cursor is behind anything else.

                    Hmm, you are using the fact that the custom statusline is redrawn after each
                    typed character. It works, although it wasn't really intended for this.

                    We could add an autocommand that gets triggered after each inserted character.
                    It would cause a lot of overhead though, mostly because we need to match the
                    pattern with the file name. That could be reduced by only doing it for
                    a specific buffer.

                    We don't have buffer-local autocommands yet. Do we need this? It seems like
                    a logical extension of buffer-local mappings.

                    We could then add autocommand events for inserting a character, moving the
                    cursor and switching mode. This probably requires a few restrictions to avoid
                    causing overhead and messing things up.

                    A completely different solution to the original problem would be to disallow
                    setting 'statusline' from a modeline. Then it's safe enough to execute it
                    outside of the sandbox. Would anyone set 'statusline' from a modeline?

                    --
                    In Joseph Heller's novel "Catch-22", the main character tries to get out of a
                    war by proving he is crazy. But the mere fact he wants to get out of the war
                    only shows he isn't crazy -- creating the original "Catch-22".

                    /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                    ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                    \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                  • Johannes Zellner
                    ... no this doesn t work. This boils down to: inoremap =TabFun() fun! TabFun() return endfun I tried multiple approaches with this and
                    Message 9 of 25 , Jan 2, 2001
                      On Tue, Jan 02, 2001 at 09:53:43AM +0100, Rafael Garcia-Suarez wrote:
                      > Johannes Zellner wrote:
                      > >
                      > > On Mon, Jan 01, 2001 at 08:52:01PM +0100, Bram Moolenaar wrote:
                      > > > Evaluate 'includeexpr' and 'statusline' in the sandbox, for extra safety.
                      > >
                      > > this breaks my /beautiful/ KeyPressedHandler()
                      > >
                      > > fun! KeyPressedHandler()
                      > > let m = mode()
                      > > if 'i' != m && 'R' != m
                      > > return ''
                      > > endif
                      > > let col = col('.') - 1
                      > > if !col || getline('.')[col - 1] !~ '\k'
                      > > if '' != mapcheck('<tab>', 'i')
                      > > iunmap <tab>
                      > > endif
                      > > elseif '' == mapcheck('<tab>', 'i')
                      > > imap <tab> <c-p>
                      > > endif
                      > > if '' != mapcheck('<tab>', 'i')
                      > > return '<complete>'
                      > > else
                      > > return '<tab>'
                      > > endif
                      > > endfun
                      > >
                      > > set statusline=%<[%n]%f%y%r%1*%m%*%w%4(%)%2*%{KeyPressedHandler()}%*%=%(C\ %c%V%)%4(%)%-10(L\ %l(%L)%)%4(%)%p%%
                      > >
                      > > :-(
                      > >
                      > > as 'imap' and iunmap are not allowed in a 'sandbox'.
                      > > Does anyone have any idea how I could get back the
                      > > functionality of this handler:
                      > >
                      > > - <tab> works like ins-complete, if the cursor is behind a keyword char.
                      > > - <tab> just inserts a tab, if the cursor is behind anything else.
                      >
                      > An idea :
                      > Make KeyPressedHandler just return the string <complete> or <tab> and
                      > store it in a variable g:keypressedhandlerstatus. Map <tab> to a small
                      > function that checks the value of g:keypressedhandlerstatus and that
                      > does <c-p> or the regular <tab> depending on this value.

                      no this doesn't work. This boils down to:

                      inoremap <tab> <c-r>=TabFun()<cr>
                      fun! TabFun()
                      return "\<c-p>"
                      endfun

                      I tried multiple approaches with this and figured out that it
                      can't work, because the ins-completion interferes with the <cr>.
                      Actually it will work when hitting the first time <tab> (and
                      TabFun() returns <c-p>), but hitting the second time <tab>
                      (in a row) the <c-p> as returned by TabFun() won't trigger
                      the next match.

                      --
                      Johannes
                    • Johannes Zellner
                      ... yes, I m aware that I misused the stl. But it worked like a charm. ... [...] I wouldn t make it too complicated (although I d /really/ like to get get my
                      Message 10 of 25 , Jan 2, 2001
                        On Tue, Jan 02, 2001 at 11:28:26AM +0100, Bram Moolenaar wrote:
                        >
                        > Johannes Zellner wrote:
                        >
                        > > On Mon, Jan 01, 2001 at 08:52:01PM +0100, Bram Moolenaar wrote:
                        > > > Evaluate 'includeexpr' and 'statusline' in the sandbox, for extra safety.
                        > >
                        > > this breaks my /beautiful/ KeyPressedHandler()
                        > [...]
                        > > as 'imap' and iunmap are not allowed in a 'sandbox'.
                        > > Does anyone have any idea how I could get back the
                        > > functionality of this handler:
                        > >
                        > > - <tab> works like ins-complete, if the cursor is behind a keyword char.
                        > > - <tab> just inserts a tab, if the cursor is behind anything else.
                        >
                        > Hmm, you are using the fact that the custom statusline is redrawn after each
                        > typed character. It works, although it wasn't really intended for this.

                        yes, I'm aware that I misused the stl. But it worked like a charm.

                        > We could add an autocommand that gets triggered after each inserted character.
                        > It would cause a lot of overhead though, mostly because we need to match the
                        > pattern with the file name. That could be reduced by only doing it for
                        > a specific buffer.
                        [...]

                        I wouldn't make it too complicated (although I'd /really/ like
                        to get get my old behaviour back -- it's really convenient IMHO).

                        Apparently, there are alreay autocommands which trigger on ft
                        instead of a file extension (FileType). So the third part of
                        `autocmd' is not consistent between autocommand types anyway.
                        The question is, what the third part of the KeyPressed autocmd
                        should specify (extension or filetype ?). As I understand you
                        this could make the autocommand slow. But I guess a simple '*'
                        must be fast, because one can immediately say that it matches
                        all buffers (which will be the common case, I guess).

                        so:

                        au KeyPressed * ...

                        shouldn't be slow, isn't it ? -- And the syntax is the same
                        as for all other autocommands!

                        I would prefer this solution over allowing again imap in
                        stl, because the way I used stl was a dirty trick, but
                        a KeyPressed autocmd is a clean solution.

                        --
                        Johannes
                      • Bram Moolenaar
                        ... That s true. But it doesn t apply here. Suppose we add a CharInserted ... Thus the pattern would be useful here. But might be slow, because the
                        Message 11 of 25 , Jan 2, 2001
                          Johannes Zellner wrote:

                          > Apparently, there are alreay autocommands which trigger on ft
                          > instead of a file extension (FileType). So the third part of
                          > `autocmd' is not consistent between autocommand types anyway.

                          That's true. But it doesn't apply here. Suppose we add a "CharInserted"
                          event, then you might want to do:

                          :au CharInserted *.[ch] do-something

                          Thus the pattern would be useful here. But might be slow, because the pattern
                          has to be matched against the file name for every typed character..

                          > The question is, what the third part of the KeyPressed autocmd
                          > should specify (extension or filetype ?). As I understand you
                          > this could make the autocommand slow. But I guess a simple '*'
                          > must be fast, because one can immediately say that it matches
                          > all buffers (which will be the common case, I guess).

                          It's also slow because the regexp has to be compiled, functions called, memory
                          allocated and freed... Even when there is no autocommand defined there is
                          some overhead, but that should be minimal.

                          When defining a buffer-local autocommand, the pattern could be simply ignored.
                          That should speed up things a bit. In fact, we could replace the pattern with
                          "<buffer>" to specify a buffer-local autocommand:

                          :au CharInserted <buffer> ...

                          Doesn't look to bad, does it?

                          > so:
                          >
                          > au KeyPressed * ...
                          >
                          > shouldn't be slow, isn't it ? -- And the syntax is the same
                          > as for all other autocommands!

                          Yes, but there are many places where a key press would need to be checked for,
                          thus creating overhead (and a bigger executable). I would like to keep this
                          down to a minimum. Also because autocommands can have nasty side effects,
                          which need to be checked for (can you imagine an autocommand closing the
                          window while in the middle of inserting some text?).

                          > I would prefer this solution over allowing again imap in
                          > stl, because the way I used stl was a dirty trick, but
                          > a KeyPressed autocmd is a clean solution.

                          "KeyPressed" sounds a bit too generic. For your purpose you would need a
                          "CharInserted" event. Although a "TextChanged" event could also be used. All
                          this isn't easy to implement though, mostly because there isn't a single place
                          where the event can be triggered, and it's deep down in code that might suffer
                          from the side effects of executing the autocommand. The implementation will
                          restrict the type of events that can be triggered.

                          --
                          Very funny, Scotty. Now beam down my clothes.

                          /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                          ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                          \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                        • Ron Aaron
                          ... I would go for this solution, as it is clean. Look at the FuncUndefined autocommand -- it also ignores the pattern, and fires if a func called is
                          Message 12 of 25 , Jan 2, 2001
                            Johannes Zellner <johannes@...> writes:
                            >On Tue, Jan 02, 2001 at 11:28:26AM +0100, Bram Moolenaar wrote:
                            >> We could add an autocommand that gets triggered after each inserted character.
                            >> It would cause a lot of overhead though, mostly because we need to match the
                            >> pattern with the file name. That could be reduced by only doing it for
                            >> a specific buffer.
                            >The question is, what the third part of the KeyPressed autocmd
                            >should specify (extension or filetype ?). As I understand you
                            >this could make the autocommand slow. But I guess a simple '*'
                            >must be fast, because one can immediately say that it matches
                            >all buffers (which will be the common case, I guess).
                            >
                            >so:
                            >
                            > au KeyPressed * ...
                            >
                            >shouldn't be slow, isn't it ? -- And the syntax is the same
                            >as for all other autocommands!

                            I would go for this solution, as it is clean. Look at the FuncUndefined
                            autocommand -- it also ignores the pattern, and fires if a func called is
                            undefined whatever buffer happens to be loaded. So too with the KeyPressed,
                            one should just fire off if it exists (and it can be ignored if requested via
                            'eventignore').

                            Running a command on each keypress might indeed be slow, but if a person
                            decides to do that, so be it! I would, BTW, make it something like:

                            au KeyPressed * OnKeyPressed

                            so the OnKeyPressed function just gets called, and has the form:


                            func OnKeyPressed(incoming_key)
                            return modified_key
                            endfunc

                            so if the user wants to munge the keys in a more complicated way than maps can
                            do, s/he can do so...

                            Regards,

                            Ron
                          • Benji Fisher
                            ... [snip] ... I do not have any suggestions for making it faster or more robust, but I would like to put in a weak vote in favor of adding some such
                            Message 13 of 25 , Jan 2, 2001
                              Bram Moolenaar wrote:
                              >
                              > Johannes Zellner wrote:
                              >
                              > > Apparently, there are alreay autocommands which trigger on ft
                              > > instead of a file extension (FileType). So the third part of
                              > > `autocmd' is not consistent between autocommand types anyway.
                              >
                              > That's true. But it doesn't apply here. Suppose we add a "CharInserted"
                              > event, then you might want to do:
                              >
                              > :au CharInserted *.[ch] do-something
                              >
                              > Thus the pattern would be useful here. But might be slow, because the pattern
                              > has to be matched against the file name for every typed character..
                              >
                              [snip]
                              >
                              > "KeyPressed" sounds a bit too generic. For your purpose you would need a
                              > "CharInserted" event. Although a "TextChanged" event could also be used. All
                              > this isn't easy to implement though, mostly because there isn't a single place
                              > where the event can be triggered, and it's deep down in code that might suffer
                              > from the side effects of executing the autocommand. The implementation will
                              > restrict the type of events that can be triggered.

                              I do not have any suggestions for making it faster or more robust,
                              but I would like to put in a weak vote in favor of adding some such
                              autocommand. You see, some folks actually use the word_complete.vim
                              script that I wrote a while ago. Basically, this invokes <C-P>
                              automatically and leaves the added characters in Select mode, so they can
                              be removed by further typing. This script would be a lot easier to write,
                              and work better, if I could use a CharInserted autocommand instead of a
                              bunch of :imaps.

                              On the subject of new autocommand events, am I the only one who would
                              like to have a way to do something every time a variable (global or
                              buffer, say) is modified? (Have a look at my matchit.vim script and see
                              how much processing is done each time you press %!)

                              --Benji Fisher
                            • Zdenek Sekera
                              ... I d use it, too. And right now. ... Quite right, it is impressive and really fast, too. By the way, I can see the usefullnes of CharInserted or
                              Message 14 of 25 , Jan 2, 2001
                                Benji Fisher wrote:
                                >
                                ...
                                > On the subject of new autocommand events, am I the only one who would
                                > like to have a way to do something every time a variable (global or
                                > buffer, say) is modified?

                                I'd use it, too. And right now.

                                > (Have a look at my matchit.vim script and see
                                > how much processing is done each time you press %!)

                                Quite right, it is impressive and really fast, too.

                                By the way, I can see the usefullnes of 'CharInserted' or 'KeyPressed'
                                event as well.

                                ---Zdenek
                              • Bram Moolenaar
                                ... We need to be more specific about when this event would be triggered. Does it need to be local to a buffer? Is it also triggered after an :imap was
                                Message 15 of 25 , Jan 2, 2001
                                  Benji Fisher wrote:

                                  > I do not have any suggestions for making it faster or more robust,
                                  > but I would like to put in a weak vote in favor of adding some such
                                  > autocommand. You see, some folks actually use the word_complete.vim
                                  > script that I wrote a while ago. Basically, this invokes <C-P>
                                  > automatically and leaves the added characters in Select mode, so they can
                                  > be removed by further typing. This script would be a lot easier to write,
                                  > and work better, if I could use a CharInserted autocommand instead of a
                                  > bunch of :imaps.

                                  We need to be more specific about when this event would be triggered. Does it
                                  need to be local to a buffer? Is it also triggered after an ":imap" was
                                  expanded? Or perhaps for every character that an ":imap" inserted? Perhaps
                                  it's sufficient to trigger the event when the user typed the character and not
                                  when it's the result of some mapping or script?

                                  These details matter a lot when you are actually going to use the event. I
                                  want to know in advance how it would need to work, so that I can estimate how
                                  much work it would be to implement.

                                  > On the subject of new autocommand events, am I the only one who would
                                  > like to have a way to do something every time a variable (global or
                                  > buffer, say) is modified? (Have a look at my matchit.vim script and see
                                  > how much processing is done each time you press %!)

                                  How much processing do you want to do when any other command is executed that
                                  uses (global/buffer) variables?

                                  --
                                  Wizards had always known that the act of observation changed the thing that
                                  was observed, and sometimes forgot that it also changed the observer too.
                                  Terry Pratchett - Interesting times

                                  /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                  ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                                  \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                • Benji Fisher
                                  ... I am willing to go with whatever option is easiest to implement and most efficient. If you want my preferences, a local-to-buffer option would be nice,
                                  Message 16 of 25 , Jan 2, 2001
                                    Bram Moolenaar wrote:
                                    >
                                    > Benji Fisher wrote:
                                    >
                                    > > I do not have any suggestions for making it faster or more robust,
                                    > > but I would like to put in a weak vote in favor of adding some such
                                    > > autocommand. You see, some folks actually use the word_complete.vim
                                    > > script that I wrote a while ago. Basically, this invokes <C-P>
                                    > > automatically and leaves the added characters in Select mode, so they can
                                    > > be removed by further typing. This script would be a lot easier to write,
                                    > > and work better, if I could use a CharInserted autocommand instead of a
                                    > > bunch of :imaps.
                                    >
                                    > We need to be more specific about when this event would be triggered. Does it
                                    > need to be local to a buffer? Is it also triggered after an ":imap" was
                                    > expanded? Or perhaps for every character that an ":imap" inserted? Perhaps
                                    > it's sufficient to trigger the event when the user typed the character and not
                                    > when it's the result of some mapping or script?
                                    >
                                    > These details matter a lot when you are actually going to use the event. I
                                    > want to know in advance how it would need to work, so that I can estimate how
                                    > much work it would be to implement.
                                    >
                                    > > On the subject of new autocommand events, am I the only one who would
                                    > > like to have a way to do something every time a variable (global or
                                    > > buffer, say) is modified? (Have a look at my matchit.vim script and see
                                    > > how much processing is done each time you press %!)
                                    >
                                    > How much processing do you want to do when any other command is executed that
                                    > uses (global/buffer) variables?

                                    I am willing to go with whatever option is easiest to implement and
                                    most efficient. If you want my preferences, a local-to-buffer option
                                    would be nice, and a CharacterActuallyTypedByUser event would be
                                    preferable to a CharacterInsertedByAnyMeans event. ;)

                                    I am not sure I understand your last question. Are you suggesting
                                    that a GlobalVariableTwiddled autocommand event would involve too much
                                    overhead, since it would be triggered every time a script accessed a
                                    global variable? If so, I can see your point. OTOH, as a writer of vim
                                    scripts, I prefer to use local variables as much as possible anyway, so I
                                    do not often use global ones. From the same point of view, I envy writers
                                    of vim internals, who can get the same effect that I want whenever the
                                    user changes an option.

                                    This may be a very big can of worms, but another option would be to
                                    allow user-defined options, in addition to user-defined global variables.
                                    Allow autocommands to be triggered when these options are changed. This
                                    would solve the problem of overhead, since the autocommands would not have
                                    to be checked when regular variables were changed.

                                    --Benji Fisher
                                  • Bram Moolenaar
                                    ... Since a user only types so many characters per second, it s not too bad to have some extra processing per character. Making this local to a buffer will
                                    Message 17 of 25 , Jan 3, 2001
                                      Benji Fisher wrote:

                                      > I am willing to go with whatever option is easiest to implement and
                                      > most efficient. If you want my preferences, a local-to-buffer option
                                      > would be nice, and a CharacterActuallyTypedByUser event would be
                                      > preferable to a CharacterInsertedByAnyMeans event. ;)

                                      Since a user only types so many characters per second, it's not too bad to
                                      have some extra processing per character. Making this local to a buffer will
                                      further reduce the need to do regexp stuff. You could always define it for
                                      every buffer opened with an autocommand that installs the buffer-local
                                      autocommand, if you really need that.

                                      Now, when would the event need to be triggered? After typing a character that
                                      is inserted in the text? Before or after the character is inserted? If it's
                                      before, you might want to change the inserted character. That could be done
                                      with a Vim variable, which you can change. That sounds simple enough.

                                      > I am not sure I understand your last question. Are you suggesting
                                      > that a GlobalVariableTwiddled autocommand event would involve too much
                                      > overhead, since it would be triggered every time a script accessed a
                                      > global variable? If so, I can see your point. OTOH, as a writer of vim
                                      > scripts, I prefer to use local variables as much as possible anyway, so I
                                      > do not often use global ones. From the same point of view, I envy writers
                                      > of vim internals, who can get the same effect that I want whenever the
                                      > user changes an option.

                                      Well, some scripts might want to use global variables anyway. And when there
                                      is an autocommand for changing a global variable, it's a matter of time before
                                      someone asks for an event on script variables.

                                      Actually, it's not clear to me why you would want to do something when a
                                      global variable is changed.

                                      > This may be a very big can of worms, but another option would be to
                                      > allow user-defined options, in addition to user-defined global variables.
                                      > Allow autocommands to be triggered when these options are changed. This
                                      > would solve the problem of overhead, since the autocommands would not have
                                      > to be checked when regular variables were changed.

                                      I don't intend to add user-defined options. Global variables do the same
                                      thing.

                                      --
                                      hundred-and-one symptoms of being an internet addict:
                                      194. Your business cards contain your e-mail and home page address.

                                      /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                      ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                                      \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                    • Dr. Charles E. Campbell
                                      ... A fast touch-typist can do 120 words per minute, where each word has an average of 5 characters (which works out to about ten characters per second).
                                      Message 18 of 25 , Jan 3, 2001
                                        Thus saith Bram Moolenaar:
                                        > Since a user only types so many characters per second, it's not too bad to
                                        > have some extra processing per character.

                                        A fast touch-typist can do 120 "words" per minute, where each word has
                                        an average of 5 characters (which works out to about ten characters per
                                        second). Just a rule of thumb; the problem with adding keystroke
                                        overhead is testing, because not everyone types at the same speed (and
                                        individual speeds vary depending on the typing task).

                                        With that said, I doubt there's much problem with this; syntax
                                        highlighting undoubtedly slows things down rather more than the
                                        autocmd-event check would involve. Of course, one can disable syntax
                                        highlighting when that becomes a problem.

                                        Regards,
                                        C Campbell

                                        --
                                        Charles E Campbell, Jr, PhD _ __ __
                                        Goddard Space Flight Center / /_/\_\_/ /
                                        cec@... /_/ \/_//_/
                                        PGP public key: http://www.erols.com/astronaut/pgp.html/
                                      • Nils Lohner
                                        In message , Dr. Charles E. C ... How about a mouse cut-and-paste? That looks like very fast typing, right?
                                        Message 19 of 25 , Jan 3, 2001
                                          In message <200101031453.f03Er1g26256@...>, "Dr.
                                          Charles E. C
                                          ampbell" writes:
                                          >Thus saith Bram Moolenaar:
                                          >> Since a user only types so many characters per second, it's not too bad to
                                          >> have some extra processing per character.
                                          >
                                          >A fast touch-typist can do 120 "words" per minute, where each word has
                                          >an average of 5 characters (which works out to about ten characters per
                                          >second). Just a rule of thumb; the problem with adding keystroke
                                          >overhead is testing, because not everyone types at the same speed (and
                                          >individual speeds vary depending on the typing task).
                                          >

                                          How about a mouse cut-and-paste? That looks like very fast typing,
                                          right?

                                          Nils.
                                        • Dr. Charles E. Campbell
                                          ... Yes, I imagine it does, and generally that can be considerably faster than mere human speeds. Should that fall into CharacterActuallyTypedByUser or
                                          Message 20 of 25 , Jan 3, 2001
                                            Thus saith Nils Lohner:
                                            > How about a mouse cut-and-paste? That looks like very fast typing,
                                            > right?

                                            Yes, I imagine it does, and generally that can be considerably faster
                                            than mere human speeds. Should that fall into
                                            "CharacterActuallyTypedByUser" or "CharacterInsertedByAnyMeans", Benji?
                                            Can the difference be detected?

                                            Regards,
                                            C Campbell

                                            --
                                            Charles E Campbell, Jr, PhD _ __ __
                                            Goddard Space Flight Center / /_/\_\_/ /
                                            cec@... /_/ \/_//_/
                                            PGP public key: http://www.erols.com/astronaut/pgp.html/
                                          • Bram Moolenaar
                                            ... If you have the mouse disabled, or are using a terminal where the mouse doesn t work inside Vim, pasting text arrives in Vim as if it was typed. This is
                                            Message 21 of 25 , Jan 3, 2001
                                              Charles Campbell wrote:

                                              > Thus saith Nils Lohner:
                                              > > How about a mouse cut-and-paste? That looks like very fast typing,
                                              > > right?
                                              >
                                              > Yes, I imagine it does, and generally that can be considerably faster
                                              > than mere human speeds. Should that fall into
                                              > "CharacterActuallyTypedByUser" or "CharacterInsertedByAnyMeans", Benji?
                                              > Can the difference be detected?

                                              If you have the mouse disabled, or are using a terminal where the mouse
                                              doesn't work inside Vim, pasting text arrives in Vim as if it was typed. This
                                              is indeed a very fast way of typing. It's a good reason to use the mouse in
                                              Vim, if possible. And make those InsertChar autocommands really fast.

                                              --
                                              panic("Foooooooood fight!");
                                              -- In the kernel source aha1542.c, after detecting a bad segment list

                                              /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                              ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                                              \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                            • Johannes Zellner
                                              On Wed, Jan 03, 2001 at 05:40:29PM +0100, Bram Moolenaar wrote: [...] ... [...] what about disabling InsertChar if paste is on ? -- Johannes
                                              Message 22 of 25 , Jan 3, 2001
                                                On Wed, Jan 03, 2001 at 05:40:29PM +0100, Bram Moolenaar wrote:
                                                [...]
                                                > If you have the mouse disabled, or are using a terminal where the mouse
                                                > doesn't work inside Vim, pasting text arrives in Vim as if it was typed. This
                                                > is indeed a very fast way of typing. It's a good reason to use the mouse in
                                                > Vim, if possible. And make those InsertChar autocommands really fast.
                                                [...]

                                                what about disabling InsertChar if 'paste' is on ?

                                                --
                                                Johannes
                                              • Bram Moolenaar
                                                ... That s a good idea. -- hundred-and-one symptoms of being an internet addict: 213. Your kids start referring to you as that guy in front of the monitor.
                                                Message 23 of 25 , Jan 3, 2001
                                                  Johannes Zellner wrote:

                                                  > On Wed, Jan 03, 2001 at 05:40:29PM +0100, Bram Moolenaar wrote:
                                                  > [...]
                                                  > > If you have the mouse disabled, or are using a terminal where the mouse
                                                  > > doesn't work inside Vim, pasting text arrives in Vim as if it was typed.
                                                  > > This is indeed a very fast way of typing. It's a good reason to use the
                                                  > > mouse in Vim, if possible. And make those InsertChar autocommands really
                                                  > > fast.
                                                  > [...]
                                                  >
                                                  > what about disabling InsertChar if 'paste' is on ?

                                                  That's a good idea.

                                                  --
                                                  hundred-and-one symptoms of being an internet addict:
                                                  213. Your kids start referring to you as "that guy in front of the monitor."

                                                  /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                                  ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                                                  \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                                • Paul Moore
                                                  From: Bram@moolenaar.net [mailto:Bram@moolenaar.net] ... (butting in here, sorry...) Er, I think that s exactly the point. The one thing you can do with an
                                                  Message 24 of 25 , Jan 4, 2001
                                                    From: Bram@... [mailto:Bram@...]
                                                    > Actually, it's not clear to me why you would want to
                                                    > do something when a global variable is changed.
                                                    >
                                                    > > This may be a very big can of worms, but another
                                                    > > option would be to allow user-defined options, in
                                                    > > addition to user-defined global variables. Allow
                                                    > > autocommands to be triggered when these options are
                                                    > > changed. This would solve the problem of overhead,
                                                    > > since the autocommands would not have to be checked
                                                    > > when regular variables were changed.
                                                    >
                                                    > I don't intend to add user-defined options. Global
                                                    > variables do the same thing.

                                                    (butting in here, sorry...)
                                                    Er, I think that's exactly the point. The one thing you can do with an
                                                    option which you can't do with a global variable, is to have extra effects
                                                    take place when the option is changed. With a GlobalChanged autocommand, you
                                                    would indeed be able to get the effect of an option with a global variable.

                                                    (I don't have a use for user-defined options myself, I just thought this
                                                    point was worth clarifying...)

                                                    Paul.
                                                  • Bram Moolenaar
                                                    ... Ehm, you can t have extra effects when setting an option, as far as I know. I hope you understand that adding an autocommand event has the potential of
                                                    Message 25 of 25 , Jan 5, 2001
                                                      Paul Moore wrote:

                                                      > > I don't intend to add user-defined options. Global variables do the same
                                                      > > thing.
                                                      >
                                                      > (butting in here, sorry...)
                                                      > Er, I think that's exactly the point. The one thing you can do with an
                                                      > option which you can't do with a global variable, is to have extra effects
                                                      > take place when the option is changed. With a GlobalChanged autocommand, you
                                                      > would indeed be able to get the effect of an option with a global variable.
                                                      >
                                                      > (I don't have a use for user-defined options myself, I just thought this
                                                      > point was worth clarifying...)

                                                      Ehm, you can't have "extra effects" when setting an option, as far as I know.

                                                      I hope you understand that adding an autocommand event has the potential of
                                                      introducing many new problems. Mostly because of the side effects an
                                                      autocommand can have (well, it can do _anything_). You don't want a ":let
                                                      g:var = value" command have unpredictable side effects, do you?

                                                      --
                                                      hundred-and-one symptoms of being an internet addict:
                                                      256. You are able to write down over 250 symptoms of being an internet
                                                      addict, even though they only asked for 101.

                                                      /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                                      ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                                                      \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                                    Your message has been successfully submitted and would be delivered to recipients shortly.