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

Re: script bloat

Expand Messages
  • dman
    ... No, sorry, I wasn t with vim back then. ... Sounds cool. ... The cluster size can be adjusted. ... WinNT/2k like to use NTFS as their file system. I don t
    Message 1 of 24 , Nov 2, 2001
    • 0 Attachment
      On Fri, Nov 02, 2001 at 04:42:55PM +0100, Zdenek Sekera wrote:
      | Benoit Cerrina wrote:

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

      No, sorry, I wasn't with vim back then.

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

      Sounds cool.

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

      The cluster size can be adjusted.

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

      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.

      | So we can today autoload somehow mostly what we want but we still cannot
      | 'delf' automatically anything. Maybe it's really not needed.

      I think try the autoloading thing, and if it turns out that memory
      usage is a problem add the unloading thing.

      -D
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.