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

CVS is alive (and up to date)

Expand Messages
  • Johannes Zellner
    Hello all, vim s CVS repository was moved to sourceforge where we hope that it will be served reliable. You can find all necessary information at
    Message 1 of 16 , Jul 30, 2000
      Hello all,

      vim's CVS repository was moved to sourceforge where we hope that it
      will be served reliable. You can find all necessary information
      at
      http://sourceforge.net/projects/vim/
      http://sourceforge.net/cvs/?group_id=8
      and the pages which are linked there. Note, that we don't use any
      of the services provided there except the cvs repository and it's
      html representation (cvsweb).

      Stefan `Sec` Zehl has already made cvs.vim.org pointing to
      the new site (cvs.vim.sourceforge.net). So you can just do a
      cvs -d :pserver:anonymous@...:/cvsroot/vim login
      cvs -d :pserver:anonymous@...:/cvsroot/vim co vim
      The CVS repository contains already vim-6.0d (in the MAIN trunk).
      I added also a branch rooted at vim-5-7-002 in case of eventual
      bug fixes for this (stable) version.

      (The repository address on sourceforge's cvs page is /wrong/,
      for some reason a `http..' got into the cvs addresses. I'll
      ask the people at sourceforge for correcting this.)

      I want to thank Wichert Akkerman here for hosting cvs.vim.org for
      more than half a year (Dec 1999 - July 2000)!


      There are still a few things to do and discuss now:

      1) decide if we want to use any of the service tools provided
      by sourceforge.
      2) decide if we create new modules (besides vim) where useful
      scripts (such as Benji's famous matchit.vim) would be collected
      and could be accessed by everybody by anonymous cvs. There are
      actually two possibilities for this: Either creating separate
      modules at vim.sourcefoge.net or creating a separate site.
      The latter method has several advantages in my opinion, but
      that's only my personal view.
      3) decide /what/ should actually go into the CVS. Currently
      everything is inside, so you can just checkout and compile.
      For example ctags has it's own repository at sf and could
      be removed from the repository. This does /not/ mean to remove
      it from the releases, it just means that ctags is developed
      elsewhere (by Darren).
      4) get at least one more person who cares about the site. This
      makes it easier for me and is more reliable anyway.


      Last but not least here comes something for your pleasure.
      This is a snippet from a mail which I got during setup of
      the cvs account at sourceforge.

      ----- Forwarded message from Tim Perdue <tperdue@...> -----
      From: Tim Perdue <tperdue@...>
      Subject: [Fwd: vim cvs repository (fwd)]
      To: johannes@..., "staff@..." <staff@...>
      Date: Thu, 27 Jul 2000 09:30:41 -0700

      [...]
      It's well worth noting that the *entirety* of SourceForge was written
      using vim and its nifty PHP syntax highlighting. I think the entire
      SF.net tech staff uses vim and we're all excited to have you aboard!

      Tim
      [...]
      ----- End of Forwarded message -----

      happy Vimming :-)

      --
      Johannes
    • Wichert Akkerman
      ... I wouldn t mind functioning as a backup for you, I should have bits of extra now that I won t have to maintain the previous cvs.vim.org anymore :) Wichert.
      Message 2 of 16 , Jul 30, 2000
        Previously Johannes Zellner wrote:
        > 4) get at least one more person who cares about the site. This
        > makes it easier for me and is more reliable anyway.

        I wouldn't mind functioning as a backup for you, I should have bits
        of extra now that I won't have to maintain the previous cvs.vim.org
        anymore :)

        Wichert.

        --
        _________________________________________________________________
        / Generally uninteresting signature - ignore at your convenience \
        | wichert@... http://www.liacs.nl/~wichert/ |
        | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
      • David Odin
        Hi, I ve checked the latest cvs version of vim. The build ended with this gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/lib/glib/include
        Message 3 of 16 , Jul 30, 2000
          Hi,

          I've checked the latest cvs version of vim. The build ended with this

          gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/X11R6/include -g
          -O2 -Wall -I/usr/X11R6/include -Dbool=char -DHAS_BOOL -I/usr/local/include -I/usr/lib/perl5/5.00502/i586-linux/CORE -I/usr/local/include/python1.5 -D_THREAD_SAFE -o objects/gui_gtk_x11.o gui_gtk_x11.c
          gui_gtk_x11.c: In function `gui_mch_init_font':
          gui_gtk_x11.c:2392: warning: implicit declaration of function `gui_mch_free_fontset'
          gui_gtk_x11.c: At top level:
          gui_gtk_x11.c:2524: warning: type mismatch with previous external decl
          gui_gtk_x11.c:2392: warning: previous external decl of `gui_mch_free_fontset'
          gui_gtk_x11.c:2524: warning: type mismatch with previous implicit declaration
          gui_gtk_x11.c:2392: warning: previous implicit declaration of `gui_mch_free_fontset'
          gui_gtk_x11.c:2524: warning: `gui_mch_free_fontset' was previously implicitly declared to return `int'
          gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/X11R6/include -g
          -O2 -Wall -I/usr/X11R6/include -Dbool=char -DHAS_BOOL -I/usr/local/include -I/usr/lib/perl5/5.00502/i586-linux/CORE -I/usr/local/include/python1.5 -D_THREAD_SAFE -o objects/pty.o pty.c
          pty.c: In function `OpenPTY':
          pty.c:371: `PtyProto' undeclared (first use this function)
          pty.c:371: (Each undeclared identifier is reported only once
          pty.c:371: for each function it appears in.)
          pty.c:372: `TtyProto' undeclared (first use this function)
          make[1]: *** [objects/pty.o] Error 1
          make[1]: Leaving directory `/export2/Vim/vim/src'
          make: *** [first] Error 2

          My configure command was this one:
          ./configure --with-features=huge --enable-perlinterp --enable-pythoninterp --enable-tclinterp --enable-cscope --enable-multibyte --enable-hangulinput --enable-fontset --with-x --enable-gui=gtk --without-gnome

          Regards,

          DindinX


          --
          David.Odin@...
          Author of the French Book: Programmation Linux avec GTK+

          Thinking you know something is a sure way to blind yourself.
          -- Frank Herbert, "Chapterhouse: Dune"
        • Johannes Zellner
          On Mon, Jul 31, 2000 at 02:46:58AM +0200, David Odin wrote: [...] ... [...] having a quick look at the source: maybe SVR4 is undefined so that src/pty.c:121 is
          Message 4 of 16 , Jul 30, 2000
            On Mon, Jul 31, 2000 at 02:46:58AM +0200, David Odin wrote:

            [...]
            > pty.c:371: `PtyProto' undeclared (first use this function)
            > pty.c:371: (Each undeclared identifier is reported only once
            > pty.c:371: for each function it appears in.)
            > pty.c:372: `TtyProto' undeclared (first use this function)
            > make[1]: *** [objects/pty.o] Error 1
            > make[1]: Leaving directory `/export2/Vim/vim/src'
            > make: *** [first] Error 2
            [...]

            having a quick look at the source:
            maybe SVR4 is undefined so that src/pty.c:121 is false ?
            The config results can be found in src/auto/config.h.
            It works here with your config options (debian Linux potato).
            What system are you on ?

            --
            Johannes
          • Bram Moolenaar
            ... These warnings are my fault, I generated the prototypes without FEAT_XFONTSET. Add this patch to fix it: ... *************** ... void gui_mch_set_font
            Message 5 of 16 , Jul 31, 2000
              David Odin wrote:

              > I've checked the latest cvs version of vim. The build ended with this
              >
              > gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/X11R6/include -g
              > -O2 -Wall -I/usr/X11R6/include -Dbool=char -DHAS_BOOL -I/usr/local/include -I/usr/lib/perl5/5.00502/i586-linux/CORE -I/usr/local/include/python1.5 -D_THREAD_SAFE -o objects/gui_gtk_x11.o gui_gtk_x11.c
              > gui_gtk_x11.c: In function `gui_mch_init_font':
              > gui_gtk_x11.c:2392: warning: implicit declaration of function `gui_mch_free_fontset'
              > gui_gtk_x11.c: At top level:
              > gui_gtk_x11.c:2524: warning: type mismatch with previous external decl
              > gui_gtk_x11.c:2392: warning: previous external decl of `gui_mch_free_fontset'
              > gui_gtk_x11.c:2524: warning: type mismatch with previous implicit declaration
              > gui_gtk_x11.c:2392: warning: previous implicit declaration of `gui_mch_free_fontset'
              > gui_gtk_x11.c:2524: warning: `gui_mch_free_fontset' was previously implicitly declared to return `int'

              These warnings are my fault, I generated the prototypes without FEAT_XFONTSET.
              Add this patch to fix it:

              *** ../dist/vim60d/src/proto/gui_gtk_x11.pro Sun Jul 30 21:23:23 2000
              --- proto/gui_gtk_x11.pro Sun Jul 30 22:48:06 2000
              ***************
              *** 21,26 ****
              --- 21,27 ----
              void gui_mch_set_font __ARGS((GuiFont font));
              void gui_mch_set_fontset __ARGS((GuiFontset fontset));
              void gui_mch_free_font __ARGS((GuiFont font));
              + void gui_mch_free_fontset __ARGS((GuiFontset fontset));
              guicolor_t gui_mch_get_color __ARGS((char_u *name));
              void gui_mch_set_fg_color __ARGS((guicolor_t color));
              void gui_mch_set_bg_color __ARGS((guicolor_t color));

              > gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/X11R6/include -g
              > -O2 -Wall -I/usr/X11R6/include -Dbool=char -DHAS_BOOL -I/usr/local/include -I/usr/lib/perl5/5.00502/i586-linux/CORE -I/usr/local/include/python1.5 -D_THREAD_SAFE -o objects/pty.o pty.c
              > pty.c: In function `OpenPTY':
              > pty.c:371: `PtyProto' undeclared (first use this function)
              > pty.c:371: (Each undeclared identifier is reported only once
              > pty.c:371: for each function it appears in.)
              > pty.c:372: `TtyProto' undeclared (first use this function)
              > make[1]: *** [objects/pty.o] Error 1
              > make[1]: Leaving directory `/export2/Vim/vim/src'
              > make: *** [first] Error 2

              Try this patch;

              *** pty.c~ Sun Jul 23 23:22:20 2000
              --- pty.c Mon Jul 31 11:17:43 2000
              ***************
              *** 118,138 ****
              # undef HAVE_SVR4_PTYS
              #endif

              - #if !(defined(sequent) || defined(_SEQUENT_) || defined(SVR4))
              - # ifdef hpux
              - static char PtyProto[] = "/dev/ptym/ptyXY";
              - static char TtyProto[] = "/dev/pty/ttyXY";
              - # else
              - # ifdef __BEOS__
              - static char PtyProto[] = "/dev/pt/XY";
              - static char TtyProto[] = "/dev/tt/XY";
              - # else
              - static char PtyProto[] = "/dev/ptyXY";
              - static char TtyProto[] = "/dev/ttyXY";
              - # endif
              - # endif
              - #endif
              -
              static void initmaster __ARGS((int));

              /*
              --- 118,123 ----
              ***************
              *** 357,362 ****
              --- 342,361 ----
              #endif

              #ifndef PTY_DONE
              +
              + # ifdef hpux
              + static char PtyProto[] = "/dev/ptym/ptyXY";
              + static char TtyProto[] = "/dev/pty/ttyXY";
              + # else
              + # ifdef __BEOS__
              + static char PtyProto[] = "/dev/pt/XY";
              + static char TtyProto[] = "/dev/tt/XY";
              + # else
              + static char PtyProto[] = "/dev/ptyXY";
              + static char TtyProto[] = "/dev/ttyXY";
              + # endif
              + # endif
              +
              int
              OpenPTY(ttyn)
              char **ttyn;

              --
              I started out with nothing, and I still have most of it.

              /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
              \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
            • Bram Moolenaar
              ... Indeed, the goal is to have a reliable service. Thanks for setting it up! ... I would first wait a little while to see if it all works well. Then
              Message 6 of 16 , Jul 31, 2000
                Johannes Zellner wrote:

                > vim's CVS repository was moved to sourceforge where we hope that it
                > will be served reliable.

                Indeed, the goal is to have a reliable service. Thanks for setting it up!

                > There are still a few things to do and discuss now:
                >
                > 1) decide if we want to use any of the service tools provided
                > by sourceforge.

                I would first wait a little while to see if it all works well. Then gradually
                expand the use of sourceforge, keeping in mind that it must keep on working
                well.

                Note that the link to the ftp site doesn't work, there is a "http://" in the
                link.

                > 2) decide if we create new modules (besides vim) where useful
                > scripts (such as Benji's famous matchit.vim) would be collected
                > and could be accessed by everybody by anonymous cvs. There are
                > actually two possibilities for this: Either creating separate
                > modules at vim.sourcefoge.net or creating a separate site.
                > The latter method has several advantages in my opinion, but
                > that's only my personal view.

                I didn't manage to add the "plugin" directory to Vim 6.0d, hopefully it will
                be in 6.0e. That will make it real easy to get a Vim script file and drop it
                in your plugin directory.

                I would like to find someone who can take care of the scripts collection. Not
                just dump them all in a directory, but sort out the good ones from the bad
                ones, make it possible to find the script you are looking for, ask
                contributors to write documentation, etc.

                Making the scripts available by CVS is good, but I'm sure we also need access
                by http and/or ftp.

                > 3) decide /what/ should actually go into the CVS. Currently
                > everything is inside, so you can just checkout and compile.
                > For example ctags has it's own repository at sf and could
                > be removed from the repository. This does /not/ mean to remove
                > it from the releases, it just means that ctags is developed
                > elsewhere (by Darren).

                Well, if you type "make" it expects ctags to be there. Is there a good reason
                to do this different from before?

                > ----- Forwarded message from Tim Perdue <tperdue@...> -----
                > From: Tim Perdue <tperdue@...>
                > Subject: [Fwd: vim cvs repository (fwd)]
                > To: johannes@..., "staff@..." <staff@...>
                > Date: Thu, 27 Jul 2000 09:30:41 -0700
                >
                > [...]
                > It's well worth noting that the *entirety* of SourceForge was written
                > using vim and its nifty PHP syntax highlighting. I think the entire
                > SF.net tech staff uses vim and we're all excited to have you aboard!
                >
                > Tim
                > [...]
                > ----- End of Forwarded message -----

                That's a good one for the quotes file! :-)

                --
                hundred-and-one symptoms of being an internet addict:
                39. You move into a new house and decide to Netscape before you landscape.

                /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
              • Johannes Zellner
                ... I ve added you with admin priviledges. -- Johannes
                Message 7 of 16 , Jul 31, 2000
                  On Mon, Jul 31, 2000 at 02:36:14AM +0200, Wichert Akkerman wrote:
                  > Previously Johannes Zellner wrote:
                  > > 4) get at least one more person who cares about the site. This
                  > > makes it easier for me and is more reliable anyway.
                  >
                  > I wouldn't mind functioning as a backup for you, I should have bits
                  > of extra now that I won't have to maintain the previous cvs.vim.org
                  > anymore :)

                  I've added you with admin priviledges.

                  --
                  Johannes
                • Johannes Zellner
                  On Mon, Jul 31, 2000 at 11:43:25AM +0200, Bram Moolenaar wrote: [...] ... Yes sure that would be nice. I think we should decide if another `project should be
                  Message 8 of 16 , Jul 31, 2000
                    On Mon, Jul 31, 2000 at 11:43:25AM +0200, Bram Moolenaar wrote:

                    [...]
                    > I didn't manage to add the "plugin" directory to Vim 6.0d, hopefully it will
                    > be in 6.0e. That will make it real easy to get a Vim script file and drop it
                    > in your plugin directory.
                    >
                    > I would like to find someone who can take care of the scripts collection. Not
                    > just dump them all in a directory, but sort out the good ones from the bad
                    > ones, make it possible to find the script you are looking for, ask
                    > contributors to write documentation, etc.
                    Yes sure that would be nice. I think we should decide if another
                    `project' should be created for this, or if this stuff will go
                    in another module on the same site.

                    Many projects use different projects for contributed stuff
                    (just go to SF and search for gimp or python for example).
                    The advantage of having a different project for the contributed
                    stuff is that there's better control of who has write access to
                    which modules. The disadvantage is that it might be more confusing
                    and difficult to find if it is spread over several projects.

                    > Making the scripts available by CVS is good, but I'm sure we also need access
                    > by http and/or ftp.
                    yes it is just as before: the CVS is thought to be /supplementary/ to
                    the tar files as they can be downloaded from http and ftp sites.


                    > > 3) decide /what/ should actually go into the CVS. Currently
                    > > everything is inside, so you can just checkout and compile.
                    > > For example ctags has it's own repository at sf and could
                    > > be removed from the repository. This does /not/ mean to remove
                    > > it from the releases, it just means that ctags is developed
                    > > elsewhere (by Darren).
                    >
                    > Well, if you type "make" it expects ctags to be there. Is there a good reason
                    > to do this different from before?
                    actually I don't really care. I just recognized that ctags has it's own
                    SF repository. If you like it to be included it will be included.

                    --
                    Johannes
                  • Thomas Köhler
                    On Mon, Jul 31, 2000 at 02:10:53PM +0200, ... [...] ... I d vote for ctags stay in the repository - so I don t need to update two pieces of software when a
                    Message 9 of 16 , Jul 31, 2000
                      On Mon, Jul 31, 2000 at 02:10:53PM +0200,
                      Johannes Zellner <johannes@...> wrote:
                      >
                      > On Mon, Jul 31, 2000 at 11:43:25AM +0200, Bram Moolenaar wrote:
                      [...]
                      > > > 3) decide /what/ should actually go into the CVS. Currently
                      > > > everything is inside, so you can just checkout and compile.
                      > > > For example ctags has it's own repository at sf and could
                      > > > be removed from the repository. This does /not/ mean to remove
                      > > > it from the releases, it just means that ctags is developed
                      > > > elsewhere (by Darren).
                      > > Well, if you type "make" it expects ctags to be there. Is there a good reason
                      > > to do this different from before?
                      > actually I don't really care. I just recognized that ctags has it's own
                      > SF repository. If you like it to be included it will be included.

                      I'd vote for ctags stay in the repository - so I don't need to update
                      two pieces of software when a single "cvs -z3 update" would do :-)
                      But that's only my $0.02 :-)

                      CU,
                      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
                      [...] ... [...] yes that s indeed the advantage. -- Johannes
                      Message 10 of 16 , Jul 31, 2000
                        [...]
                        > I'd vote for ctags stay in the repository - so I don't need to update
                        > two pieces of software when a single "cvs -z3 update" would do :-)
                        [...]
                        yes that's indeed the advantage.

                        --
                        Johannes
                      • David Odin
                        ... Yes. warning is gone away. ... Great. That does the job. Thanks. For info I m using a Debian (Hamm) 2.0 THanks a lot. DindinX -- David.Odin@bigfoot.com
                        Message 11 of 16 , Jul 31, 2000
                          On Mon, Jul 31, 2000 at 11:43:25AM +0200, Bram Moolenaar wrote:
                          >
                          > David Odin wrote:
                          >
                          > > I've checked the latest cvs version of vim. The build ended with this
                          > >
                          > > gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/X11R6/include -g
                          > > -O2 -Wall -I/usr/X11R6/include -Dbool=char -DHAS_BOOL -I/usr/local/include -I/usr/lib/perl5/5.00502/i586-linux/CORE -I/usr/local/include/python1.5 -D_THREAD_SAFE -o objects/gui_gtk_x11.o gui_gtk_x11.c
                          > > gui_gtk_x11.c: In function `gui_mch_init_font':
                          > > gui_gtk_x11.c:2392: warning: implicit declaration of function `gui_mch_free_fontset'
                          > > gui_gtk_x11.c: At top level:
                          > > gui_gtk_x11.c:2524: warning: type mismatch with previous external decl
                          > > gui_gtk_x11.c:2392: warning: previous external decl of `gui_mch_free_fontset'
                          > > gui_gtk_x11.c:2524: warning: type mismatch with previous implicit declaration
                          > > gui_gtk_x11.c:2392: warning: previous implicit declaration of `gui_mch_free_fontset'
                          > > gui_gtk_x11.c:2524: warning: `gui_mch_free_fontset' was previously implicitly declared to return `int'
                          >
                          > These warnings are my fault, I generated the prototypes without FEAT_XFONTSET.
                          > Add this patch to fix it:
                          >
                          > *** ../dist/vim60d/src/proto/gui_gtk_x11.pro Sun Jul 30 21:23:23 2000
                          > --- proto/gui_gtk_x11.pro Sun Jul 30 22:48:06 2000
                          > ***************
                          > *** 21,26 ****
                          > --- 21,27 ----
                          > void gui_mch_set_font __ARGS((GuiFont font));
                          > void gui_mch_set_fontset __ARGS((GuiFontset fontset));
                          > void gui_mch_free_font __ARGS((GuiFont font));
                          > + void gui_mch_free_fontset __ARGS((GuiFontset fontset));
                          > guicolor_t gui_mch_get_color __ARGS((char_u *name));
                          > void gui_mch_set_fg_color __ARGS((guicolor_t color));
                          > void gui_mch_set_bg_color __ARGS((guicolor_t color));
                          >
                          Yes. warning is gone away.

                          > > gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/X11R6/include -g
                          > > -O2 -Wall -I/usr/X11R6/include -Dbool=char -DHAS_BOOL -I/usr/local/include -I/usr/lib/perl5/5.00502/i586-linux/CORE -I/usr/local/include/python1.5 -D_THREAD_SAFE -o objects/pty.o pty.c
                          > > pty.c: In function `OpenPTY':
                          > > pty.c:371: `PtyProto' undeclared (first use this function)
                          > > pty.c:371: (Each undeclared identifier is reported only once
                          > > pty.c:371: for each function it appears in.)
                          > > pty.c:372: `TtyProto' undeclared (first use this function)
                          > > make[1]: *** [objects/pty.o] Error 1
                          > > make[1]: Leaving directory `/export2/Vim/vim/src'
                          > > make: *** [first] Error 2
                          >
                          > Try this patch;
                          >
                          > *** pty.c~ Sun Jul 23 23:22:20 2000
                          > --- pty.c Mon Jul 31 11:17:43 2000
                          > ***************
                          > *** 118,138 ****
                          > # undef HAVE_SVR4_PTYS
                          > #endif
                          >
                          > - #if !(defined(sequent) || defined(_SEQUENT_) || defined(SVR4))
                          > - # ifdef hpux
                          > - static char PtyProto[] = "/dev/ptym/ptyXY";
                          > - static char TtyProto[] = "/dev/pty/ttyXY";
                          > - # else
                          > - # ifdef __BEOS__
                          > - static char PtyProto[] = "/dev/pt/XY";
                          > - static char TtyProto[] = "/dev/tt/XY";
                          > - # else
                          > - static char PtyProto[] = "/dev/ptyXY";
                          > - static char TtyProto[] = "/dev/ttyXY";
                          > - # endif
                          > - # endif
                          > - #endif
                          > -
                          > static void initmaster __ARGS((int));
                          >
                          > /*
                          > --- 118,123 ----
                          > ***************
                          > *** 357,362 ****
                          > --- 342,361 ----
                          > #endif
                          >
                          > #ifndef PTY_DONE
                          > +
                          > + # ifdef hpux
                          > + static char PtyProto[] = "/dev/ptym/ptyXY";
                          > + static char TtyProto[] = "/dev/pty/ttyXY";
                          > + # else
                          > + # ifdef __BEOS__
                          > + static char PtyProto[] = "/dev/pt/XY";
                          > + static char TtyProto[] = "/dev/tt/XY";
                          > + # else
                          > + static char PtyProto[] = "/dev/ptyXY";
                          > + static char TtyProto[] = "/dev/ttyXY";
                          > + # endif
                          > + # endif
                          > +
                          > int
                          > OpenPTY(ttyn)
                          > char **ttyn;
                          >

                          Great. That does the job. Thanks.
                          For info I'm using a Debian (Hamm) 2.0

                          THanks a lot.

                          DindinX

                          --
                          David.Odin@...
                          Author of the French Book: Programmation Linux avec GTK+

                          You're always thinking you're gonna be the one that makes 'em act different.
                          -- Woody Allen, "Manhattan"
                        • Bram Moolenaar
                          Johannes Zellner wrote: I ll leave it to you to organize the CVS site in a good way. ... Except that there currently are no archives for scripts. So this will
                          Message 12 of 16 , Jul 31, 2000
                            Johannes Zellner wrote:

                            I'll leave it to you to organize the CVS site in a good way.

                            > > Making the scripts available by CVS is good, but I'm sure we also need
                            > > access by http and/or ftp.
                            > yes it is just as before: the CVS is thought to be /supplementary/ to
                            > the tar files as they can be downloaded from http and ftp sites.

                            Except that there currently are no archives for scripts. So this will be new.

                            It would be nice to be able to browse the internet (do some search or follow a
                            few links) and do a "save as" to drop the script in your plugin directory.
                            Thus the scripts would need to be available by http, and each separately.

                            Perhaps an archive with all the scripts can also be made (generated
                            automatically?). The maintainer would have to setup something to save work
                            and avoid mistakes.

                            It would be great if each syntax maintainer can upload his script file to
                            sourceforge and it's automatically used for the single-file download, CVS and
                            added to the all-the-scripts archive. Would that be possible on sourceforge?

                            > > > 3) decide /what/ should actually go into the CVS. Currently
                            > > > everything is inside, so you can just checkout and compile.
                            > > > For example ctags has it's own repository at sf and could
                            > > > be removed from the repository. This does /not/ mean to remove
                            > > > it from the releases, it just means that ctags is developed
                            > > > elsewhere (by Darren).
                            > >
                            > > Well, if you type "make" it expects ctags to be there. Is there a good
                            > > reason to do this different from before?
                            > actually I don't really care. I just recognized that ctags has it's own
                            > SF repository. If you like it to be included it will be included.

                            With things like this I prefer to keep it as it is, unless there is a good
                            reason to change it. I'm sure Darren likes ctags to be included with Vim.
                            I like promoting it (although it has grown quite a bit now).

                            --
                            hundred-and-one symptoms of being an internet addict:
                            52. You ask a plumber how much it would cost to replace the chair in front of
                            your computer with a toilet.

                            /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                            \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                          • Johannes Zellner
                            ... something like a vim-pkg (vim script package manager) using a html form. Not bad. With features like `install `uninstall `upgrade . :-) ... no problem.
                            Message 13 of 16 , Jul 31, 2000
                              On Mon, Jul 31, 2000 at 10:46:09PM +0200, Bram Moolenaar wrote:
                              >
                              > Johannes Zellner wrote:
                              >
                              > I'll leave it to you to organize the CVS site in a good way.
                              >
                              > > > Making the scripts available by CVS is good, but I'm sure we also need
                              > > > access by http and/or ftp.
                              > > yes it is just as before: the CVS is thought to be /supplementary/ to
                              > > the tar files as they can be downloaded from http and ftp sites.
                              >
                              > Except that there currently are no archives for scripts. So this will be new.
                              >
                              > It would be nice to be able to browse the internet (do some search or follow a
                              > few links) and do a "save as" to drop the script in your plugin directory.
                              > Thus the scripts would need to be available by http, and each separately.

                              something like a vim-pkg (vim script package manager) using a html form.
                              Not bad. With features like `install' `uninstall' `upgrade'. :-)
                              ... well I guess it should be kept simple.

                              > Perhaps an archive with all the scripts can also be made (generated
                              > automatically?). The maintainer would have to setup something to save work
                              > and avoid mistakes.
                              no problem. Something like a `nightly tar'. Cron is my friend. (or at
                              least one of my friends :)

                              > It would be great if each syntax maintainer can upload his script file to
                              > sourceforge and it's automatically used for the single-file download, CVS and
                              > added to the all-the-scripts archive. Would that be possible on sourceforge?
                              The problem arises when using the same project (vim) for scripts and vim
                              itself as I've pointed out earlier. In principle this is the idea behind
                              CVS but it would mean giving write access to the repository for about
                              something like (currently) 200 syntax maintainers! There's no selective
                              write access to CVS AFAIK.
                              Alternatively and maybe better is a php (or simple good old cgi) file upload.
                              The syntax and script maintainers would upload the files which would
                              then processed by either a nifty script or the maintainer of the
                              archive. I think this is feasable. This could also be done for the
                              language `po' files.

                              Well I'm aware that there's some work to do ...

                              --
                              Johannes
                            • Wichert Akkerman
                              ... Next we ll need to add dependencies and so as well.. might as well come up with a standard way of making a vim script and create scripts to automatically
                              Message 14 of 16 , Jul 31, 2000
                                Previously Johannes Zellner wrote:
                                > something like a vim-pkg (vim script package manager) using a html form.
                                > Not bad. With features like `install' `uninstall' `upgrade'. :-)
                                > ... well I guess it should be kept simple.

                                Next we'll need to add dependencies and so as well.. might as well
                                come up with a standard way of making a vim script and create scripts
                                to automatically create .deb and .rpms from that.

                                > no problem. Something like a `nightly tar'. Cron is my friend. (or at
                                > least one of my friends :)

                                Built-in feature from sourceforge already I think.

                                > The problem arises when using the same project (vim) for scripts and vim
                                > itself as I've pointed out earlier. In principle this is the idea behind
                                > CVS but it would mean giving write access to the repository for about
                                > something like (currently) 200 syntax maintainers! There's no selective
                                > write access to CVS AFAIK.

                                There is indeed not

                                > Alternatively and maybe better is a php (or simple good old cgi) file upload.
                                > The syntax and script maintainers would upload the files which would
                                > then processed by either a nifty script or the maintainer of the
                                > archive. I think this is feasable. This could also be done for the
                                > language `po' files.

                                That would be a better option I think, and should be doable.

                                Wichert.

                                --
                                _________________________________________________________________
                                / Generally uninteresting signature - ignore at your convenience \
                                | wichert@... http://www.liacs.nl/~wichert/ |
                                | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
                              • Bram Moolenaar
                                ... I m sure this requires some work now. But when it is setup right, not only will it make many Vim users happy, it will also save a lot of time on the
                                Message 15 of 16 , Aug 1, 2000
                                  Johannes Zellner wrote:

                                  > The problem arises when using the same project (vim) for scripts and vim
                                  > itself as I've pointed out earlier. In principle this is the idea behind
                                  > CVS but it would mean giving write access to the repository for about
                                  > something like (currently) 200 syntax maintainers! There's no selective
                                  > write access to CVS AFAIK.
                                  > Alternatively and maybe better is a php (or simple good old cgi) file upload.
                                  > The syntax and script maintainers would upload the files which would
                                  > then processed by either a nifty script or the maintainer of the
                                  > archive. I think this is feasable. This could also be done for the
                                  > language `po' files.
                                  >
                                  > Well I'm aware that there's some work to do ...

                                  I'm sure this requires some work now. But when it is setup right, not only
                                  will it make many Vim users happy, it will also save a lot of time on the
                                  manual work. Go for it!

                                  The best would be that each maintainer can only access the files he maintains.
                                  Would it be possible to setup a group for each maintainer, and then copy the
                                  files over to the "real" group with some script? I would hate it when people
                                  start fixing problems in somebody else's stuff... "But I was only fixing this
                                  problem" "You introduced two new problems!" "Oh, sorry, didn't see that"
                                  "Keep your hands off my files, moron!" "Oh, shutup, or I'll...". Isn't this
                                  how wars start? :-)

                                  --
                                  hundred-and-one symptoms of being an internet addict:
                                  58. You turn on your computer and turn off your wife.

                                  /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                                  \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                                • Wichert Akkerman
                                  ... Probably, yes. I m going to see if I can come up with some php magic next week. Wichert. --
                                  Message 16 of 16 , Aug 2, 2000
                                    Previously Bram Moolenaar wrote:
                                    > Would it be possible to [....]

                                    Probably, yes. I'm going to see if I can come up with some php magic
                                    next week.

                                    Wichert.

                                    --
                                    _________________________________________________________________
                                    / Generally uninteresting signature - ignore at your convenience \
                                    | wichert@... http://www.liacs.nl/~wichert/ |
                                    | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
                                  Your message has been successfully submitted and would be delivered to recipients shortly.