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

missing features for 7.4 - is somebody working on these?

Expand Messages
  • Marc Weber
    I d like to try providing patches for the following features: - nox patch https://code.google.com/r/yukihironakadaira-vim-cmdsrv-nox/ What is it? Allows
    Message 1 of 4 , May 29, 2013
    • 0 Attachment
      I'd like to try providing patches for the following features:

      - nox patch
      https://code.google.com/r/yukihironakadaira-vim-cmdsrv-nox/
      What is it? Allows client-server communication via sockets.

      pro: only you can access your vim instances
      con: you cannot connect to a vim instance running as root using X
      anymore (is this bad or a feature)

      Anyway, how should it look like?
      Because there are multiple communication ways, does it makes sesne to
      allow opting-in out eg this way?

      vim --enable-client-server nox,x11

      If both communication ways are allowed at the same time, which one to
      use with --remote-* commands?

      - make vim load plugin/*.py files with version hinting
      if a file has a second line # python 2 or # python 3
      vim will try to load those files with that interpreter.

      if there is no hinting, use any (if enabled)

      - keyboard interrupt for python !
      Eg try :py while True: print "abc"

      You cannot abort.

      try the same in shell:

      python -c 'while True: print "abc"'

      press ctrl-c and you'll get:

      Traceback (most recent call last):
      File "<string>", line 1, in <module>
      KeyboardInterrupt

      I don't know whether this is possible. But if python would be much
      more fun.

      I dont' know exactly which patches are pending, that's why I'm asking
      this way whether anybody is already working on those features?

      Marc Weber

      --
      --
      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.
    • ZyX ZyX
      ... Reasoning for not implementing this this way is same as for autoloading python/**.py: there are existing plugins that do not expect such behavior. I would
      Message 2 of 4 , May 29, 2013
      • 0 Attachment


        On May 29, 2013 11:57 AM, "Marc Weber" <marco-oweber@...> wrote:
        >
        > I'd like to try providing patches for the following features:
        >
        > - nox patch
        >   https://code.google.com/r/yukihironakadaira-vim-cmdsrv-nox/
        >   What is it? Allows client-server communication via sockets.
        >
        >   pro: only you can access your vim instances
        >   con: you cannot connect to a vim instance running as root using X
        >   anymore (is this bad or a feature)
        >
        >   Anyway, how should it look like?
        >   Because there are multiple communication ways, does it makes sesne to
        >   allow opting-in out eg this way?
        >
        >     vim --enable-client-server nox,x11
        >
        >   If both communication ways are allowed at the same time, which one to
        >   use with --remote-* commands?
        >
        > - make vim load plugin/*.py files with version hinting
        >   if a file has a second line # python 2 or # python 3
        >   vim will try to load those files with that interpreter.
        >
        >   if there is no hinting, use any (if enabled)

        Reasoning for not implementing this this way is same as for autoloading python/**.py: there are existing plugins that do not expect such behavior. I would vote for some directory that is neither python/ (after some thinking I find previous suggestion with __vim_init__ non-pythonic), plugin/, autoload/, scripts?/ and so on: which is unlikely to hold python files in existing plugins. Perhaps, pyplugin/?

        > - keyboard interrupt for python !
        >   Eg try :py while True: print "abc"
        >
        >   You cannot abort.
        >
        >   try the same in shell:
        >
        >   python -c 'while True: print "abc"'
        >
        >   press ctrl-c and you'll get:
        >
        >   Traceback (most recent call last):
        >     File "<string>", line 1, in <module>
        >     KeyboardInterrupt
        >
        >   I don't know whether this is possible. But if python would be much
        >   more fun.
        >
        > I dont' know exactly which patches are pending, that's why I'm asking
        > this way whether anybody is already working on those features?
        >
        > Marc Weber
        >
        > --
        > --
        > 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.
         
         
      • mattn
        ... I hope to provide my-plugins for all users, for example some peaple that don t have if_python-feature. -- -- You received this message from the vim_dev
        Message 3 of 4 , May 29, 2013
        • 0 Attachment
          On Wednesday, May 29, 2013 7:14:54 PM UTC+9, ZyX wrote:
          > On May 29, 2013 11:57 AM, "Marc Weber" <marco-...@...> wrote:
          > Reasoning for not implementing this this way is same as for autoloading python/**.py: there are existing plugins that do not expect such behavior. I would vote for some directory that is neither python/ (after some thinking I find previous suggestion with __vim_init__ non-pythonic), plugin/, autoload/, scripts?/ and so on: which is unlikely to hold python files in existing plugins. Perhaps, pyplugin/?

          I hope to provide my-plugins for all users, for example some peaple that don't have if_python-feature.

          --
          --
          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.
        • Marc Weber
          ... you re right. It might break some plugins who have put .py files into plugin/ The idea behind plugin was is that people know that things in plugin/ get
          Message 4 of 4 , May 29, 2013
          • 0 Attachment
            > ZyX
            you're right. It might break some plugins who have put .py files into
            plugin/

            The idea behind "plugin" was is that people know that things in plugin/
            get sourced. Its like "keeping things simple".

            I've no idea how many plugins would break. I'd also agree on a different
            directory. That's an implementation detail from my point of view.

            Its simpler for the user, because he/she has to remember only one
            directory -> and it will force users to separate configuration from
            implementation, which is a good thing in the long run.

            > I hope to provide my-plugins for all users, for example some peaple
            > that don't have if_python-feature.
            Good luck if you want to provide your plugin for *all users*, also
            *windows users* and you need a "rm -fr" feature.

            You start reinventing the wheel this way:
            https://github.com/MarcWeber/vim-addon-manager/blob/master/autoload/vam/utils.vim

            That's why VimL should die, and all people should start using python
            then. Of course feel free to continue this style of insanity. Nobody
            will stop you.
            In the future I want to use shutils.rmtree('..') and have it work on all
            platforms.

            Yes - VimL will not die - and most plugins will just happily work
            with VimL - and many new plugins will be VimL only.
            But there must be default escape path for complexer plugins - without
            exhausting devs working around things - such as "implement XML libaries
            in VimL" (see webapi) - sorry, this is *insane*. This all has been done
            many times before.

            That's why this "python" improvement is that important for the community
            IMHO. But of course that's only my perception. In the end whether its
            python, perl or ruby doesn't matter as long as its any decent language.
            VimL was ahead of time when it was introduced. But today having to
            maintain your own language does no longer make sense unless you have
            veriy specific needs.

            Marc Weber

            --
            --
            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.