I used the breakindent patch for a few months before reverting to Vim's
regular behavior because of the bug described by Tobia Conforto and
another one that seems to be related: On the second and later screen
lines of a wrapped physical line that displays the "backwrap" bug, the
displayed position of the text cursor is off by as many characters as
are "backwrapped" on the previous virtual lines. It's a shame because I
rather liked the goal of the breakindent patch :-(.

  - Peter Odding


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Craig Barkhouse wrote:
> vim -c "bufdo normal gg" *.c
>
> The problem I see is that the first and last buffers have
> syntax highlighting, but all the intermediate buffers do not.

At ':help :bufdo' we see that bufdo disables the Syntax
automcommand event (for speed). That means the buffers you had
not previously visited do not have syntax highlighting. I do not
know the official way to overcome this issue, but I press F7
once (twice??) where I have this in vimrc:

" Toggle syntax off/on (from Help).
noremap <F7> :if exists("syntax_on") <Bar>
     \   syntax off <Bar>
     \ else <Bar>
     \   syntax enable <Bar>
     \ endif <CR>

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Wed, November 25, 2009 2:49 am, Craig Barkhouse wrote:

> And then invoke Vim as follows in a directory that has several .c
> files (it seems you could use any :bufdo command here, this is just an
> example): vim -c "bufdo normal gg" *.c
>
> The problem I see is that the first and last buffers have syntax
> highlighting, but all the intermediate buffers do not.  For example,
> if there are 10 .c files, then only buffers 1 and 10 will have syntax
> highlighting.

When issuing :bufdo, the Syntax autocommand event is added to the
'eventignore' option, so that bufdo can perform faster. This is
described at :h :bufdo

If you don't like this, you could possibly set this option within the
:bufdo command like this:

vim -c "bufdo set ei=| normal gg" *.c

> P.S.  I actually don't remember why I set 'hidden' in my .vimrc, it's
> just been that way for so long!

It enables you to switch buffers, even when the current buffer is
modified. Otherwise you would have save the current buffer before
switching to another one.

regards,
Christian


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.304
Problem:    Compiler warning for bad pointer cast.
Solution:   Use another variable for int pointer.
Files:     src/ops.c


*** ../vim-7.2.303/src/ops.c 2009-11-17 12:43:19.000000000 +0100
--- src/ops.c 2009-11-18 15:40:26.000000000 +0100
***************
*** 5597,5603 ****
  	     vc.vc_type = CONV_NONE;
  	     if (convert_setup(&vc, p_enc, (char_u *)"latin1") == OK)
  	     {
! 	 conv_str = string_convert(&vc, str, (int*)&len);
  		 if (conv_str != NULL)
  		 {
  		     vim_free(str);
--- 5597,5606 ----
  	     vc.vc_type = CONV_NONE;
  	     if (convert_setup(&vc, p_enc, (char_u *)"latin1") == OK)
  	     {
! 	        int intlen = len;
!
! 	 conv_str = string_convert(&vc, str, &intlen);
! 	 len = intlen;
  		 if (conv_str != NULL)
  		 {
  		     vim_free(str);
*** ../vim-7.2.303/src/version.c 2009-11-18 20:12:15.000000000 +0100
--- src/version.c 2009-11-25 12:37:36.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     304,
   /**/

--
I recommend ordering large cargo containers of paper towels to make up
whatever budget underruns you have.  Paper products are always useful and they
have the advantage of being completely flushable if you need to make room in
the storage area later.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.305
Problem:    Recursively redrawing causes a memory leak. (Dominique Pelle)
Solution:   Disallow recursive screen updating.
Files:     src/screen.c


*** ../vim-7.2.304/src/screen.c 2009-11-11 17:07:25.000000000 +0100
--- src/screen.c 2009-11-17 16:30:53.000000000 +0100
***************
*** 323,328 ****
--- 323,329 ----
       int  did_one;
   #endif

+     /* Don't do anything if the screen structures are (not yet) valid. */
       if (!screen_valid(TRUE))
  	 return;

***************
*** 342,348 ****
       if (curwin->w_lines_valid == 0 && type < NOT_VALID)
  	 type = NOT_VALID;

!     if (!redrawing())
       {
  	 redraw_later(type);  /* remember type for next time */
  	 must_redraw = type;
--- 343,351 ----
       if (curwin->w_lines_valid == 0 && type < NOT_VALID)
  	 type = NOT_VALID;

!     /* Postpone the redrawing when it's not needed and when being called
!      * recursively. */
!     if (!redrawing() || updating_screen)
       {
  	 redraw_later(type);  /* remember type for next time */
  	 must_redraw = type;
***************
*** 582,587 ****
--- 585,591 ----

   /*
    * Prepare for updating one or more windows.
+  * Caller must check for "updating_screen" already set to avoid recursiveness.
    */
       static void
   update_prepare()
***************
*** 663,669 ****
  	     doit = TRUE;
       }

!     if (!doit)
  	 return;

       /* update all windows that need updating */
--- 667,675 ----
  	     doit = TRUE;
       }

!     /* Return when there is nothing to do or screen updating already
!      * happening. */
!     if (!doit || updating_screen)
  	 return;

       /* update all windows that need updating */
***************
*** 696,701 ****
--- 702,711 ----
   updateWindow(wp)
       win_T *wp;
   {
+     /* return if already busy updating */
+     if (updating_screen)
+  return;
+
       update_prepare();

   #ifdef FEAT_CLIPBOARD
*** ../vim-7.2.304/src/version.c 2009-11-25 12:38:49.000000000 +0100
--- src/version.c 2009-11-25 13:01:48.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     305,
   /**/

--
If the Universe is constantly expanding, why can't I ever find a parking space?

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.305
Problem:    Recursively redrawing causes a memory leak. (Dominique Pelle)
Solution:   Disallow recursive screen updating.
Files:     src/screen.c


*** ../vim-7.2.304/src/screen.c 2009-11-11 17:07:25.000000000 +0100
--- src/screen.c 2009-11-17 16:30:53.000000000 +0100
***************
*** 323,328 ****
--- 323,329 ----
       int  did_one;
   #endif

+     /* Don't do anything if the screen structures are (not yet) valid. */
       if (!screen_valid(TRUE))
  	 return;

***************
*** 342,348 ****
       if (curwin->w_lines_valid == 0 && type < NOT_VALID)
  	 type = NOT_VALID;

!     if (!redrawing())
       {
  	 redraw_later(type);  /* remember type for next time */
  	 must_redraw = type;
--- 343,351 ----
       if (curwin->w_lines_valid == 0 && type < NOT_VALID)
  	 type = NOT_VALID;

!     /* Postpone the redrawing when it's not needed and when being called
!      * recursively. */
!     if (!redrawing() || updating_screen)
       {
  	 redraw_later(type);  /* remember type for next time */
  	 must_redraw = type;
***************
*** 582,587 ****
--- 585,591 ----

   /*
    * Prepare for updating one or more windows.
+  * Caller must check for "updating_screen" already set to avoid recursiveness.
    */
       static void
   update_prepare()
***************
*** 663,669 ****
  	     doit = TRUE;
       }

!     if (!doit)
  	 return;

       /* update all windows that need updating */
--- 667,675 ----
  	     doit = TRUE;
       }

!     /* Return when there is nothing to do or screen updating already
!      * happening. */
!     if (!doit || updating_screen)
  	 return;

       /* update all windows that need updating */
***************
*** 696,701 ****
--- 702,711 ----
   updateWindow(wp)
       win_T *wp;
   {
+     /* return if already busy updating */
+     if (updating_screen)
+  return;
+
       update_prepare();

   #ifdef FEAT_CLIPBOARD
*** ../vim-7.2.304/src/version.c 2009-11-25 12:38:49.000000000 +0100
--- src/version.c 2009-11-25 13:01:48.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     305,
   /**/

--
If the Universe is constantly expanding, why can't I ever find a parking space?

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hello,

Thanks for describing the 2 ways. I am not happy if I would disappoint
you for writing that down, but I was aware about those.
What I was a bit annoyed, is that a format that is output of several
commands used everyday by most of us, is not accepted as "standard"
command line. I have created for myself a wrapper that converts
file:line into file +line.

So my wrapper is wrvim and
wrvim file:line
is the same as
wrvim file +line




--
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 25-Nov-09 16:44, mobi phil wrote:
> Hello,
>
> Thanks for describing the 2 ways. I am not happy if I would disappoint
> you for writing that down, but I was aware about those.
> What I was a bit annoyed, is that a format that is output of several
> commands used everyday by most of us, is not accepted as "standard"
> command line. I have created for myself a wrapper that converts
> file:line into file +line.
>
> So my wrapper is wrvim and
> wrvim file:line
> is the same as
> wrvim file +line

Why don't you use the file-line.vim plugin? I mentioned it a month ago in
exactly the current thread:
      http://groups.google.com/group/vim_dev/msg/722aefe8494c3a44

-- cheers, ingo

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 24-Nov-09 19:06, Peter Odding wrote:
> I used the breakindent patch for a few months before reverting to Vim's
> regular behavior because of the bug described by Tobia Conforto and
> another one that seems to be related: On the second and later screen
> lines of a wrapped physical line that displays the "backwrap" bug, the
> displayed position of the text cursor is off by as many characters as
> are "backwrapped" on the previous virtual lines. It's a shame because I
> rather liked the goal of the breakindent patch :-(.
>
>  - Peter Odding

I had experienced exactly the same problems when checking out the vim_extended
Git repository a couple of months ago, but thought it was caused either by the
interaction of different experimental patches in that repository, or by my
peculiar system.

Is Václav Šmilauer, the patch author, reading this list? Please confirm this
(rather obvious) bug and whether you plan to fix it. I would really love (and
re-try) this feature; it would be nice if it could make it into the next Vim
release.

-- cheers, ingo

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.306
Problem:    shellescape("10%%", 1) only escapes first %. (Christian Brabandt)
Solution:   Don't copy the character after the escaped one.
Files:     src/misc2.c


*** ../vim-7.2.305/src/misc2.c 2009-11-11 16:56:13.000000000 +0100
--- src/misc2.c 2009-11-25 17:11:49.000000000 +0100
***************
*** 1390,1395 ****
--- 1390,1396 ----
  		 *d++ = '\\';  /* insert backslash */
  		 while (--l >= 0) /* copy the var */
  		     *d++ = *p++;
+ 	 continue;
  	     }

  	     MB_COPY_CHAR(p, d);
*** ../vim-7.2.305/src/version.c 2009-11-25 13:03:29.000000000 +0100
--- src/version.c 2009-11-25 17:13:54.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     306,
   /**/

--
Article in the first Free Software Magazine: "Bram Moolenaar studied electrical
engineering at the Technical University of Delft and graduated in 1985 on a
multi-processor Unix architecture."
Response by "dimator": Could the school not afford a proper stage for the
ceremony?

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.307
Problem:    Crash with a very long syntax match statement. (Guy Gur Ari)
Solution:   When the offset does not fit in the two bytes available give an
             error instead of continuing with invalid pointers.
Files:      src/regexp.c


*** ../vim-7.2.306/src/regexp.c 2009-05-15 21:31:11.000000000 +0200
--- src/regexp.c 2009-11-25 18:13:03.000000000 +0100
***************
*** 583,588 ****
--- 583,589 ----
   #endif
   static char_u *regcode; /* Code-emit pointer, or JUST_CALC_SIZE */
   static long regsize; /* Code size. */
+ static int reg_toolong; /* TRUE when offset out of range */
   static char_u had_endbrace[NSUBEXP]; /* flags, TRUE if end of () found */
   static unsigned regflags; /* RF_ flags for prog */
   static long brace_min[10]; /* Minimums for complex brace repeats */
***************
*** 1028,1036 ****
       regcomp_start(expr, re_flags);
       regcode = r->program;
       regc(REGMAGIC);
!     if (reg(REG_NOPAREN, &flags) == NULL)
       {
  	 vim_free(r);
  	 return NULL;
       }

--- 1029,1039 ----
       regcomp_start(expr, re_flags);
       regcode = r->program;
       regc(REGMAGIC);
!     if (reg(REG_NOPAREN, &flags) == NULL || reg_toolong)
       {
  	 vim_free(r);
+  if (reg_toolong)
+ 	    EMSG_RET_NULL(_("E339: Pattern too long"));
  	 return NULL;
       }

***************
*** 1141,1146 ****
--- 1144,1150 ----
       re_has_z = 0;
   #endif
       regsize = 0L;
+     reg_toolong = FALSE;
       regflags = 0;
   #if defined(FEAT_SYN_HL) || defined(PROTO)
       had_eol = FALSE;
***************
*** 1228,1234 ****
       {
  	 skipchr();
  	 br = regbranch(&flags);
!  if (br == NULL)
  	     return NULL;
  	 regtail(ret, br); /* BRANCH -> BRANCH. */
  	 if (!(flags & HASWIDTH))
--- 1232,1238 ----
       {
  	 skipchr();
  	 br = regbranch(&flags);
!  if (br == NULL || reg_toolong)
  	     return NULL;
  	 regtail(ret, br); /* BRANCH -> BRANCH. */
  	 if (!(flags & HASWIDTH))
***************
*** 1313,1318 ****
--- 1317,1324 ----
  	     break;
  	 skipchr();
  	 regtail(latest, regnode(END)); /* operand ends */
+  if (reg_toolong)
+ 	    break;
  	 reginsert(MATCH, latest);
  	 chain = latest;
       }
***************
*** 1382,1388 ****
  			     break;
  	     default:
  			     latest = regpiece(&flags);
! 			    if (latest == NULL)
  				 return NULL;
  			     *flagp |= flags & (HASWIDTH | HASNL | HASLOOKBH);
  			     if (chain == NULL) /* First piece. */
--- 1388,1394 ----
  			     break;
  	     default:
  			     latest = regpiece(&flags);
! 			    if (latest == NULL || reg_toolong)
  				 return NULL;
  			     *flagp |= flags & (HASWIDTH | HASNL | HASLOOKBH);
  			     if (chain == NULL) /* First piece. */
***************
*** 2540,2547 ****
  	 offset = (int)(scan - val);
       else
  	 offset = (int)(val - scan);
!     *(scan + 1) = (char_u) (((unsigned)offset >> 8) & 0377);
!     *(scan + 2) = (char_u) (offset & 0377);
   }

   /*
--- 2546,2561 ----
  	 offset = (int)(scan - val);
       else
  	 offset = (int)(val - scan);
!     /* When the offset uses more than 16 bits it can no longer fit in the two
!      * bytes avaliable.  Use a global flag to avoid having to check return
!      * values in too many places. */
!     if (offset > 0xffff)
!  reg_toolong = TRUE;
!     else
!     {
!  *(scan + 1) = (char_u) (((unsigned)offset >> 8) & 0377);
!  *(scan + 2) = (char_u) (offset & 0377);
!     }
   }

   /*
***************
*** 5764,5769 ****
--- 5778,5785 ----

   /*
    * regnext - dig the "next" pointer out of a node
+  * Returns NULL when calculating size, when there is no next item and when
+  * there is an error.
    */
       static char_u *
   regnext(p)
***************
*** 5771,5777 ****
   {
       int     offset;

!     if (p == JUST_CALC_SIZE)
  	 return NULL;

       offset = NEXT(p);
--- 5787,5793 ----
   {
       int     offset;

!     if (p == JUST_CALC_SIZE || reg_toolong)
  	 return NULL;

       offset = NEXT(p);
*** ../vim-7.2.306/src/version.c 2009-11-25 17:15:16.000000000 +0100
--- src/version.c 2009-11-25 18:14:32.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     307,
   /**/

--
The fastest way to get an engineer to solve a problem is to declare that the
problem is unsolvable.  No engineer can walk away from an unsolvable problem
until it's solved.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

> -----Original Message-----
> From: vim_dev@googlegroups.com [mailto:vim_dev@googlegroups.com] On
> Behalf Of Christian Brabandt
> Sent: Tuesday, November 24, 2009 10:38 PM
> To: vim_dev@googlegroups.com
> Subject: Re: Problem with 'hidden' and :bufdo
>
>
> On Wed, November 25, 2009 2:49 am, Craig Barkhouse wrote:
>
> > And then invoke Vim as follows in a directory that has several .c
> > files (it seems you could use any :bufdo command here, this is just
> an
> > example): vim -c "bufdo normal gg" *.c
> >
> > The problem I see is that the first and last buffers have syntax
> > highlighting, but all the intermediate buffers do not.  For example,
> > if there are 10 .c files, then only buffers 1 and 10 will have syntax
> > highlighting.
>
> When issuing :bufdo, the Syntax autocommand event is added to the
> 'eventignore' option, so that bufdo can perform faster. This is
> described at :h :bufdo
>
> If you don't like this, you could possibly set this option within the
> :bufdo command like this:
>
> vim -c "bufdo set ei=| normal gg" *.c
>
> > P.S.  I actually don't remember why I set 'hidden' in my .vimrc, it's
> > just been that way for so long!
>
> It enables you to switch buffers, even when the current buffer is
> modified. Otherwise you would have save the current buffer before
> switching to another one.
>
> regards,
> Christian

Thanks Christian (and John Beckett) for the explanation.

This still doesn't quite explain the interaction with 'hidden'.  If I comment
out the "set hidden" line in my .vimrc, reducing it to the following 2-line
.vimrc:
filetype on
syntax on

... then I do in fact get syntax highlighting for every buffer.  (Unfortunately
then 'nohidden' is set, which I don't want, for exactly the reason you pointed
out.)  Your suggested workaround does the trick.  So does this:

vim -c "set nohidden" -c "bufdo normal gg" -c "set hidden" *.c


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.308
Problem:    When using a regexp in the "\=" expression of a substitute
	     command, submatch() returns empty strings for further lines.
	     (Clockwork Jam)
Solution:   Save and restore the line number and line count when calling
	     reg_getline().
Files:     src/regexp.c


*** ../vim-7.2.307/src/regexp.c 2009-11-25 18:21:48.000000000 +0100
--- src/regexp.c 2009-11-25 19:45:07.000000000 +0100
***************
*** 6828,6833 ****
--- 6828,6835 ----
    * that contains a call to substitute() and submatch(). */
   static regmatch_T *submatch_match;
   static regmmatch_T *submatch_mmatch;
+ static linenr_T  submatch_firstlnum;
+ static linenr_T  submatch_maxline;
   #endif

   #if defined(FEAT_MODIFY_FNAME) || defined(FEAT_EVAL) || defined(PROTO)
***************
*** 6941,6947 ****
  	 }
  	 else
  	 {
- 	    linenr_T save_reg_maxline;
  	     win_T *save_reg_win;
  	     int  save_ireg_ic;

--- 6943,6948 ----
***************
*** 6953,6959 ****
  	      * vim_regexec_multi() can't be called recursively. */
  	     submatch_match = reg_match;
  	     submatch_mmatch = reg_mmatch;
! 	    save_reg_maxline = reg_maxline;
  	     save_reg_win = reg_win;
  	     save_ireg_ic = ireg_ic;
  	     can_f_submatch = TRUE;
--- 6954,6961 ----
  	      * vim_regexec_multi() can't be called recursively. */
  	     submatch_match = reg_match;
  	     submatch_mmatch = reg_mmatch;
! 	    submatch_firstlnum = reg_firstlnum;
! 	    submatch_maxline = reg_maxline;
  	     save_reg_win = reg_win;
  	     save_ireg_ic = ireg_ic;
  	     can_f_submatch = TRUE;
***************
*** 6976,6982 ****

  	     reg_match = submatch_match;
  	     reg_mmatch = submatch_mmatch;
! 	    reg_maxline = save_reg_maxline;
  	     reg_win = save_reg_win;
  	     ireg_ic = save_ireg_ic;
  	     can_f_submatch = FALSE;
--- 6978,6985 ----

  	     reg_match = submatch_match;
  	     reg_mmatch = submatch_mmatch;
! 	    reg_firstlnum = submatch_firstlnum;
! 	    reg_maxline = submatch_maxline;
  	     reg_win = save_reg_win;
  	     ireg_ic = save_ireg_ic;
  	     can_f_submatch = FALSE;
***************
*** 7212,7217 ****
--- 7215,7243 ----

   #ifdef FEAT_EVAL
   /*
+  * Call reg_getline() with the line numbers from the submatch.  If a
+  * substitute() was used the reg_maxline and other values have been
+  * overwritten.
+  */
+     static char_u *
+ reg_getline_submatch(lnum)
+     linenr_T lnum;
+ {
+     char_u *s;
+     linenr_T save_first = reg_firstlnum;
+     linenr_T save_max = reg_maxline;
+
+     reg_firstlnum = submatch_firstlnum;
+     reg_maxline = submatch_maxline;
+
+     s = reg_getline(lnum);
+
+     reg_firstlnum = save_first;
+     reg_maxline = save_max;
+     return s;
+ }
+
+ /*
    * Used for the submatch() function: get the string from the n'th submatch in
    * allocated memory.
    * Returns NULL when not in a ":s" command and for a non-existing submatch.
***************
*** 7241,7247 ****
  	     if (lnum < 0 || submatch_mmatch->endpos[no].lnum < 0)
  		 return NULL;

! 	    s = reg_getline(lnum) + submatch_mmatch->startpos[no].col;
  	     if (s == NULL)  /* anti-crash check, cannot happen? */
  		 break;
  	     if (submatch_mmatch->endpos[no].lnum == lnum)
--- 7267,7273 ----
  	     if (lnum < 0 || submatch_mmatch->endpos[no].lnum < 0)
  		 return NULL;

! 	    s = reg_getline_submatch(lnum) + submatch_mmatch->startpos[no].col;
  	     if (s == NULL)  /* anti-crash check, cannot happen? */
  		 break;
  	     if (submatch_mmatch->endpos[no].lnum == lnum)
***************
*** 7267,7273 ****
  		 ++lnum;
  		 while (lnum < submatch_mmatch->endpos[no].lnum)
  		 {
! 		    s = reg_getline(lnum++);
  		     if (round == 2)
  			 STRCPY(retval + len, s);
  		     len += (int)STRLEN(s);
--- 7293,7299 ----
  		 ++lnum;
  		 while (lnum < submatch_mmatch->endpos[no].lnum)
  		 {
! 		    s = reg_getline_submatch(lnum++);
  		     if (round == 2)
  			 STRCPY(retval + len, s);
  		     len += (int)STRLEN(s);
***************
*** 7276,7282 ****
  		     ++len;
  		 }
  		 if (round == 2)
! 		    STRNCPY(retval + len, reg_getline(lnum),
  					      submatch_mmatch->endpos[no].col);
  		 len += submatch_mmatch->endpos[no].col;
  		 if (round == 2)
--- 7302,7308 ----
  		     ++len;
  		 }
  		 if (round == 2)
! 		    STRNCPY(retval + len, reg_getline_submatch(lnum),
  					      submatch_mmatch->endpos[no].col);
  		 len += submatch_mmatch->endpos[no].col;
  		 if (round == 2)
*** ../vim-7.2.307/src/version.c 2009-11-25 18:21:48.000000000 +0100
--- src/version.c 2009-11-25 19:50:16.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     308,
   /**/

--
Engineers are always delighted to share wisdom, even in areas in which they
have no experience whatsoever.  Their logic provides them with inherent
insight into any field of expertise.  This can be a problem when dealing with
the illogical people who believe that knowledge can only be derived through
experience.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi all!

Recently I've noticed that the Vim's "make test" does not return
appropriate exit code if something goes wrong during the testing.

This makes the usual sequence "make && make test && make install"
unusable. Including such a test inside a source package makes no
sense and actually does not prevent any possible failures which
should be it's main purpose I guess.

The following comment from the Makefile is not true, as the "ALL
DONE" message appears always, regardless of the actual test result:
# If everything is alright, the final message will be "ALL DONE".

Moreover, the final result output of the test seems quite brief to
myself. From the report it's not clear which/how many tests were
actually run:

     Test results:
     ALL DONE

I've created a simple patch that fixes all the issues mentioned.
What do you think about it? Thank you for your time! And special
thanks to Bram for the Vim itself! It's really a great tool! :-)

psss...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

FAIL before:

     # make test
     ...
     test3 FAILED
     ALL DONE
     # echo $?
     0

FAIL after:

     # make test
     ...
     Test results:
     test1 PASS
     test2 PASS
     test3 FAILED
     test4 PASS
     test5 PASS
     test6 PASS
     ...
     SOME TESTS FAILED
     make: *** [nongui] Error 1
     # echo $?
     2
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi all!

Recently I've noticed that the Vim's "make test" does not return
appropriate exit code if something goes wrong during the testing.

This makes the usual sequence "make && make test && make install"
unusable. Including such a test inside a source package makes no
sense and actually does not prevent any possible failures which
should be it's main purpose I guess.

The following comment from the Makefile is not true, as the "ALL
DONE" message appears always, regardless of the actual test result:
# If everything is alright, the final message will be "ALL DONE".

Moreover, the final result output of the test seems quite brief to
myself. From the report it's not clear which/how many tests were
actually run:

     Test results:
     ALL DONE

I've created a simple patch that fixes all the issues mentioned.
What do you think about it? Thank you for your time! And special
thanks to Bram for the Vim itself! It's really a great tool! :-)

psss...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

FAIL before:

     # make test
     ...
     test3 FAILED
     ALL DONE
     # echo $?
     0

FAIL after:

     # make test
     ...
     Test results:
     test1 PASS
     test2 PASS
     test3 FAILED
     test4 PASS
     test5 PASS
     test6 PASS
     ...
     SOME TESTS FAILED
     make: *** [nongui] Error 1
     # echo $?
     2
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 25/11/09 19:52, Bram Moolenaar wrote:
>
>
> Patch 7.2.308
> Problem:    When using a regexp in the "\=" expression of a substitute
> 	    command, submatch() returns empty strings for further lines.
> 	    (Clockwork Jam)
> Solution:   Save and restore the line number and line count when calling
> 	    reg_getline().
> Files:     src/regexp.c
[...]

While watching the compile, I suddenly notice that -D_FORTIFY_SOURCE=1
appears three times in succession, in both my "Huge" version and my
"Tiny" version. This is of course not a problem, but it "looks strange".

Here are the "Compilation" lines as pasted from the ":version" or
--version output:

Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12   -DORBIT2=1 -pthread
-I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
-I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
-I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
-I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
-I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
-I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
-I/usr/include/pango-1.0 -I/usr/include/gail-1.0
-I/usr/include/freetype2 -I/usr/include/atk-1.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/libpng12     -O2 -fno-strength-reduce -Wall
-D_FORTIFY_SOURCE=1 -D_FORTIFY_SOURCE=1 -D_FORTIFY_SOURCE=1
-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
-I/usr/include/python2.6 -pthread -I/usr/include
-D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i586-linux

Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2
-fno-strength-reduce -Wall -D_FORTIFY_SOURCE=1 -D_FORTIFY_SOURCE=1
-D_FORTIFY_SOURCE=1


Best regards,
Tony.
--
McGowan's Madison Avenue Axiom:
	 If an item is advertised as "under $50", you can bet it's not
$19.95.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi

Function mzvim_apply(...) defined in src/if_mzsch.c is not used
anywhere.  I assume it can be removed, or am I missing something?

Attached patch removes it.  Removing it also allows to remove
function do_apply(...) in if_mzsch.c and struct Apply_Info.

Regards
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

> While watching the compile, I suddenly notice that -D_FORTIFY_SOURCE=1
> appears three times in succession, in both my "Huge" version and my
> "Tiny" version. This is of course not a problem, but it "looks strange".
>
> Here are the "Compilation" lines as pasted from the ":version" or
> --version output:
>
> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
> -I/usr/include/freetype2 -I/usr/include/libpng12   -DORBIT2=1 -pthread
> -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
> -I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
> -I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
> -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
> -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
> -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0
> -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
> -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
> -I/usr/include/pango-1.0 -I/usr/include/gail-1.0
> -I/usr/include/freetype2 -I/usr/include/atk-1.0
> -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
> -I/usr/include/libpng12     -O2 -fno-strength-reduce -Wall
> -D_FORTIFY_SOURCE=1 -D_FORTIFY_SOURCE=1 -D_FORTIFY_SOURCE=1
> -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -I/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
> -I/usr/include/python2.6 -pthread -I/usr/include
> -D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i586-linux
>
> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2
> -fno-strength-reduce -Wall -D_FORTIFY_SOURCE=1 -D_FORTIFY_SOURCE=1
> -D_FORTIFY_SOURCE=1
>
>
> Best regards,
> Tony.

Hi Tony

I don't see this buglet on my machine.  -D_FORTIFY_SOURCE=1
appears just once here.

Anyway, the attached patch should probably fix it.

Can you try it? You'll need to recreate the "configure" script
with autoconf.  Example:

$ cd vim7/src
$ autoconf
$ ./configure --with-feature=huge
$ make

Cheers
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 25/11/09 23:10, Dominique Pellé wrote:
>> While watching the compile, I suddenly notice that -D_FORTIFY_SOURCE=1
>> appears three times in succession, in both my "Huge" version and my
>> "Tiny" version. This is of course not a problem, but it "looks strange".
>>
>> Here are the "Compilation" lines as pasted from the ":version" or
>> --version output:
>>
>> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
>> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
>> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
>> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
>> -I/usr/include/freetype2 -I/usr/include/libpng12   -DORBIT2=1 -pthread
>> -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
>> -I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
>> -I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
>> -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
>> -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
>> -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0
>> -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
>> -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
>> -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
>> -I/usr/include/pango-1.0 -I/usr/include/gail-1.0
>> -I/usr/include/freetype2 -I/usr/include/atk-1.0
>> -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
>> -I/usr/include/libpng12     -O2 -fno-strength-reduce -Wall
>> -D_FORTIFY_SOURCE=1 -D_FORTIFY_SOURCE=1 -D_FORTIFY_SOURCE=1
>> -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING
>> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>> -I/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
>> -I/usr/include/python2.6 -pthread -I/usr/include
>> -D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i586-linux
>>
>> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2
>> -fno-strength-reduce -Wall -D_FORTIFY_SOURCE=1 -D_FORTIFY_SOURCE=1
>> -D_FORTIFY_SOURCE=1
>>
>>
>> Best regards,
>> Tony.
>
> Hi Tony
>
> I don't see this buglet on my machine.  -D_FORTIFY_SOURCE=1
> appears just once here.
>
> Anyway, the attached patch should probably fix it.
>
> Can you try it? You'll need to recreate the "configure" script
> with autoconf.  Example:
>
> $ cd vim7/src
> $ autoconf
> $ ./configure --with-feature=huge
> $ make
>
> Cheers
> -- Dominique

Must be something I did at some point in the past. Before applying your
patch, I tried "make reconfig" and the problem went away.

Here are my config arguments and compile lines now:

Tiny build (built in a shadow directory):

export CONF_OPT_X='--without-x'
export CONF_OPT_GUI='--disable-gui'
export CONF_OPT_FEAT='--with-features=tiny'
export CONF_OPT_PERL='--disable-perlinterp'
export CONF_OPT_PYTHON='--disable-pythoninterp'
export CONF_OPT_TCL='--disable-tclinterp'
export CONF_OPT_RUBY='--disable-rubyinterp'
export CONF_OPT_MZSCHEME='--disable-mzschemeinterp'
export CONF_OPT_CSCOPE='--disable-cscope'
export CONF_OPT_MULTIBYTE='--disable-multibyte'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechelynck@..."'
export CONF_OPT_NETBEANS='--disable-netbeans'
export CONF_OPT_NLS='--disable-nls'
export CONF_OPT_ACL='--disable-acl'
export CONF_OPT_GPM='--disable-gpm'
export CONF_OPT_SYSMOUSE='--disable-sysmouse'
export CONF_ARGS='--with-vim-name=vi'

gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -fno-strength-reduce -Wall
-D_FORTIFY_SOURCE=1


Huge build:

export CONF_OPT_GUI='--enable-gnome-check'
export CONF_OPT_PERL='--enable-perlinterp'
export CONF_OPT_PYTHON='--enable-pythoninterp'
#export CONF_OPT_TCL='--enable-tclinterp --with-tclsh=tclsh8.5'
export CONF_OPT_TCL='--enable-tclinterp'
export CONF_OPT_RUBY='--enable-rubyinterp'
export CONF_OPT_MZSCHEME='--disable-mzschemeinterp'
#export CONF_OPT_PLTHOME='--with-plthome=/usr/local/plt'
export CONF_OPT_CSCOPE='--enable-cscope'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_FEAT='--with-features=huge'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechelynck@..."'
#
# need to patch feature.h
# to disable +tag_old_static: comment out:
# # define FEAT_TAG_OLDSTATIC
# at line 360 (or about)
# to enable +xterm_save: uncomment:
# /* #define FEAT_XTERM_SAVE */
# at line 831 (or about)
#
export CONF_ARGS=''

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12   -DORBIT2=1 -pthread
-I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
-I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
-I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
-I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
-I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
-I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
-I/usr/include/pango-1.0 -I/usr/include/gail-1.0
-I/usr/include/freetype2 -I/usr/include/atk-1.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/libpng12     -O2 -fno-strength-reduce -Wall
-D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV
-DDEBUGGING  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
-I/usr/include/python2.6 -pthread -I/usr/include
-D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i586-linux



Best regards,
Tony.
--
I can't understand it.  I can't even understand the people who can
understand it.
		 -- Queen Juliana of the Netherlands.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hey all,

I was wondering if there was some sort of known/decent VCS repo
(Preferably hg or git, SVN if the first two aren't doable and...I
can't use CVS) for Vim that's pretty up-to-date as far as patches and
such. The only thing i need to qualify this with is that i know about
the vim_extended repo at repo.or.cz, but it's branch system seems a
bit odd.

Thanks
JD

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

2009/11/26 JD <jdhore1@...>:
> I was wondering if there was some sort of known/decent VCS repo
> (Preferably hg or git, SVN if the first two aren't doable and...I
> can't use CVS) for Vim that's pretty up-to-date as far as patches and
> such. The only thing i need to qualify this with is that i know about
> the vim_extended repo at repo.or.cz, but it's branch system seems a
> bit odd.

http://repo.or.cz/w/vim_mainline.git

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Hi JD!

-------- Original-Nachricht --------
> Datum: Thu, 26 Nov 2009 00:16:28 -0800 (PST)
> Von: JD <jdhore1@...>
> An: vim_dev <vim_dev@googlegroups.com>
> Betreff: Vim VCS repo

> Hey all,
>
> I was wondering if there was some sort of known/decent VCS repo
> (Preferably hg or git, SVN if the first two aren't doable and...I
> can't use CVS) for Vim that's pretty up-to-date as far as patches and
> such. The only thing i need to qualify this with is that i know about
> the vim_extended repo at repo.or.cz, but it's branch system seems a
> bit odd.
> [...]

If you need only the official patches you can use vim_mainline at repo.or.cz
Just do: git clone git://repo.or.cz/vim_mainline.git


HTH,
Dennis Benzinger

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Thursday 26 November 2009 02:16:28 am JD wrote:

> I was wondering if there was some sort of known/decent VCS
>  repo (Preferably hg or git, SVN if the first two aren't
>  doable and...I can't use CVS) for Vim that's pretty
>  up-to-date as far as patches and such. The only thing i need
>  to qualify this with is that i know about the vim_extended
>  repo at repo.or.cz, but it's branch system seems a bit odd.
>

odd schmod

+1 markus' git repo

of course i can't claim to be objective -- i am a fan of his
relatiive number patch -- but if i can figure it out and use it,
so can you

sc

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Wed, 25 Nov 2009 19:52:16 +0100, Bram Moolenaar wrote:

> Solution:   Save and restore the line number and line count when calling
> 	    reg_getline().

Using Borland C++, I get the following warnings:

Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
.\regexp.c:
Warning W8065 .\regexp.c 7270: Call to function 'reg_getline_submatch'
with no prototype in function reg_submatch
Warning W8065 .\regexp.c 7296: Call to function 'reg_getline_submatch'
with no prototype in function reg_submatch
Warning W8065 .\regexp.c 7306: Call to function 'reg_getline_submatch'
with no prototype in function reg_submatch
--
Patrick Texier

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

It seems the 'Sender' header has gone missing from posts that are sent to me. It
used to always be included, with the list address as the sender, and today it
started no longer being included. My email filters now don't work.

Anyone know anything about this? A weird inexplicable Google Groups thing?
Something we could/should follow up? Something our list admins have changed?

One of these days I'll get a bit more active on the list again...just too much
on
this year to keep abreast of it all on the whole, unfortunately.

Ben.





--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

> I applied Václav ¿milauer's 2007 breakindent patch to vim trunk. After a
minimal amount of tweaking I got it to compile (see attached patch), but there
is a weird bug when breakindent and linebreak are both set.

I cannot verify this problem but I stopped patching vim at 7.2-79
because I noticed that a patch failed to be applied when the
breakindent patch was included. Which version do you use? Maybe a
patch introduced some sort of inconsistency?

I personally really wish this patch/feature were included in vim. I
personally haven't had any problems with it since I first applied it
-- shortly after 7.2 was released.

Regards,
Thomas.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Patrick Texier wrote:

> On Wed, 25 Nov 2009 19:52:16 +0100, Bram Moolenaar wrote:
>
> > Solution:   Save and restore the line number and line count when calling
> > 	    reg_getline().
>
> Using Borland C++, I get the following warnings:
>
> Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
> .\regexp.c:
> Warning W8065 .\regexp.c 7270: Call to function 'reg_getline_submatch'
> with no prototype in function reg_submatch
> Warning W8065 .\regexp.c 7296: Call to function 'reg_getline_submatch'
> with no prototype in function reg_submatch
> Warning W8065 .\regexp.c 7306: Call to function 'reg_getline_submatch'
> with no prototype in function reg_submatch

Thanks for the report.  I'll make a patch.

--
While it's true that many normal people whould prefer not to _date_ an
engineer, most normal people harbor an intense desire to _mate_ with them,
thus producing engineerlike children who will have high-paying jobs long
before losing their virginity.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Patch 7.2.309 (after 7.2.308)
Problem:    Warning for missing function prototype. (Patrick Texier)
Solution:   Add the prototype.
Files:     src/regexp.c


*** ../vim-7.2.308/src/regexp.c 2009-11-25 19:51:56.000000000 +0100
--- src/regexp.c 2009-11-26 20:39:18.000000000 +0100
***************
*** 7214,7219 ****
--- 7214,7221 ----
   }

   #ifdef FEAT_EVAL
+ static char_u *reg_getline_submatch __ARGS((linenr_T lnum));
+
   /*
    * Call reg_getline() with the line numbers from the submatch.  If a
    * substitute() was used the reg_maxline and other values have been
*** ../vim-7.2.308/src/version.c 2009-11-25 19:51:56.000000000 +0100
--- src/version.c 2009-11-26 20:40:11.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     309,
   /**/

--
Female engineers become irresistible at the age of consent and remain that
way until about thirty minutes after their clinical death.  Longer if it's a
warm day.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Fri, Nov 27, 2009 at 04:06:32AM +1100, Ben Schmidt wrote:

>It seems the 'Sender' header has gone missing from posts that are sent to me.
It
>used to always be included, with the list address as the sender, and today it
>started no longer being included. My email filters now don't work.
>
>Anyone know anything about this? A weird inexplicable Google Groups thing?
>Something we could/should follow up? Something our list admins have changed?

Well, something weird definitely happened, since I seem to have been
magically resubscribed to this list after several years away.

David

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php