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

Re: script bloat

Expand Messages
  • Dan Sharp
    ... Sorry for the formatting above. Hotmail s compose window is really small. Anyway, to make the command a little more consistent with 6.0 features, I
    Message 1 of 24 , Nov 2, 2001
    • 0 Attachment
      >From: Zdenek Sekera <zs@...>
      >
      >Ron Aaron wrote:
      >>
      >>aug autoload_package
      >> au FuncUndefined * :silent! exe 'source
      >>'.$VIMGLOBAL.'/auto/'.expand("<afile>").'.vim'
      >>aug END
      >>
      >>Put the files named after the functions, in $VIMGLOBAL/auto as before...
      >
      >Yep, that's it! :-)

      Sorry for the formatting above. Hotmail's compose window is really small.
      Anyway, to make the command a little more consistent with 6.0 features, I
      changed the part

      exe 'source '.$VIMGLOBAL.'/auto/'.expand("<afile>").'.vim'

      to

      exe 'runtime! auto/'.expand("<afile>").'.vim'

      to make it look in the runtime directories for files. It uses Vim's builtin
      path searching mechanism and saves having to define an environment variable.
      Of course, it makes it 6.0 specific, if that matters...

      I called a function without an auto directory created, and just got an
      "unknown funtion" error. Then I created a vimfiles\auto directory and put
      the function in it, and it ran the function when I called it.

      The autoloading works very well! I missed this idea the first time around.
      Thanks guys!

      Dan Sharp

      _________________________________________________________________
      Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
    • Aric Blumer
      ... I think we agree that there is a means to load functions from a library , so what we need now is a set of standard functions that all Vim distributions
      Message 2 of 24 , Nov 2, 2001
      • 0 Attachment
        On Fri Nov 2 11:52:21 2001 Dan Sharp wrote:
        > [discussion of using FuncUndefined event to load a function snipped]

        I think we agree that there is a means to load functions from a
        "library", so what we need now is a set of standard functions that all
        Vim distributions contain (similar to standard plugins).

        We know there's one on the list already:

        Sort

        Others?

        (BTW, Bram, do you think this is a good idea? feasible?)
      • Dan Sharp
        ... What we need now to make it truly useful is a method to unload the functions, perhaps automatically after some interval (via CursorHold?). Otherwise, the
        Message 3 of 24 , Nov 2, 2001
        • 0 Attachment
          >From: Aric Blumer <Aric.Blumer@...>
          >
          >I think we agree that there is a means to load functions from a
          >"library", so what we need now is a set of standard functions that all
          >Vim distributions contain (similar to standard plugins).

          What we need now to make it truly useful is a method to unload the
          functions, perhaps automatically after some interval (via CursorHold?).
          Otherwise, the library scripts could just be stuck in the plugins directory
          and achieve almost the same effect -- always being in memory after use; in
          that case they would just be in memory before use as well.

          >We know there's one on the list already:
          >
          > Sort
          >
          >Others?

          I think there is a binary search routine that a few scripts use.
          ctags-script.vim does, at least, but with a little modification it could be
          generally useful. No header info, so I don't know who created it.

          Dan Sharp

          _________________________________________________________________
          Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
        • Ron Aaron
          ... That is true, but the real point of autoloading is that it reduces startup time dramatically if you set things up correctly. I m not sure the memory
          Message 4 of 24 , Nov 2, 2001
          • 0 Attachment
            Dan Sharp <dwsharp@...> writes:
            >What we need now to make it truly useful is a method to unload the
            >functions, perhaps automatically after some interval (via CursorHold?).
            >Otherwise, the library scripts could just be stuck in the plugins directory
            >and achieve almost the same effect -- always being in memory after use; in
            >that case they would just be in memory before use as well.

            That is true, but the real point of autoloading is that it reduces startup
            time dramatically if you set things up correctly. I'm not sure the memory
            footprint is terribly important compared to the time savings.

            >>We know there's one on the list already:
            >>
            >> Sort
            >>
            >>Others?
            >
            >I think there is a binary search routine that a few scripts use.
            >ctags-script.vim does, at least, but with a little modification it could be
            >generally useful. No header info, so I don't know who created it.

            Here's my .00199 -- I think that there should be a *builtin function* 'sort'
            and 'bsearch', which would treat the buffer as an array of lines. This would
            be far faster than any script, and the runtime library /already/ has suitable
            functions. It would be a pretty easy set of functions to add.

            Ron
          • Bram Moolenaar
            ... It s already possible to load functions on demand. It doesn t make much sense to add a library of functions to the distribution, implementing them in C
            Message 5 of 24 , Nov 2, 2001
            • 0 Attachment
              Aric Blumer wrote:

              > On Fri Nov 2 11:52:21 2001 Dan Sharp wrote:
              > > [discussion of using FuncUndefined event to load a function snipped]
              >
              > I think we agree that there is a means to load functions from a
              > "library", so what we need now is a set of standard functions that all
              > Vim distributions contain (similar to standard plugins).
              >
              > We know there's one on the list already:
              >
              > Sort
              >
              > Others?
              >
              > (BTW, Bram, do you think this is a good idea? feasible?)

              It's already possible to load functions on demand. It doesn't make much
              sense to add a library of functions to the distribution, implementing
              them in C would be much better for speed (and probably for size as
              well). Only advantage of the script is that it doesn't occupy memory
              when it's not used. But is that important these days?

              It might help a bit if we have a standard directory to put the functions
              into. Remaining problem is the naming. That's where we always got
              stuck in the past.

              --
              BEDEVERE: And what do you burn, apart from witches?
              FOURTH VILLAGER: ... Wood?
              BEDEVERE: So why do witches burn?
              SECOND VILLAGER: (pianissimo) ... Because they're made of wood...?
              "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

              /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
              ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
              \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
            • Benji Fisher
              ... Like most people, I have my own favorites, which just happen to be in scripts I wrote myself. Here are a few: 1. Functions to deal with comma-separated
              Message 6 of 24 , Nov 2, 2001
              • 0 Attachment
                On Friday, November 2, 2001, at 12:17 PM, Aric Blumer wrote:

                > On Fri Nov 2 11:52:21 2001 Dan Sharp wrote:
                >> [discussion of using FuncUndefined event to load a function snipped]
                >
                > I think we agree that there is a means to load functions from a
                > "library", so what we need now is a set of standard functions that all
                > Vim distributions contain (similar to standard plugins).
                >
                > We know there's one on the list already:
                >
                > Sort
                >
                > Others?
                >
                > (BTW, Bram, do you think this is a good idea? feasible?)

                Like most people, I have my own favorites, which just happen to be
                in scripts I wrote myself. Here are a few:

                1. Functions to deal with "comma-separated lists" or arrays. You can
                find a lot of these in matchit.vim . I would have to clean them up a
                bit to make them widely useful. I think there are other implementations
                around (cf. the title of this thread).

                2. Functions to save and restore cursor and screen position. A lot of
                scripts use something like this, and you have to remember to use
                virtcol() and the trick of recording the line number at the top of the
                screen, and going there for a "normal!zt" before going to the original
                line. These are in foo.vim:
                http://vim.sourceforge.net/scripts/script.php?script_id=72

                3. Other functions or commands that make it easier to write vim
                scripts. For example, a command that allows you to do

                :let foo=3 | let bar = 6
                :Range foo-1,bar+2 s/foo/bar/g

                is also in foo.vim.

                4. I have a function that creates a menu entry with a reminder of the
                keyboard shortcut, so the user can customize the key binding and still
                have the menu remind him or her what the shortcut is. This is in my tex
                macros (not yet released as an ftplugin for vim 6.0).

                It may be too early to decide on particular functions to include or
                not. Let me propose one criterion: if a function is used by two
                standard plugins, or by a standard plugin and a popular, non-standard
                one, then it should be available for everyone to use. (By "plugin" I
                mean filetype as well as global plugins.)

                --Benji Fisher
              • Brian Medley
                ... Yes, I agree with you a method to only what is needed would be most beneficial. However, I was not referring to having one huge library file. Having small
                Message 7 of 24 , Nov 2, 2001
                • 0 Attachment
                  On Fri, Nov 02, 2001 at 11:25:48AM +0100, Benoit Cerrina wrote:

                  > Problem with one pottentially large standard library is that you load it
                  > all or not at all. This is why I was suggesting a directory with plenty
                  > of smaller vim files containing each one library function, those would
                  > autoload thanks to the
                  >
                  > [..neat autoload snipped..]

                  Yes, I agree with you a method to only what is needed would be most
                  beneficial. However, I was not referring to having one huge library file.
                  Having small organized chunks would be useful.

                  --
                  ~'`^`'~=-.,__,.-=~'`^`'~=-.,__,.-=~'`^`'~=-., \|/ (___) \|/ _,.-=~'`^`
                  Brian Medley @~./'O o`\.~@
                  "Knowledge is Power" brian.medley@... /__( \___/ )__\ *PPPFFBT!*
                  -- Francis Bacon `\__`U_/'
                  _,.-=~'`^`'~=-.,__,.-=~'`^`'~=-.,__,.-=~'`^`'~= <____|' ^^`'~=-.,__,.-=
                  ~`'^`'~=-.,__,.-=~'`^`'~=-.,__,.-=~'`^`'~=-.,__,.-==--^'~=-.,__,.-=~'`^`
                • Benoit Cerrina
                  ... Sorry but the function I posted is direcly taken from Ron s scripts ... I didn t know about it, once more I was just advocating the solution I found in
                  Message 8 of 24 , Nov 4, 2001
                  • 0 Attachment
                    > Benoit Cerrina wrote:
                    > >
                    > > Problem with one pottentially large standard library is that you load
                    > > it all or not at all. This is why I was suggesting a directory with
                    > > plenty of smaller vim files containing each one library function, those
                    > > would autoload thanks to the
                    > >
                    > > " autoload stuff
                    > > fu! LoadOnDemand(funcname) abort
                    > > " first, save our current location information:
                    > > " see if the function exists:
                    > > let fn = $VIMGLOBAL.'/auto/'.a:funcname.'.vim'
                    >
                    > I don't understand why this function is needed after Ron Aaron's
                    > very nice invention of FuncUndefined event in autocmd. That does
                    > it already all. I have a directory with plenty of functions that
                    > are loaded 'on demand' due to the FuncUndefined event.
                    > Very nice and trivial.
                    Sorry but the function I posted is direcly taken from Ron's scripts

                    >
                    > However, I find the Benoit suggestion of '...a directory with
                    > plenty of smaller vim files containing each one library function...'
                    > kind of puzzling:
                    >
                    > Some of you may remember my patch for 'dynamic functions' for
                    > vim 5.4g (that's around May/99).
                    I didn't know about it, once more I was just advocating the solution
                    I found in Ron's scripts which I found apealing
                    >
                    > What did it do:
                    > Have one (or more directories) with plenty of small vim files
                    > containing one function (coincidence?). A function would be loaded
                    > only if not yet in vim's memory, timer was kept for when function
                    > was loaded and when last used, if not used with user selectable
                    > timer, it would be automatically 'delfunction'ed to free up memory.
                    > If needed next time after, it would be reloaded by the same
                    > mechanism. A provision existed for (user definable) functions that
                    > would not be 'delf'ed ever, because of whatever reason user could
                    > imagine.
                    > (The autoload mechanism was since replaced by (better IMHO)
                    > FuncUndefined
                    > event.)
                    I don't know how you were doing it without this event. There is still
                    need for a FuncUndefined handler, just the existence of the event
                    doesn't make the function autoload and I don't know what is the hit
                    with many handlers, it may be ok
                    >
                    > It was voted down by M$windows user's with the argument that
                    > M$windows is very (even 'extremely' was used at that time)
                    > inefficient with disk space usage so keeping many small (and vim
                    > functions are mostly really small) just eats up unreasonably disk
                    > space.
                    This is true for fat16, it is largely not true with fat32 which is
                    mainstream now and simply completely wrong with NTFS which is already
                    default for NT and 2000 and with the advent of XP will become mainstream

                    >
                    > It is interesting to note that this argument doesn't seem to be valid
                    > anymore, because *NOBODY* ever complained when plugin/ftplugin/...
                    > (great!) directories appeared in 6.0 with contents that is exactly
                    > 'plenty of small files...'
                    >
                    > Could some knowledgable Windows user comment on that?
                    > Has anything in the disk handling changed in Windows since?
                    >
                    > So I was asked to invent some mechanism with tags so all these
                    > small files could be kept in one (or several) big files and
                    > autoloaded from there (find the beginning and end of a function
                    > and source between those two points.
                    >
                    > I never found that idea very appealing so I gave up.
                    >
                    > Note that I am, however, doing it right now, little differently
                    > (not in such a generic way), but only in special cases:
                    >
                    > I have often have scripts that contain number functions, unique
                    > to this script. There is always one functions that starts it up,
                    > so I load the whole script via that one function, like this
                    > (suppose MyNewInvention.vim is that script, A is the 'main'
                    > calling entry):
                    >
                    > autocmd FuncUndefined A runtime functions/MyNewInvention.vim
                    > or autocmd FuncUndefined A source somedir/MyNewInvention.vim
                    >
                    > depending on circumstances. I have many different variants of this.
                    > This way the first called function will get in all the others,
                    > they will be needed anyway.
                    >
                    > But this is not the same as the original request with tags (to find
                    > any function anywhere on any file withint certain directories).
                    >
                    > So we can today autoload somehow mostly what we want but we still cannot
                    > 'delf' automatically anything. Maybe it's really not needed.
                    >
                    > Just a comment.
                    >
                    > ---Zdenek
                    >
                    My problem with loading a bunch of stuff as it is now done with plugins is
                    the startup time. For example I have the drawit plugin, then it loads each
                    time I start vim. I really like this plugin but I use it maybe once every
                    20 or 30 times I launch a vim. Therefore I rewrote it to be autoloadable.
                    This is still some work for most plugins. You say you do just this, then
                    its great but the vim manual doesn't encourage it so many plugins do not
                    come
                    with this type of functionality.
                    Benoit
                  • Benoit Cerrina
                    ... .$VIMGLOBAL. /auto/ .expand( ). .vim ... Great, as I said the function I posted directly came from a version of your scripts. which I had on my
                    Message 9 of 24 , Nov 4, 2001
                    • 0 Attachment
                      > Zdenek Sekera <zs@...> writes:
                      > >I don't understand why this function is needed after Ron Aaron's
                      > >very nice invention of FuncUndefined event in autocmd. That does
                      > >it already all. I have a directory with plenty of functions that
                      > >are loaded 'on demand' due to the FuncUndefined event.
                      > >Very nice and trivial.
                      > >
                      >
                      > Ok, Zdenek -- here's my more simple version, which works just as well:
                      >
                      > aug autoload_package
                      > au FuncUndefined * :silent! exe 'source
                      '.$VIMGLOBAL.'/auto/'.expand("<afile>").'.vim'
                      > aug END
                      >
                      >
                      > Put the files named after the functions, in $VIMGLOBAL/auto as before...
                      >
                      > Ron
                      >
                      Great, as I said the function I posted directly came from a version of your
                      scripts. which
                      I had on my computer.
                      Benoit
                    • Benoit Cerrina
                      ... http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fsys _538t.asp Benoit
                      Message 10 of 24 , Nov 4, 2001
                      • 0 Attachment
                        >
                        > WinNT/2k like to use NTFS as their file system. I don't really know
                        > how it is different from FAT(16/32) other than the linux dudes haven't
                        > completely reverse engineered it yet.
                        http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fsys
                        _538t.asp
                        Benoit
                      • Benoit Cerrina
                        contain (similar to standard plugins). ... directory ... and slow down startup time Benoit
                        Message 11 of 24 , Nov 4, 2001
                        • 0 Attachment
                          contain (similar to standard plugins).
                          >
                          > What we need now to make it truly useful is a method to unload the
                          > functions, perhaps automatically after some interval (via CursorHold?).
                          > Otherwise, the library scripts could just be stuck in the plugins
                          directory
                          > and achieve almost the same effect -- always being in memory after use; in
                          > that case they would just be in memory before use as well.
                          and slow down startup time
                          Benoit
                        Your message has been successfully submitted and would be delivered to recipients shortly.