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

Re: some vim standard ? (stdlib.vim)

Expand Messages
  • Luc Hermitte
    Hello Sylvain, ... Exactly. ... Not necesserally. Some of us write plugins intended to be used by other plugins. Often we also write a documentation. ...
    Message 1 of 6 , Dec 1, 2002
    • 0 Attachment
      Hello Sylvain,

      * On Sat, Nov 30, 2002 at 11:26:54PM -0500, Sylvain Viart <viart.sylvain@...> wrote:
      > > No. There are many global functions developped by different people
      > > that could serve as a library. That's all.
      > >
      > [...]
      > > If you found plugins/macros that already propose features you are
      > > interrested in, my advice is to use these scripts.
      > [...]
      > > contact the author to see if he is willing to enhance his script, if
      > > not then develop our own.
      > >
      > The well known big round wheel reinvented once again ! ;)

      Exactly.

      > How do I found the interesting functions ?
      > Reading and reading undocumented vim code ?..
      > A pretty good challenge, isn't it. ;)

      Not necesserally. Some of us write plugins intended to be used by other
      plugins. Often we also write a documentation.

      > [maintenance & modularity]
      > A common problem, in fact. May be a libbuilder would be a solution.

      > Here is how I see the trick :
      >
      > There is a library of plenty a functions for various task. A libbuilder
      > can be a CGI script (or php, or what ever...) which will build
      > the custom library with the subset of function you need.
      >
      > Would it solve everyone preference ?
      everyone preferences ? ... hardly I think.

      A tour on SF shows us a tendency to reinvent the wheel because of a
      little something missing, or too many things unwanted, etc. And i'm not
      the last to reinvent things :-)

      But, I reckon having a libbuilder may be interresting in some
      situations.

      --
      Luc Hermitte
      http://hermitte.free.fr/vim/
    • Sylvain Viart
      Hi Luc, ... I ve seen user documentation and that s very good. :) But I never seen developer documentation. And that s pretty normal, because script are rarely
      Message 2 of 6 , Dec 1, 2002
      • 0 Attachment
        Hi Luc,

        Luc Hermitte wrote:
        > > How do I found the interesting functions ?
        > > Reading and reading undocumented vim code ?..
        > > A pretty good challenge, isn't it. ;)
        >
        > Not necesserally. Some of us write plugins intended to be used by
        > other plugins. Often we also write a documentation.
        >
        I've seen user documentation and that's very good. :)

        But I never seen developer documentation. And that's pretty normal,
        because script are rarely developed to be shared at development
        level. That's my opinion for now, I may be wrong.

        > > May be a libbuilder would be a solution.
        > > Would it solve everyone preference ?
        > everyone preferences ? ... hardly I think.
        >
        Could you give me case where a libbuilder will fail to solve people's
        problem about code inclusion / sharing ?

        Of course the libbuilder need also an input strategy. It's not our
        problem for now, we are just guessing.

        > A tour on SF shows us a tendency to reinvent the wheel because of a
        > little something missing, or too many things unwanted, etc.
        >
        Yes, that's true. But I'm speaking at API level not application level.

        I mean, it would probably interest developer to have a common library
        shared/tested/debugged/cvsized to be the base of any application
        development. Like functions in eval.txt in fact.

        It's the goal of open source sharing, isn't it ?

        I should probably ask my initial question this way :

        How should I write my code so developer can use/share/add/change
        the coding effort I've made ?

        Because I care about people interested by my work. I wouldn't share it
        if not. And because I will lack of time when problem will come with my
        code.

        An interesting question raise:
        Is vim designed to enable code share/reuse ?

        The difficulty to write a function which would give the name
        of the sourced script in which a function was written may be a clue...

        I continue to read the doc, I may found a solution.
        Regards,
        --
        - Sylvain Viart -
        - Blainville - Canada -
        Je parle aussi le fran├žais.
      • Steve Hall
        ... Vim help is sprinkled with some of these but a Vim Standard Library Guidelines doc might be a good place to start. Here s a few of mine: * Don t ever use
        Message 3 of 6 , Dec 1, 2002
        • 0 Attachment
          On Sun, 2002-12-01 at 22:02, Sylvain Viart wrote:
          >
          > I mean, it would probably interest developer to have a common
          > library shared/tested/debugged/cvsized to be the base of any
          > application development. Like functions in eval.txt in fact.
          >
          > It's the goal of open source sharing, isn't it ?
          >
          > I should probably ask my initial question this way :
          >
          > How should I write my code so developer can use/share/add/change
          > the coding effort I've made ?

          Vim help is sprinkled with some of these but a "Vim Standard Library
          Guidelines" doc might be a good place to start. Here's a few of mine:

          * Don't ever use <Esc>. It does different things depending on whether
          insertmode is on or off.

          * Always create insertmode mappings for those who use insertmode.

          * Try to avoid loose script commands. Instead, always create functions
          that do specific tasks when called.

          * Try to have mode passed as an argument to main functions so calling
          mappings, scripts or menus are forced to consider mode.

          * Always scope functions and variables when not intended to be global.

          * Always write script with &fileformat=unix. &fileformat=dos won't
          work on unix.

          * Never use Vim's abbreviated forms for commands or options. Always
          use the full name since code readability is paramount!

          * Always use spaces around operators and concatenation symbols.

          * Don't glob normal commands on one line. Separate them into readable
          chunks.

          * Never use the "l:" scope indicator within functions. It's redundant
          redundant.


          Wow, that was fun! But see how quickly I degraded into personal
          preference and style guide rather than "legitimate" library
          guidelines? I'd be game to help on a stdlib.vim effort like this, but
          I wonder if it would become ensnared in a similar bureaucracy. ;)


          Steve Hall [ digitect@... ]
        • Piet Delport
          ... [...] ... Sometimes the abbreviated forms are more readable, IMHO. Examples: :abbrev, :exec, :hi, :e, and friends ... This one also depends... sometimes
          Message 4 of 6 , Dec 2, 2002
          • 0 Attachment
            On Sun, 01 Dec 2002 at 22:34:56 -0500, Steve Hall wrote:
            >
            > Vim help is sprinkled with some of these but a "Vim Standard Library
            > Guidelines" doc might be a good place to start. Here's a few of mine:
            >
            [...]
            >
            > * Never use Vim's abbreviated forms for commands or options. Always
            > use the full name since code readability is paramount!

            Sometimes the abbreviated forms are more readable, IMHO.

            Examples: :abbrev, :exec, :hi, :e, and friends

            > * Always use spaces around operators and concatenation symbols.

            This one also depends... sometimes it's more readable to cluster a small
            group of related operators together without spaces, to keep them from
            visually interfering with other operators.

            --
            Piet Delport
            Today's subliminal thought is:
          • Luc Hermitte
            ... It depends. The rare plugins exposing functions to developpers often have a documentation aimed at developpers. Somehow they are API plugins. Other plugins
            Message 5 of 6 , Dec 2, 2002
            • 0 Attachment
              * On Sun, Dec 01, 2002 at 10:02:19PM -0500, Sylvain Viart <viart.sylvain@...> wrote:
              > I've seen user documentation and that's very good. :)
              >
              > But I never seen developer documentation. And that's pretty normal,
              > because script are rarely developed to be shared at development level.
              > That's my opinion for now, I may be wrong.

              It depends. The rare plugins exposing functions to developpers often
              have a documentation aimed at developpers. Somehow they are API plugins.

              Other plugins don't have documentation about their functions as they are
              not API-plugins. However, sometimes internal considerations are embedded
              within the code for those who may wish to look at the code.

              > > > May be a libbuilder would be a solution.
              > > > Would it solve everyone preference ?
              > > everyone preferences ? ... hardly I `think'.
              > >
              > Could you give me case where a libbuilder will fail to solve people's
              > problem about code inclusion / sharing ?

              I have misunderstood you. On an application level, supporting every
              possible preference is quite impossible.
              On an API level, what is a preference ?
              Why does it concern the user ? Who is the user ? The VimL developper or
              the end-user ?

              It is very fuzzy.
              The latest plugin I wrote (ui-functions.vim) defines several functions
              aimed at plugin writers (or template-files writers). I think I can say
              ui-functions.vim is an API-plugin.

              At this time, the functions wraps VimL functions like |confirm()| to
              interact with the user in :
              - a gui-way (default behaviour when "has('gui_running')" is true)
              - a text-ui-way (otherwise)
              Depending on the current session characteristics or options set by the
              end user, one of these two ways will be used.

              Then, as I had a problem with |statusline|, I exposed it on this list.
              Two other 'ways' were evoked. And I have two others in mind.
              Unless I expose hooks, my functions can only propose a _finite_ number
              of ways.


              > Of course the libbuilder need also an input strategy. It's not our
              > problem for now, we are just guessing.

              Just curious, have you checked |libcall()| ?

              > > A tour on SF shows us a tendency to reinvent the wheel because of a
              > > little something missing, or too many things unwanted, etc.
              > Yes, that's true. But I'm speaking at API level not application level.

              It is the same problem.

              > [...]
              > An interesting question raise:
              > Is vim designed to enable code share/reuse ?

              It is not really efficient or neat, but possible.

              For instance, as I do have several 'API'-plugins used by other scripts I
              wrote, I often need to check dependencies are respected. As I can not
              define a script that will check other scripts are installed (... snake
              that bites its tail), every time I end up with:
              - a function that display error messages (gui or text depending on
              current session)
              - a function that check a thing is defined (command, function, or
              variable), if not try to source the file that is supposed to define
              the thing (with runtime), it the thing is still not defined, then
              an error message is displayed.
              - several calls to the dependencies-checker function.

              [Now, I'm thinking, this is a very good candidate for a template-file.]

              > The difficulty to write a function which would give the name of the
              > sourced script in which a function was written may be a clue...

              Try:
              let s:script_name = expand('<sfile>')
              function ScriptName()
              return s:script_name
              endfunction


              Anyway, there are many low level stuff (ie aimed at plugin writters)
              that I miss. So any step in this direction would be great.

              Luck.

              --
              Luc Hermitte, qui se doutait bien tu parlais aussi fran├žais. ~_^
              http://hermitte.free.fr/vim/
            Your message has been successfully submitted and would be delivered to recipients shortly.