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

Suggestion: Every primitive vim operation should have a callable descriptive name

Expand Messages
  • Mosh
    All builtin vim operations should be named for 2 reasons: 1. if you map a key, then the original command binding is unavailable: example: :map [ 0 .. Now
    Message 1 of 9 , Jan 11, 2014
      All builtin vim operations should be named for 2 reasons:

      1. if you map a key, then the original command binding is unavailable:
      example: :map [ 0 ..
      Now how do I call [c in diff mode; [c doesn't have a name.

      2. scripts become un-maintainable and unreadable to others:
      simple example. ".....exe normal vip ......"
      :h vip
      Vim help doesn't know what vip is is,
      only google can help you here.

      This is just an example, but many operations cannot be found in vim help
      unless you already know about it. That is why vim-tips is such a
      useful site,
      and emacs-tips site is unnecessary - because every command is named and
      can be grepped for.

      thanks,
      mohsin.
      http://in.linkedin.com/in/moshahmed

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Manuel Ortega
      ... Use :normal with the exclamation point, and create a new mapping. ... Because normal-mode commands especially can be concatenated arbitrarily many times,
      Message 2 of 9 , Jan 11, 2014

        On Sat, Jan 11, 2014 at 11:36 PM, Mosh <moshahmed@...> wrote:
        All builtin vim operations should be named for 2 reasons:

        1.  if you map a key, then the original command binding is unavailable:
            example: :map [ 0    ..
            Now how do I call  [c in diff mode; [c doesn't have a name.

        Use ':normal' with the exclamation point, and create a new mapping.




         
        2. scripts become un-maintainable and unreadable to others:
            simple example. ".....exe normal vip ......"
            :h vip
            Vim help doesn't know what vip is is,
            only google can help you here.

        Because normal-mode commands especially can be concatenated arbitrarily many times, this is not feasible.  If 'vip' gets a name other than the name it already has ("vip"), what will be the name for "vipp"?  For "vippp"?  For "vippp"?  For "vipgpgpggipp"?

        Anyway, the fact that in the example there is "normal", that tells you that 'vip' is a normal mode command.  So do ":h v".  Then do ":h ip". 

        -Manny

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
         
        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Mosh
        manny Because normal-mode commands especially can be concatenated arbitrarily many times, this is not feasible. If vip gets a name other than the name it
        Message 3 of 9 , Jan 11, 2014
          manny> Because normal-mode commands especially can be concatenated
          arbitrarily many times, this is not feasible. If 'vip' gets a name
          other than the name it already has ("vip"), what will be the name for
          "vipp"? For "vippp"? For "vippp"? For "vipgpgpggipp"?

          Your examples support my point, your arbitrary long abbreviations
          would be then be readable:
          vip = :visual(), inner(), block(),
          vippp == visual() inner(), block(), paste(), paste(),
          or whatever that obscure abbrev means.

          And elegantly composable with arguments as in functional programming
          (that would be asking for too much from vim at this point).



          On 1/12/14, Manuel Ortega <mannyvimdev@...> wrote:
          > On Sat, Jan 11, 2014 at 11:36 PM, Mosh <moshahmed@...> wrote:
          >
          >> All builtin vim operations should be named for 2 reasons:
          >>
          >> 1. if you map a key, then the original command binding is unavailable:
          >> example: :map [ 0 ..
          >> Now how do I call [c in diff mode; [c doesn't have a name.
          >>
          >
          > Use ':normal' with the exclamation point, and create a new mapping.
          >
          >
          >
          >
          >
          >
          >> 2. scripts become un-maintainable and unreadable to others:
          >> simple example. ".....exe normal vip ......"
          >> :h vip
          >> Vim help doesn't know what vip is is,
          >> only google can help you here.
          >>
          >
          > Because normal-mode commands especially can be concatenated arbitrarily
          > many times, this is not feasible. If 'vip' gets a name other than the name
          > it already has ("vip"), what will be the name for "vipp"? For "vippp"?
          > For "vippp"? For "vipgpgpggipp"?
          >
          > Anyway, the fact that in the example there is "normal", that tells you that
          > 'vip' is a normal mode command. So do ":h v". Then do ":h ip".
          >
          > -Manny
          >
          > --
          > --
          > You received this message from the "vim_dev" maillist.
          > Do not top-post! Type your reply below the text you are replying to.
          > For more information, visit http://www.vim.org/maillist.php
          >
          > ---
          > You received this message because you are subscribed to the Google Groups
          > "vim_dev" group.
          > To unsubscribe from this group and stop receiving emails from it, send an
          > email to vim_dev+unsubscribe@....
          > For more options, visit https://groups.google.com/groups/opt_out.
          >

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Andre Sihera
          Dear all, Apologies for this long-ish post. Your patience is appreciated! The Original Poster who suggested every primitive vim operation should have a
          Message 4 of 9 , Jan 11, 2014
            Dear all,

            Apologies for this long-ish post. Your patience is appreciated!

            The Original Poster who suggested "every primitive vim operation
            should have a descriptive name" was thinking exactly the way that
            ViM should be positioning itself in order to be able to support
            any language binding that we want to in the future. The Original
            Poster was, unfortunately, thinking way ahead of his time given
            ViM's current "construction".

            I have been considering proposing a ".Net-style" language-binding
            upgrade for ViM for some time now and I would now like to take
            this opportunity to share my particular take on the idea and to
            get everybody's opinions.

            Currently, as well as the main operation modes that ViM has
            (insert, normal, command, etc.), there is also ViM script which
            has a huge number of very useful and flexible functions to drive
            every feature of ViM (from now on, called "Primitives").

            The idea I have is to create an internal default language binding
            called (for example) "VIM", and to hang all the current commands
            off the internal binding. The following is NOT a literal
            specification for such a binding, but it could look something like
            this:

            VIM
            |
            +--- Insert
            | |
            | +--- (all insert mode commands)
            |
            +--- Normal
            | |
            | +--- (all normal mode commands)
            |
            +--- Command
            | |
            | +--- (all command mode commands)
            |
            +--- Script
            |
            +--- (all script functions)

            Once this default binding is in place, we then create "aliases"
            onto the primitives for all the existing commands and script
            functions so that the Ex command language works exactly as it
            does now (guaranteeing backward compatibility and continued
            POSIX compliance).

            For example:

            stridx => VIM.Script.stridx

            Once this is done, it could then be easier to support any other
            language binding by creating a new language binding module. E.g.
            for python interface, we could take "python-style" object
            references and convert them to and from the default language
            binding using some kind of "interface description language"
            that knows about fundamental data types, data widths, calling
            conventions etc.

            This is the reason I originally referred to this proposal as a
            ".net-style" upgrade. So, for example, in python:

            vim.str.find => [INTERFACE DESCRIPTION] => VIM.Script.stridx
            vim.str.index => [INTERFACE DESCRIPTION] => VIM.Script.stridx

            (see: http://docs.python.org/2/library/stdtypes.html#string-methods)

            The huge advantage with this method is that while ViM is not object-
            oriented in its implementation, it would still be able to support
            object-oriented language bindings thus no fundamental rewrite of
            ViM in an "object oriented language" would be required. If a pure
            object model in the target language is required it can be
            implemented in the target language with a final call to the ViM
            language binding.

            At the same time, it would also stop the childish "script language
            X is better than ViM script so why don't we dump ViM script and
            replace it with X?" arguments that pop up all too frequently on
            this mailing list.

            Finally, the Original Poster's suggestion "every vim primitive
            operation should have a callable descriptive name" could also be
            supported. Instead of using the Ex command "alias" for the command
            "normal vippp", the OP could use the default language binding
            directly and call (for example):

            VIM.Normal.Visual();
            VIM.Normal.Insert();
            VIM.Normal.Paste();
            VIM.Normal.Paste();

            etc.


            Forget about the implementation details at this stage. What about
            the concept itself?


            Thanks in advance,

            Andre Sihera.



            On 12/01/14 13:36, Mosh wrote:
            > All builtin vim operations should be named for 2 reasons:
            >
            > 1. if you map a key, then the original command binding is unavailable:
            > example: :map [ 0 ..
            > Now how do I call [c in diff mode; [c doesn't have a name.
            >
            > 2. scripts become un-maintainable and unreadable to others:
            > simple example. ".....exe normal vip ......"
            > :h vip
            > Vim help doesn't know what vip is is,
            > only google can help you here.
            >
            > This is just an example, but many operations cannot be found in vim help
            > unless you already know about it. That is why vim-tips is such a
            > useful site,
            > and emacs-tips site is unnecessary - because every command is named and
            > can be grepped for.
            >
            > thanks,
            > mohsin.

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Thiago Padilha
            Having support for multiple scripting languages would certainly be useful. One simple way to achieve this would be to follow weechat s take on
            Message 5 of 9 , Jan 12, 2014
              Having support for multiple scripting languages would certainly be useful.

              One simple way to achieve this would be to follow weechat's take on
              plugins(http://weechat.org/files/doc/stable/weechat_user.en.html#plugins)
              where each plugin is a dynamic library loaded at startup(eg: dlopen)
              by vim's core program. This would enable vim to support any language,
              as adding support to a new language wouldn't require recompiling vim,
              just add a file to the runtime dir.

              Each dynamic library can embed its own interpreter and handle
              converting to/from vim's data structures, and it should also have a
              initialization function that would be called by vim at startup time.
              This function could be used for example, to register a vimscript/ex
              commands for calling the language interpreter(eg: python <<)

              In any case, this would imply in significant changes in the current
              way vim works, so good luck getting such a patch to merge in the main
              code.


              On Sun, Jan 12, 2014 at 4:48 AM, Andre Sihera
              <andre.sihera@...> wrote:
              > Dear all,
              >
              > Apologies for this long-ish post. Your patience is appreciated!
              >
              > The Original Poster who suggested "every primitive vim operation
              > should have a descriptive name" was thinking exactly the way that
              > ViM should be positioning itself in order to be able to support
              > any language binding that we want to in the future. The Original
              > Poster was, unfortunately, thinking way ahead of his time given
              > ViM's current "construction".
              >
              > I have been considering proposing a ".Net-style" language-binding
              > upgrade for ViM for some time now and I would now like to take
              > this opportunity to share my particular take on the idea and to
              > get everybody's opinions.
              >
              > Currently, as well as the main operation modes that ViM has
              > (insert, normal, command, etc.), there is also ViM script which
              > has a huge number of very useful and flexible functions to drive
              > every feature of ViM (from now on, called "Primitives").
              >
              > The idea I have is to create an internal default language binding
              > called (for example) "VIM", and to hang all the current commands
              > off the internal binding. The following is NOT a literal
              > specification for such a binding, but it could look something like
              > this:
              >
              > VIM
              > |
              > +--- Insert
              > | |
              > | +--- (all insert mode commands)
              > |
              > +--- Normal
              > | |
              > | +--- (all normal mode commands)
              > |
              > +--- Command
              > | |
              > | +--- (all command mode commands)
              > |
              > +--- Script
              > |
              > +--- (all script functions)
              >
              > Once this default binding is in place, we then create "aliases"
              > onto the primitives for all the existing commands and script
              > functions so that the Ex command language works exactly as it
              > does now (guaranteeing backward compatibility and continued
              > POSIX compliance).
              >
              > For example:
              >
              > stridx => VIM.Script.stridx
              >
              > Once this is done, it could then be easier to support any other
              > language binding by creating a new language binding module. E.g.
              > for python interface, we could take "python-style" object
              > references and convert them to and from the default language
              > binding using some kind of "interface description language"
              > that knows about fundamental data types, data widths, calling
              > conventions etc.
              >
              > This is the reason I originally referred to this proposal as a
              > ".net-style" upgrade. So, for example, in python:
              >
              > vim.str.find => [INTERFACE DESCRIPTION] => VIM.Script.stridx
              > vim.str.index => [INTERFACE DESCRIPTION] => VIM.Script.stridx
              >
              > (see: http://docs.python.org/2/library/stdtypes.html#string-methods)
              >
              > The huge advantage with this method is that while ViM is not object-
              > oriented in its implementation, it would still be able to support
              > object-oriented language bindings thus no fundamental rewrite of
              > ViM in an "object oriented language" would be required. If a pure
              > object model in the target language is required it can be
              > implemented in the target language with a final call to the ViM
              > language binding.
              >
              > At the same time, it would also stop the childish "script language
              > X is better than ViM script so why don't we dump ViM script and
              > replace it with X?" arguments that pop up all too frequently on
              > this mailing list.
              >
              > Finally, the Original Poster's suggestion "every vim primitive
              > operation should have a callable descriptive name" could also be
              > supported. Instead of using the Ex command "alias" for the command
              > "normal vippp", the OP could use the default language binding
              > directly and call (for example):
              >
              > VIM.Normal.Visual();
              > VIM.Normal.Insert();
              > VIM.Normal.Paste();
              > VIM.Normal.Paste();
              >
              > etc.
              >
              >
              > Forget about the implementation details at this stage. What about
              > the concept itself?
              >
              >
              > Thanks in advance,
              >
              > Andre Sihera.
              >
              >
              >
              > On 12/01/14 13:36, Mosh wrote:
              >>
              >> All builtin vim operations should be named for 2 reasons:
              >>
              >> 1. if you map a key, then the original command binding is unavailable:
              >> example: :map [ 0 ..
              >> Now how do I call [c in diff mode; [c doesn't have a name.
              >>
              >> 2. scripts become un-maintainable and unreadable to others:
              >> simple example. ".....exe normal vip ......"
              >> :h vip
              >> Vim help doesn't know what vip is is,
              >> only google can help you here.
              >>
              >> This is just an example, but many operations cannot be found in vim
              >> help
              >> unless you already know about it. That is why vim-tips is such a
              >> useful site,
              >> and emacs-tips site is unnecessary - because every command is named
              >> and
              >> can be grepped for.
              >>
              >> thanks,
              >> mohsin.
              >
              >
              > --
              > --
              > You received this message from the "vim_dev" maillist.
              > Do not top-post! Type your reply below the text you are replying to.
              > For more information, visit http://www.vim.org/maillist.php
              >
              > --- You received this message because you are subscribed to the Google
              > Groups "vim_dev" group.
              > To unsubscribe from this group and stop receiving emails from it, send an
              > email to vim_dev+unsubscribe@....
              > For more options, visit https://groups.google.com/groups/opt_out.

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Andre Sihera
              ... The DLL-style plug-in implementation is how I was imagining it. Although changes are significant, they could be reduced if we implement the default
              Message 6 of 9 , Jan 12, 2014
                On 12/01/14 18:50, Thiago Padilha wrote:
                > Having support for multiple scripting languages would certainly be useful.
                >
                > One simple way to achieve this would be to follow weechat's take on
                > plugins(http://weechat.org/files/doc/stable/weechat_user.en.html#plugins)
                > where each plugin is a dynamic library loaded at startup(eg: dlopen)
                > by vim's core program. This would enable vim to support any language,
                > as adding support to a new language wouldn't require recompiling vim,
                > just add a file to the runtime dir.
                >
                > Each dynamic library can embed its own interpreter and handle
                > converting to/from vim's data structures, and it should also have a
                > initialization function that would be called by vim at startup time.
                > This function could be used for example, to register a vimscript/ex
                > commands for calling the language interpreter(eg: python<<)
                >
                > In any case, this would imply in significant changes in the current
                > way vim works, so good luck getting such a patch to merge in the main
                > code.
                >

                The DLL-style plug-in implementation is how I was imagining
                it.

                Although changes are significant, they could be reduced if we
                implement the default language binding *on top* of the current
                command implementation as opposed to rewriting the current
                command implementation on top of a new language binding
                feature ("smoke and mirrors"...)

                > On Sun, Jan 12, 2014 at 4:48 AM, Andre Sihera
                > <andre.sihera@...> wrote:
                >> Dear all,
                >>
                >> Apologies for this long-ish post. Your patience is appreciated!
                >>
                >> The Original Poster who suggested "every primitive vim operation
                >> should have a descriptive name" was thinking exactly the way that
                >> ViM should be positioning itself in order to be able to support
                >> any language binding that we want to in the future. The Original
                >> Poster was, unfortunately, thinking way ahead of his time given
                >> ViM's current "construction".
                >>
                >> I have been considering proposing a ".Net-style" language-binding
                >> upgrade for ViM for some time now and I would now like to take
                >> this opportunity to share my particular take on the idea and to
                >> get everybody's opinions.
                >>
                >> Currently, as well as the main operation modes that ViM has
                >> (insert, normal, command, etc.), there is also ViM script which
                >> has a huge number of very useful and flexible functions to drive
                >> every feature of ViM (from now on, called "Primitives").
                >>
                >> The idea I have is to create an internal default language binding
                >> called (for example) "VIM", and to hang all the current commands
                >> off the internal binding. The following is NOT a literal
                >> specification for such a binding, but it could look something like
                >> this:
                >>
                >> VIM
                >> |
                >> +--- Insert
                >> | |
                >> | +--- (all insert mode commands)
                >> |
                >> +--- Normal
                >> | |
                >> | +--- (all normal mode commands)
                >> |
                >> +--- Command
                >> | |
                >> | +--- (all command mode commands)
                >> |
                >> +--- Script
                >> |
                >> +--- (all script functions)
                >>
                >> Once this default binding is in place, we then create "aliases"
                >> onto the primitives for all the existing commands and script
                >> functions so that the Ex command language works exactly as it
                >> does now (guaranteeing backward compatibility and continued
                >> POSIX compliance).
                >>
                >> For example:
                >>
                >> stridx => VIM.Script.stridx
                >>
                >> Once this is done, it could then be easier to support any other
                >> language binding by creating a new language binding module. E.g.
                >> for python interface, we could take "python-style" object
                >> references and convert them to and from the default language
                >> binding using some kind of "interface description language"
                >> that knows about fundamental data types, data widths, calling
                >> conventions etc.
                >>
                >> This is the reason I originally referred to this proposal as a
                >> ".net-style" upgrade. So, for example, in python:
                >>
                >> vim.str.find => [INTERFACE DESCRIPTION] => VIM.Script.stridx
                >> vim.str.index => [INTERFACE DESCRIPTION] => VIM.Script.stridx
                >>
                >> (see: http://docs.python.org/2/library/stdtypes.html#string-methods)
                >>
                >> The huge advantage with this method is that while ViM is not object-
                >> oriented in its implementation, it would still be able to support
                >> object-oriented language bindings thus no fundamental rewrite of
                >> ViM in an "object oriented language" would be required. If a pure
                >> object model in the target language is required it can be
                >> implemented in the target language with a final call to the ViM
                >> language binding.
                >>
                >> At the same time, it would also stop the childish "script language
                >> X is better than ViM script so why don't we dump ViM script and
                >> replace it with X?" arguments that pop up all too frequently on
                >> this mailing list.
                >>
                >> Finally, the Original Poster's suggestion "every vim primitive
                >> operation should have a callable descriptive name" could also be
                >> supported. Instead of using the Ex command "alias" for the command
                >> "normal vippp", the OP could use the default language binding
                >> directly and call (for example):
                >>
                >> VIM.Normal.Visual();
                >> VIM.Normal.Insert();
                >> VIM.Normal.Paste();
                >> VIM.Normal.Paste();
                >>
                >> etc.
                >>
                >>
                >> Forget about the implementation details at this stage. What about
                >> the concept itself?
                >>
                >>
                >> Thanks in advance,
                >>
                >> Andre Sihera.
                >>
                >>
                >>
                >> On 12/01/14 13:36, Mosh wrote:
                >>> All builtin vim operations should be named for 2 reasons:
                >>>
                >>> 1. if you map a key, then the original command binding is unavailable:
                >>> example: :map [ 0 ..
                >>> Now how do I call [c in diff mode; [c doesn't have a name.
                >>>
                >>> 2. scripts become un-maintainable and unreadable to others:
                >>> simple example. ".....exe normal vip ......"
                >>> :h vip
                >>> Vim help doesn't know what vip is is,
                >>> only google can help you here.
                >>>
                >>> This is just an example, but many operations cannot be found in vim
                >>> help
                >>> unless you already know about it. That is why vim-tips is such a
                >>> useful site,
                >>> and emacs-tips site is unnecessary - because every command is named
                >>> and
                >>> can be grepped for.
                >>>
                >>> thanks,
                >>> mohsin.
                >>
                >> --
                >> --
                >> You received this message from the "vim_dev" maillist.
                >> Do not top-post! Type your reply below the text you are replying to.
                >> For more information, visit http://www.vim.org/maillist.php
                >>
                >> --- You received this message because you are subscribed to the Google
                >> Groups "vim_dev" group.
                >> To unsubscribe from this group and stop receiving emails from it, send an
                >> email to vim_dev+unsubscribe@....
                >> For more options, visit https://groups.google.com/groups/opt_out.

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • tooth pik
                ... all so we could add interpreters without rebuilding vim? Sounds like a lot of code, a very lot of added complexity and bloat to achieve something we can
                Message 7 of 9 , Jan 12, 2014
                  On Sun, Jan 12, 2014 at 09:20:02PM +0900, Andre Sihera wrote:
                  > On 12/01/14 18:50, Thiago Padilha wrote:
                  > >Having support for multiple scripting languages would certainly be useful.
                  > >
                  > >One simple way to achieve this would be to follow weechat's take on
                  > >plugins(http://weechat.org/files/doc/stable/weechat_user.en.html#plugins)
                  > >where each plugin is a dynamic library loaded at startup(eg: dlopen)
                  > >by vim's core program. This would enable vim to support any language,
                  > >as adding support to a new language wouldn't require recompiling vim,
                  > >just add a file to the runtime dir.
                  > >
                  > >Each dynamic library can embed its own interpreter and handle
                  > >converting to/from vim's data structures, and it should also have a
                  > >initialization function that would be called by vim at startup time.
                  > >This function could be used for example, to register a vimscript/ex
                  > >commands for calling the language interpreter(eg: python<<)
                  > >
                  > >In any case, this would imply in significant changes in the current
                  > >way vim works, so good luck getting such a patch to merge in the main
                  > >code.
                  > >

                  > The DLL-style plug-in implementation is how I was imagining
                  > it.

                  > Although changes are significant, they could be reduced if we
                  > implement the default language binding *on top* of the current
                  > command implementation as opposed to rewriting the current
                  > command implementation on top of a new language binding
                  > feature ("smoke and mirrors"...)

                  all so we could add interpreters without rebuilding vim? Sounds like a
                  lot of code, a very lot of added complexity and bloat to achieve
                  something we can already do with a simple rebuild. This particular
                  voice from the peanut gallery will be voting against it if it ever makes
                  it that far.

                  In view of the fact that vim is first and foremost a programmer's
                  editor, I think the requirement to rebuild so you can use something
                  other than vimL is akin to telling humans they have to breathe if they
                  want to continue living.

                  --
                  _|_ _ __|_|_ ._ o|
                  |_(_)(_)|_| ||_)||<
                  |

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Andre Sihera
                  ... This proposal with its external DLLs would would hardly affect the size of the core binary due to most extra code being in the DLLs, so your worries about
                  Message 8 of 9 , Jan 12, 2014
                    On 13/01/14 01:56, tooth pik wrote:
                    > On Sun, Jan 12, 2014 at 09:20:02PM +0900, Andre Sihera wrote:
                    >> On 12/01/14 18:50, Thiago Padilha wrote:
                    >>> Having support for multiple scripting languages would certainly be useful.
                    >>>
                    >>> One simple way to achieve this would be to follow weechat's take on
                    >>> plugins(http://weechat.org/files/doc/stable/weechat_user.en.html#plugins)
                    >>> where each plugin is a dynamic library loaded at startup(eg: dlopen)
                    >>> by vim's core program. This would enable vim to support any language,
                    >>> as adding support to a new language wouldn't require recompiling vim,
                    >>> just add a file to the runtime dir.
                    >>>
                    >>> Each dynamic library can embed its own interpreter and handle
                    >>> converting to/from vim's data structures, and it should also have a
                    >>> initialization function that would be called by vim at startup time.
                    >>> This function could be used for example, to register a vimscript/ex
                    >>> commands for calling the language interpreter(eg: python<<)
                    >>>
                    >>> In any case, this would imply in significant changes in the current
                    >>> way vim works, so good luck getting such a patch to merge in the main
                    >>> code.
                    >>>
                    >> The DLL-style plug-in implementation is how I was imagining
                    >> it.
                    >> Although changes are significant, they could be reduced if we
                    >> implement the default language binding *on top* of the current
                    >> command implementation as opposed to rewriting the current
                    >> command implementation on top of a new language binding
                    >> feature ("smoke and mirrors"...)
                    > all so we could add interpreters without rebuilding vim? Sounds like a
                    > lot of code, a very lot of added complexity and bloat to achieve
                    > something we can already do with a simple rebuild. This particular
                    > voice from the peanut gallery will be voting against it if it ever makes
                    > it that far.
                    >
                    > In view of the fact that vim is first and foremost a programmer's
                    > editor, I think the requirement to rebuild so you can use something
                    > other than vimL is akin to telling humans they have to breathe if they
                    > want to continue living.
                    >

                    This proposal with its external DLLs would would hardly affect
                    the size of the core binary due to most extra code being in the
                    DLLs, so your worries about "code bloat" may not apply here.

                    Humans don't have to be told to breathe in order to continue
                    living. Of course not! And in the same way, programmers
                    *should not* have to build their own tools just because they
                    can. You think all hairdressers want to cut their own hair? Or
                    that all tailors want to make all their own clothes? Ridiculous.

                    Programmers operating in highly competitive IT sectors where
                    speed and efficiency are King and are necessary just to be able
                    to survive. The editor is the programmer's most fundamental
                    tool and he/she should be able to exploit current *and future*
                    interpreters instantly, without recompilation; like "breathing air".

                    For people like yourself who want to recompile ViM every time
                    you want to add or remove a feature, there is the "tiny" build.
                    And while you're constantly recompiling, other programmers
                    who run with the "huge" build of ViM by default, and have all
                    the features and interpreters automatically at their fingertips,
                    will be more productive, will be finishing their work quicker,
                    and will be commanding bigger pay rises from their bosses.

                    I would be interested to know: how many other programmers
                    prefer to run the "huge" ViM build purely due to the ease and
                    improved productivity with not having to constantly recompile?

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Justin M. Keyes
                    On Sun, Jan 12, 2014 at 11:00 PM, Andre Sihera ... I have been wondering if it is feasible, or has been discussed, to provide a C API that exposes Vim s
                    Message 9 of 9 , Jan 12, 2014
                      On Sun, Jan 12, 2014 at 11:00 PM, Andre Sihera
                      <andre.sihera@...> wrote:
                      >
                      >
                      > On 13/01/14 01:56, tooth pik wrote:
                      >>
                      >> On Sun, Jan 12, 2014 at 09:20:02PM +0900, Andre Sihera wrote:
                      >>>
                      >>> On 12/01/14 18:50, Thiago Padilha wrote:
                      >>>>
                      >>>> Having support for multiple scripting languages would certainly be
                      >>>> useful.
                      >>>>
                      >>>> One simple way to achieve this would be to follow weechat's take on
                      >>>>
                      >>>> plugins(http://weechat.org/files/doc/stable/weechat_user.en.html#plugins)
                      >>>> where each plugin is a dynamic library loaded at startup(eg: dlopen)
                      >>>> by vim's core program. This would enable vim to support any language,
                      >>>> as adding support to a new language wouldn't require recompiling vim,
                      >>>> just add a file to the runtime dir.
                      >>>>
                      >>>> Each dynamic library can embed its own interpreter and handle
                      >>>> converting to/from vim's data structures, and it should also have a
                      >>>> initialization function that would be called by vim at startup time.
                      >>>> This function could be used for example, to register a vimscript/ex
                      >>>> commands for calling the language interpreter(eg: python<<)
                      >>>>
                      >>>> In any case, this would imply in significant changes in the current
                      >>>> way vim works, so good luck getting such a patch to merge in the main
                      >>>> code.
                      >>>>
                      >>> The DLL-style plug-in implementation is how I was imagining
                      >>> it.
                      >>> Although changes are significant, they could be reduced if we
                      >>> implement the default language binding *on top* of the current
                      >>> command implementation as opposed to rewriting the current
                      >>> command implementation on top of a new language binding
                      >>> feature ("smoke and mirrors"...)
                      >>
                      >> all so we could add interpreters without rebuilding vim? Sounds like a
                      >> lot of code, a very lot of added complexity and bloat to achieve
                      >> something we can already do with a simple rebuild. This particular
                      >> voice from the peanut gallery will be voting against it if it ever makes
                      >> it that far.
                      >>
                      >> In view of the fact that vim is first and foremost a programmer's
                      >> editor, I think the requirement to rebuild so you can use something
                      >> other than vimL is akin to telling humans they have to breathe if they
                      >> want to continue living.
                      >>
                      >
                      > This proposal with its external DLLs would would hardly affect
                      > the size of the core binary due to most extra code being in the
                      > DLLs, so your worries about "code bloat" may not apply here.
                      >
                      > Humans don't have to be told to breathe in order to continue
                      > living. Of course not! And in the same way, programmers
                      > *should not* have to build their own tools just because they
                      > can. You think all hairdressers want to cut their own hair? Or
                      > that all tailors want to make all their own clothes? Ridiculous.
                      >
                      > Programmers operating in highly competitive IT sectors where
                      > speed and efficiency are King and are necessary just to be able
                      > to survive. The editor is the programmer's most fundamental
                      > tool and he/she should be able to exploit current *and future*
                      > interpreters instantly, without recompilation; like "breathing air".
                      >
                      > For people like yourself who want to recompile ViM every time
                      > you want to add or remove a feature, there is the "tiny" build.
                      > And while you're constantly recompiling, other programmers
                      > who run with the "huge" build of ViM by default, and have all
                      > the features and interpreters automatically at their fingertips,
                      > will be more productive, will be finishing their work quicker,
                      > and will be commanding bigger pay rises from their bosses.
                      >
                      > I would be interested to know: how many other programmers
                      > prefer to run the "huge" ViM build purely due to the ease and
                      > improved productivity with not having to constantly recompile?

                      I have been wondering if it is feasible, or has been discussed, to
                      provide a C API that exposes Vim's functions and state, to provide a
                      "Vim core" (sort of like libgit2 provides git functionality without
                      having to wrap shell commands). Even without non-C language bindings,
                      a C API that allowed an IDE or some other editor to "host" the Vim
                      core could enable modern Vim implementations without having to
                      actually reimplement Vim. I think that is a much better idea than
                      re-writing Vim in C++, which has been discussed on vim_dev and
                      vim_use.


                      Justin M. Keyes

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    Your message has been successfully submitted and would be delivered to recipients shortly.