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

Re: Vim 6.0r alpha available

Expand Messages
  • 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 1 of 25 , Jan 2, 2001
    View Source
    • 0 Attachment
      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 2 of 25 , Jan 2, 2001
      View Source
      • 0 Attachment
        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 3 of 25 , Jan 2, 2001
        View Source
        • 0 Attachment
          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 4 of 25 , Jan 2, 2001
          View Source
          • 0 Attachment
            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 5 of 25 , Jan 2, 2001
            View Source
            • 0 Attachment
              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 6 of 25 , Jan 3, 2001
              View Source
              • 0 Attachment
                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 7 of 25 , Jan 3, 2001
                View Source
                • 0 Attachment
                  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 8 of 25 , Jan 3, 2001
                  View Source
                  • 0 Attachment
                    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 9 of 25 , Jan 3, 2001
                    View Source
                    • 0 Attachment
                      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 10 of 25 , Jan 3, 2001
                      View Source
                      • 0 Attachment
                        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 11 of 25 , Jan 3, 2001
                        View Source
                        • 0 Attachment
                          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 12 of 25 , Jan 3, 2001
                          View Source
                          • 0 Attachment
                            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 13 of 25 , Jan 4, 2001
                            View Source
                            • 0 Attachment
                              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 14 of 25 , Jan 5, 2001
                              View Source
                              • 0 Attachment
                                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.