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

RE: automatic loading of scripts

Expand Messages
  • Brandt, Servatius
    ... will ... of ... But then the file scope is a scope more generic than s: and g: etc. So script variables should not be named s:longpackagename:foofunc
    Message 1 of 50 , Feb 8, 2005
      Bram Moolenaar wrote:
      > Servatius Brandt wrote:
      > > In my opinion it's a bit difficult to understand. Function names
      > > get very long because of the path prefix, and I don't like the use
      > > the colon because it can be confused with the scope prefixes.
      > In a sense the name is a scope name. A scope in which functions are
      > defined.

      But then the file scope is a scope more generic than "s:" and "g:" etc.
      So script variables should not be named




      and then the a script could not be named "s.vim". If we require the


      we would have to forbid single letter subdirectories under "autoload",
      but the "s:" scope specifier in front of the "longpackagename:" scope
      specifier does not look intuitive to me. Of course, it is possible and
      I'll get used to it.

      Hmm, maybe I misunderstood something. Is the "longpackagename:" just
      a new scope specifier that can be used instead of but not in conjunction
      with the single letter scope specifiers?

      > Function names will get longer, that is true. You can use a FuncRef
      > variable if that becomes a problem:
      > :let s:Foo = function('longpackagename:foofunc')
      > :call s:Foo()
      > The long name is required to avoid name clashes, since all function
      > names are global (script-local ones get a special number, so that they
      > can be invoked from a mapping, but they are still global).

      So the "longpackagename:" is just a generalisation of the "s:" prefix?
      So that it allows to call functions between different scripts of
      a group? Then maybe it would be useful to have also
      a "./longpackagename" or "../longpackagename" beginning at the directory
      of the current script rather than the "autoload" directory.

      > > I think it's not sufficient since it expects script writers to speed
      > > up each of their scripts seperately.
      > >
      > > As a user I would prefer a method that allows to autoload every
      > > I've downloaded somewhere, even if the script writer didn't care
      > > this issue.
      > I don't agree with that. The script writer is repsonsible for what he
      > writes. And it's nearly impossible to guarantee autoloading a script
      > works, you have to carefully check that it's OK.

      But plugins are autoloaded anyway. The question is only when this
      happens: at startup or when needed. I'm not sure that it is really
      impossible to postpone loading plugins. Maybe it is, but from a user's
      view it would be useful if this worked for every script.

      > > It would be good if I could do this without changing the
      > > script and even without looking into it.
      > Yes, but that is not possible. The solution you describe does not
      > care of:
      > - user commands that are defined in the script

      See my reply to Antony Scriven's post.

      > - mappings that are defined in the script

      It should be possible to generate corresponding mappings in loader.vim
      that undefine themselves, source the correct script defining them and
      execute this new definition.

      > - default values for global variables (used as a setting)

      This would not be necessary: Global variables executed in a script are
      defined when the script is sourced the first time. Global variables
      defined as a setting in the user .vimrc file (before sourcing the
      plugins) are not affected when the sourcing is postponted to the time
      the plugin is actually used.

      > - probably a few other things.

      Don't know.

      > It's very complicated as well. Sorry, I just don't find it

      I tried to think simple: we need just a mechanism to postpone the
      sourcing of the plugin and to map its user interface (functions,
      commands, mappings) to something that triggers the sourcing of the
      plugin to get the correct definitions before execution.

      As I said, it's just an idea, not fully worked out.

      Servatius Brandt Phone: +49 89 636-41504
      Fujitsu Siemens Computers Fax: +49 89 636-48716
      EP SW AD C++ Email: Servatius.Brandt@...
    • 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
        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

        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

        My thoughts:
        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..

        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":


        in more detail:

        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?
        notes.vim # < containing notes about the changes, author of the script myscript

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

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