On Mon, 01 Oct 2007 11:39:47 +1000, Ben Schmidt
<mail_ben_schmidt@...> wrote:

> > I've been digging through the Vim source and had trouble trying to
> > understand what win_lbr_chartabsize() is doing. About 112 lines from
> > the start of the function (in 7.1.94) there's a part that should take
> > the width of a tab into account when used in combination with
> > "showbreak". I couldn't work out how these parts were supposed to
> > interact from studying the code so I tried studying Vim's behaviour
> > instead. The results are a bit odd.
> >
> > Create a file with a line containing a repeating pattern of four
> > letters and a tab (that is, "abcd<tab>abcd<tab>abcd<tab>...") to a
> > width of about 300 columns. Then set wrap, showbreak=>>> and tabstop
> > to something like 9 so there aren't a even number of tabs in your
> > screen width or your screen width less the width of the showbreak.
> >
> > Now, starting from the beginning of the line, press w repeatedly
> > and watch where the cursor goes after each movement. On some of the
> > wrapped lines I see it settle three characters to the left of where it
> > should be when it moves to the first word on each wrapped screen line.
> > I've tried to fix it, but no matter what I change the cursor always
> > lands in the wrong place at some point. Does anyone else see this?
>
> I see it. There is definitely something wrong here. I doubt it's just in that
one
> function you mention, though.

I don't think there's anywhere else where tabs and showbreak interact
in that way. There are other character size functions but I think they
all treat the line as if it were unbroken.

I was inspired to look at this by the thread on non-uniform tabstops
a month ago, as that's something I'd often find useful and I'm out of
work at the moment so I have some free time. Different column widths
for tabs isn't all that hard to implement (in that it melts only half
your brain instead of all of it), but this one place didn't seem to
make sense.

> With 'linebreak' on the results are also impressive, though not always so
> impressive--after a few lines wrapping does not occur properly, but words are
> broken, and when moving through them with 'w' in some circumstances at the
> beginning of a line the cursor stops 'between' words!

I noticed that too, but I couldn't reproduce it reliably.

> In both cases the cursor won't actually move to the end of the logical line
> either, i.e. push $ and the cursor will be put near, but not at the end!

I didn't notice that. I didn't try $.

> Is there a reason for not making the tabs work properly on wrapped lines with
> showbreak? Is it too difficult to implement? I would've expected all the
tabstops
> and everything else to be pushed backward by the 'showbreak' string as well.

That's what I'd have expected.

> If I have some time, I'll have a look at this, but don't expect I will for at
> least a week!

I'm going to be looking at it too. It's bugging me, not knowing what's
going on.

--
Matthew Winn

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

On 26/09/2007 21:02, Bram Moolenaar wrote:
> Mike -
>
>> The following is a resend of a patch from 6 months ago to enable
>> optimized building with to use VC8 features and remove compiler option
>> warnings.
>
> I had a few problems with this patch, which is why I didn't send it out
> yet.  Also, it collides with a patch from George Reilly for Win64
> support, which also has a problem.
>
>> @@ -320,7 +322,44 @@ INTDIR=$(OBJDIR)
>>  INTDIR=$(OBJDIR)
>>  OUTDIR=$(OBJDIR)
>>
>> +# Derive version of VC being used from nmake if not specified
>> +!if "$(MSVCVER)" == ""
>> +!if "$(_NMAKE_VER)" == ""
>> +MSVCVER = "4.0"
>
> The "4.0" needs to be 4.0 (no quotes) for this to work with old nmake.
>
>>  # Convert processor ID to MVC-compatible number
>> +!if $(MSVCVER) != "8.0"
>
> But we do need quotes here:
>    !if "$(MSVCVER)" != "8.0"
>
> Other "if" for MSVCVER are similar.

Ok, here is the next version for identifying compiler version and
supporting VC8 optimisation compiler options.  How about sending this
out separate to the Win64 support as VIM cannot currently use VC8
specific optimisations without it.  Win64 specific changes can then be
made on top of it.  Just a thought.

TTFN

Mike
--
I hear, I forget. I see, I remember. I experience, I understand. -
Chinese Proverb

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

diff -r 95b0dc7a6113 src/Make_mvc.mak
--- a/src/Make_mvc.mak Sun Sep 23 16:13:03 2007 +0100
+++ b/src/Make_mvc.mak Sun Sep 30 22:34:50 2007 +0100
@@ -91,6 +91,8 @@
  #
  #       Netbeans Debugging Support: NBDEBUG=[yes or no] (should be no, yes
  #       doesn't work)
+#
+#       Visual C Version: MSVCVER=m.n (default derived from nmake if undefined)
  #
  # You can combine any of these interfaces
  #
@@ -320,7 +322,44 @@ INTDIR=$(OBJDIR)
  INTDIR=$(OBJDIR)
  OUTDIR=$(OBJDIR)

+# Derive version of VC being used from nmake if not specified
+!if "$(MSVCVER)" == ""
+!if "$(_NMAKE_VER)" == ""
+MSVCVER = 4.0
+!endif
+!if "$(_NMAKE_VER)" == "162"
+MSVCVER = 5.0
+!endif
+!if "$(_NMAKE_VER)" == "6.00.8168.0"
+MSVCVER = 6.0
+!endif
+!if "$(_NMAKE_VER)" == "7.00.9466"
+MSVCVER = 7.0
+!endif
+!if "$(_NMAKE_VER)" == "7.10.3077"
+MSVCVER = 7.1
+!endif
+!if "$(_NMAKE_VER)" == "8.00.50727.42"
+MSVCVER = 8.0
+!endif
+!if "$(_NMAKE_VER)" == "8.00.50727.762"
+MSVCVER = 8.0
+!endif
+!endif
+
+# Abort bulding VIM if version of VC is unrecognised.
+!ifndef MSVCVER
+!message *** ERROR
+!message Cannot determine Visual C version being used.  If you are using the
+!message Windows SDK then you must have the environment variable MSVCVER set to
+!message your version of the VC compiler.  If you are not using the Express
+!message version of Visual C you van either set MSVCVER or update this makefile
+!message to handle the new value for _NMAKE_VER.
+!error Make aborted.
+!endif
+
  # Convert processor ID to MVC-compatible number
+!if "$(MSVCVER)" != "8.0"
  !if "$(CPUNR)" == "i386"
  CPUARG = /G3
  !elseif "$(CPUNR)" == "i486"
@@ -334,6 +373,12 @@ CPUARG = /G7 /arch:SSE2
  !else
  CPUARG =
  !endif
+!else
+# VC8 only allows specifying SSE architecture
+!if "$(CPUNR)" == "pentium4"
+CPUARG = /arch:SSE2
+!endif
+!endif

  !ifdef NODEBUG
  VIM = vim
@@ -343,6 +388,12 @@ OPTFLAG = /O2
  OPTFLAG = /O2
  !else # MAXSPEED
  OPTFLAG = /Ox
+!endif
+!if "$(MSVCVER)" == "8.0"
+# Use link time code generation if not worried about size
+!if "$(OPTIMIZE)" != "SPACE"
+OPTFLAG = $(OPTFLAG) /GL
+!endif
  !endif
  CFLAGS = $(CFLAGS) $(OPTFLAG) -DNDEBUG $(CPUARG)
  RCFLAGS = $(rcflags) $(rcvars) -DNDEBUG
@@ -363,7 +414,7 @@ CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od
  CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od
  RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG
  # The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in VC4.0.
-! if "$(_NMAKE_VER)" == ""
+! if "$(MSVCVER)" == "4.0"
  LIBC =
  ! else
  LIBC = /fixed:no
@@ -707,6 +758,15 @@ LINKARGS2 = $(CON_LIB) $(GUI_LIB) $(LIBC
 		 $(MZSCHEME_LIB) $(PERL_LIB) $(PYTHON_LIB) $(RUBY_LIB) \
 		 $(TCL_LIB) $(NETBEANS_LIB) $(XPM_LIB) $(LINK_PDB)

+# Report link time code generation progress if used.
+!ifdef NODEBUG
+!if "$(MSVCVER)" == "8.0"
+!if "$(OPTIMIZE)" != "SPACE"
+LINKARGS1 = $(LINKARGS1) /LTCG:STATUS
+!endif
+!endif
+!endif
+
  all: $(VIM).exe vimrun.exe install.exe uninstal.exe xxd/xxd.exe \
 		 GvimExt/gvimext.dll

@@ -794,7 +854,7 @@ testclean:

  # Create a default rule for transforming .c files to .obj files in $(OUTDIR)
  # Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
-!IF "$(_NMAKE_VER)" == ""
+!IF "$(MSVCVER)" == "4.0"
  .c{$(OUTDIR)/}.obj:
  !ELSE
  .c{$(OUTDIR)/}.obj::
@@ -803,7 +863,7 @@ testclean:

  # Create a default rule for transforming .cpp files to .obj files in $(OUTDIR)
  # Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
-!IF "$(_NMAKE_VER)" == ""
+!IF "$(MSVCVER)" == "4.0"
  .cpp{$(OUTDIR)/}.obj:
  !ELSE
  .cpp{$(OUTDIR)/}.obj::

Bram Moolenaar wrote:
>> gui_gtk_x11.c:3418: warning: not enough variable
>> arguments to fit a sentinel
>
> The function definition that is in gnome-program.h looks like this:
>
> GnomeProgram *
> gnome_program_init (const char *app_id, const char *app_version,
> 		    const GnomeModuleInfo *module_info,
> 		    int argc, char **argv,
> 		    const char *first_property_name, ...);
>
> Which would fit our use just fine.  Don't know what the
> warning is for.

Googling does not throw much light on the matter, but I see hints that gcc
wants the caller to pass at least one variable argument. I infer that the
"sentinel" mentioned here is (void *)0 appended to the variable argument
list to flag the end. Maybe gcc does that for safety, or maybe gcc checks if
the source does it. Of course some code would not use a sentinel, but maybe
it is for safety in case the called function wants it?

So the warning may go away if there were an extra NULL argument in the
gnome_program_init() call (so there is one optional argument).

John


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

> Ok, got it.
>> Note that I don't like the idea of running a shell in a Vim window.  But
>> running make in the background would be useful.
>>
> Because this is on of  the first steps from an editor to an operating
> system
> alla emacs ?
> If someone starts a shell as a subprocess and redirect its in- and
> output to buffer
> ,provided this will ever be realized, it would be pretty much close to
> shell
> in a vim window.
>
I like the idea!  Are you resuming work on SLIM-VIM?

-- Mikael

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

Hi Vimmers,

In file os_win32.c there is a function mch_get_user_name() which uses
GetUserName() function to get the logon name on Windows. The constant
used to declare a buffer to get the name is MAX_COMPUTERNAME_LENGTH
which is not correct. The correct constant (as mentioned in the
documentation) is UNLEN.

I don't know the severity of this problem, but note that UNLEN is 256
characters, while MAX_COMPUTERNAME_LENGTH is only 15 characters.

In fact, I discovered this problem while looking into BoundsChecker
results for Vim - my logon name is longer than 15 chars and
GetUserName were failing. Still, I can work in Vim perfectly - so this
bug doesn't affect most of us.


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

There is a known issue with things working on Vista having to do
   the _access() function.  For example, the application gcc uses
   _access() to find other tools such as cc1.exe and the usual gcc
   fails on Vista -- the usual gcc needs to be patched to work on
   Vista.  If VIM uses _access() to find things, vim is likely to
   fail too.

   My very high level understanding: In older MSVCRT, passing X_OK to
   _access was the same as passing F_OK.  But in Vista, passing X_OK
   returns the error "invalid param value".

   --Suresh


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

Hi vimmers,

I try to update my Vim runtime files with AAP. I have AAP 1.090
installed, plus Python 2.5. I execute command

  > aap -f ftp://ftp.vim.org/pub/vim/runtime/main.aap fetch

which is a copy-paste from Vim site and get the following error:

fetch
Aap: c:\cygwin\bin\gcc.EXE --version
Aap: Attempting download of "ftp://ftp.vim.org/pub/vim/runtime/main.aap"
Aap: Downloaded "ftp://ftp.vim.org/pub/vim/runtime/main.aap" to "main.aap"
Aap: Updating recipe "main.aap"
Aap: Attempting download of "ftp://ftp.vim.org/pub/vim/runtime/main.aap"
Aap: Downloaded "ftp://ftp.vim.org/pub/vim/runtime/main.aap" to
"D:\programs\vim\111\main.aap"
Cannot read "filetype.vim", guessing fileformat is "dos".
Aap: Attempting download of "ftp://ftp.vim.org/pub/vim/runtime/getdos.aap"
Aap: Downloaded "ftp://ftp.vim.org/pub/vim/runtime/getdos.aap" to
"D:\programs\vim\111\getdos.aap"
Aap: Internal Error
Aap: Traceback (most recent call last):
     File "D:\programs\aap\Process.py", line 1163, in Process
      exec script_string in recdict, recdict
     File "<string>", line 7, in <module>
     File "D:\programs\aap\Error.py", line 50, in __init__
      self.args = args
   TypeError: 'NoneType' object is not iterable

Aap: Aborted
Aap: More info in the logfile: D:\programs\vim\111\AAPDIR\log

What might be the reason of the failure?

--
Alexei Alexandrov


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

Bill McCarthy wrote:

> On Sun 30-Sep-07 3:28pm -0600, Bram Moolenaar wrote:
>
> > Patch 7.1.128 (extra)
>
> What's with the "About" in the subject line?  Isn't simply:
>
>     Patch 7.1.127
>     Patch 7.1.128 (extra)
>
> enough?

OK, so I made a mistake in my correction for a mistake, sigh...

It was about Patch 7.1.126.  126?   Let's check...  Yes!  7.1.126.  It
patches src/gui_w48.c, which is in the extra files department.

Sorry for the confusing confusion.  I was actually planning to put the
change to the extra file in a separate patch, but forgot to remove it
when actually sending out the patch...

--
SOLDIER: What?  Ridden on a horse?
ARTHUR:  Yes!
SOLDIER: You're using coconuts!
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        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.1.129 (extra)
Problem:    Win32: Can't get the user name when it is longer than 15
	     characters.
Solution:   Use UNLEN instead of MAX_COMPUTERNAME_LENGTH. (Alexei Alexandrov)
Files:     src/os_win32.c


*** ../vim-7.1.128/src/os_win32.c Thu May 10 19:22:59 2007
--- src/os_win32.c Mon Oct  1 20:07:24 2007
***************
*** 2378,2384 ****
       char_u  *s,
       int     len)
   {
!     char szUserName[MAX_COMPUTERNAME_LENGTH + 1];
       DWORD cch = sizeof szUserName;

       if (GetUserName(szUserName, &cch))
--- 2378,2384 ----
       char_u  *s,
       int     len)
   {
!     char szUserName[256 + 1]; /* UNLEN is 256 */
       DWORD cch = sizeof szUserName;

       if (GetUserName(szUserName, &cch))
*** ../vim-7.1.128/src/version.c Sun Sep 30 22:28:08 2007
--- src/version.c Mon Oct  1 20:32:52 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     129,
   /**/

--
ARTHUR: It is I, Arthur, son of Uther Pendragon, from the castle of Camelot.
         King of all Britons, defeator of the Saxons, sovereign of all England!
    [Pause]
SOLDIER: Get away!
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        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
-~----------~----~----~----~------~----~------~--~---

Alexei Alexandrov wrote:

> Hi Vimmers,
>
> In file os_win32.c there is a function mch_get_user_name() which uses
> GetUserName() function to get the logon name on Windows. The constant
> used to declare a buffer to get the name is MAX_COMPUTERNAME_LENGTH
> which is not correct. The correct constant (as mentioned in the
> documentation) is UNLEN.
>
> I don't know the severity of this problem, but note that UNLEN is 256
> characters, while MAX_COMPUTERNAME_LENGTH is only 15 characters.
>
> In fact, I discovered this problem while looking into BoundsChecker
> results for Vim - my logon name is longer than 15 chars and
> GetUserName were failing. Still, I can work in Vim perfectly - so this
> bug doesn't affect most of us.

Thanks for reporthing this.  I'll make a patch.

--
It might look like I'm doing nothing, but at the cellular level
I'm really quite busy.

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

Matthew Winn wrote:

> I've been digging through the Vim source and had trouble trying to
> understand what win_lbr_chartabsize() is doing. About 112 lines from
> the start of the function (in 7.1.94) there's a part that should take
> the width of a tab into account when used in combination with
> "showbreak". I couldn't work out how these parts were supposed to
> interact from studying the code so I tried studying Vim's behaviour
> instead. The results are a bit odd.
>
> Create a file with a line containing a repeating pattern of four
> letters and a tab (that is, "abcd<tab>abcd<tab>abcd<tab>...") to a
> width of about 300 columns. Then set wrap, showbreak=>>> and tabstop
> to something like 9 so there aren't a even number of tabs in your
> screen width or your screen width less the width of the showbreak.
>
> Now, starting from the beginning of the line, press w repeatedly
> and watch where the cursor goes after each movement. On some of the
> wrapped lines I see it settle three characters to the left of where it
> should be when it moves to the first word on each wrapped screen line.
> I've tried to fix it, but no matter what I change the cursor always
> lands in the wrong place at some point. Does anyone else see this?

The code hasn't been tested much with 'tabstop' set to values other than
8.  But it should work.

I can see the problem you explain.  Hopefully you can fix it, but I'll
put it somewhere in my todo list.

--
SECOND SOLDIER: It could be carried by an African swallow!
FIRST SOLDIER:  Oh  yes! An African swallow maybe ... but not a European
                 swallow. that's my point.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        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.1.130
Problem:    Crash with specific order of undo and redo. (A.Politz)
Solution:   Clear and adjust pointers properly.  Add u_check() for debugging.
Files:     src/undo.c, src/structs.h


*** ../vim-7.1.129/src/undo.c Thu May 10 20:01:43 2007
--- src/undo.c Mon Oct  1 22:49:16 2007
***************
*** 76,81 ****
--- 76,87 ----
    * buffer is unloaded.
    */

+ /* Uncomment the next line for including the u_check() function.  This warns
+  * for errors in the debug information. */
+ /* #define U_DEBUG 1 */
+ #define UH_MAGIC 0x18dade /* value for uh_magic when in use */
+ #define UE_MAGIC 0xabc123 /* value for ue_magic when in use */
+
   #include "vim.h"

   /* See below: use malloc()/free() for memory management. */
***************
*** 113,118 ****
--- 119,213 ----
    */
   static int undo_undoes = FALSE;

+ #ifdef U_DEBUG
+ /*
+  * Check the undo structures for being valid.  Print a warning when something
+  * looks wrong.
+  */
+ static int seen_b_u_curhead;
+ static int seen_b_u_newhead;
+ static int header_count;
+
+     static void
+ u_check_tree(u_header_T *uhp,
+  u_header_T *exp_uh_next,
+  u_header_T *exp_uh_alt_prev)
+ {
+     u_entry_T *uep;
+
+     if (uhp == NULL)
+  return;
+     ++header_count;
+     if (uhp == curbuf->b_u_curhead && ++seen_b_u_curhead > 1)
+     {
+  EMSG("b_u_curhead found twice (looping?)");
+  return;
+     }
+     if (uhp == curbuf->b_u_newhead && ++seen_b_u_newhead > 1)
+     {
+  EMSG("b_u_newhead found twice (looping?)");
+  return;
+     }
+
+     if (uhp->uh_magic != UH_MAGIC)
+  EMSG("uh_magic wrong (may be using freed memory)");
+     else
+     {
+  /* Check pointers back are correct. */
+  if (uhp->uh_next != exp_uh_next)
+  {
+ 	    EMSG("uh_next wrong");
+ 	    smsg((char_u *)"expected: 0x%x, actual: 0x%x",
+ 						   exp_uh_next, uhp->uh_next);
+  }
+  if (uhp->uh_alt_prev != exp_uh_alt_prev)
+  {
+ 	    EMSG("uh_alt_prev wrong");
+ 	    smsg((char_u *)"expected: 0x%x, actual: 0x%x",
+ 					   exp_uh_alt_prev, uhp->uh_alt_prev);
+  }
+
+  /* Check the undo tree at this header. */
+  for (uep = uhp->uh_entry; uep != NULL; uep = uep->ue_next)
+  {
+ 	    if (uep->ue_magic != UE_MAGIC)
+ 	    {
+ 	 EMSG("ue_magic wrong (may be using freed memory)");
+ 	 break;
+ 	    }
+  }
+
+  /* Check the next alt tree. */
+  u_check_tree(uhp->uh_alt_next, uhp->uh_next, uhp);
+
+  /* Check the next header in this branch. */
+  u_check_tree(uhp->uh_prev, uhp, NULL);
+     }
+ }
+
+     void
+ u_check(int newhead_may_be_NULL)
+ {
+     seen_b_u_newhead = 0;
+     seen_b_u_curhead = 0;
+     header_count = 0;
+
+     u_check_tree(curbuf->b_u_oldhead, NULL, NULL);
+
+     if (seen_b_u_newhead == 0 && curbuf->b_u_oldhead != NULL
+ 	    && !(newhead_may_be_NULL && curbuf->b_u_newhead == NULL))
+  EMSGN("b_u_newhead invalid: 0x%x", curbuf->b_u_newhead);
+     if (curbuf->b_u_curhead != NULL && seen_b_u_curhead == 0)
+  EMSGN("b_u_curhead invalid: 0x%x", curbuf->b_u_curhead);
+     if (header_count != curbuf->b_u_numhead)
+     {
+  EMSG("b_u_numhead invalid");
+  smsg((char_u *)"expected: %ld, actual: %ld",
+ 			       (long)header_count, (long)curbuf->b_u_numhead);
+     }
+ }
+ #endif
+
   /*
    * Save the current line for both the "u" and "U" command.
    * Returns OK or FAIL.
***************
*** 243,248 ****
--- 338,346 ----
       if (!undo_allowed())
  	 return FAIL;

+ #ifdef U_DEBUG
+     u_check(FALSE);
+ #endif
   #ifdef FEAT_NETBEANS_INTG
       /*
        * Netbeans defines areas that cannot be modified.  Bail out here when
***************
*** 294,299 ****
--- 392,400 ----
  	     uhp = (u_header_T *)U_ALLOC_LINE((unsigned)sizeof(u_header_T));
  	     if (uhp == NULL)
  		 goto nomem;
+ #ifdef U_DEBUG
+ 	    uhp->uh_magic = UH_MAGIC;
+ #endif
  	 }
  	 else
  	     uhp = NULL;
***************
*** 316,323 ****
  	 {
  	     u_header_T     *uhfree = curbuf->b_u_oldhead;

! 	    /* If there is no branch only free one header. */
! 	    if (uhfree->uh_alt_next == NULL)
  		 u_freeheader(curbuf, uhfree, &old_curhead);
  	     else
  	     {
--- 417,427 ----
  	 {
  	     u_header_T     *uhfree = curbuf->b_u_oldhead;

! 	    if (uhfree == old_curhead)
! 	 /* Can't reconnect the branch, delete all of it. */
! 	 u_freebranch(curbuf, uhfree, &old_curhead);
! 	    else if (uhfree->uh_alt_next == NULL)
! 	 /* There is no branch, only free one header. */
  		 u_freeheader(curbuf, uhfree, &old_curhead);
  	     else
  	     {
***************
*** 326,331 ****
--- 430,438 ----
  		     uhfree = uhfree->uh_alt_next;
  		 u_freebranch(curbuf, uhfree, &old_curhead);
  	     }
+ #ifdef U_DEBUG
+ 	    u_check(TRUE);
+ #endif
  	 }

  	 if (uhp == NULL)  /* no undo at all */
***************
*** 478,483 ****
--- 585,593 ----
       uep = (u_entry_T *)U_ALLOC_LINE((unsigned)sizeof(u_entry_T));
       if (uep == NULL)
  	 goto nomem;
+ #ifdef U_DEBUG
+     uep->ue_magic = UE_MAGIC;
+ #endif

       uep->ue_size = size;
       uep->ue_top = top;
***************
*** 525,530 ****
--- 635,643 ----
       curbuf->b_u_synced = FALSE;
       undo_undoes = FALSE;

+ #ifdef U_DEBUG
+     u_check(FALSE);
+ #endif
       return OK;

   nomem:
***************
*** 955,960 ****
--- 1068,1076 ----
       int  empty_buffer; 	    /* buffer became empty */
       u_header_T *curhead = curbuf->b_u_curhead;

+ #ifdef U_DEBUG
+     u_check(FALSE);
+ #endif
       old_flags = curhead->uh_flags;
       new_flags = (curbuf->b_changed ? UH_CHANGED : 0) +
  	        ((curbuf->b_ml.ml_flags & ML_EMPTY) ? UH_EMPTYBUF : 0);
***************
*** 1186,1191 ****
--- 1302,1310 ----
       /* The timestamp can be the same for multiple changes, just use the one of
        * the undone/redone change. */
       curbuf->b_u_seq_time = curhead->uh_time;
+ #ifdef U_DEBUG
+     u_check(FALSE);
+ #endif
   }

   /*
***************
*** 1515,1521 ****
   }

   /*
!  * Free one header and its entry list and adjust the pointers.
    */
       static void
   u_freeheader(buf, uhp, uhpp)
--- 1634,1640 ----
   }

   /*
!  * Free one header "uhp" and its entry list and adjust the pointers.
    */
       static void
   u_freeheader(buf, uhp, uhpp)
***************
*** 1523,1528 ****
--- 1642,1649 ----
       u_header_T     *uhp;
       u_header_T     **uhpp; /* if not NULL reset when freeing this header */
   {
+     u_header_T     *uhap;
+
       /* When there is an alternate redo list free that branch completely,
        * because we can never go there. */
       if (uhp->uh_alt_next != NULL)
***************
*** 1540,1546 ****
       if (uhp->uh_prev == NULL)
  	 buf->b_u_newhead = uhp->uh_next;
       else
!  uhp->uh_prev->uh_next = uhp->uh_next;

       u_freeentries(buf, uhp, uhpp);
   }
--- 1661,1668 ----
       if (uhp->uh_prev == NULL)
  	 buf->b_u_newhead = uhp->uh_next;
       else
!  for (uhap = uhp->uh_prev; uhap != NULL; uhap = uhap->uh_alt_next)
! 	    uhap->uh_next = uhp->uh_next;

       u_freeentries(buf, uhp, uhpp);
   }
***************
*** 1585,1590 ****
--- 1707,1714 ----
       /* Check for pointers to the header that become invalid now. */
       if (buf->b_u_curhead == uhp)
  	 buf->b_u_curhead = NULL;
+     if (buf->b_u_newhead == uhp)
+  buf->b_u_newhead = NULL;  /* freeing the newest entry */
       if (uhpp != NULL && uhp == *uhpp)
  	 *uhpp = NULL;

***************
*** 1594,1599 ****
--- 1718,1726 ----
  	 u_freeentry(uep, uep->ue_size);
       }

+ #ifdef U_DEBUG
+     uhp->uh_magic = 0;
+ #endif
       U_FREE_LINE((char_u *)uhp);
       --buf->b_u_numhead;
   }
***************
*** 1609,1614 ****
--- 1736,1744 ----
       while (n > 0)
  	 U_FREE_LINE(uep->ue_array[--n]);
       U_FREE_LINE((char_u *)uep->ue_array);
+ #ifdef U_DEBUG
+     uep->ue_magic = 0;
+ #endif
       U_FREE_LINE((char_u *)uep);
   }

*** ../vim-7.1.129/src/structs.h Sun Aug 12 15:50:26 2007
--- src/structs.h Sat Sep 29 15:03:38 2007
***************
*** 278,283 ****
--- 278,286 ----
       linenr_T ue_lcount; /* linecount when u_save called */
       char_u **ue_array; /* array of lines in undo block */
       long ue_size; /* number of lines in ue_array */
+ #ifdef U_DEBUG
+     int  ue_magic; /* magic number to check allocation */
+ #endif
   };

   struct u_header
***************
*** 300,305 ****
--- 303,311 ----
       visualinfo_T uh_visual; /* Visual areas before undo/after redo */
   #endif
       time_t uh_time; /* timestamp when the change was made */
+ #ifdef U_DEBUG
+     int  uh_magic; /* magic number to check allocation */
+ #endif
   };

   /* values for uh_flags */
*** ../vim-7.1.129/src/version.c Mon Oct  1 20:33:45 2007
--- src/version.c Mon Oct  1 22:50:23 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     130,
   /**/

--
FIRST SOLDIER:  So they wouldn't be able to bring a coconut back anyway.
SECOND SOLDIER: Wait a minute! Suppose two swallows carried it together?
FIRST SOLDIER:  No, they'd have to have it on a line.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        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:

>
> Patch 7.1.129 (extra)
  >
  > ....

Thanks!

P.S. So is the "About patch .*" pattern in the subject line intentional?


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

On 2007-10-01, Bram Moolenaar <Bram@...> wrote:
> Bill McCarthy wrote:
>
> > On Sun 30-Sep-07 3:28pm -0600, Bram Moolenaar wrote:
> >
> > > Patch 7.1.128 (extra)
> >
> > What's with the "About" in the subject line?  Isn't simply:
> >
> >     Patch 7.1.127
> >     Patch 7.1.128 (extra)
> >
> > enough?
>
> OK, so I made a mistake in my correction for a mistake, sigh...
>
> It was about Patch 7.1.126.  126?   Let's check...  Yes!  7.1.126.  It
> patches src/gui_w48.c, which is in the extra files department.
>
> Sorry for the confusing confusion.  I was actually planning to put the
> change to the extra file in a separate patch, but forgot to remove it
> when actually sending out the patch...

I don't think that's what Bill was talking about. You posted
patch 7.1.126 as "patch 7.1.126", then amended that posting with
one titled "About patch 7.1.126". We all understand that. The
odd thing is that the title of every subsequent patch posting
has begun with "About". It looks like a copy-and-paste error. Here
are your most recent patch postings as they appear in my mailer.

    Sep 26  Bram Moolenaar  patch 7.1.123
    Sep 29  Bram Moolenaar  patch 7.1.124
    Sep 29  Bram Moolenaar  patch 7.1.125
    Sep 30  Bram Moolenaar  patch 7.1.126
    Sep 30  Bram Moolenaar  About patch 7.1.126
    Sep 30  Bram Moolenaar  About patch 7.1.127
    Oct 01  Bram Moolenaar  About patch 7.1.129 (extra)
    Sep 30  Bram Moolenaar  About patch 7.1.128 (extra)
    Oct 01  Bram Moolenaar  About patch 7.1.130

Regards,
Gary

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

> Patch 7.1.130
> Problem:    Crash with specific order of undo and redo. (A.Politz)
> Solution:   Clear and adjust pointers properly.  Add u_check() for debugging.
> Files:     src/undo.c, src/structs.h

I shouldn't send out patches late at night...  The title should be
without "About"!

--
CART DRIVER: Bring out your dead!
    We follow the cart through a wretched, impoverished plague-ridden village.
    A few starved mongrels run about in the mud scavenging.  In the open
    doorway of one house perhaps we jug glimpse a pair of legs dangling from
    the ceiling.  In another doorway an OLD WOMAN is beating a cat against a
    wall rather like one does with a mat.  The cart passes round a dead donkey
    or cow in the mud.  And a MAN tied to a cart is being hammered to death by
    four NUNS with huge mallets.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        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 10/2/07, Bram Moolenaar <Bram@...> wrote:
>
>
> > Patch 7.1.130
> > Problem:    Crash with specific order of undo and redo. (A.Politz)
> > Solution:   Clear and adjust pointers properly.  Add u_check() for
debugging.
> > Files:            src/undo.c, src/structs.h
>
> I shouldn't send out patches late at night...  The title should be
> without "About"!

Could you please tell me that which titles should be with "About" and
which shouldn't?  It seems that many patches these days are all with
"About" prefix.

Any way, good night and sleep tight~


>
> --
> CART DRIVER: Bring out your dead!
>    We follow the cart through a wretched, impoverished plague-ridden village.
>    A few starved mongrels run about in the mud scavenging.  In the open
>    doorway of one house perhaps we jug glimpse a pair of legs dangling from
>    the ceiling.  In another doorway an OLD WOMAN is beating a cat against a
>    wall rather like one does with a mat.  The cart passes round a dead donkey
>    or cow in the mud.  And a MAN tied to a cart is being hammered to death by
>    four NUNS with huge mallets.
>                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
>
>  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
> ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\        download, build and distribute -- http://www.A-A-P.org        ///
>  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///
>
> >
>

L. F.

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

Edward L. Fox wrote:
[...]
> Could you please tell me that which titles should be with "About" and
> which shouldn't?  It seems that many patches these days are all with
> "About" prefix.
[...]

There was a recent thread about that. They all should be without, except the
"About" post about patch 126.

Best regards,
Tony.
--
Wit, n.:
	 The salt with which the American Humorist spoils his cookery
... by leaving it out.
		 -- Ambrose Bierce, "The Devil's Dictionary"

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

Bram Moolenaar schrieb:
> Patch 7.1.130
> Problem:    Crash with specific order of undo and redo. (A.Politz)
> Solution:   Clear and adjust pointers properly.  Add u_check() for debugging.
> Files:     src/undo.c, src/structs.h

Btw: How to reproduce this crash?

--
Andy

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

I ran "make test" after patch 7.1.130 and it failed test61 with the
following diff...

../vim -u unix.vim -U NONE --noplugin -s dotest.in test61.in
20c20
< 23456789
---
  > 123456789

I reran the test a few times and noticed that resizing the urxvt terminal
during the test caused the test to fail more often.

I re-ran "make test61.out" in a loop (removing the out file each time)
with the terminal window minimised and it failed one test (loop 47) in 130
loops. The failure had the following error.

../vim -u unix.vim -U NONE --noplugin -s dotest.in test61.in
20c20
< 3456789
---
Tests for undo tree.
Tests for undo tree.
  > 123456789

I reversed patch 7.1.130 and I ran the loop (minimised), it failed on loop
246 of 264 with the following diff...

../vim -u unix.vim -U NONE --noplugin -s dotest.in test61.in
20c20
< 23456789
---
Tests for undo tree.
  > 123456789


I don't know if this is a genuine failure of some race or mistake in the test.


------------------------------------------------------------------
VIM - Vi IMproved 7.1, Included patches: 1-94, 96-130
Normal version with GTK2 GUI.


regards,
JohnM

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

Hi,


I suspect that this issue relates to the complete removal of the lines
in question. No idea how hard this makes a possible fix. As the issue is
not critical (unlikely to be scripted, a human will notice), it might
not be worth the effort. Also, I might just no be aware of known
behaviour. In any case, here goes:

Select visual block    : ^v
Enter replace mode     : R
Go into command mode   : <esc>
Undo latest change     : u
Reselect latest vblock : gv

Expected behaviour:
   Visual block mode with the block selected

Shown behaviour:
   Visual line mode with all lines that were part of the block selected.


Thanks
Richard

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

Richard Hartmann schrieb:
> Hi,
>
>
> I suspect that this issue relates to the complete removal of the lines
> in question. No idea how hard this makes a possible fix. As the issue is
> not critical (unlikely to be scripted, a human will notice), it might
> not be worth the effort. Also, I might just no be aware of known
> behaviour. In any case, here goes:
>
> Select visual block    : ^v
> Enter replace mode     : R
> Go into command mode   : <esc>
> Undo latest change     : u
> Reselect latest vblock : gv
>
> Expected behaviour:
>   Visual block mode with the block selected
>
> Shown behaviour:
>   Visual line mode with all lines that were part of the block selected.
>
>
> Thanks
> Richard

R as a side effect changes the selection into line-wise (to replace the
lines and not only the block).
After gv, press Ctrl-V to get the blockwise selection back.

--
Andy

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

Richard Hartmann wrote:
> Hi,
>
>
> I suspect that this issue relates to the complete removal of the lines
> in question. No idea how hard this makes a possible fix. As the issue is
> not critical (unlikely to be scripted, a human will notice), it might
> not be worth the effort. Also, I might just no be aware of known
> behaviour. In any case, here goes:
>
> Select visual block    : ^v
> Enter replace mode     : R
> Go into command mode   : <esc>
> Undo latest change     : u
> Reselect latest vblock : gv
>
> Expected behaviour:
>   Visual block mode with the block selected
>
> Shown behaviour:
>   Visual line mode with all lines that were part of the block selected.
>
>
> Thanks
> Richard

Here when I hit shift-R, the whole lines containing the visual block get
replaced by one empty line. If I hit <Ins> instead, I get a beep. Checking for
mappings:

	 :map R
No mapping found
	 :map! R
No mapping found


It might be a feature rather than a bug: see
	 :help v_R
	 :help v_S

Best regards,
Tony.
--
If they can make penicillin out of moldy bread, they can sure make
something out of you.
		 -- Muhammad Ali

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

On 02/10/2007, Tony Mechelynck <antoine.mechelynck@...> wrote:

> It might be a feature rather than a bug: see
>         :help v_R
>         :help v_S

I _did_ check R, but I never knew v_foo existed. Thanks! Sounds to me as
if my expected behaviour is on Bram To{olong}do list, already :)


Richard

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

An attempt to implement v_R:

" File:         vbreplace.vim
" Created:      2007 Oct 02
" Last Change:  2007 Oct 02

" Implement v_b_R: works like v_b_I, but starts replace mode in every line.
" This is different from v_s (change the selection).
" Note: You should stick with Esc and Ctrl-C to quit replace mode.

vno R :<c-u>call <sid>Rstart()<cr>R

func! <sid>Rstart()
     if visualmode() != "\<c-v>"
	 return
     endif
     let s:col = virtcol(".")
     ino <esc> <esc>:call <sid>Repeat()<cr>
     ino <c-c> <c-c>:call <sid>Rend()<cr>
endfunc

func! <sid>Repeat()
     let sav_ve = &ve
     " set virtualedit+=onemore
     set virtualedit=all
     " without ve: would change the last char of a line if one column behind
     exec "'<,'>g/\\%>".(s:col-1).'v/normal! '.s:col.'|.'
     normal! `<m[
     let &ve = sav_ve
     call <sid>Rend()
endfunc

func! <sid>Rend()
     iun <esc>
     iun <c-c>
endfunc

" just found a bug:
"   :set ve+=onemore
"
" works with "2|", but not with ":normal! 2|" (check out with the above
" line)

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

Patch 7.1.131
Problem:    ":mksession" always adds ":setlocal autoread". (Christian J.
	     Robinson)
Solution:   Skip boolean global/local option using global value.
Files:     src/option.c


*** ../vim-7.1.130/src/option.c Wed Sep 26 22:35:06 2007
--- src/option.c Sun Sep 30 16:21:08 2007
***************
*** 8753,8758 ****
--- 8753,8760 ----
       char *name;
       int  value;
   {
+     if (value < 0) /* global/local option using global value */
+  return OK;
       if (fprintf(fd, "%s %s%s", cmd, value ? "" : "no", name) < 0
  	     || put_eol(fd) < 0)
  	 return FAIL;
*** ../vim-7.1.130/src/version.c Mon Oct  1 22:53:27 2007
--- src/version.c Tue Oct  2 20:39:02 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     131,
   /**/

--
ARTHUR: Old woman!
DENNIS: Man!
ARTHUR: Man.  I'm sorry.  Old man, What knight live in that castle over there?
DENNIS: I'm thirty-seven.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        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.1.132
Problem:    getpos("'>") may return a negative column number for a Linewise
	     selection. (A.Politz)
Solution:   Don't add one to MAXCOL.
Files:     src/eval.c


*** ../vim-7.1.131/src/eval.c Tue Sep 25 20:39:14 2007
--- src/eval.c Mon Oct  1 20:56:09 2007
***************
*** 10388,10394 ****
  	     list_append_number(l, (varnumber_T)0);
  	 list_append_number(l, (fp != NULL) ? (varnumber_T)fp->lnum
  							     : (varnumber_T)0);
!  list_append_number(l, (fp != NULL) ? (varnumber_T)fp->col + 1
  							     : (varnumber_T)0);
  	 list_append_number(l,
   #ifdef FEAT_VIRTUALEDIT
--- 10388,10395 ----
  	     list_append_number(l, (varnumber_T)0);
  	 list_append_number(l, (fp != NULL) ? (varnumber_T)fp->lnum
  							     : (varnumber_T)0);
!  list_append_number(l, (fp != NULL)
! 		     ? (varnumber_T)(fp->col == MAXCOL ? MAXCOL : fp->col + 1)
  							     : (varnumber_T)0);
  	 list_append_number(l,
   #ifdef FEAT_VIRTUALEDIT
*** ../vim-7.1.131/src/version.c Tue Oct  2 20:40:01 2007
--- src/version.c Tue Oct  2 22:07:17 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     132,
   /**/

--
"The future's already arrived - it's just not evenly distributed yet."
		 -- William Gibson

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

Edward L. Fox wrote:

> On 10/2/07, Bram Moolenaar <Bram@...> wrote:
> >
> >
> > > Patch 7.1.130
> > > Problem:    Crash with specific order of undo and redo. (A.Politz)
> > > Solution:   Clear and adjust pointers properly.  Add u_check() for
debugging.
> > > Files:            src/undo.c, src/structs.h
> >
> > I shouldn't send out patches late at night...  The title should be
> > without "About"!
>
> Could you please tell me that which titles should be with "About" and
> which shouldn't?  It seems that many patches these days are all with
> "About" prefix.

None of the actual patches should have "About" in the subject.

> Any way, good night and sleep tight~

I will.  But first finish reading all the messages...

--
Bad programs can be written in any language.

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

Alexei Alexandrov wrote:

> I try to update my Vim runtime files with AAP. I have AAP 1.090
> installed, plus Python 2.5. I execute command
>
>  > aap -f ftp://ftp.vim.org/pub/vim/runtime/main.aap fetch
>
> which is a copy-paste from Vim site and get the following error:
>
> fetch
> Aap: c:\cygwin\bin\gcc.EXE --version
> Aap: Attempting download of "ftp://ftp.vim.org/pub/vim/runtime/main.aap"
> Aap: Downloaded "ftp://ftp.vim.org/pub/vim/runtime/main.aap" to "main.aap"
> Aap: Updating recipe "main.aap"
> Aap: Attempting download of "ftp://ftp.vim.org/pub/vim/runtime/main.aap"
> Aap: Downloaded "ftp://ftp.vim.org/pub/vim/runtime/main.aap" to
> "D:\programs\vim\111\main.aap"
> Cannot read "filetype.vim", guessing fileformat is "dos".
> Aap: Attempting download of "ftp://ftp.vim.org/pub/vim/runtime/getdos.aap"
> Aap: Downloaded "ftp://ftp.vim.org/pub/vim/runtime/getdos.aap" to
> "D:\programs\vim\111\getdos.aap"
> Aap: Internal Error
> Aap: Traceback (most recent call last):
>     File "D:\programs\aap\Process.py", line 1163, in Process
>      exec script_string in recdict, recdict
>     File "<string>", line 7, in <module>
>     File "D:\programs\aap\Error.py", line 50, in __init__
>      self.args = args
>   TypeError: 'NoneType' object is not iterable
>
> Aap: Aborted
> Aap: More info in the logfile: D:\programs\vim\111\AAPDIR\log
>
> What might be the reason of the failure?

Hmm, perhaps another Python 2.5 incompatibility?  At least it works fine
for me with Python 2.4.2.

Can you please locate the Process.py file in the aap Exec directory, and
uncomment the msg_note() call below DEBUG?  Then we can see what code is
actually executed.  Aap generates Python code and executes it,
unfortunately Python then doesn't give good error messages.

--
THEOREM: VI is perfect.
PROOF: VI in roman numerals is 6.  The natural numbers < 6 which divide 6 are
1, 2, and 3. 1+2+3 = 6.  So 6 is a perfect number.  Therefore, VI is perfect.
QED
						     -- Arthur Tateishi

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

John Mullin wrote:

> I ran "make test" after patch 7.1.130 and it failed test61 with the
> following diff...
>
> ../vim -u unix.vim -U NONE --noplugin -s dotest.in test61.in
> 20c20
> < 23456789
> ---
>  > 123456789
>
> I reran the test a few times and noticed that resizing the urxvt terminal
> during the test caused the test to fail more often.
>
> I re-ran "make test61.out" in a loop (removing the out file each time)
> with the terminal window minimised and it failed one test (loop 47) in 130
> loops. The failure had the following error.
>
> ../vim -u unix.vim -U NONE --noplugin -s dotest.in test61.in
> 20c20
> < 3456789
> ---
> Tests for undo tree.
> Tests for undo tree.
>  > 123456789
>
> I reversed patch 7.1.130 and I ran the loop (minimised), it failed on loop
> 246 of 264 with the following diff...
>
> ../vim -u unix.vim -U NONE --noplugin -s dotest.in test61.in
> 20c20
> < 23456789
> ---
> Tests for undo tree.
>  > 123456789
>
>
> I don't know if this is a genuine failure of some race or mistake in
> the test.

It's a race condition.  The test checks if jumping back in time works
for undo.  This is inherently tricky, especially on a slow system or
when something else takes away CPU time.  I did manage to make it mostly
work, but it may still fail once in a while.

If it works more than 50% of the time it should be OK.

--
OLD WOMAN: King of the WHO?
ARTHUR:    The Britons.
OLD WOMAN: Who are the Britons?
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        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
-~----------~----~----~----~------~----~------~--~---

Andy Wokula wrote:

> Bram Moolenaar schrieb:
> > Patch 7.1.130
> > Problem:    Crash with specific order of undo and redo. (A.Politz)
> > Solution:   Clear and adjust pointers properly.  Add u_check() for
debugging.
> > Files:     src/undo.c, src/structs.h
>
> Btw: How to reproduce this crash?

A.Politz made this script:


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
"Function : Segfault
"Args     : None
"Purpose  : Called by the "UserGettingBored" aucommand.
func! Segfault()
   setl noswapfile
   new
   setl noswapfile
   set undolevels=3
   put =0
   put =1
   set undolevels=3
   put =2
   set undolevels=3
   put =3
   set undolevels=3
   put =4
   set undolevels=1
   norm 3u
   set undolevels=3
   put =5
   set undolevels=1
   norm 3u
endfun


call Segfault()
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Even with some small changes it still crashes, tries to free memory
that's already free, hangs, and other nasty things.

--
OLD WOMAN: Well, how did you become king, then?
ARTHUR: The Lady of the Lake, her arm clad in the purest shimmering samite,
         held Excalibur aloft from the bosom of the water to signify by Divine
         Providence ...  that I, Arthur, was to carry Excalibur ...  That is
         why I am your king!
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        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
-~----------~----~----~----~------~----~------~--~---