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

Re: some vim standard ? (stdlib.vim)

Expand Messages
  • 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 1 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 2 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 3 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.