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

Patch 7.4.073

Expand Messages
  • Bram Moolenaar
    Patch 7.4.073 Problem: Setting undolevels for one buffer changes undo in another. Solution: Make undolevels a global-local option. (Christian Brabandt)
    Message 1 of 11 , Nov 5, 2013
    • 0 Attachment
      Patch 7.4.073
      Problem: Setting undolevels for one buffer changes undo in another.
      Solution: Make 'undolevels' a global-local option. (Christian Brabandt)
      Files: runtime/doc/options.txt, src/buffer.c, src/option.c, src/option.h
      src/structs.h, src/undo.c


      *** ../vim-7.4.072/runtime/doc/options.txt 2013-08-10 13:24:57.000000000 +0200
      --- runtime/doc/options.txt 2013-11-06 04:18:43.000000000 +0100
      ***************
      *** 7594,7600 ****
      *'undolevels'* *'ul'*
      'undolevels' 'ul' number (default 100, 1000 for Unix, VMS,
      Win32 and OS/2)
      ! global
      {not in Vi}
      Maximum number of changes that can be undone. Since undo information
      is kept in memory, higher numbers will cause more memory to be used
      --- 7594,7600 ----
      *'undolevels'* *'ul'*
      'undolevels' 'ul' number (default 100, 1000 for Unix, VMS,
      Win32 and OS/2)
      ! global or local to buffer |global-local|
      {not in Vi}
      Maximum number of changes that can be undone. Since undo information
      is kept in memory, higher numbers will cause more memory to be used
      ***************
      *** 7605,7612 ****
      < But you can also get Vi compatibility by including the 'u' flag in
      'cpoptions', and still be able to use CTRL-R to repeat undo.
      Also see |undo-two-ways|.
      ! Set to a negative number for no undo at all: >
      ! set ul=-1
      < This helps when you run out of memory for a single change.
      Also see |clear-undo|.

      --- 7605,7613 ----
      < But you can also get Vi compatibility by including the 'u' flag in
      'cpoptions', and still be able to use CTRL-R to repeat undo.
      Also see |undo-two-ways|.
      ! Set to -1 for no undo at all. You might want to do this only for the
      ! current buffer: >
      ! setlocal ul=-1
      < This helps when you run out of memory for a single change.
      Also see |clear-undo|.

      *** ../vim-7.4.072/src/buffer.c 2013-11-05 17:40:47.000000000 +0100
      --- src/buffer.c 2013-11-06 04:25:27.000000000 +0100
      ***************
      *** 1949,1954 ****
      --- 1949,1955 ----
      clear_string_option(&buf->b_p_qe);
      #endif
      buf->b_p_ar = -1;
      + buf->b_p_ul = NO_LOCAL_UNDOLEVEL;
      }

      /*
      *** ../vim-7.4.072/src/option.c 2013-11-05 07:12:59.000000000 +0100
      --- src/option.c 2013-11-06 04:34:23.000000000 +0100
      ***************
      *** 234,239 ****
      --- 234,240 ----
      #ifdef FEAT_STL_OPT
      # define PV_STL OPT_BOTH(OPT_WIN(WV_STL))
      #endif
      + #define PV_UL OPT_BOTH(OPT_BUF(BV_UL))
      #ifdef FEAT_WINDOWS
      # define PV_WFH OPT_WIN(WV_WFH)
      #endif
      ***************
      *** 2683,2689 ****
      #endif
      {(char_u *)FALSE, (char_u *)0L} SCRIPTID_INIT},
      {"undolevels", "ul", P_NUM|P_VI_DEF,
      ! (char_u *)&p_ul, PV_NONE,
      {
      #if defined(UNIX) || defined(WIN3264) || defined(OS2) || defined(VMS)
      (char_u *)1000L,
      --- 2684,2690 ----
      #endif
      {(char_u *)FALSE, (char_u *)0L} SCRIPTID_INIT},
      {"undolevels", "ul", P_NUM|P_VI_DEF,
      ! (char_u *)&p_ul, PV_UL,
      {
      #if defined(UNIX) || defined(WIN3264) || defined(OS2) || defined(VMS)
      (char_u *)1000L,
      ***************
      *** 3313,3318 ****
      --- 3314,3320 ----

      curbuf->b_p_initialized = TRUE;
      curbuf->b_p_ar = -1; /* no local 'autoread' value */
      + curbuf->b_p_ul = NO_LOCAL_UNDOLEVEL;
      check_buf_options(curbuf);
      check_win_options(curwin);
      check_options();
      ***************
      *** 4512,4519 ****
      ((flags & P_VI_DEF) || cp_val)
      ? VI_DEFAULT : VIM_DEFAULT];
      else if (nextchar == '<')
      ! value = *(long *)get_varp_scope(&(options[opt_idx]),
      ! OPT_GLOBAL);
      else if (((long *)varp == &p_wc
      || (long *)varp == &p_wcm)
      && (*arg == '<'
      --- 4514,4529 ----
      ((flags & P_VI_DEF) || cp_val)
      ? VI_DEFAULT : VIM_DEFAULT];
      else if (nextchar == '<')
      ! {
      ! /* For 'undolevels' NO_LOCAL_UNDOLEVEL means to
      ! * use the global value. */
      ! if ((long *)varp == &curbuf->b_p_ul
      ! && opt_flags == OPT_LOCAL)
      ! value = NO_LOCAL_UNDOLEVEL;
      ! else
      ! value = *(long *)get_varp_scope(
      ! &(options[opt_idx]), OPT_GLOBAL);
      ! }
      else if (((long *)varp == &p_wc
      || (long *)varp == &p_wcm)
      && (*arg == '<'
      ***************
      *** 8487,8492 ****
      --- 8497,8509 ----
      u_sync(TRUE);
      p_ul = value;
      }
      + else if (pp == &curbuf->b_p_ul)
      + {
      + /* use the old value, otherwise u_sync() may not work properly */
      + curbuf->b_p_ul = old_value;
      + u_sync(TRUE);
      + curbuf->b_p_ul = value;
      + }

      #ifdef FEAT_LINEBREAK
      /* 'numberwidth' must be positive */
      ***************
      *** 9720,9726 ****
      /*
      * Unset local option value, similar to ":set opt<".
      */
      -
      void
      unset_global_local_option(name, from)
      char_u *name;
      --- 9737,9742 ----
      ***************
      *** 9793,9798 ****
      --- 9809,9817 ----
      clear_string_option(&((win_T *)from)->w_p_stl);
      break;
      #endif
      + case PV_UL:
      + buf->b_p_ul = NO_LOCAL_UNDOLEVEL;
      + break;
      }
      }

      ***************
      *** 9841,9846 ****
      --- 9860,9866 ----
      #ifdef FEAT_STL_OPT
      case PV_STL: return (char_u *)&(curwin->w_p_stl);
      #endif
      + case PV_UL: return (char_u *)&(curbuf->b_p_ul);
      }
      return NULL; /* "cannot happen" */
      }
      ***************
      *** 9905,9910 ****
      --- 9925,9932 ----
      case PV_STL: return *curwin->w_p_stl != NUL
      ? (char_u *)&(curwin->w_p_stl) : p->var;
      #endif
      + case PV_UL: return curbuf->b_p_ul != NO_LOCAL_UNDOLEVEL
      + ? (char_u *)&(curbuf->b_p_ul) : p->var;

      #ifdef FEAT_ARABIC
      case PV_ARAB: return (char_u *)&(curwin->w_p_arab);
      ***************
      *** 10445,10450 ****
      --- 10467,10473 ----
      /* options that are normally global but also have a local value
      * are not copied, start using the global value */
      buf->b_p_ar = -1;
      + buf->b_p_ul = NO_LOCAL_UNDOLEVEL;
      #ifdef FEAT_QUICKFIX
      buf->b_p_gp = empty_option;
      buf->b_p_mp = empty_option;
      *** ../vim-7.4.072/src/option.h 2013-06-26 18:41:39.000000000 +0200
      --- src/option.h 2013-11-06 04:17:40.000000000 +0100
      ***************
      *** 1031,1036 ****
      --- 1031,1037 ----
      , BV_TW
      , BV_TX
      , BV_UDF
      + , BV_UL
      , BV_WM
      , BV_COUNT /* must be the last one */
      };
      ***************
      *** 1109,1111 ****
      --- 1110,1115 ----
      , WV_WRAP
      , WV_COUNT /* must be the last one */
      };
      +
      + /* Value for b_p_ul indicating the global value must be used. */
      + #define NO_LOCAL_UNDOLEVEL -123456
      *** ../vim-7.4.072/src/structs.h 2013-11-05 07:12:59.000000000 +0100
      --- src/structs.h 2013-11-06 04:26:17.000000000 +0100
      ***************
      *** 1627,1632 ****
      --- 1627,1633 ----
      char_u *b_p_dict; /* 'dictionary' local value */
      char_u *b_p_tsr; /* 'thesaurus' local value */
      #endif
      + long b_p_ul; /* 'undolevels' local value */
      #ifdef FEAT_PERSISTENT_UNDO
      int b_p_udf; /* 'undofile' */
      #endif
      *** ../vim-7.4.072/src/undo.c 2013-09-08 15:40:45.000000000 +0200
      --- src/undo.c 2013-11-06 04:33:12.000000000 +0100
      ***************
      *** 83,88 ****
      --- 83,89 ----

      #include "vim.h"

      + static long get_undolevel __ARGS((void));
      static void u_unch_branch __ARGS((u_header_T *uhp));
      static u_entry_T *u_get_headentry __ARGS((void));
      static void u_getbot __ARGS((void));
      ***************
      *** 336,341 ****
      --- 337,353 ----
      }

      /*
      + * Get the undolevle value for the current buffer.
      + */
      + static long
      + get_undolevel()
      + {
      + if (curbuf->b_p_ul == NO_LOCAL_UNDOLEVEL)
      + return p_ul;
      + return curbuf->b_p_ul;
      + }
      +
      + /*
      * Common code for various ways to save text before a change.
      * "top" is the line above the first changed line.
      * "bot" is the line below the last changed line.
      ***************
      *** 419,425 ****
      curbuf->b_new_change = TRUE;
      #endif

      ! if (p_ul >= 0)
      {
      /*
      * Make a new header entry. Do this first so that we don't mess
      --- 431,437 ----
      curbuf->b_new_change = TRUE;
      #endif

      ! if (get_undolevel() >= 0)
      {
      /*
      * Make a new header entry. Do this first so that we don't mess
      ***************
      *** 449,455 ****
      /*
      * free headers to keep the size right
      */
      ! while (curbuf->b_u_numhead > p_ul && curbuf->b_u_oldhead != NULL)
      {
      u_header_T *uhfree = curbuf->b_u_oldhead;

      --- 461,468 ----
      /*
      * free headers to keep the size right
      */
      ! while (curbuf->b_u_numhead > get_undolevel()
      ! && curbuf->b_u_oldhead != NULL)
      {
      u_header_T *uhfree = curbuf->b_u_oldhead;

      ***************
      *** 530,536 ****
      }
      else
      {
      ! if (p_ul < 0) /* no undo at all */
      return OK;

      /*
      --- 543,549 ----
      }
      else
      {
      ! if (get_undolevel() < 0) /* no undo at all */
      return OK;

      /*
      ***************
      *** 1972,1978 ****
      {
      if (curbuf->b_u_curhead == NULL) /* first undo */
      curbuf->b_u_curhead = curbuf->b_u_newhead;
      ! else if (p_ul > 0) /* multi level undo */
      /* get next undo */
      curbuf->b_u_curhead = curbuf->b_u_curhead->uh_next.ptr;
      /* nothing to undo */
      --- 1985,1991 ----
      {
      if (curbuf->b_u_curhead == NULL) /* first undo */
      curbuf->b_u_curhead = curbuf->b_u_newhead;
      ! else if (get_undolevel() > 0) /* multi level undo */
      /* get next undo */
      curbuf->b_u_curhead = curbuf->b_u_curhead->uh_next.ptr;
      /* nothing to undo */
      ***************
      *** 1993,1999 ****
      }
      else
      {
      ! if (curbuf->b_u_curhead == NULL || p_ul <= 0)
      {
      beep_flush(); /* nothing to redo */
      if (count == startcount - 1)
      --- 2006,2012 ----
      }
      else
      {
      ! if (curbuf->b_u_curhead == NULL || get_undolevel() <= 0)
      {
      beep_flush(); /* nothing to redo */
      if (count == startcount - 1)
      ***************
      *** 2751,2757 ****
      if (im_is_preediting())
      return; /* XIM is busy, don't break an undo sequence */
      #endif
      ! if (p_ul < 0)
      curbuf->b_u_synced = TRUE; /* no entries, nothing to do */
      else
      {
      --- 2764,2770 ----
      if (im_is_preediting())
      return; /* XIM is busy, don't break an undo sequence */
      #endif
      ! if (get_undolevel() < 0)
      curbuf->b_u_synced = TRUE; /* no entries, nothing to do */
      else
      {
      ***************
      *** 2911,2917 ****
      }
      if (!curbuf->b_u_synced)
      return; /* already unsynced */
      ! if (p_ul < 0)
      return; /* no entries, nothing to do */
      else
      {
      --- 2924,2930 ----
      }
      if (!curbuf->b_u_synced)
      return; /* already unsynced */
      ! if (get_undolevel() < 0)
      return; /* no entries, nothing to do */
      else
      {
      *** ../vim-7.4.072/src/version.c 2013-11-06 04:04:29.000000000 +0100
      --- src/version.c 2013-11-06 05:21:43.000000000 +0100
      ***************
      *** 740,741 ****
      --- 740,743 ----
      { /* Add new patch number below this line */
      + /**/
      + 73,
      /**/

      --
      Living on Earth includes an annual free trip around the Sun.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ an exciting new programming language -- http://www.Zimbu.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Christian Brabandt
      ... Now this time, I was too slow, with adding some tests to that patch ;( But this is mainly, because I discovered a problem with the undo tree, that I
      Message 2 of 11 , Nov 5, 2013
      • 0 Attachment
        On Wed, November 6, 2013 05:26, Bram Moolenaar wrote:
        >
        > Patch 7.4.073
        > Problem: Setting undolevels for one buffer changes undo in another.
        > Solution: Make 'undolevels' a global-local option. (Christian Brabandt)
        > Files: runtime/doc/options.txt, src/buffer.c, src/option.c,
        > src/option.h
        > src/structs.h, src/undo.c
        >

        Now this time, I was too slow, with adding some tests to that patch ;(

        But this is mainly, because I discovered a problem with the undo tree,
        that I haven't completly debugged yet.


        regards,
        Christian

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Bram Moolenaar
        ... Yes, tests were missing. I also fixed a few problems relative to your patch (which was old). What kind of problems did you notice? Oh, I see another
        Message 3 of 11 , Nov 6, 2013
        • 0 Attachment
          Christian Brabandt wrote:

          > On Wed, November 6, 2013 05:26, Bram Moolenaar wrote:
          > >
          > > Patch 7.4.073
          > > Problem: Setting undolevels for one buffer changes undo in another.
          > > Solution: Make 'undolevels' a global-local option. (Christian Brabandt)
          > > Files: runtime/doc/options.txt, src/buffer.c, src/option.c,
          > > src/option.h
          > > src/structs.h, src/undo.c
          > >
          >
          > Now this time, I was too slow, with adding some tests to that patch ;(
          >
          > But this is mainly, because I discovered a problem with the undo tree,
          > that I haven't completly debugged yet.

          Yes, tests were missing. I also fixed a few problems relative to your
          patch (which was old).

          What kind of problems did you notice?
          Oh, I see another message from you.

          --
          FROG: How you English say: I one more time, mac, I unclog my nose towards
          you, sons of a window-dresser, so, you think you could out-clever us
          French fellows with your silly knees-bent creeping about advancing
          behaviour. (blows a raspberry) I wave my private parts at your aunties,
          you brightly-coloured, mealy-templed, cranberry-smelling, electric
          donkey-bottom biters.
          "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ an exciting new programming language -- http://www.Zimbu.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Christian Brabandt
          Hi Bram! ... Here is the missing test. Best, Christian -- Betrachte alles von der guten Seite. -- Thomas Jefferson -- -- You received this message from the
          Message 4 of 11 , Nov 6, 2013
          • 0 Attachment
            Hi Bram!

            On Mi, 06 Nov 2013, Bram Moolenaar wrote:

            >
            > Christian Brabandt wrote:
            >
            > > On Wed, November 6, 2013 05:26, Bram Moolenaar wrote:
            > > >
            > > > Patch 7.4.073
            > > > Problem: Setting undolevels for one buffer changes undo in another.
            > > > Solution: Make 'undolevels' a global-local option. (Christian Brabandt)
            > > > Files: runtime/doc/options.txt, src/buffer.c, src/option.c,
            > > > src/option.h
            > > > src/structs.h, src/undo.c
            > > >
            > >
            > > Now this time, I was too slow, with adding some tests to that patch ;(
            > >
            > > But this is mainly, because I discovered a problem with the undo tree,
            > > that I haven't completly debugged yet.
            >
            > Yes, tests were missing. I also fixed a few problems relative to your
            > patch (which was old).

            Here is the missing test.

            Best,
            Christian
            --
            Betrachte alles von der guten Seite.
            -- Thomas Jefferson

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Bram Moolenaar
            ... Thanks. Are you scared of the number 100? :-) -- BEDEVERE: Stand by for attack!! [CUT TO enormous army forming up. Trebuchets, rows of PIKEMEN, siege
            Message 5 of 11 , Nov 6, 2013
            • 0 Attachment
              Christian Brabandt wrote:

              > On Mi, 06 Nov 2013, Bram Moolenaar wrote:
              >
              > >
              > > Christian Brabandt wrote:
              > >
              > > > On Wed, November 6, 2013 05:26, Bram Moolenaar wrote:
              > > > >
              > > > > Patch 7.4.073
              > > > > Problem: Setting undolevels for one buffer changes undo in another.
              > > > > Solution: Make 'undolevels' a global-local option. (Christian Brabandt)
              > > > > Files: runtime/doc/options.txt, src/buffer.c, src/option.c,
              > > > > src/option.h
              > > > > src/structs.h, src/undo.c
              > > > >
              > > >
              > > > Now this time, I was too slow, with adding some tests to that patch ;(
              > > >
              > > > But this is mainly, because I discovered a problem with the undo tree,
              > > > that I haven't completly debugged yet.
              > >
              > > Yes, tests were missing. I also fixed a few problems relative to your
              > > patch (which was old).
              >
              > Here is the missing test.

              Thanks. Are you scared of the number 100? :-)


              --
              BEDEVERE: Stand by for attack!!
              [CUT TO enormous army forming up. Trebuchets, rows of PIKEMEN, siege
              towers, pennants flying, shouts of "Stand by for attack!" Traditional
              army build-up shots. The shouts echo across the ranks of the army.
              We see various groups reacting, and stirring themselves in readiness.]
              ARTHUR: Who are they?
              BEDEVERE: Oh, just some friends!
              "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ an exciting new programming language -- http://www.Zimbu.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Christian Brabandt
              ... kind of. The more tests we add, the harder it is to find one, that can be used for adding more tests. So I figured, it would make sense, to give them more
              Message 6 of 11 , Nov 7, 2013
              • 0 Attachment
                On Thu, November 7, 2013 03:26, Bram Moolenaar wrote:
                > Thanks. Are you scared of the number 100? :-)

                kind of. The more tests we add, the harder it is to find one, that can
                be used for adding more tests. So I figured, it would make sense, to
                give them more meaningful names, so one can make an educated guess
                from the name what they are about.

                Plus, it prevents name clashes and allows to easier handle local
                patches. I have a bunch of local patches laying around, that each
                wants to add test100.in and .ok and once I go through my patch queue,
                it gets more and more likely, that a patch can't be applied, because
                of that.

                BTW: is there a reason, not to make the Test Makefile use wildcard
                expansion to find all relevant tests? (i.e. something like this:

                SCRIPTS = $(subst in,out,$(wildcard test*.in))

                Well, I just see, this would need a couple of more changes, to exclude
                the test*a.in files, but should be reasonable, I think.
                (Not sure if this is really workable on non GNU Systems).

                regards,
                Christian

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Nikolay Pavlov
                ... I have raised the question earlier. I personally have patches with tests 100 (and no 101 and 102), 101 (and no ...), 102 (...). I would suggest giving
                Message 7 of 11 , Nov 7, 2013
                • 0 Attachment


                  On Nov 7, 2013 12:27 PM, "Christian Brabandt" <cblists@...> wrote:
                  >
                  > On Thu, November 7, 2013 03:26, Bram Moolenaar wrote:
                  > > Thanks.  Are you scared of the number 100? :-)
                  >
                  > kind of. The more tests we add, the harder it is to find one, that can
                  > be used for adding more tests. So I figured, it would make sense, to
                  > give them more meaningful names, so one can make an educated guess
                  > from the name what they are about.
                  >
                  > Plus, it prevents name clashes and allows to easier handle local
                  > patches. I have a bunch of local patches laying around, that each
                  > wants to add test100.in and .ok and once I go through my patch queue,
                  > it gets more and more likely, that a patch can't be applied, because
                  > of that.

                  I have raised the question earlier. I personally have patches with tests 100 (and no 101 and 102), 101 (and no ...), 102 (...).

                  I would suggest giving patches meaningful names, splitting lines in Makefiles into one line per file fashion and telling contributors that they should place tests there in alphabetical order. Splitting and ordering are there to reduce probability of conflicts when merging.

                  > BTW: is there a reason, not to make the Test Makefile use wildcard
                  > expansion to find all relevant tests? (i.e. something like this:
                  >
                  > SCRIPTS = $(subst in,out,$(wildcard test*.in))
                  >
                  > Well, I just see, this would need a couple of more changes, to exclude
                  > the test*a.in files, but should be reasonable, I think.
                  > (Not sure if this is really workable on non GNU Systems).

                  Some Makefiles do not list all tests because some tests should not be run on some systems. I do not know why usual workaround (copying *.ok to test.out) is not used in such cases though.

                  >
                  > regards,
                  > Christian
                  >
                  > --
                  > --
                  > You received this message from the "vim_dev" maillist.
                  > Do not top-post! Type your reply below the text you are replying to.
                  > For more information, visit http://www.vim.org/maillist.php
                  >
                  > ---
                  > You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  > To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  > For more options, visit https://groups.google.com/groups/opt_out.

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php
                   
                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Bram Moolenaar
                  ... Yeah, names would be clearer. Although it s not so easy to come up with names, numbers are a lot simpler. ... My experience with wildcards is that they
                  Message 8 of 11 , Nov 7, 2013
                  • 0 Attachment
                    Christian Brabandt wrote:

                    > On Thu, November 7, 2013 03:26, Bram Moolenaar wrote:
                    > > Thanks. Are you scared of the number 100? :-)
                    >
                    > kind of. The more tests we add, the harder it is to find one, that can
                    > be used for adding more tests. So I figured, it would make sense, to
                    > give them more meaningful names, so one can make an educated guess
                    > from the name what they are about.
                    >
                    > Plus, it prevents name clashes and allows to easier handle local
                    > patches. I have a bunch of local patches laying around, that each
                    > wants to add test100.in and .ok and once I go through my patch queue,
                    > it gets more and more likely, that a patch can't be applied, because
                    > of that.

                    Yeah, names would be clearer. Although it's not so easy to come up with
                    names, numbers are a lot simpler.

                    > BTW: is there a reason, not to make the Test Makefile use wildcard
                    > expansion to find all relevant tests? (i.e. something like this:
                    >
                    > SCRIPTS = $(subst in,out,$(wildcard test*.in))
                    >
                    > Well, I just see, this would need a couple of more changes, to exclude
                    > the test*a.in files, but should be reasonable, I think.
                    > (Not sure if this is really workable on non GNU Systems).

                    My experience with wildcards is that they often cause trouble. They may
                    pick up too much or not work on older systems. We don't add tests often
                    enough that it's a problem to edit the Makefiles.

                    Keep in mind that these Makefiles have to work on just about any system.
                    That's what makes it easy to run Vim on just about any Unix-like system.
                    Not supporting certain implementations of make will cause serious
                    problems for a small group of users.

                    One thing that should be a portable solution is to put the list of test
                    files in a separte Makefile that is included by others. However, that
                    doesn't work for the Makefiles that skip a few that don't work on the
                    specific system, such as VMS or MS-Windows.


                    --
                    TERRY GILLIAM PLAYED: PATSY (ARTHUR'S TRUSTY STEED), THE GREEN KNIGHT
                    SOOTHSAYER, BRIDGEKEEPER, SIR GAWAIN (THE FIRST TO BE
                    KILLED BY THE RABBIT)
                    "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                    /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                    /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                    \\\ an exciting new programming language -- http://www.Zimbu.org ///
                    \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Nikolay Pavlov
                    ... It is very easy if you think about it before writing a test. It would not be so easy for existing ones though, especially monsters like test49. ... I would
                    Message 9 of 11 , Nov 7, 2013
                    • 0 Attachment


                      On Nov 8, 2013 1:16 AM, "Bram Moolenaar" <Bram@...> wrote:
                      >
                      >
                      > Christian Brabandt wrote:
                      >
                      > > On Thu, November 7, 2013 03:26, Bram Moolenaar wrote:
                      > > > Thanks.  Are you scared of the number 100? :-)
                      > >
                      > > kind of. The more tests we add, the harder it is to find one, that can
                      > > be used for adding more tests. So I figured, it would make sense, to
                      > > give them more meaningful names, so one can make an educated guess
                      > > from the name what they are about.
                      > >
                      > > Plus, it prevents name clashes and allows to easier handle local
                      > > patches. I have a bunch of local patches laying around, that each
                      > > wants to add test100.in and .ok and once I go through my patch queue,
                      > > it gets more and more likely, that a patch can't be applied, because
                      > > of that.
                      >
                      > Yeah, names would be clearer.  Although it's not so easy to come up with
                      > names, numbers are a lot simpler.

                      It is very easy if you think about it before writing a test. It would not be so easy for existing ones though, especially monsters like test49.

                      > > BTW: is there a reason, not to make the Test Makefile use wildcard
                      > > expansion to find all relevant tests? (i.e. something like this:
                      > >
                      > > SCRIPTS = $(subst in,out,$(wildcard test*.in))
                      > >
                      > > Well, I just see, this would need a couple of more changes, to exclude
                      > > the test*a.in files, but should be reasonable, I think.
                      > > (Not sure if this is really workable on non GNU Systems).
                      >
                      > My experience with wildcards is that they often cause trouble.  They may
                      > pick up too much or not work on older systems.  We don't add tests often
                      > enough that it's a problem to edit the Makefiles.
                      >
                      > Keep in mind that these Makefiles have to work on just about any system.
                      > That's what makes it easy to run Vim on just about any Unix-like system.
                      > Not supporting certain implementations of make will cause serious
                      > problems for a small group of users.

                      I would rather solve this by adding a Makefile generator which will update Makefiles and not by requiring contributors create changes for 100500 makefiles. This is inefficient. There is no need for generator to be runnable all systems like we do not require autoconf to run make or configure.

                      It is easy enough to write generator in POSIX shell making it runnable on every system contributors actually use. This will also solve problems with wildcards: wildcards will be placed in the generator and not in Makefiles.

                      >
                      > One thing that should be a portable solution is to put the list of test
                      > files in a separte Makefile that is included by others.  However, that
                      > doesn't work for the Makefiles that skip a few that don't work on the
                      > specific system, such as VMS or MS-Windows.

                      There are :if !has(...) ... workarounds for this in some files. I do not see why we should not use them for VMS or MS Windows since there are things like has('vms').

                      >
                      > --
                      > TERRY GILLIAM PLAYED: PATSY (ARTHUR'S TRUSTY STEED), THE GREEN KNIGHT
                      >                       SOOTHSAYER, BRIDGEKEEPER, SIR GAWAIN (THE FIRST TO BE
                      >                       KILLED BY THE RABBIT)
                      >                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
                      >
                      >  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
                      > ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                      > \\\  an exciting new programming language -- http://www.Zimbu.org        ///
                      >  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///
                      >
                      > --
                      > --
                      > You received this message from the "vim_dev" maillist.
                      > Do not top-post! Type your reply below the text you are replying to.
                      > For more information, visit http://www.vim.org/maillist.php
                      >
                      > ---
                      > You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      > To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      > For more options, visit https://groups.google.com/groups/opt_out.

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php
                       
                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • Christian Brabandt
                      Hi Bram! ... Here is a patch, that 1) documents the contents of the testfiles. (the README was generated by the first couple of lines of each test*.in file) 2)
                      Message 10 of 11 , Nov 7, 2013
                      • 0 Attachment
                        Hi Bram!

                        On Do, 07 Nov 2013, Christian Brabandt wrote:

                        > On Thu, November 7, 2013 03:26, Bram Moolenaar wrote:
                        > > Thanks. Are you scared of the number 100? :-)
                        >
                        > kind of. The more tests we add, the harder it is to find one, that can
                        > be used for adding more tests. So I figured, it would make sense, to
                        > give them more meaningful names, so one can make an educated guess
                        > from the name what they are about.
                        >
                        > Plus, it prevents name clashes and allows to easier handle local
                        > patches. I have a bunch of local patches laying around, that each
                        > wants to add test100.in and .ok and once I go through my patch queue,
                        > it gets more and more likely, that a patch can't be applied, because
                        > of that.
                        >
                        > BTW: is there a reason, not to make the Test Makefile use wildcard
                        > expansion to find all relevant tests? (i.e. something like this:
                        >
                        > SCRIPTS = $(subst in,out,$(wildcard test*.in))
                        >
                        > Well, I just see, this would need a couple of more changes, to exclude
                        > the test*a.in files, but should be reasonable, I think.
                        > (Not sure if this is really workable on non GNU Systems).

                        Here is a patch, that

                        1) documents the contents of the testfiles.
                        (the README was generated by the first couple of lines of each
                        test*.in file)
                        2) uses wildcard with the main (Unix) Makefile
                        3) renames a couple of tests, so that wildcards can be used more easily
                        4) changes test50 to check for a windows system
                        5) does not include test100 yet ;(

                        Best,
                        Christian

                        --
                        --
                        You received this message from the "vim_dev" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php

                        ---
                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • tooth pik
                        ... s/ /or/ -- _|_ _ __|_|_ ._ o| ... -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you
                        Message 11 of 11 , Nov 7, 2013
                        • 0 Attachment
                          On Thu, Nov 07, 2013 at 10:55:12PM +0100, Christian Brabandt wrote:
                          > On Do, 07 Nov 2013, Christian Brabandt wrote:
                          > > On Thu, November 7, 2013 03:26, Bram Moolenaar wrote:
                          > +=========
                          > +test49.in
                          > +=========
                          > +
                          > +This is a test of the script language.
                          > +
                          > +If after adding a new test, the test output doesn't appear properly in
                          > +test49.failed, try to add one ore more "G"s at the line ending in "test.out"

                          s/\<ore\>/or/

                          --
                          _|_ _ __|_|_ ._ o|
                          |_(_)(_)|_| ||_)||<
                          |

                          --
                          --
                          You received this message from the "vim_dev" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php

                          ---
                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        Your message has been successfully submitted and would be delivered to recipients shortly.