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

Re: accessing vim variables outside of eval.c

Expand Messages
  • Doug Kearns
    ... Interestingly enough I was suffering the same irritation with the Ruby interface tonight. I cobbled together a module written in Ruby to solve my problems
    Message 1 of 7 , Sep 26, 2005
    • 0 Attachment
      On Sat, Sep 24, 2005 at 05:59:29PM +0200, Pierre-Yves Ritschard wrote:
      > Hi
      >
      > While writing python scripts for vim i stumbled across the problem of
      > moving information back and forth from a python script to vim.

      Interestingly enough I was suffering the same irritation with the Ruby
      interface tonight. I cobbled together a module written in Ruby to solve
      my problems but I guess a more general solution might also be useful to
      others.

      I guess one issue is how similar the different language interfaces are
      required to be... Bram, would you be happy for them to evolve at
      different rates? I wouldn't be particularly interested in updating the
      Perl interface for example. ;-)

      Regards,
      Doug
    • Bram Moolenaar
      ... Good. Also keep in mind there are window-local and buffer-local variables. ... Suggestions on how to organise the functionality if files is welcome. But
      Message 2 of 7 , Sep 26, 2005
      • 0 Attachment
        Pierre-Yves Ritschard wrote:

        > Bram Moolenaar wrote:
        > >>* Is there a way to access variables i just missed ?
        > >
        > >
        > > You would need to implement conversion of the types you use in Python to
        > > the types used in Vim. Probably only supporting strings and numbers is
        > > possible.
        >
        > Thas is what i've done.
        > But the hard part was then telling vim to set the variable.
        > I'll look into set_internal_string_var()

        Good. Also keep in mind there are window-local and buffer-local
        variables.

        > > There are two contradicting goals: avoid operations on typval_T spread
        > > out over multiple files, and not putting too many things in one file.
        > > eval.c is getting really big now, thus splitting it up in pieces is
        > > becoming more attractive.
        >
        > would you be interested if i worked on such a patch ?
        > in the case you would be, i'd stall the if_python.c improvements and
        > work on that then implement the functionnality in if_python.c using this.

        Suggestions on how to organise the functionality if files is welcome.
        But it's often hard to see in a patch, describing it in words would be
        better. Moving chunks of code around is something I rather do myself,
        so that I can include the latest changes.

        --
        TALL KNIGHT: Firstly. You must get us another shrubbery!
        OTHER KNIGHTS: More shrubberies! More shrubberies for the ex-Knights of Ni!
        ARTHUR: Not another shrubbery -
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
      • Bram Moolenaar
        ... I very much like generic solutions. Getting and setting variable values is something that should work for all interfaces. -- TALL KNIGHT: When you have
        Message 3 of 7 , Sep 26, 2005
        • 0 Attachment
          Doug Kearns wrote:

          > On Sat, Sep 24, 2005 at 05:59:29PM +0200, Pierre-Yves Ritschard wrote:
          > > Hi
          > >
          > > While writing python scripts for vim i stumbled across the problem of
          > > moving information back and forth from a python script to vim.
          >
          > Interestingly enough I was suffering the same irritation with the Ruby
          > interface tonight. I cobbled together a module written in Ruby to solve
          > my problems but I guess a more general solution might also be useful to
          > others.
          >
          > I guess one issue is how similar the different language interfaces are
          > required to be... Bram, would you be happy for them to evolve at
          > different rates? I wouldn't be particularly interested in updating the
          > Perl interface for example. ;-)

          I very much like generic solutions. Getting and setting variable values
          is something that should work for all interfaces.

          --
          TALL KNIGHT: When you have found the shrubbery, then you must cut down the
          mightiest tree in the forest ... with a herring.
          "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
          \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
        • Pierre-Yves Ritschard
          ... I would have thought so. I ll try and see what organisation would benefit both eval.c and the language interfaces and describe it.
          Message 4 of 7 , Sep 26, 2005
          • 0 Attachment
            Bram Moolenaar wrote:
            > Pierre-Yves Ritschard wrote:
            >
            >
            > Suggestions on how to organise the functionality if files is welcome.
            > But it's often hard to see in a patch, describing it in words would be
            > better. Moving chunks of code around is something I rather do myself,
            > so that I can include the latest changes.
            >

            I would have thought so.
            I'll try and see what organisation would benefit both eval.c and the
            language interfaces and describe it.
          Your message has been successfully submitted and would be delivered to recipients shortly.