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

Re: automatic loading of scripts

Expand Messages
  • Marc Weber
    Really hot topic ;) Remarks to prior posts: adding path as prefix to a function isn t necessary (if there is a autoload folder) because the place of the file
    Message 1 of 50 , Mar 7, 2005
    • 0 Attachment
      Really hot topic ;)

      Remarks to prior posts:
      adding path as prefix to a function isn't necessary (if there is a
      autoload folder) because the place of the file tells already that the
      function should have the prefix [...].
      So the problem doesn't arise that s.o want's to use your function
      you haven't thought of (and you've forgotten to add the
      directory-namingspace)

      The nice effect of having errormessages which tell where the function
      was defined can be implemented without thinking of autoloading.. Just
      save the origin and the functionname and you can create errormessages
      like this:
      error in line xy of function directory:functionname
      or commandline:functionname if it's a function written at the vim
      commandline..

      My thoughts:
      goals:
      1 sharing of the source (reusable code)
      2 should be updateable ( s.th. like update all would be nice)
      3 the implementation should be loaded when the function is used to
      speed up start up time of vim.
      4 due to different keyboard layouts and personal preferences everybody
      want's to have is own (different) keybindings..

      Problems:
      1: If you only want to use one function of another script you have to
      include the whole file.. So the most used way was to copy/paste the
      function (I think)

      2: If you're using functions from other scripts you run the risk of
      braking things when you intall a newer version of that script

      3: The example netrw was mentioned earlier that it's a huge script so
      it makes no sense to load the whole script if you want to use only
      limited functionality of it.

      I'm not such an experienced vim programmer because I'm using vim/linux
      (gentoo ;) for little longer than a year now.o

      Point 4 (personal keybindings) lead me to the idea of seperating the
      description of the userinterface (commands/ maps and so on) from the
      script functionality.. So all users on a linux box might share the
      vimscript implementation but may use different ui-descriptions:
      So this might end in a vimfile which might look
      like this:

      --- ui_myscript.vim - start
      " This file describes the commands/keymappings
      map \thislineUpperCase call library/experimental/MarcsUsefulScripts/MakeThisLineUppercase()v>0.2
      --- ui_myscript.vim - end

      I think you've already noticed that I'm moving towards some kind of
      version-control (as gentoo uses it). So you can be sure if you limit
      yourself to one specific version that it will work in the future, too.
      I like the idea of having a "vim library":

      userinteraces/
      [..]
      library/
      experimental/
      [..]
      vim63stable/
      [..]

      in more detail:
      userinteraces/
      examplemappings/
      examplemappings.vim
      DrChipScripts/
      HiCurLine.vim
      WhereFrom.vim
      Manpageview.vim
      MyOwnMappings/
      C++Mappings.vim
      library/
      experimental/
      myownscripts/datefunctions/
      StrinToDate-0.9.vim
      dateToString-0.9.vim
      DrChipScripts;-)/
      AsNeeded/
      AsNeeded-1.0.vim
      ANX-1.0.vim
      vim63stable/
      userinteraction/
      askquestion-1.0.vim
      yesnoquestion-1.1.vim
      date/
      netrw/
      allthefunctions-1.0.vim
      [..]

      If you combine a system like this you can do a lot..
      Let me give an example
      It should be easy to create a parser for your vim scripts which lists
      all used functions.. So you can automatically delete all outdated
      functions which you don't need anymore. But you can also do the
      opposite: Write a script which downloads all missing functions/ updates
      all functions (If you're using something like cvs/ftp)

      But I don't know how much time it takes to source every function..
      Of course you'll tell me that it will be much effort to write the
      directory in front of everyt functions (as in the example of the user
      interface script) But it should be easy to write a script which looks
      the directory/version up perhaps using s.th. similar to ANtags.. The
      difference would be that only the users who develop have to use the
      tags and you can easily automate operations like 'find all wrong
      invalid function references and correct them.

      And I'm sure many thins would become simpler eg:
      Use functionality of matchit.vim in your own indent expressions..
      or use the functionality privided in the imaps.vim from the LaTeX suite
      to jump to the next <+description+> tag using C-j ....

      And if you are writing a script which has a lot of functions why not add
      an using.vim file with aliases or function references in your script
      directory providing a dictionary for the vimscript interpreter so that
      it does know which function you want to have?
      experimental/myscript/
      notes.vim # < containing notes about the changes, author of the script myscript
      using.vim
      function1-version.vim
      function8-version.vim

      -- experimental/myscript/using.vim - start
      function AddElementToArray(): library/stable/array/AddElementToArray()v>1.2
      function RemoveElementFromArray(): library/stable/array/RemoveElementFromArray()v>1.2
      -- experimental/myscript/using.vim - end

      -- experimental/myscript/function1-version.vim - start
      source using.vim
      function fucntion1()
      "Call the functions and because of source using.vim vim does know
      "where to look for the functions
      let array=library/stable/array/CreateNewArray()v>1.0
      call AddElementToArray(array,element)
      call RemoveElementFromArray(array,element)
      endfunction
      -- experimental/myscript/function1-version.vim - end

      So creating a "namespace" would become nothing more then writing such a
      using.vim file which you (or others) can source..

      Of course there would arise some conflicts but keep in mind that
      everyone can fix them easily.

      And you can also teach vim to first look for a function in the stable
      directory, then at the expermental one.. So you can move the functions
      from experimental to stable without changing your scripts.!

      I'm sure I have forgotten some points or problems with a system like
      that so reply to open my mind.

      Marc
    • Marc Weber
      Really hot topic ;) Remarks to prior posts: adding path as prefix to a function isn t necessary (if there is a autoload folder) because the place of the file
      Message 50 of 50 , Mar 7, 2005
      • 0 Attachment
        Really hot topic ;)

        Remarks to prior posts:
        adding path as prefix to a function isn't necessary (if there is a
        autoload folder) because the place of the file tells already that the
        function should have the prefix [...].
        So the problem doesn't arise that s.o want's to use your function
        you haven't thought of (and you've forgotten to add the
        directory-namingspace)

        The nice effect of having errormessages which tell where the function
        was defined can be implemented without thinking of autoloading.. Just
        save the origin and the functionname and you can create errormessages
        like this:
        error in line xy of function directory:functionname
        or commandline:functionname if it's a function written at the vim
        commandline..

        My thoughts:
        goals:
        1 sharing of the source (reusable code)
        2 should be updateable ( s.th. like update all would be nice)
        3 the implementation should be loaded when the function is used to
        speed up start up time of vim.
        4 due to different keyboard layouts and personal preferences everybody
        want's to have is own (different) keybindings..

        Problems:
        1: If you only want to use one function of another script you have to
        include the whole file.. So the most used way was to copy/paste the
        function (I think)

        2: If you're using functions from other scripts you run the risk of
        braking things when you intall a newer version of that script

        3: The example netrw was mentioned earlier that it's a huge script so
        it makes no sense to load the whole script if you want to use only
        limited functionality of it.

        I'm not such an experienced vim programmer because I'm using vim/linux
        (gentoo ;) for little longer than a year now.o

        Point 4 (personal keybindings) lead me to the idea of seperating the
        description of the userinterface (commands/ maps and so on) from the
        script functionality.. So all users on a linux box might share the
        vimscript implementation but may use different ui-descriptions:
        So this might end in a vimfile which might look
        like this:

        --- ui_myscript.vim - start
        " This file describes the commands/keymappings
        map \thislineUpperCase call library/experimental/MarcsUsefulScripts/MakeThisLineUppercase()v>0.2
        --- ui_myscript.vim - end

        I think you've already noticed that I'm moving towards some kind of
        version-control (as gentoo uses it). So you can be sure if you limit
        yourself to one specific version that it will work in the future, too.
        I like the idea of having a "vim library":

        userinteraces/
        [..]
        library/
        experimental/
        [..]
        vim63stable/
        [..]

        in more detail:
        userinteraces/
        examplemappings/
        examplemappings.vim
        DrChipScripts/
        HiCurLine.vim
        WhereFrom.vim
        Manpageview.vim
        MyOwnMappings/
        C++Mappings.vim
        library/
        experimental/
        myownscripts/datefunctions/
        StrinToDate-0.9.vim
        dateToString-0.9.vim
        DrChipScripts;-)/
        AsNeeded/
        AsNeeded-1.0.vim
        ANX-1.0.vim
        vim63stable/
        userinteraction/
        askquestion-1.0.vim
        yesnoquestion-1.1.vim
        date/
        netrw/
        allthefunctions-1.0.vim
        [..]

        If you combine a system like this you can do a lot..
        Let me give an example
        It should be easy to create a parser for your vim scripts which lists
        all used functions.. So you can automatically delete all outdated
        functions which you don't need anymore. But you can also do the
        opposite: Write a script which downloads all missing functions/ updates
        all functions (If you're using something like cvs/ftp)

        But I don't know how much time it takes to source every function..
        Of course you'll tell me that it will be much effort to write the
        directory in front of everyt functions (as in the example of the user
        interface script) But it should be easy to write a script which looks
        the directory/version up perhaps using s.th. similar to ANtags.. The
        difference would be that only the users who develop have to use the
        tags and you can easily automate operations like 'find all wrong
        invalid function references and correct them.

        And I'm sure many thins would become simpler eg:
        Use functionality of matchit.vim in your own indent expressions..
        or use the functionality privided in the imaps.vim from the LaTeX suite
        to jump to the next <+description+> tag using C-j ....

        And if you are writing a script which has a lot of functions why not add
        an using.vim file with aliases or function references in your script
        directory providing a dictionary for the vimscript interpreter so that
        it does know which function you want to have?
        experimental/myscript/
        notes.vim # < containing notes about the changes, author of the script myscript
        using.vim
        function1-version.vim
        function8-version.vim

        -- experimental/myscript/using.vim - start
        function AddElementToArray(): library/stable/array/AddElementToArray()v>1.2
        function RemoveElementFromArray(): library/stable/array/RemoveElementFromArray()v>1.2
        -- experimental/myscript/using.vim - end

        -- experimental/myscript/function1-version.vim - start
        source using.vim
        function fucntion1()
        "Call the functions and because of source using.vim vim does know
        "where to look for the functions
        let array=library/stable/array/CreateNewArray()v>1.0
        call AddElementToArray(array,element)
        call RemoveElementFromArray(array,element)
        endfunction
        -- experimental/myscript/function1-version.vim - end

        So creating a "namespace" would become nothing more then writing such a
        using.vim file which you (or others) can source..

        Of course there would arise some conflicts but keep in mind that
        everyone can fix them easily.

        And you can also teach vim to first look for a function in the stable
        directory, then at the expermental one.. So you can move the functions
        from experimental to stable without changing your scripts.!

        I'm sure I have forgotten some points or problems with a system like
        that so reply to open my mind.

        Marc
      Your message has been successfully submitted and would be delivered to recipients shortly.