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

Re: Vim user repository suggestion

Expand Messages
  • Chris Niekel
    ... I just posted a somewhat negative post about guidelines to this list. However, your guidelines seem like a very good idea. Maybe I should read a
    Message 1 of 8 , Sep 11, 2000
    • 0 Attachment
      On Mon, Sep 11, 2000 at 04:17:45PM +0200, Johannes Zellner wrote:
      > I've put some /quick/ thoughts at
      >
      > http://vim.sourceforge.net/scripts/script-guidelines.html
      > (This page is not yet linked anywhere!)

      I just posted a somewhat negative post about guidelines to this list.
      However, your guidelines seem like a very good idea. Maybe I should read a
      mailinglist for a longer time before I join discussions. :)

      > wouldn't this discussion be better located at vim-dev ?

      I wouldn't think so. vim-dev is about developing vim, while this list is
      about using it. A collection of scripts is mostly for users, and maybe many
      users have ideas about how such a collection would be most valuable.

      But I may be completely wrong. That has happened before.

      Greetings,
      Chris Niekel

      --
      Geek code version 3.1:
      GCS d- s++: a- C++$ ULSI++ P+(---) L+++>++++ E--- W++ N++ o K? w--- O M-
      V?>-- PS+ PE-() Y PGP+ t+>+++ 5? X- !R tv+ b DI++ D+ G>++ e+++ h--- r+++ y+++
    • Thomas Köhler
      On Mon, Sep 11, 2000 at 04:17:45PM +0200, ... OK so far. As for rule 7: break lines longer than 80 columns into pieces Better reduce that 80 to 72 or so
      Message 2 of 8 , Sep 11, 2000
      • 0 Attachment
        On Mon, Sep 11, 2000 at 04:17:45PM +0200,
        Johannes Zellner <johannes@...> wrote:
        >
        > On Mon, Sep 11, 2000 at 02:56:24PM +0200, Zdenek Sekera wrote:
        > [...]
        > > it be a good idea to write some sort of 'submission guidelines' to
        > > avoid a havoc in scripts? I think a minimum coding standards/rules
        > > wouldn't harm. Johanes, haven't you suggested not long ago to volunteer
        > > to write something like this? If so, go for it!
        > [...]
        >
        > I've put some /quick/ thoughts at
        >
        > http://vim.sourceforge.net/scripts/script-guidelines.html
        > (This page is not yet linked anywhere!)

        OK so far.
        As for rule 7:
        "break lines longer than 80 columns into pieces"
        Better reduce that "80" to "72" or so - I use "set foldcolumn number"
        resulting in less space here. And sometimes, I happen to use 80x25
        terminals. Oops, only 72 characters left (I know, I can scroll or set
        the wrap option, but then where's the point of using only 80 characters
        in the first place?)

        Some ideas for documentation:
        - Functions: add documentation about all of their parameters, including
        type, same for return values.
        Example:
        " args:
        " x (type: string) - some string to be manipulated
        " returns:
        " a new string representing the result of a manipulation to the
        " arguments
        fun LolaDoSomething(x)
        ...
        - When using mappings, list _all_ used mappings in documentation.

        (not too much, but OK for 2 minutes of thinking :-)

        > If you want to be listed in the section `Authors' you've to make
        > suggestions / comments :-)

        Oops, so I've made suggestions / comments, will I go into `Authors' now?
        :-)

        > wouldn't this discussion be better located at vim-dev ?

        Yes, Cc'ed & Reply-To set :-)

        > Johannes

        Ciao,
        Thomas

        --
        Thomas Köhler Email: jean-luc@... | LCARS - Linux
        <>< WWW: http://jeanluc-picard.de | for Computers
        IRC: jeanluc | on All Real
        PGP public key available from Homepage! | Starships
      • Zdenek Sekera
        ... [...] ... Not bad at all for the start! Yes, the doc is the issue, I d like to see: - some systematic function header definition I think it is very
        Message 3 of 8 , Sep 11, 2000
        • 0 Attachment
          Johannes Zellner wrote:
          >
          [...]
          > I've put some /quick/ thoughts at
          >
          > http://vim.sourceforge.net/scripts/script-guidelines.html
          > (This page is not yet linked anywhere!)
          >

          Not bad at all for the start!
          Yes, the doc is the issue, I'd like to see:
          - some systematic function header definition
          I think it is very convenient to see 'always the same' header that
          defines:
          function args, their defaults (if any)
          what regs are used (they should always be restored or maybe better
          even avoid using regs altogether)
          global variables read/created/reset
          dependence on envvars (arrrgh, that's mostly ugly IMHO but I think
          some scripts use those....arrrrgh!)
          perhaps the format of 'input' if used
          function return values
          pitfalls of using it (the function was perhaps meant only as part
          of this script and even if it looks like it could be taken out
          and used separately, the internals will blow up)
          etc...

          - it's nice to see some comments inside at critical places (I am not
          going to define them, though :-)!

          - and more...

          > If you want to be listed in the section `Authors' you've to make
          > suggestions / comments :-)

          Hey, what a responsibility when one tried to contribute :-),
          don't make it too hard!

          >
          > wouldn't this discussion be better located at vim-dev ?
          >

          Yes, I think so, but I replied to both, let's f-ups go only to
          vim-dev.

          ---Zdenek
        • Dr. Charles E. Campbell
          Hello! How about providing the guidelines as an example (see below)? Regards, C Campbell =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
          Message 4 of 8 , Sep 11, 2000
          • 0 Attachment
            Hello!

            How about providing the guidelines as an example (see below)?

            Regards,
            C Campbell

            =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
            " NameOfFile: A one or two-line terse explanation of purpose
            " Author: Firstname Lastname <optional@email>
            " Date: Date of Release
            " Version: Optional Version Number
            " Copyright: If any
            "
            " Global Variables: (if any)
            " abc: explanation
            " def: explanation
            "
            " Register Utilization: (if any, preferably not, should at least be restored)
            " temporary: x y z
            " permanent: a b c
            "
            " Environment Variables: (if any)
            " HOME :
            " EDITOR : should be vim, of course! :)
            "
            " Usage:
            " Whatever seems appropriate to explain package use
            " Is it friendly and use localmapchar for version 6.x?

            " ---------------------------------------------------------------------

            " Command Interface:
            :com ...
            :com ...

            " ---------------------------------------------------------------------

            " FunctionName:
            " Arguments:
            " string x : used for whatever
            " integer y : used for whatever
            " Used By: command :Abc :Def etc
            fu! FunctionName(...)
            <indent>code (keep lines less than or equal to 72 characters in length, please)
            <indent>if ...
            <indent><indent>
            <indent>endif
            <indent>while ...
            <indent><indent>code
            <indent>endwhile
            endfunction

            " ---------------------------------------------------------------------
            =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--

            --
            Charles E Campbell, Jr, PhD _ __ __
            Goddard Space Flight Center / /_/\_\_/ /
            cec@... /_/ \/_//_/
            PGP public key: http://www.erols.com/astronaut/pgp.html/
          • Thomas Köhler
            On Mon, Sep 11, 2000 at 11:18:45AM -0400, ... Neat idea. Now, somebody write something similar to javadoc, and we would have a cool documentation system... ...
            Message 5 of 8 , Sep 11, 2000
            • 0 Attachment
              On Mon, Sep 11, 2000 at 11:18:45AM -0400,
              Dr. Charles E. Campbell <cec@...> wrote:
              >
              > Hello!
              >
              > How about providing the guidelines as an example (see below)?

              Neat idea.
              Now, somebody write something similar to javadoc, and we would have a
              cool documentation system...

              > Regards,
              > C Campbell
              [example snipped]

              Ciao,
              Thomas

              --
              Thomas Köhler Email: jean-luc@... | LCARS - Linux
              <>< WWW: http://jeanluc-picard.de | for Computers
              IRC: jeanluc | on All Real
              PGP public key available from Homepage! | Starships
            • Johannes Zellner
              ... good. I ve put the stuff together and updated http://vim.sourceforge.net/scripts/script-guidelines.html I don t know if we really need to list
              Message 6 of 8 , Sep 11, 2000
              • 0 Attachment
                On Mon, Sep 11, 2000 at 11:18:45AM -0400, Dr. Charles E. Campbell wrote:

                > How about providing the guidelines as an example (see below)?

                good. I've put the stuff together and updated
                http://vim.sourceforge.net/scripts/script-guidelines.html

                I don't know if we really need to list registers/global-vars ...
                both in the header and the function comments. What do you think ?

                --
                Johannes
              • Thomas Köhler
                On Mon, Sep 11, 2000 at 07:20:57PM +0200, ... It gets better :-) ... I tend to disagree. Let s say you use a global variable to hold a configuration value for
                Message 7 of 8 , Sep 11, 2000
                • 0 Attachment
                  On Mon, Sep 11, 2000 at 07:20:57PM +0200,
                  Johannes Zellner <johannes@...> wrote:
                  > On Mon, Sep 11, 2000 at 11:18:45AM -0400, Dr. Charles E. Campbell
                  > wrote:
                  >
                  > > How about providing the guidelines as an example (see below)?
                  >
                  > good. I've put the stuff together and updated
                  > http://vim.sourceforge.net/scripts/script-guidelines.html

                  It gets better :-)

                  > I don't know if we really need to list registers/global-vars ...
                  > both in the header and the function comments. What do you think ?

                  I tend to disagree. Let's say you use a global variable to hold a
                  configuration value for your script, and there's a function that sets
                  this variable, then I'd really appreciate the header to contain a
                  comment "global variable 'g:foobar' is there for configuration value
                  foobar", and the function headers to have something like "this function
                  sets the global variable 'foobar'" - not another complete explanation of
                  what that global variable is good for, but a short statement that it is
                  being used.

                  Thinking of indention:
                  Would it make sense to add a note about how large shiftwidth and tabstop
                  should be and whether or not to use expandtab? I think of something like
                  this:
                  shiftwidth should be 4, tabstop should be 8. You should (not?) use
                  the expandtab option. If you prefer other values, please add a
                  modeline that sets these values.

                  > Johannes

                  Ciao,
                  Thomas

                  --
                  Thomas Köhler Email: jean-luc@... | LCARS - Linux
                  <>< WWW: http://jeanluc-picard.de | for Computers
                  IRC: jeanluc | on All Real
                  PGP public key available from Homepage! | Starships
                • Sylvain VIART
                  Hi, ... Yes, it depends on what we are speaking about... If we speak about Vim user s repository, the good location is vim@vim.org (for me). If we speak about
                  Message 8 of 8 , Sep 12, 2000
                  • 0 Attachment
                    Hi,

                    Chris Niekel wrote:
                    >
                    > On Mon, Sep 11, 2000 at 04:17:45PM +0200, Johannes Zellner wrote:
                    > > wouldn't this discussion be better located at vim-dev ?
                    >
                    > I wouldn't think so. vim-dev is about developing vim, while this list
                    > is about using it. A collection of scripts is mostly for users, and
                    > maybe many users have ideas about how such a collection would be most
                    > valuable.
                    >
                    Yes, it depends on what we are speaking about...

                    If we speak about Vim user's repository, the good location is
                    vim@... (for me). If we speak about writing some guidelines,
                    vim-dev is a good location for speaking about it.

                    I think guideline are not completely related with repository...
                    And really, those suggested in vim-dev earlier... They seem very
                    heavy. Even if I understand well the goal of such header...

                    http://vim.sourceforge.net/scripts/script-guidelines.html

                    For the repository, headers of interest are the first until Usage
                    included.

                    Sylvain.
                    --
                    - Sylvain VIART - Informaticien - Analyste programmeur -
                    Montréal
                  Your message has been successfully submitted and would be delivered to recipients shortly.