Hello,

would it be OK to set some subversion properties for ignoring certain files?

This is my suggestion:
     svn propset svn:ignore "$(for i in objects tags vim; do echo $i; done)" src
     svn propset svn:ignore "$(for i in config.cache config.h config.log
config.mk config.status link.log link.sed osdef.h pathdef.c; do echo $i; done)"
src/auto
     svn propset svn:ignore "*.mo" src/po
     svn propset svn:ignore "xxd" src/xxd

Markus

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

Dominique Pelle wrote:

> >  > Using Vim-7.1.266 and cscope-15.6, I notice that
> >  > my /tmp/ directory gets cluttered with many temporary
> >  > directories /tmp/cscope.*/   (where * is a PID).
> [...]
> >  > I attach a patch which fixes it.
> >
> >  A few hints to improve this:
> >  - Call alarm(0) to stop the alarm when cscope exits quickly.
>
> OK, done.
>
> >  - The default signal handler for SIGALRM is to ignore it.  This needs to
> >   be restored.
>
> OK, done.
>
> >  - sigaction() is not always available.  Use signal().  See os_unix.c for
> >   examples.
>
> I actually initially implemented it with signal() rather than sigaction().
> It worked fine as long as cscope exits (unblocking waitpid())
> but if cscope does not exit, SIGALRM did not unblock waitpid!?
> If put a printf() in the signal handler, I could see the timeout happening,
> yet it would not unblock waitpid(). With sigaction() on the other
> hand it works fine, SIGALRM unblocks waitpid().  I've tested in normal
> case when cscope exits normally (i.e. before timer expires) as well as
> when cscope does not exits itself (i.e. when timer expires) which I
> simulated by temporarily commenting the line that sends the "q"
> command to cscope).

This must be because signal() works like sigaction() with the SA_RESTART
flag.

> So everything works fine on my machine (Linux x86) with the
> attached patch. But I cannot test on machines where HAVE_SIGACTION
> is not defined. Hopefully you have a machine to test?

Nope.

> I have to say that setting up a timeout for waitpid() in a portable way
> is a tad complicated and ugly: 3 different ways for various flavors of
> Unix + another way for non Unix.  I tried to make it as portable
> as possible. If SIGALRM is not defined, it does not used timeout.
>
> Perhaps the code using sigvec() is not needed?  i.e. either use
> sigaction() on Linux or signal() on other Unix flavors.  That would
> simplify a bit but I don't have the machine to test it.

Why don't we use two methods: When sigaction() is available use that, as
in your first version of the patch.  When it is not available then make
a loop that sleeps for a very short moment (e.g., 50ms, using
mch_delay()) and checks if cscope still runs.  Break the loop after 2
seconds or when cscope has quit.  That should be very portable.

See the proposed patch below, please try it out.  I removed SA_NOMASK, my
system doesn't have it.  I think SA_NODEFER is used instead.  But can we
leave this one out completely?

> >  > PS: different topic: file src/testdir/test42.ok is still corrupted in CVS
> >
> >  Hmm, I thought I fixed it with:
> >         cvs ... admin -kb src/testdir/test42.ok
> >  What else can I do?
>
> Revision 1.2 looks corrupted somehow.  Whether it was because of
> CVS -kb option, I'm not sure.  In any case, since it's a binary file, it
> was better to set -kb option.  How about checking it out and commiting
> the pristine version again as revision 1.3?

Ah, the copy of the file was already corrupted locally.  Must have been
because "patch" failed on this file.  Sorry for blaming CVS.


*** ../vim-7.1.266/src/if_cscope.c Fri Sep 14 19:56:18 2007
--- src/if_cscope.c Sat Mar  1 14:11:49 2008
***************
*** 2096,2101 ****
--- 2096,2113 ----
       return CSCOPE_SUCCESS;
   }

+ #if defined(UNIX) && defined(SIGALRM)
+ /*
+  * Used to catch and ignore SIGALRM below.
+  */
+ /* ARGSUSED */
+     static RETSIGTYPE
+ sig_handler SIGDEFARG(sigarg)
+ {
+     /* do nothing */
+     SIGRETURN;
+ }
+ #endif

   /*
    * PRIVATE: cs_release_csp
***************
*** 2108,2116 ****
       int i;
       int freefnpp;
   {
- #if defined(UNIX)
-     int pstat;
- #else
       /*
        * Trying to exit normally (not sure whether it is fit to UNIX cscope
        */
--- 2120,2125 ----
***************
*** 2119,2124 ****
--- 2128,2177 ----
  	 (void)fputs("q\n", csinfo[i].to_fp);
  	 (void)fflush(csinfo[i].to_fp);
       }
+ #if defined(UNIX)
+     {
+  int pstat;
+  pid_t pid;
+
+ # if defined(HAVE_SIGACTION)
+  struct sigaction sa, old;
+
+         /* Use sigaction() to limit the waiting time to two seconds. */
+  sa.sa_handler = sig_handler;
+  sa.sa_flags = SA_NODEFER;
+  sigaction(SIGALRM, &sa, &old);
+  alarm(2); /* 2 sec timeout */
+
+  /* Block until cscope exits or until timer expires */
+  pid = waitpid(csinfo[i].pid, &pstat, 0);
+
+  /* cancel pending alarm if still there and restore signal */
+  alarm(0);
+  sigaction(SIGALRM, &old, NULL);
+ # else
+  int waited;
+
+  /* Can't use sigaction(), loop for two seconds. */
+  for (waited = 0; waited < 40; ++waited)
+  {
+ 	    pid = waitpid(csinfo[i].pid, &pstat, WNOHANG);
+ 	    if (pid > 0)
+ 	 break;
+ 	    mch_delay(50); /* sleep 50 ms */
+  }
+ # endif
+  /*
+ 	 * If the cscope process is still running: kill it.
+ 	 * Safety check: If the PID would be zero here, the entire X session
+ 	 * would be killed.  -1 and 1 are dangerous as well.
+ 	 */
+  if (pid < 0 && csinfo[i].pid > 1)
+  {
+ 	    kill(csinfo[i].pid, SIGTERM);
+ 	    (void)waitpid(csinfo[i].pid, &pstat, 0);
+  }
+     }
+ #else  /* !UNIX */
       if (csinfo[i].hProc != NULL)
       {
  	 /* Give cscope a chance to exit normally */
***************
*** 2133,2150 ****
       if (csinfo[i].to_fp != NULL)
  	 (void)fclose(csinfo[i].to_fp);

-     /*
-      * Safety check: If the PID would be zero here, the entire X session would
-      * be killed.  -1 and 1 are dangerous as well.
-      */
- #if defined(UNIX)
-     if (csinfo[i].pid > 1)
-     {
-  kill(csinfo[i].pid, SIGTERM);
-  (void)waitpid(csinfo[i].pid, &pstat, 0);
-     }
- #endif
-
       if (freefnpp)
       {
  	 vim_free(csinfo[i].fname);
--- 2186,2191 ----



--
hundred-and-one symptoms of being an internet addict:
69. Yahoo welcomes you with your own start page

  /// 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 Jan 3, 4:30 pm, "Matt Wozniski" <m...@...> wrote:
> On Dec 20, 2007 11:44 PM, Matt Wozniski <m...@...> wrote:
>
>
>
> > ...
> > So, I've reworked the patch to support, in addition to the
> > xterm-compatible palette, Eterm and Konsole's palettes.  Which palette
> > is used for the matching is controlled by a new option, 'termpalette'
> > (short name 'tpal').  If the option is unset, I default to an xterm
> > palette, but display a warning that color matching might be
> > unaccurate.
>
> > For those interested, a comparison between the 3 palettes that I've
> > found so far can be seen here:
> >http://www.cs.drexel.edu/~mjw452/256.html
>
> > So, I'd appreciate comments.  The reworked patch can be found:
> >http://www.cs.drexel.edu/~mjw452/ctermrgb-src.diff(source, against SVN)
> >http://www.cs.drexel.edu/~mjw452/ctermrgb-runtime.diff(runtime,
> > against latest AAP)
>
> > And, the two modified colorschemes for testing are available at
> >http://www.cs.drexel.edu/~mjw452/brookstream-rgb.vimand
> >http://www.cs.drexel.edu/~mjw452/autumnleaf-rgb.vim; it should be
> > trivial to modify other colorschemes in this way.
>
> > Please comment!
> > ~Matt
>
> Has anyone tried this out?  I would love to have some feedback on
> this, since I think that it would be a really nice feature to make
> life easier for colorscheme authors!
>
> ~Matt

It works well for me (after editing my system colorschemes).  A few
things I noticed:

  * The new code be wrapped in an #ifdef FEAT_SYN_HL . Certain of the
prototypes are, which means the code doesn't compile correctly when
this feature is disabled.
  * hexhex2nr in charset.c should be defined whenever the patch is
included (as noted in a comment).  Adding defined(FEAT_SYN_HL) to the
list of conditions should work.

  * As discussed on IRC, colorschemes will have to define colors
differently depending on whether one is in 16- or 256-color mode.  If
hex colors aren't going to be supported for 16-color mode (and I think
your arguments here are convincing), maybe there should be separate
hctermfg/hctermbg arguments for high-color schemes.  This would
require less work on the part of colorscheme authors to support both
kinds of terminals (they could keep ctermfg=14 and add a separate
hctermfg=#ff33ff to support high-color terms).

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

On Sat, Mar 1, 2008 at 2:04 PM, Bram Moolenaar <Bram@...> wrote:

>  Dominique Pelle wrote:
(...snip...)
>  > I have to say that setting up a timeout for waitpid() in a portable way
>  > is a tad complicated and ugly: 3 different ways for various flavors of
>  > Unix + another way for non Unix.  I tried to make it as portable
>  > as possible. If SIGALRM is not defined, it does not used timeout.
>  >
>  > Perhaps the code using sigvec() is not needed?  i.e. either use
>  > sigaction() on Linux or signal() on other Unix flavors.  That would
>  > simplify a bit but I don't have the machine to test it.
>
>  Why don't we use two methods: When sigaction() is available use that, as
>  in your first version of the patch.  When it is not available then make
>  a loop that sleeps for a very short moment (e.g., 50ms, using
>  mch_delay()) and checks if cscope still runs.  Break the loop after 2
>  seconds or when cscope has quit.  That should be very portable.
>
>  See the proposed patch below, please try it out.  I removed SA_NOMASK, my
>  system doesn't have it.  I think SA_NODEFER is used instead.  But can we
>  leave this one out completely?


Yes, it looks simpler. Using asynchronous SIGALRM is
better of course. But when it's not possible, polling is a
pragmatic and portable fallback.

I can't try it because I'm away until next week.  I see 2 refinements:

- If waitpid() returns -1 (error), the loop will currently retry 40 times.
   I think this is a useless delay of 2 seconds.  It's better
   to break the loop immediately if waitpid returns -1.
   In other words:

   when pid == 0,  sleep 50ms and retry
   when pid > 0  exit loop (normal case when cscope finishes)
   when pid < 0  error, break loop and revert to kill cscope.

- I think with the proposed patch, Vim will almost always
   wait at least 50ms, because cscope did yet get a chance to
   be scheduled before Vim calls the first unblocking waitpid().  So first
   call to waitpid() will always return 0, and Vim will then always
   call mch_delay(50) at least once (giving then a chance for cscope
   to be scheduled) and second call to waitpid() is then likely to
   return > 0. This may always add a small unfortunate delay
   (but no much) when exiting Vim. If we add a sleep(0) before
   first call to waitpid() to yield the CPU, it will give more chance
   for cscope process to grab the CPU and thus respond to the
   q command before Vim calls waitpid() for the first time. So the
   first call to waitpid() has more chance to return with pid > 0,
   hence possibly avoiding a sleep of 50ms. Of course they is
   no guarantee, but it can only help I think.

Sorry, I can't provide a patch with this as I am away until
next week and I only have a webmail access.

>  > >  > PS: different topic: file src/testdir/test42.ok is still corrupted in
CVS
>  > >
>  > >  Hmm, I thought I fixed it with:
>  > >         cvs ... admin -kb src/testdir/test42.ok
>  > >  What else can I do?
>  >
>  > Revision 1.2 looks corrupted somehow.  Whether it was because of
>  > CVS -kb option, I'm not sure.  In any case, since it's a binary file, it
>  > was better to set -kb option.  How about checking it out and commiting
>  > the pristine version again as revision 1.3?
>
>  Ah, the copy of the file was already corrupted locally.  Must have been
>  because "patch" failed on this file.  Sorry for blaming CVS.

Thanks, I will check this when I'm back.

Cheers
-- Dominique

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

Dominique Pelle wrote:

> (...snip...)
> >  > I have to say that setting up a timeout for waitpid() in a portable way
> >  > is a tad complicated and ugly: 3 different ways for various flavors of
> >  > Unix + another way for non Unix.  I tried to make it as portable
> >  > as possible. If SIGALRM is not defined, it does not used timeout.
> >  >
> >  > Perhaps the code using sigvec() is not needed?  i.e. either use
> >  > sigaction() on Linux or signal() on other Unix flavors.  That would
> >  > simplify a bit but I don't have the machine to test it.
> >
> >  Why don't we use two methods: When sigaction() is available use that, as
> >  in your first version of the patch.  When it is not available then make
> >  a loop that sleeps for a very short moment (e.g., 50ms, using
> >  mch_delay()) and checks if cscope still runs.  Break the loop after 2
> >  seconds or when cscope has quit.  That should be very portable.
> >
> >  See the proposed patch below, please try it out.  I removed SA_NOMASK, my
> >  system doesn't have it.  I think SA_NODEFER is used instead.  But can we
> >  leave this one out completely?
>
>
> Yes, it looks simpler. Using asynchronous SIGALRM is
> better of course. But when it's not possible, polling is a
> pragmatic and portable fallback.
>
> I can't try it because I'm away until next week.  I see 2 refinements:
>
> - If waitpid() returns -1 (error), the loop will currently retry 40 times.
>   I think this is a useless delay of 2 seconds.  It's better
>   to break the loop immediately if waitpid returns -1.
>   In other words:
>
>   when pid == 0,  sleep 50ms and retry
>   when pid > 0  exit loop (normal case when cscope finishes)
>   when pid < 0  error, break loop and revert to kill cscope.
>
> - I think with the proposed patch, Vim will almost always
>   wait at least 50ms, because cscope did yet get a chance to
>   be scheduled before Vim calls the first unblocking waitpid().  So first
>   call to waitpid() will always return 0, and Vim will then always
>   call mch_delay(50) at least once (giving then a chance for cscope
>   to be scheduled) and second call to waitpid() is then likely to
>   return > 0. This may always add a small unfortunate delay
>   (but no much) when exiting Vim. If we add a sleep(0) before
>   first call to waitpid() to yield the CPU, it will give more chance
>   for cscope process to grab the CPU and thus respond to the
>   q command before Vim calls waitpid() for the first time. So the
>   first call to waitpid() has more chance to return with pid > 0,
>   hence possibly avoiding a sleep of 50ms. Of course they is
>   no guarantee, but it can only help I think.
>
> Sorry, I can't provide a patch with this as I am away until
> next week and I only have a webmail access.

I've included your suggestions.  New patch:


*** ../vim-7.1.266/src/if_cscope.c Fri Sep 14 19:56:18 2007
--- src/if_cscope.c Sun Mar  2 13:31:43 2008
***************
*** 2096,2101 ****
--- 2096,2113 ----
       return CSCOPE_SUCCESS;
   }

+ #if defined(UNIX) && defined(SIGALRM)
+ /*
+  * Used to catch and ignore SIGALRM below.
+  */
+ /* ARGSUSED */
+     static RETSIGTYPE
+ sig_handler SIGDEFARG(sigarg)
+ {
+     /* do nothing */
+     SIGRETURN;
+ }
+ #endif

   /*
    * PRIVATE: cs_release_csp
***************
*** 2108,2116 ****
       int i;
       int freefnpp;
   {
- #if defined(UNIX)
-     int pstat;
- #else
       /*
        * Trying to exit normally (not sure whether it is fit to UNIX cscope
        */
--- 2120,2125 ----
***************
*** 2119,2124 ****
--- 2128,2179 ----
  	 (void)fputs("q\n", csinfo[i].to_fp);
  	 (void)fflush(csinfo[i].to_fp);
       }
+ #if defined(UNIX)
+     {
+  int pstat;
+  pid_t pid;
+
+ # if defined(HAVE_SIGACTION)
+  struct sigaction sa, old;
+
+         /* Use sigaction() to limit the waiting time to two seconds. */
+  sa.sa_handler = sig_handler;
+  sa.sa_flags = SA_NODEFER;
+  sigaction(SIGALRM, &sa, &old);
+  alarm(2); /* 2 sec timeout */
+
+  /* Block until cscope exits or until timer expires */
+  pid = waitpid(csinfo[i].pid, &pstat, 0);
+
+  /* cancel pending alarm if still there and restore signal */
+  alarm(0);
+  sigaction(SIGALRM, &old, NULL);
+ # else
+  int waited;
+
+  /* Can't use sigaction(), loop for two seconds.  First yield the CPU
+ 	 * to give cscope a chance to exit quickly. */
+  sleep(0);
+  for (waited = 0; waited < 40; ++waited)
+  {
+ 	    pid = waitpid(csinfo[i].pid, &pstat, WNOHANG);
+ 	    if (pid != 0)
+ 	 break;  /* break unless the process is still running */
+ 	    mch_delay(50); /* sleep 50 ms */
+  }
+ # endif
+  /*
+ 	 * If the cscope process is still running: kill it.
+ 	 * Safety check: If the PID would be zero here, the entire X session
+ 	 * would be killed.  -1 and 1 are dangerous as well.
+ 	 */
+  if (pid < 0 && csinfo[i].pid > 1)
+  {
+ 	    kill(csinfo[i].pid, SIGTERM);
+ 	    (void)waitpid(csinfo[i].pid, &pstat, 0);
+  }
+     }
+ #else  /* !UNIX */
       if (csinfo[i].hProc != NULL)
       {
  	 /* Give cscope a chance to exit normally */
***************
*** 2133,2150 ****
       if (csinfo[i].to_fp != NULL)
  	 (void)fclose(csinfo[i].to_fp);

-     /*
-      * Safety check: If the PID would be zero here, the entire X session would
-      * be killed.  -1 and 1 are dangerous as well.
-      */
- #if defined(UNIX)
-     if (csinfo[i].pid > 1)
-     {
-  kill(csinfo[i].pid, SIGTERM);
-  (void)waitpid(csinfo[i].pid, &pstat, 0);
-     }
- #endif
-
       if (freefnpp)
       {
  	 vim_free(csinfo[i].fname);
--- 2188,2193 ----


--
Proof techniques #2: Proof by Oddity.
	 SAMPLE: To prove that horses have an infinite number of legs.
(1) Horses have an even number of legs.
(2) They have two legs in back and fore legs in front.
(3) This makes a total of six legs, which certainly is an odd number of
     legs for a horse.
(4) But the only number that is both odd and even is infinity.
(5) Therefore, horses must have an infinite number of legs.

  /// 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
-~----------~----~----~----~------~----~------~--~---

==buffer==
foo
bar
foo
=========

:3|.m?foo?

In versions prior to 7.1.025, this effectively swapped the 2nd and 3rd
line.
Since patch 7.1.025 this does nothing, apparently because the
pattern does match in the 3rd instead of the 1st line.

The patch is very small and here it goes :


Patch 7.1.025
Problem:    search() and searchpos() don't use match under cursor at
start of
	     line when using 'bc' flags. (Viktor Kojouharov)
Solution:   Don't go to the previous line when the 'c' flag is
present.
	     Also fix that "j" doesn't move the cursor to the right column.
Files:     src/eval.c, src/search.c


*** ../vim-7.1.024/src/eval.c Tue Jun 19 17:23:46 2007
--- src/eval.c Thu Jul  5 21:16:31 2007
***************
*** 13925,13930 ****
--- 13925,13932 ----
       /* If 'n' flag is used: restore cursor position. */
       if (flags & SP_NOMOVE)
  	 curwin->w_cursor = save_cursor;
+     else
+  curwin->w_set_curswant = TRUE;
   theend:
       p_ws = save_p_ws;

*** ../vim-7.1.024/src/search.c Tue Jul 10 13:07:08 2007
--- src/search.c Thu Jul  5 21:18:55 2007
***************
*** 573,580 ****
  	 /*
  	  * Start searching in current line, unless searching backwards and
  	  * we're in column 0.
  	  */
!  if (dir == BACKWARD && start_pos.col == 0)
  	 {
  	     lnum = pos->lnum - 1;
  	     at_first_line = FALSE;
--- 573,584 ----
  	 /*
  	  * Start searching in current line, unless searching backwards and
  	  * we're in column 0.
+ 	 * If we are searching backwards, in column 0, and not including
the
+ 	 * current position, gain some efficiency by skipping back a line.
+ 	 * Otherwise begin the search in the current line.
  	  */
!  if (dir == BACKWARD && start_pos.col == 0
! 					     && (options & SEARCH_START) == 0)
  	 {
  	     lnum = pos->lnum - 1;
  	     at_first_line = FALSE;
*** ../vim-7.1.024/src/version.c Tue Jul 10 13:07:08 2007
--- src/version.c Tue Jul 10 13:26:13 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     25,
   /**/

--


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

A.Politz wrote:

> ==buffer==
> foo
> bar
> foo
> =========
>
> :3|.m?foo?
>
> In versions prior to 7.1.025, this effectively swapped the 2nd and 3rd
> line.
> Since patch 7.1.025 this does nothing, apparently because the
> pattern does match in the 3rd instead of the 1st line.

Hmm, why did the code for Ex addresses use the SEARCH_START flag?  Not
clear to me at all.  If I remove it the search appears to work properly:

*** ../vim-7.1.266/src/ex_docmd.c Tue Feb 26 21:29:06 2008
--- src/ex_docmd.c Sun Mar  2 20:50:43 2008
***************
*** 3932,3939 ****
  				 curwin->w_cursor.col = 0;
  			     searchcmdlen = 0;
  			     if (!do_search(NULL, c, cmd, 1L,
! 				 SEARCH_HIS + SEARCH_MSG + SEARCH_START,
! 				 NULL))
  			     {
  				 curwin->w_cursor = pos;
  				 cmd = NULL;
--- 3932,3938 ----
  				 curwin->w_cursor.col = 0;
  			     searchcmdlen = 0;
  			     if (!do_search(NULL, c, cmd, 1L,
! 					       SEARCH_HIS | SEARCH_MSG, NULL))
  			     {
  				 curwin->w_cursor = pos;
  				 cmd = NULL;
***************
*** 3980,3987 ****
  				 pos.col = 0;
  			     if (searchit(curwin, curbuf, &pos,
  					 *cmd == '?' ? BACKWARD : FORWARD,
! 				 (char_u *)"", 1L,
! 				 SEARCH_MSG + SEARCH_START,
  						 i, (linenr_T)0, NULL) != FAIL)
  				 lnum = pos.lnum;
  			     else
--- 3979,3985 ----
  				 pos.col = 0;
  			     if (searchit(curwin, curbuf, &pos,
  					 *cmd == '?' ? BACKWARD : FORWARD,
! 				 (char_u *)"", 1L, SEARCH_MSG,
  						 i, (linenr_T)0, NULL) != FAIL)
  				 lnum = pos.lnum;
  			     else
*** ../vim-7.1.266/src/search.c Wed Feb 20 13:41:14 2008
--- src/search.c Sun Mar  2 20:49:59 2008
***************
*** 538,544 ****
  	 return FAIL;
       }

!     if (options & SEARCH_START)
  	 extra_col = 0;
   #ifdef FEAT_MBYTE
       /* Watch out for the "col" being MAXCOL - 2, used in a closed fold. */
--- 538,544 ----
  	 return FAIL;
       }

!     if ((options & SEARCH_START) || pos->col == MAXCOL)
  	 extra_col = 0;
   #ifdef FEAT_MBYTE
       /* Watch out for the "col" being MAXCOL - 2, used in a closed fold. */


--
hundred-and-one symptoms of being an internet addict:
83. Batteries in the TV remote now last for months.

  /// 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
-~----------~----~----~----~------~----~------~--~---

After loading a session (using e.g. "gvim -S") the cursor line always
finds itself 'scrolloff' lines below the top of its window, even if it
is the last line of the file. Shouldn't the window be scrolled down, so
that no "tilde" lines be displayed if the file is longer than the window?

My current session script is at
http://users.skynet.be/antoine.mechelynck/other/Session.vim -- it is a
"real" case, not a "minimal" case.


Best regards,
Tony.
--
FATHER:    Who are you?
PRINCE:    I'm ... your son ...
FATHER:    Not you.
LAUNCELOT: I'm ... er ... Sir Launcelot, sir.
                   "Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD

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

Hello,

I executed the vim configure for my cross compiling for NetBSD with
all your patches (configure & configure.in). Configure completes
properly. But by default, it takes my local GCC for making the target
binary when i "make". And it generates only vim.exe file. Removing
".EXE" extension type from Makefile also didn't work out. It still
generates the vim.exe.
So in Makefile i just replaced "CC=GCC" with my NetBSD cross compile
gcc path. Now it list out lot of errors when i "make".

So exported the CC with my cross compile gcc path, in environment.
making configure itself gives the following error:

"checking for C compiler default output file name... configure: error:
C compiler
 cannot create executables
See `config.log' for more details."

In this case, how should i use my cross compile gcc? Whether should be
used in config.mk or should be exported like I said? But both the
cases are not successful. What should i do now?

Could you please give me some idea?

Thanks & Regards,
Gnani

On Feb 29, 10:36 pm, Tony Mechelynck <antoine.mechely...@...>
wrote:
> gnani wrote:
> > I read this link and your replies. I'm trying to make vim binary for
> > NetBSD-3.0 from CYGWIN_NT-5.0 system. So, i tried cross compiling the
> > vim. It was not successful initially. Then I tried with your patches
> > for configure.in and configure scripts. I get the following error
> > messages while configuring.
> > -------
> > checking for strip... strip... configure: error: failed to compile
> > test program
> > configure: error: cannot compile a simple program, check CC and
> > CFLAGS
> >   (cross compiling doesn't work)
> > ------
> > This is what my configure parameters and I executed like below.
>
> > ./configure --build=i686-pc-cygwin --host=i386-unknown-netbsdelf3.0 --
> > target=i386-unknown-netbsdelf3.0 --with-tlib=ncurses
>
> > but I haven't set any other environment variables like you said
> > already.
>
> > If you could give me some solution to get my expected binary, it will
> > be great helpful?
> > Thanks alot in advance.
>
> > Regards,
> > Gnani.
>
> The way it is distributed with Vim, configure runs by making some assumptions
> about the system upon which it is installed, and testing them by compiling
> test programs. Whether each test program can be compiled, linked, and/or run,
> and what the exit return is in each case, gives it the data it needs. However,
> this means that configure must be used on the same system where the compiled
> Vim will ultimately be run.
>
> If you want to cross-compile Vim, you will have to tell configure explicitly
> everything it needs to know about the target system -- it cannot test it by
> running test programs. This means that you will have to patch the configure
> script so that it doesn't try to run test programs on the target system, _and_
> give it a lot of info -- all the info it would normally have found out by
> running the tests you're suppressing.
>
> Alternately, you can either:
>
> a) compile on the target system itself, using configure as implicitly called
> by the top-level Makefile, if it is a Unix-like system. That Makefile calls
> src/Makefile, which has some notes about BSD, NetBSD and FreeBSD, so I suppose
> you can use it without too many changes if you can afford to compile on NetBSD
> for NetBSD.
>
> b) write a different makefile in the src subdirectory, like the several ones
> which have been written for Windows compilers, and give it by hand (e.g. by
> environment variables) all the installation-dependent info they need.
>
> Best regards,
> Tony.
> --
> The use of COBOL cripples the mind; its teaching should, therefore, be
> regarded as a criminal offense.
>                 -- E. W. Dijkstra
> Issuing dogmatic statements, even anathemata, about all and sundry programming
> languages, as if one were the Pope of Programming, is a far worse
> mind-crippling criminal offense. We've got enough trouble with one Pope as it
> is.
>                  -- A. J. Mechelynck- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

gnani wrote:
> Hello,
>
> I executed the vim configure for my cross compiling for NetBSD with
> all your patches (configure&  configure.in). Configure completes
> properly. But by default, it takes my local GCC for making the target
> binary when i "make". And it generates only vim.exe file. Removing
> ".EXE" extension type from Makefile also didn't work out. It still
> generates the vim.exe.
> So in Makefile i just replaced "CC=GCC" with my NetBSD cross compile
> gcc path. Now it list out lot of errors when i "make".
>
> So exported the CC with my cross compile gcc path, in environment.
> making configure itself gives the following error:
>
> "checking for C compiler default output file name... configure: error:
> C compiler
>   cannot create executables
> See `config.log' for more details."
>
> In this case, how should i use my cross compile gcc? Whether should be
> used in config.mk or should be exported like I said? But both the
> cases are not successful. What should i do now?
>
> Could you please give me some idea?
>
> Thanks&  Regards,
> Gnani

You will probably have to modify the configure some more, so that:
- configure should never try to run gcc (neither the Cygwin-unix one,
the Cygwin-Windows cross-compiler, nor the Cygwin-BSD cross-compiler).
The only reason configure would try to run gcc is to check what kind of
software is installed on the target system (where the vim you'll compile
will have to run), but of course it cannopt run BSD programs, so any
such attempt is pointless.
- configure should also not try to check for the presence of software
such as include files or libraries, etc., because they could quite well
be present on the target system and not on the source system, or
vice-versa, or present in both but at a different place in the directory
tree, or with a different version. Here again, such checks are pointless
for a cross-compiler, unless you can install a mirror image of the
target system "chroot" on the source system. But in that case you may
want to replace the target gcc (and maybe also the target perl etc.) by
something like

	 #!/bin/sh
	 echo 'Error: trying to run software on the wrong machine'
	 return 255

- You will have to set up all the defines (HAVE_something etc.)
according to how the software works on your BSD system. You may have to
extensively edit auto/config.mk (or something) by hand after running
configure (or checking what it would do) to set up the defines
corresponding to your --with-features=something, --enable-xxxxinterp, etc.

Do you really not have a system running the same software as the target
system, where you could run configure and make? IMHO it would be
infinitely less problematic than trying to compile NetBSD software on a
Cygwin (or Windows) machine.


Best regards,
Tony.
--
God is a polytheist.

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

gnani wrote:
> I read this link and your replies. I'm trying to make vim binary for
> NetBSD-3.0 from CYGWIN_NT-5.0 system. So, i tried cross compiling the
> vim. It was not successful initially. Then I tried with your patches
> for configure.in and configure scripts. I get the following error
> messages while configuring.
> -------
> checking for strip... strip... configure: error: failed to compile
> test program
> configure: error: cannot compile a simple program, check CC and
> CFLAGS
>   (cross compiling doesn't work)
> ------
> This is what my configure parameters and I executed like below.
>
> ./configure --build=i686-pc-cygwin --host=i386-unknown-netbsdelf3.0 --
> target=i386-unknown-netbsdelf3.0 --with-tlib=ncurses
>
> but I haven't set any other environment variables like you said
> already.
>
> If you could give me some solution to get my expected binary, it will
> be great helpful?
> Thanks alot in advance.
>
In reading this thread, it looks like configure is giving you some
problems.  I haven't delved into it deeply, but it seems to me that what
configure does you're basically not going to be able to get it to do on
a separate system.  Configure creates/touches directories xxd/,
testdir/, po/, objects/, and auto/  under vim71/src (assuming vim71, of
course).  The only one that it makes files in is vim71/src/auto:
config.cache  config.h  config.log  config.mk  config.status*
configure*  configure.orig* .  So you need to cut configure down to just
involve doing things like huge/tiny and whether or not to include
perl/tcl/etc support.  This cut-down configure won't be able to test
whether, for example, perl is available on your target; you'll have to
tell it where it is expected to be.

I think you'd be better off thinking about writing a new configure to do
this and perhaps extracting some pieces of configure rather than
thinking of it as a "modify configure" problem.

Regards,
Chip Campbell


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

I seem to have a problem where I want to upgrade my version of gvim
for linux but am somewhat confused by the site....

there seems to be a vim-7.1.tar.bz2.... but I have no idea what a bz2
file is and the site doesn't explain it (that I can find...).

so I tried to use vim-6.4-src1.tar.gz and vim-6.4-src2.tar.gz and
untar'ed them.
according to the site you need to type "make install" and everything
will work (assuming a c compiler and such...) but unfortunately, I
couldn't find a "makefile"....

Not sure why this couldn't be setup to be as easy as installing gvim
for my windows box...



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

e0richt@... wrote:
> I seem to have a problem where I want to upgrade my version of gvim
> for linux but am somewhat confused by the site....
>
> there seems to be a vim-7.1.tar.bz2.... but I have no idea what a bz2
> file is and the site doesn't explain it (that I can find...).
>
> so I tried to use vim-6.4-src1.tar.gz and vim-6.4-src2.tar.gz and
> untar'ed them.
> according to the site you need to type "make install" and everything
> will work (assuming a c compiler and such...) but unfortunately, I
> couldn't find a "makefile"....
>
> Not sure why this couldn't be setup to be as easy as installing gvim
> for my windows box...
>
bunzip2 vim-7.1.tar.bz2
tar -xf vim-7.1.tar
cd vim71
configure
make
make install

Regards,
Chip Campbell


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

On Tue, Mar 4, 2008 at 4:58 PM, Charles E Campbell Jr
<drchip@...> wrote:
>
>  e0richt@... wrote:
>  > I seem to have a problem where I want to upgrade my version of gvim
>  > for linux but am somewhat confused by the site....
>  >
>  > there seems to be a vim-7.1.tar.bz2.... but I have no idea what a bz2
>  > file is and the site doesn't explain it (that I can find...).
>  >
>  > so I tried to use vim-6.4-src1.tar.gz and vim-6.4-src2.tar.gz and
>  > untar'ed them.
>  > according to the site you need to type "make install" and everything
>  > will work (assuming a c compiler and such...) but unfortunately, I
>  > couldn't find a "makefile"....
>  >
>  > Not sure why this couldn't be setup to be as easy as installing gvim
>  > for my windows box...
>  >
>  bunzip2 vim-7.1.tar.bz2
>  tar -xf vim-7.1.tar
>  cd vim71
>  configure
>  make
>  make install

I find the method using aap much simpler:

http://www.a-a-p.org/ports.html

It downloads all patches automatically.

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

Charles E Campbell Jr wrote:
> e0richt@... wrote:
>> I seem to have a problem where I want to upgrade my version of gvim
>> for linux but am somewhat confused by the site....
>>
>> there seems to be a vim-7.1.tar.bz2.... but I have no idea what a bz2
>> file is and the site doesn't explain it (that I can find...).
>>
>> so I tried to use vim-6.4-src1.tar.gz and vim-6.4-src2.tar.gz and
>> untar'ed them.
>> according to the site you need to type "make install" and everything
>> will work (assuming a c compiler and such...) but unfortunately, I
>> couldn't find a "makefile"....
>>
>> Not sure why this couldn't be setup to be as easy as installing gvim
>> for my windows box...
>>
> bunzip2 vim-7.1.tar.bz2
> tar -xf vim-7.1.tar
> cd vim71
> configure
> make
> make install
>
> Regards,
> Chip Campbell

For more details (and a full step-by-step procedure the way I use it to
keep Vim up-to-date on Linux) see
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm

One reason it's more complex on Linux is that there are a lot different
Linux (and Unix) distributions, with nonuniform conventions as to where
the runtime libraries are placed; also users have much more freedom
about which software packages they want to install -- or not. You could
say that the number of "possible" Unix/Linux systems is unbounded.
Windows, OTOH, is distributed only by Microsoft, or at least, in a form
strictly controlled by Microsoft. Compare the one CD or DVD for a given
version of Windows with the plethora of CDs, DVDs, or online downloads
released at approximately the same time by Red-Hat-Fedora, Novell-SuSE,
Debian, Ubuntu, Gentoo, Mandriva, what-have-you. So, before we actually
compile, we run a configure "program" to find out what software is
sitting on the machine, where it is located, combine that with your
configure options (such as --with-features=huge --enable-perlinterp
etc.), and create a configure.mk which will be included by the
src/Makefile invoked by the top-level Vim Makefile (Makefile, not
makefile: case is significant in Unix/Linux filenames).

This configure step also has advantages: you could say that it has the
qualities of its defaults: it allows (almost) common treatment for not
only various Linux distributions but also Unix and Unix-like systems
which have nothing to do with Linux, such as BeOS, FreeBSD, even
Mac-OS-X and VAX/VMS. The differences between all these only
approximately similar systems are resolved at configure time with only
very limited manual intervention. OTOH, when compiling for Windows,
different Makefiles are needed to cater for something as elementary as
different C compilers, hence the various Make_cyg.mak, Make_bc5.mak,
Make_bc3.mak, Make_ming.mac, Make_mvc.mak, Make_w16.mak...


Best regards,
Tony.
--
Overflow on /dev/null, please empty the bit bucket.

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

Tony Mechelynck wrote:
> <snip>
> This configure step also has advantages: you could say that it has the
> qualities of its defaults: it allows (almost) common treatment for not
> only various Linux distributions but also Unix and Unix-like systems
> which have nothing to do with Linux, such as BeOS, FreeBSD, even
> Mac-OS-X and VAX/VMS. The differences between all these only
> approximately similar systems...<snip>

Hello, Tony!

Good explanation -- but (you knew that was coming!)  vax/vms is pretty
unlike unix.  It falls into the totally dissimilar category (ie. not
unix-like).  For example, paths: [this.is.a.path]filename.ext  ~
/this/is/a/path/filename.ext .  The Amiga is another dissimilar o/s, but
I'd say its more similar to unix that vax/vms is.

Anyway, to continue with Tony's point: the build & compile process is
sufficiently flexible to handle totally dissimilar-to-unix operating
systems such as AmigaDos and Vax/Vms.

Regards,
Chip Campbell


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

e0richt@..., Tuesday, 4. March 2008:
>
> Not sure why this couldn't be setup to be as easy as installing gvim
> for my windows box...

What Linux distribution do you use? Isn't there an up-to-date version of Vim
available within your package manager? That's the normal way for end-users to
install software and this is by far easier and more comfortable than installing
software on Windows.

Markus

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

> there seems to be a vim-7.1.tar.bz2.... but I have no idea what a bz2
> file is and the site doesn't explain it (that I can find...).

bz2 is a compression format (like gz, but with better compression). On
many systems, tar can uncompress tar.bz2 files directly if you do

      tar xfj file.tar.bz2

(that is, use a 'j' instead of the 'z' you use for tar.gz files).
Here's the second hit of a google search for "bz2":
http://en.wikipedia.org/wiki/Bzip2

> Not sure why this couldn't be setup to be as easy as installing gvim
> for my windows box...

There surely is a distribution-dependent way, that's "easy" (where
"easy" means "similar to windows"). For example, I'm sure you can
upgrade Vim through the add/remove programs dialog in Ubuntu. But
uncompressing the source and doing `make && sudo make install` is what
should work with all distributions.

HTH,
Nico

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

Hi,
      I found VIM(https://vim.svn.sourceforge.net/svnroot/vim/vim7@929)
exits when I enable profiling flags in src/Makefile:

      --- Makefile    (revision 929)
      +++ Makefile    (working copy)
      @@ -545,8 +545,8 @@
       # For unknown reasons adding "-lc" fixes a linking problem with
GCC.  That's
       # probably a bug in the "-pg" implementation.
       # Need to recompile everything after changing this: "make clean"
"make".
      -#PROFILE_CFLAGS = -pg -g
      -#PROFILE_LIBS = -pg
      +PROFILE_CFLAGS = -pg -g
      +PROFILE_LIBS = -pg
       #PROFILE_LIBS = -pg -lc


      $ ./vim -u NONE -U NONE -c ":q" ../bigfile
      vim: Caught deadly signal PROF
      vim: Finished.
      Profiling timer expired.

After comment out line 274 in os_unix.c I can run that command normally,
so I think os_unix.c requires a patch like this:

      Index: os_unix.c
      ===================================================================
      --- os_unix.c   (revision 929)
      +++ os_unix.c   (working copy)
      @@ -269,7 +269,7 @@
       #ifdef SIGVTALRM
           {SIGVTALRM,            "VTALRM",   TRUE},
       #endif
      -#if defined(SIGPROF) && !defined(FEAT_MZSCHEME)
      +#if defined(SIGPROF) && !defined(FEAT_MZSCHEME) && ! DO_GPROF
           /* MzScheme uses SIGPROF for its own needs */
           {SIGPROF,      "PROF",     TRUE},
       #endif

This is not a real patch because I don't know how to define DO_GPROF,
maybe there is already a macro can tell we are compiling with gprof
support.

I compile and test the code on Debian Etch.

Best regards,

Liu Yubao


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

Liu Yubao wrote:

>      I found VIM(https://vim.svn.sourceforge.net/svnroot/vim/vim7@929)
> exits when I enable profiling flags in src/Makefile:
>
>      --- Makefile    (revision 929)
>      +++ Makefile    (working copy)
>      @@ -545,8 +545,8 @@
>       # For unknown reasons adding "-lc" fixes a linking problem with
> GCC.  That's
>       # probably a bug in the "-pg" implementation.
>       # Need to recompile everything after changing this: "make clean"
> "make".
>      -#PROFILE_CFLAGS = -pg -g
>      -#PROFILE_LIBS = -pg
>      +PROFILE_CFLAGS = -pg -g
>      +PROFILE_LIBS = -pg
>       #PROFILE_LIBS = -pg -lc
>
>
>      $ ./vim -u NONE -U NONE -c ":q" ../bigfile
>      vim: Caught deadly signal PROF
>      vim: Finished.
>      Profiling timer expired.
>
> After comment out line 274 in os_unix.c I can run that command normally,
> so I think os_unix.c requires a patch like this:
>
>      Index: os_unix.c
>      ===================================================================
>      --- os_unix.c   (revision 929)
>      +++ os_unix.c   (working copy)
>      @@ -269,7 +269,7 @@
>       #ifdef SIGVTALRM
>           {SIGVTALRM,            "VTALRM",   TRUE},
>       #endif
>      -#if defined(SIGPROF) && !defined(FEAT_MZSCHEME)
>      +#if defined(SIGPROF) && !defined(FEAT_MZSCHEME) && ! DO_GPROF
>           /* MzScheme uses SIGPROF for its own needs */
>           {SIGPROF,      "PROF",     TRUE},
>       #endif
>
> This is not a real patch because I don't know how to define DO_GPROF,
> maybe there is already a macro can tell we are compiling with gprof
> support.

The obvious thing to do is use

       PROFILE_CFLAGS = -pg -g -DWE_ARE_PROFILING

and

       #if defined(SIGPROF) && !defined(FEAT_MZSCHEME) &&
!defined(WE_ARE_PROFILING)

> I compile and test the code on Debian Etch.

I'm running on FreeBSD, it works just fine without disabling that
SIGPROF line.  Is there something about Debian that works differently
with signals?

--
Warning label on a superhero Halloween costume:
"Caution: Cape does not enable user to fly."

  /// 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,

Under the condition that other tabs have [Location List].
[Location List] is indicated with [Quickfix List] in a result of a ":buffers"
command.


*** ../vim-7.1.265/src/buffer.c 2008-03-04 23:42:41.000000000 +0900
--- buffer.c 2008-03-04 23:43:31.000000000 +0900
***************
*** 5034,5045 ****
       if (bt_quickfix(buf))
       {
  	 win_T *win;

  	 /*
  	  * For location list window, w_llist_ref points to the location list.
  	  * For quickfix window, w_llist_ref is NULL.
  	  */
!  FOR_ALL_WINDOWS(win)
  	     if (win->w_buffer == buf)
  		 break;
  	 if (win != NULL && win->w_llist_ref != NULL)
--- 5034,5046 ----
       if (bt_quickfix(buf))
       {
  	 win_T *win;
+  tabpage_T   *tp;

  	 /*
  	  * For location list window, w_llist_ref points to the location list.
  	  * For quickfix window, w_llist_ref is NULL.
  	  */
!  FOR_ALL_TAB_WINDOWS(tp, win)
  	     if (win->w_buffer == buf)
  		 break;
  	 if (win != NULL && win->w_llist_ref != NULL)



Best regards,

Hiroaki Nishihara

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

Bram Moolenaar wrote:
> Liu Yubao wrote:
>>      I found VIM(https://vim.svn.sourceforge.net/svnroot/vim/vim7@929)
>> exits when I enable profiling flags in src/Makefile:
>
>> I compile and test the code on Debian Etch.
>
> I'm running on FreeBSD, it works just fine without disabling that
> SIGPROF line.  Is there something about Debian that works differently
> with signals?
>

I test the program below on Debian Etch, Debian Lenny, Ubuntu Gusty,
Fedora Core and FreeBSD, strangely it doesn't trigger func_deadly()
only on FreeBSD. I'm not sure whether it's a bug or a feature in Linux
kernel.

Here are some version information:
Debian Etch: linux kernel 2.6.18-4-686, gcc 4.1.2, libc 2.3.6
Debian Lenny: linux kernel 2.6.22-3-686, gcc 4.2.3, libc 2.7
Ubuntu Gusty: linux kernel 2.6.22-14-generic(x86_64), gcc 4.1.3, libc 2.6.1
Fedora Core 6: linux kernel 2.6.20(x86_64), gcc 4.1.2, libc 2.5
Fedora Core 7: linux kernel 2.6.23.8-34(x86_64), gcc 4.1.2
FreeBSD 6.2: gcc 3.4.6
FreeBSD 7.0: gcc 4.2.1

And the source code:

/*
  * $ gcc -g -pg -o sigprof sigprof.c
  * $ ./sigprof
  */
#include <stdio.h>
#include <unistd.h>
#include <signal.h>

void func_deadly(int signo)
{
     fprintf(stderr, "dead: signo=%d, SIGPROF=%d\n", signo, SIGPROF);
     _exit(1);
}


int main(void)
{
         int n = 0;
         int a = 1, b = 2;
         struct sigaction sa;

         sa.sa_handler = func_deadly;
         sa.sa_flags = SA_ONSTACK;
         sigemptyset(&sa.sa_mask);
         sigaction(SIGPROF, &sa, NULL);

#if 1
         /* can receive SIGPROF  */
         while (++n < 10000000)
             a = a * b * b * a * b * b / 3;
#else
         /* can't receive SIGPROF */
         while (++n < 4)
             sleep(2);
#endif

         return 0;
}


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

Hiroaki Nishihara wrote:

> Under the condition that other tabs have [Location List].
> [Location List] is indicated with [Quickfix List] in a result of a
> ":buffers" command.

Thanks for fixing this!

--
From "know your smileys":
  +<(:-) The Pope

  /// 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
-~----------~----~----~----~------~----~------~--~---

Liu Yubao wrote:

> >>      I found VIM(https://vim.svn.sourceforge.net/svnroot/vim/vim7@929)
> >> exits when I enable profiling flags in src/Makefile:
> >
> >> I compile and test the code on Debian Etch.
> >
> > I'm running on FreeBSD, it works just fine without disabling that
> > SIGPROF line.  Is there something about Debian that works differently
> > with signals?
> >
>
> I test the program below on Debian Etch, Debian Lenny, Ubuntu Gusty,
> Fedora Core and FreeBSD, strangely it doesn't trigger func_deadly()
> only on FreeBSD. I'm not sure whether it's a bug or a feature in Linux
> kernel.
>
> Here are some version information:
> Debian Etch: linux kernel 2.6.18-4-686, gcc 4.1.2, libc 2.3.6
> Debian Lenny: linux kernel 2.6.22-3-686, gcc 4.2.3, libc 2.7
> Ubuntu Gusty: linux kernel 2.6.22-14-generic(x86_64), gcc 4.1.3, libc 2.6.1
> Fedora Core 6: linux kernel 2.6.20(x86_64), gcc 4.1.2, libc 2.5
> Fedora Core 7: linux kernel 2.6.23.8-34(x86_64), gcc 4.1.2
> FreeBSD 6.2: gcc 3.4.6
> FreeBSD 7.0: gcc 4.2.1

I tried disabling SIGPROF on FreeBSD, doesn't seem to make a difference.
Did you try that -D in the Makefile, as I suggested?

--
From "know your smileys":
  :'-D Laughing so much that they're crying

  /// 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
-~----------~----~----~----~------~----~------~--~---

Bram Moolenaar wrote:
> Liu Yubao wrote:
>
>> I test the program below on Debian Etch, Debian Lenny, Ubuntu Gusty,
>> Fedora Core and FreeBSD, strangely it doesn't trigger func_deadly()
>> only on FreeBSD. I'm not sure whether it's a bug or a feature in Linux
>> kernel.
>>
>> Here are some version information:
>> Debian Etch: linux kernel 2.6.18-4-686, gcc 4.1.2, libc 2.3.6
>> Debian Lenny: linux kernel 2.6.22-3-686, gcc 4.2.3, libc 2.7
>> Ubuntu Gusty: linux kernel 2.6.22-14-generic(x86_64), gcc 4.1.3, libc 2.6.1
>> Fedora Core 6: linux kernel 2.6.20(x86_64), gcc 4.1.2, libc 2.5
>> Fedora Core 7: linux kernel 2.6.23.8-34(x86_64), gcc 4.1.2
>> FreeBSD 6.2: gcc 3.4.6
>> FreeBSD 7.0: gcc 4.2.1
>
> I tried disabling SIGPROF on FreeBSD, doesn't seem to make a difference.
> Did you try that -D in the Makefile, as I suggested?
>

Yes, I tried, it works on Linux. It seems it's a problem specific to Linux.


Best regards,

Liu Yubao

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

I see problem with shell highlighting with the following piece,
apparently caused by the command named 'locale'.
I am using latest runtime files. from rsync.
Does anybody see incorrect highlighting, too ?
------------------------------------------
#!/bin/bash

utf-off() {
     echo "export LANG=C; unset LC_ALL LANGUAGE"
     unset `locale | awk -F= '{print$1}' `
     export LANG=C; unset LC_ALL LANGUAGE;
     env|egrep '^(LANG|LC_)';
}
------------------------------------------

The problem seem to begin with the word 'locale'.

If I remove space after 'locale' (so it becomes locale|),
there is another strange highlighting in the word 'locale'.

Yakov

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

On Thu, Mar 06, 2008 at 10:13:16AM +0200, Yakov Lerner wrote:
>
> I see problem with shell highlighting with the following piece,
> apparently caused by the command named 'locale'.
> I am using latest runtime files. from rsync.
> Does anybody see incorrect highlighting, too ?
> ------------------------------------------
> #!/bin/bash
>
> utf-off() {
>     echo "export LANG=C; unset LC_ALL LANGUAGE"
>     unset `locale | awk -F= '{print$1}' `
>     export LANG=C; unset LC_ALL LANGUAGE;
>     env|egrep '^(LANG|LC_)';
> }
> ------------------------------------------

> The problem seem to begin with the word 'locale'.
>
> If I remove space after 'locale' (so it becomes locale|),
> there is another strange highlighting in the word 'locale'.

It seems to work fine for me.

!cat $VIMRUNTIME/syntax/sh.vim | grep Version
" Version:              89

--
	 Vlad

On Thu, Mar 6, 2008 at 12:11 PM, Vladimir Marek <Vladimir.Marek@...> wrote:
>
> On Thu, Mar 06, 2008 at 10:13:16AM +0200, Yakov Lerner wrote:
>  >
>  > I see problem with shell highlighting with the following piece,
>  > apparently caused by the command named 'locale'.
>  > I am using latest runtime files. from rsync.
>  > Does anybody see incorrect highlighting, too ?
>  > ------------------------------------------
>  > #!/bin/bash
>  >
>  > utf-off() {
>  >     echo "export LANG=C; unset LC_ALL LANGUAGE"
>  >     unset `locale | awk -F= '{print$1}' `
>  >     export LANG=C; unset LC_ALL LANGUAGE;
>  >     env|egrep '^(LANG|LC_)';
>  > }
>  > ------------------------------------------
>
>  > The problem seem to begin with the word 'locale'.
>  >
>  > If I remove space after 'locale' (so it becomes locale|),
>  > there is another strange highlighting in the word 'locale'.
>
>  It seems to work fine for me.
>
>  !cat $VIMRUNTIME/syntax/sh.vim | grep Version
>  " Version:              89

Version 95 here.

Yakov

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

You can try the scriptvim7-install.sh (attached)
which downloads, builds and installs latest vim7
in one command without arguments.

Description and download link ia at:
     http://www.vim.org/scripts/script.php?script_id=1473
Invocation:
     sh ./vim7-install.sh

Or save the script directly  from this link:
   http://ilerner.3b1.org/vim7-install.sh

Attached.

Yakov

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

Patch 7.1.267
Problem:    When changing folds cursor may be positioned in the wrong place.
Solution:   Call changed_window_setting_win() instead of
	     changed_window_setting().
Files:     src/fold.c


*** ../vim-7.1.266/src/fold.c Sun Jan 13 21:57:25 2008
--- src/fold.c Wed Mar  5 12:48:43 2008
***************
*** 2307,2313 ****

       /* If some fold changed, need to redraw and position cursor. */
       if (fold_changed && wp->w_p_fen)
!  changed_window_setting();

       /* If we updated folds past "bot", need to redraw more lines.  Don't do
        * this in other situations, the changed lines will be redrawn anyway and
--- 2307,2313 ----

       /* If some fold changed, need to redraw and position cursor. */
       if (fold_changed && wp->w_p_fen)
!  changed_window_setting_win(wp);

       /* If we updated folds past "bot", need to redraw more lines.  Don't do
        * this in other situations, the changed lines will be redrawn anyway and
*** ../vim-7.1.266/src/version.c Wed Feb 27 16:13:09 2008
--- src/version.c Thu Mar  6 22:43:05 2008
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     267,
   /**/

--
From "know your smileys":
  % Bike accident.  A bit far-fetched, I suppose; although...
              o      _     _         _
      _o     /\_   _ \\o  (_)\__/o  (_)
    _< \_   _>(_) (_)/<_    \_| \   _|/' \/
   (_)>(_) (_)        (_)   (_)    (_)'  _\o_

  /// 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
-~----------~----~----~----~------~----~------~--~---