Hi all,

Description:
  Vim's restore session mechanism doesn't restore the buffer numbers properly. 
Buffer #1 is skipped and the buffers in Session.vim are appended to it, so they
start at #2.


Version:
  7.3.495


References to the same problem:
 
http://larig.wordpress.com/2012/02/14/vim-sessions-and-the-missing-first-buffer/


Reproduce problem:
  vim a b
   :ls
   :mksession
   :qa
  vim -S
   :ls


Possible solution:
  Add a workaround-function, say :bfrom1, that shifts all buffer numbers one
position to the left if the first buffer is wiped-out.  This fuction can then be
called in Session.vim after wiping buffer #1:
   if exists('s:wipebuf')
     silent exe 'bwipe ' . s:wipebuf
     bfrom1
   endif


Best,
Daan

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

Bram,
When working on my plugin SudoEdit[1], I noticed a crash in certain
circumstances, which I can reproduce currently.

Basically, with the plugin installed, you need to do:
:e sudo://etc/fstab
[change something]
:w!
:e!
at this point, Vim crashes. Here is a backtrace:

Program received signal SIGABRT, Aborted.
0x00007ffff63d73a5 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht
gefunden.
         in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x00007ffff63d73a5 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff63dab0b in __GI_abort () at abort.c:92
#2  0x00007ffff6410d63 in __libc_message (do_abort=2, fmt=0x7ffff6501e58 "***
glibc detected *** %s: %s: 0x%s ***\n")
     at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00007ffff641b6e6 in malloc_printerr (action=3, str=0x7ffff64fee6f "free():
invalid pointer", ptr=<optimized out>)
     at malloc.c:6283
#4  0x00007ffff641f9cc in __GI___libc_free (mem=<optimized out>) at
malloc.c:3738
#5  0x00000000004c5163 in vim_free (x=0x97c888) at misc2.c:1740
#6  0x0000000000550c8b in reset_synblock (wp=0x7f47a0) at syntax.c:3475
#7  0x0000000000405a8f in buf_freeall (buf=0x7f5f80, flags=4) at buffer.c:591
#8  0x000000000044ff89 in do_ecmd (fnum=0, ffname=0x94f560 "sudo://etc/fstab",
sfname=0x956ae0 "sudo://etc/fstab",
     eap=0x7fffffffd630, newlnum=19, flags=9, oldwin=0x7f47a0) at ex_cmds.c:3593
#9  0x0000000000467d1f in do_exedit (eap=0x7fffffffd630, old_curwin=0x0) at
ex_docmd.c:7759
#10 0x00000000004679dc in ex_edit (eap=0x7fffffffd630) at ex_docmd.c:7655
#11 0x000000000045f960 in do_one_cmd (cmdlinep=0x7fffffffd818, sourcing=0,
cstack=0x7fffffffd8b0,
     fgetline=0x473ccb <getexline>, cookie=0x0) at ex_docmd.c:2668
#12 0x000000000045cfb3 in do_cmdline (cmdline=0x0, fgetline=0x473ccb
<getexline>, cookie=0x0, flags=0)
     at ex_docmd.c:1122
#13 0x00000000004d6df8 in nv_colon (cap=0x7fffffffddd0) at normal.c:5404
#14 0x00000000004d08fa in normal_cmd (oap=0x7fffffffde90, toplevel=1) at
normal.c:1193
#15 0x0000000000583c68 in main_loop (cmdwin=0, noexmode=0) at main.c:1282
#16 0x0000000000583733 in main (argc=1, argv=0x7fffffffe1a8) at main.c:986

What happens is, that curwin->w_s differs from curwin->w_buffer->b_s
so both should be the same. The following patch fixes it for me:

diff --git a/src/fileio.c b/src/fileio.c
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -8992,6 +8992,7 @@

             curwin = aco->save_curwin;
             curbuf = curwin->w_buffer;
+           curwin->w_s = &(curbuf->b_s);
         }
      }
  }


[1] http://www.vim.org/scripts/script.php?script_id=2709

regards,
Christian

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

Christian Brabandt wrote:

> When working on my plugin SudoEdit[1], I noticed a crash in certain
> circumstances, which I can reproduce currently.
>
> Basically, with the plugin installed, you need to do:
> :e sudo://etc/fstab
> [change something]
> :w!
> :e!
> at this point, Vim crashes. Here is a backtrace:
>
> Program received signal SIGABRT, Aborted.
> 0x00007ffff63d73a5 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht
gefunden.
>         in ../nptl/sysdeps/unix/sysv/linux/raise.c
> (gdb) bt
> #0  0x00007ffff63d73a5 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1  0x00007ffff63dab0b in __GI_abort () at abort.c:92
> #2  0x00007ffff6410d63 in __libc_message (do_abort=2, fmt=0x7ffff6501e58 "***
glibc detected *** %s: %s: 0x%s ***\n")
>     at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
> #3  0x00007ffff641b6e6 in malloc_printerr (action=3, str=0x7ffff64fee6f
"free(): invalid pointer", ptr=<optimized out>)
>     at malloc.c:6283
> #4  0x00007ffff641f9cc in __GI___libc_free (mem=<optimized out>) at
malloc.c:3738
> #5  0x00000000004c5163 in vim_free (x=0x97c888) at misc2.c:1740
> #6  0x0000000000550c8b in reset_synblock (wp=0x7f47a0) at syntax.c:3475
> #7  0x0000000000405a8f in buf_freeall (buf=0x7f5f80, flags=4) at buffer.c:591
> #8  0x000000000044ff89 in do_ecmd (fnum=0, ffname=0x94f560 "sudo://etc/fstab",
sfname=0x956ae0 "sudo://etc/fstab",
>     eap=0x7fffffffd630, newlnum=19, flags=9, oldwin=0x7f47a0) at
ex_cmds.c:3593
> #9  0x0000000000467d1f in do_exedit (eap=0x7fffffffd630, old_curwin=0x0) at
ex_docmd.c:7759
> #10 0x00000000004679dc in ex_edit (eap=0x7fffffffd630) at ex_docmd.c:7655
> #11 0x000000000045f960 in do_one_cmd (cmdlinep=0x7fffffffd818, sourcing=0,
cstack=0x7fffffffd8b0,
>     fgetline=0x473ccb <getexline>, cookie=0x0) at ex_docmd.c:2668
> #12 0x000000000045cfb3 in do_cmdline (cmdline=0x0, fgetline=0x473ccb
<getexline>, cookie=0x0, flags=0)
>     at ex_docmd.c:1122
> #13 0x00000000004d6df8 in nv_colon (cap=0x7fffffffddd0) at normal.c:5404
> #14 0x00000000004d08fa in normal_cmd (oap=0x7fffffffde90, toplevel=1) at
normal.c:1193
> #15 0x0000000000583c68 in main_loop (cmdwin=0, noexmode=0) at main.c:1282
> #16 0x0000000000583733 in main (argc=1, argv=0x7fffffffe1a8) at main.c:986
>
> What happens is, that curwin->w_s differs from curwin->w_buffer->b_s
> so both should be the same. The following patch fixes it for me:
>
> diff --git a/src/fileio.c b/src/fileio.c
> --- a/src/fileio.c
> +++ b/src/fileio.c
> @@ -8992,6 +8992,7 @@
>
>             curwin = aco->save_curwin;
>             curbuf = curwin->w_buffer;
> +           curwin->w_s = &(curbuf->b_s);
>         }
>      }
>  }

I don't quite understand the solution.  How is it possible that
curwin->w_s gets a wrong value?  It was moved aside thus it should not
change.  And what if ":ownsyntax" was used, doesn't this leak memory?

--
Two cows are standing together in a field.  One asks the other:
"So what do you think about this Mad Cow Disease?"
The other replies: "That doesn't concern me. I'm a helicopter."

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

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

Hi Bram!

On Sa, 21 Apr 2012, Bram Moolenaar wrote:

>
> Christian Brabandt wrote:
>
> > When working on my plugin SudoEdit[1], I noticed a crash in certain
> > circumstances, which I can reproduce currently.
> >
> > Basically, with the plugin installed, you need to do:
> > :e sudo://etc/fstab
> > [change something]
> > :w!
> > :e!
> > at this point, Vim crashes. Here is a backtrace:
> >
> > Program received signal SIGABRT, Aborted.
> > 0x00007ffff63d73a5 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
> > 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis
nicht gefunden.
> >         in ../nptl/sysdeps/unix/sysv/linux/raise.c
> > (gdb) bt
> > #0  0x00007ffff63d73a5 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
> > #1  0x00007ffff63dab0b in __GI_abort () at abort.c:92
> > #2  0x00007ffff6410d63 in __libc_message (do_abort=2, fmt=0x7ffff6501e58
"*** glibc detected *** %s: %s: 0x%s ***\n")
> >     at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
> > #3  0x00007ffff641b6e6 in malloc_printerr (action=3, str=0x7ffff64fee6f
"free(): invalid pointer", ptr=<optimized out>)
> >     at malloc.c:6283
> > #4  0x00007ffff641f9cc in __GI___libc_free (mem=<optimized out>) at
malloc.c:3738
> > #5  0x00000000004c5163 in vim_free (x=0x97c888) at misc2.c:1740
> > #6  0x0000000000550c8b in reset_synblock (wp=0x7f47a0) at syntax.c:3475
> > #7  0x0000000000405a8f in buf_freeall (buf=0x7f5f80, flags=4) at
buffer.c:591
> > #8  0x000000000044ff89 in do_ecmd (fnum=0, ffname=0x94f560
"sudo://etc/fstab", sfname=0x956ae0 "sudo://etc/fstab",
> >     eap=0x7fffffffd630, newlnum=19, flags=9, oldwin=0x7f47a0) at
ex_cmds.c:3593
> > #9  0x0000000000467d1f in do_exedit (eap=0x7fffffffd630, old_curwin=0x0) at
ex_docmd.c:7759
> > #10 0x00000000004679dc in ex_edit (eap=0x7fffffffd630) at ex_docmd.c:7655
> > #11 0x000000000045f960 in do_one_cmd (cmdlinep=0x7fffffffd818, sourcing=0,
cstack=0x7fffffffd8b0,
> >     fgetline=0x473ccb <getexline>, cookie=0x0) at ex_docmd.c:2668
> > #12 0x000000000045cfb3 in do_cmdline (cmdline=0x0, fgetline=0x473ccb
<getexline>, cookie=0x0, flags=0)
> >     at ex_docmd.c:1122
> > #13 0x00000000004d6df8 in nv_colon (cap=0x7fffffffddd0) at normal.c:5404
> > #14 0x00000000004d08fa in normal_cmd (oap=0x7fffffffde90, toplevel=1) at
normal.c:1193
> > #15 0x0000000000583c68 in main_loop (cmdwin=0, noexmode=0) at main.c:1282
> > #16 0x0000000000583733 in main (argc=1, argv=0x7fffffffe1a8) at main.c:986
> >
> > What happens is, that curwin->w_s differs from curwin->w_buffer->b_s
> > so both should be the same. The following patch fixes it for me:
> >
> > diff --git a/src/fileio.c b/src/fileio.c
> > --- a/src/fileio.c
> > +++ b/src/fileio.c
> > @@ -8992,6 +8992,7 @@
> >
> >             curwin = aco->save_curwin;
> >             curbuf = curwin->w_buffer;
> > +           curwin->w_s = &(curbuf->b_s);
> >         }
> >      }
> >  }
>
> I don't quite understand the solution.  How is it possible that
> curwin->w_s gets a wrong value?  It was moved aside thus it should not
> change.  And what if ":ownsyntax" was used, doesn't this leak memory?

Shouldn't curwin->w_s point to the same value as curwin->w_buffer->b_s?
In this case it didn't and since I didn't use :ownsyntax, I figured they
should stay the same.  I am not sure, why they differ at all.

regards,
Christian

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

Christian Brabandt wrote:

> > > When working on my plugin SudoEdit[1], I noticed a crash in certain
> > > circumstances, which I can reproduce currently.
> > >
> > > Basically, with the plugin installed, you need to do:
> > > :e sudo://etc/fstab
> > > [change something]
> > > :w!
> > > :e!
> > > at this point, Vim crashes. Here is a backtrace:
> > >
> > > Program received signal SIGABRT, Aborted.
> > > 0x00007ffff63d73a5 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
> > > 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis
nicht gefunden.
> > >         in ../nptl/sysdeps/unix/sysv/linux/raise.c
> > > (gdb) bt
> > > #0  0x00007ffff63d73a5 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
> > > #1  0x00007ffff63dab0b in __GI_abort () at abort.c:92
> > > #2  0x00007ffff6410d63 in __libc_message (do_abort=2, fmt=0x7ffff6501e58
"*** glibc detected *** %s: %s: 0x%s ***\n")
> > >     at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
> > > #3  0x00007ffff641b6e6 in malloc_printerr (action=3, str=0x7ffff64fee6f
"free(): invalid pointer", ptr=<optimized out>)
> > >     at malloc.c:6283
> > > #4  0x00007ffff641f9cc in __GI___libc_free (mem=<optimized out>) at
malloc.c:3738
> > > #5  0x00000000004c5163 in vim_free (x=0x97c888) at misc2.c:1740
> > > #6  0x0000000000550c8b in reset_synblock (wp=0x7f47a0) at syntax.c:3475
> > > #7  0x0000000000405a8f in buf_freeall (buf=0x7f5f80, flags=4) at
buffer.c:591
> > > #8  0x000000000044ff89 in do_ecmd (fnum=0, ffname=0x94f560
"sudo://etc/fstab", sfname=0x956ae0 "sudo://etc/fstab",
> > >     eap=0x7fffffffd630, newlnum=19, flags=9, oldwin=0x7f47a0) at
ex_cmds.c:3593
> > > #9  0x0000000000467d1f in do_exedit (eap=0x7fffffffd630, old_curwin=0x0)
at ex_docmd.c:7759
> > > #10 0x00000000004679dc in ex_edit (eap=0x7fffffffd630) at ex_docmd.c:7655
> > > #11 0x000000000045f960 in do_one_cmd (cmdlinep=0x7fffffffd818, sourcing=0,
cstack=0x7fffffffd8b0,
> > >     fgetline=0x473ccb <getexline>, cookie=0x0) at ex_docmd.c:2668
> > > #12 0x000000000045cfb3 in do_cmdline (cmdline=0x0, fgetline=0x473ccb
<getexline>, cookie=0x0, flags=0)
> > >     at ex_docmd.c:1122
> > > #13 0x00000000004d6df8 in nv_colon (cap=0x7fffffffddd0) at normal.c:5404
> > > #14 0x00000000004d08fa in normal_cmd (oap=0x7fffffffde90, toplevel=1) at
normal.c:1193
> > > #15 0x0000000000583c68 in main_loop (cmdwin=0, noexmode=0) at main.c:1282
> > > #16 0x0000000000583733 in main (argc=1, argv=0x7fffffffe1a8) at main.c:986
> > >
> > > What happens is, that curwin->w_s differs from curwin->w_buffer->b_s
> > > so both should be the same. The following patch fixes it for me:
> > >
> > > diff --git a/src/fileio.c b/src/fileio.c
> > > --- a/src/fileio.c
> > > +++ b/src/fileio.c
> > > @@ -8992,6 +8992,7 @@
> > >
> > >             curwin = aco->save_curwin;
> > >             curbuf = curwin->w_buffer;
> > > +           curwin->w_s = &(curbuf->b_s);
> > >         }
> > >      }
> > >  }
> >
> > I don't quite understand the solution.  How is it possible that
> > curwin->w_s gets a wrong value?  It was moved aside thus it should not
> > change.  And what if ":ownsyntax" was used, doesn't this leak memory?
>
> Shouldn't curwin->w_s point to the same value as curwin->w_buffer->b_s?
> In this case it didn't and since I didn't use :ownsyntax, I figured they
> should stay the same.  I am not sure, why they differ at all.

Well, we better find out why w_s gets another value without using
:ownsyntax.  I think the way you solve it may break :ownsyntax or leak
memory, if we know the cause of the problem we might see a better
solution.  In gdb you can set a watch point on the variable.  You could
set a breakpoint in aucmd_prepbuf() and then set the watch point once it
has set aco->save_curwin.

--
ARTHUR: Did you say shrubberies?
ROGER:  Yes.  Shrubberies are my trade.  I am a shrubber.  My name is Roger
         the Shrubber.  I arrange, design, and sell shrubberies.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

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

ÞÅÔ×ÅÒÇ, 19 ÁÐÒÅÌÑ 2012 Ç., 21:53:43 UTC+4 ÐÏÌØÚÏ×ÁÔÅÌØ ZyX ÎÁÐÉÓÁÌ:
> ÐÏÎÅÄÅÌØÎÉË, 16 ÁÐÒÅÌÑ 2012 Ç., 19:24:21 UTC+4 ÐÏÌØÚÏ×ÁÔÅÌØ ZyX ÎÁÐÉÓÁÌ:
> > ÐÏÎÅÄÅÌØÎÉË, 16 ÁÐÒÅÌÑ 2012 Ç., 4:46:27 UTC+4 ÐÏÌØÚÏ×ÁÔÅÌØ Luis Carvalho
ÎÁÐÉÓÁÌ:
> > > <snip>
> > > > > So is this patch ready to be included now?
> > > > > Or should we wait until Python 3 is supported?
> > > >
> > > > Attached patch adds both python and python3 extended support (also adds
> > > > luaeval to syntax/vim.vim as it is absent there).
> > > <snip>
> > >
> > > Thanks for the great job! Since you're hacking at eval.c, can I ask you to
> > > also add the following to the prototype, i.e., promote them from static to
> > > extern:
> > >
> > > - listitem_alloc, list_find, list_remove, list_append (for symmetry with
> > >   dicts)
> > > - set_ref_in_ht, set_ref_in_list, set_ref_in_item (you copied from if_lua,
but
> > >   I copied and adapted them from eval.c before)
> > >
> > > Besides avoiding redundancies, these changes enrich the API and make for
an
> > > easier road to other language bindings. Thanks again!
> >
> > Here is the patch with functions promoted. Other differences between
previously posted one:
> > 1. Removed pyhashtab_T which is difficult to maintain (I definitely have an
error there, but unable to track it). Now all references are hold in a linked
list (thus no more "one python object for one vim structure", creating python
object must be faster as well as removing it (both not for the already
referenced structure obviously))
> > 2. pythreeeval() replaced with py3eval().
> > 3. Now using PyDict_Next instead of PyDict_Items which should be faster.
>
> Newer version (diff against lua-changes). Differences:
>
> - Added support for objects that support mapping, sequence and iterator
protocols
> - Some refactoring: moved ConvertToPyObject, FunctionNew to if_py_both.h, ....
> - Moved some code from ConvertToPyObject to a separate functions
> - Some error fixes: compiling with python3, but without python support, some
things left from the time I thought it may be a good idea to not raise the
exceptions under certain conditions.

New version:
1. It is now possible to pyeval() recursive python objects, like this:
     py l=[]; l.append(l)
     let l=pyeval('l')
     echo l is l[0] " True
2. It now uses %p printf format to generate keys for vim.eval(). It is faster
and, I believe, better then casting pointers to unsigned long and printing it as
decimal.
3. python2 now also uses long objects to hold integers, not int objects.

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

×ÏÓËÒÅÓÅÎØÅ, 22 ÁÐÒÅÌÑ 2012 Ç., 16:49:28 UTC+4 ÐÏÌØÚÏ×ÁÔÅÌØ ZyX ÎÁÐÉÓÁÌ:
> ÞÅÔ×ÅÒÇ, 19 ÁÐÒÅÌÑ 2012 Ç., 21:53:43 UTC+4 ÐÏÌØÚÏ×ÁÔÅÌØ ZyX ÎÁÐÉÓÁÌ:
> > ÐÏÎÅÄÅÌØÎÉË, 16 ÁÐÒÅÌÑ 2012 Ç., 19:24:21 UTC+4 ÐÏÌØÚÏ×ÁÔÅÌØ ZyX ÎÁÐÉÓÁÌ:
> > > ÐÏÎÅÄÅÌØÎÉË, 16 ÁÐÒÅÌÑ 2012 Ç., 4:46:27 UTC+4 ÐÏÌØÚÏ×ÁÔÅÌØ Luis Carvalho
ÎÁÐÉÓÁÌ:
> > > > <snip>
> > > > > > So is this patch ready to be included now?
> > > > > > Or should we wait until Python 3 is supported?
> > > > >
> > > > > Attached patch adds both python and python3 extended support (also
adds
> > > > > luaeval to syntax/vim.vim as it is absent there).
> > > > <snip>
> > > >
> > > > Thanks for the great job! Since you're hacking at eval.c, can I ask you
to
> > > > also add the following to the prototype, i.e., promote them from static
to
> > > > extern:
> > > >
> > > > - listitem_alloc, list_find, list_remove, list_append (for symmetry with
> > > >   dicts)
> > > > - set_ref_in_ht, set_ref_in_list, set_ref_in_item (you copied from
if_lua, but
> > > >   I copied and adapted them from eval.c before)
> > > >
> > > > Besides avoiding redundancies, these changes enrich the API and make for
an
> > > > easier road to other language bindings. Thanks again!
> > >
> > > Here is the patch with functions promoted. Other differences between
previously posted one:
> > > 1. Removed pyhashtab_T which is difficult to maintain (I definitely have
an error there, but unable to track it). Now all references are hold in a linked
list (thus no more "one python object for one vim structure", creating python
object must be faster as well as removing it (both not for the already
referenced structure obviously))
> > > 2. pythreeeval() replaced with py3eval().
> > > 3. Now using PyDict_Next instead of PyDict_Items which should be faster.
> >
> > Newer version (diff against lua-changes). Differences:
> >
> > - Added support for objects that support mapping, sequence and iterator
protocols
> > - Some refactoring: moved ConvertToPyObject, FunctionNew to if_py_both.h,
....
> > - Moved some code from ConvertToPyObject to a separate functions
> > - Some error fixes: compiling with python3, but without python support, some
things left from the time I thought it may be a good idea to not raise the
exceptions under certain conditions.
>
> New version:
> 1. It is now possible to pyeval() recursive python objects, like this:
>     py l=[]; l.append(l)
>     let l=pyeval('l')
>     echo l is l[0] " True
> 2. It now uses %p printf format to generate keys for vim.eval(). It is faster
and, I believe, better then casting pointers to unsigned long and printing it as
decimal.
> 3. python2 now also uses long objects to hold integers, not int objects.

Forgot the patch itself, sorry.

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

Attached patch adds luaeval() documentation to doc/eval.txt.

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

Hi Bram,

>> I've been trying to get the tests running on Windows; the latest roadblock
>> was test11.  test11 works correctly using vim.exe from the officially built
>> binary distribution (7.3.48), but not on vim.exe built from the latest
>> source (7.3.496).  I finally got to play with 'hg bisect', very fun.
>>
>> This patch does three things, all of them related and necessary:
>>
>> 1. Revert the only not-100%-straightforward change that was in patch 124.
>>
>> Patch 124 was mainly about moving the "did-i-have-an-eol-when-i-loaded"
>> setting from global to per-buffer, but it also changed the point at which
>> the setting was reset.  This patch undoes that last part.  There was a
>> comment about the line number becoming invalid due to edits, which I didn't
>> follow up on.
>
> You do not mention what breaks without this change.  What is it?  Can we
> write a test for it?

test11 itself breaks starting with patch 124; it works on patch 123
and previous.  The break doesn't show up as a nonzero diff result.
Instead it just leaves vim sitting in insert mode halfway through the
test, editing a garbled test.out.

In addition to making "did-i-have-an-eol-when-i-loaded" per-buffer
instead of global, patch 124 also moved the line

     curbuf->b_no_eol_lnum = 0;

from the end of buf_write() to the end of readfile().  I don't know
what the author's exact intent for this change was; it seems
inconsistent with the rest of the patch, although I admit I'm far from
100% up to speed on the vim codebase.

Keeping it the way it was written (but applying the filterpipe fix)
causes test11 to fail because gzip corrupts the output.  Here's the
end of test.out when that happens:

/*
  * HEre is a new .c file
  */
^_?^H^@¥^T?O^@^C+.I,*QEOS(I-.IEIIåEÉIKU0âtLJNIMKIEIEIÉIE/(,*.)-+_"¬?"0æ¬A^K
ªL^H?cJ?9f^DI1'E^\^K?æX^RE?¡?^B^^?RóRP?^T^@!qs&e^A^@^@
/*
  * HEre is a new .c file
  */
^_?^H^@¥^T?O^@^C+.I,*QEOS(I-.IEIIåEÉIKU0âtLJNIMKIEIEIÉIE/(,*.)-+_"¬?"0æ¬A^K
ªL^H?cJ?9f^DI1'E^\^K?æX^Re?¡?^B^^?RóRP?^T^@!qs&e^A^@^@

Reverting the change (keeping all the other per-buffer changes in
patch 124) causes the test to complete successfully, which I assume
means it was interfering with the binary representation of the file
and confusing gzip.

>> 2. Correctly sets has("filterpipe") as "false" on the Windows console,
>> leaving it enabled in the GUI as intended by patch 240.
>>
>> Almost all the code in patch 240 was guarded with FEAT_GUI_W32; for some
>> reason the change to add has("filterpipe") wasn't.  I took a look at
>> generalizing the pipe code to cover the console, but it's very GUI-specific
>> as written.  For the time being the console doesn't do pipes.
>
> This isn't quite right.  In ex_cmds.c around line 1117 there is a
> condition that only checks WIN3264, not FEAT_GUI_W32.  Thus pipes are
> used on the console as well.  It's not clear to me where that happens
> though, perhaps resetting 'shelltemp' breaks filtering?

In os_win32.c, the piping code is compiled out of the console version.
  See mch_system() around line 3861 for the shelltemp check itself,
which is only in the GUI version.  The #ifdef that enables all the
pipe-related code is around line 3250, and checks for FEAT_GUI_W32.  I
ran it under the debugger, and mch_system() went straight into the
MSCVRT system() call, not the pipe-enabled vim code.

As the code is written it's clear that the console was meant to be excluded:
   - There's a full Windows message loop
(PeekMessage/TranslateMessage/DispatchMessage), which couldn't work in
the console.
   - On pre-W2K systems, piping creates another console window, which
would only be acceptable in the GUI.
   - See the comments at the start of mch_system_classic() and
mch_system_piped().
   - See the end of mch_call_shell() for more GUI-only #ifdefs and
comments related to piping.

The code in ex_cmds.c:do_filter() sets SHELL_* flags that are consumed
by this GUI-only code; those flags are ignored in the console.  It
also adjusts some line numbers, which would NOT be ignored in the
console; these may be the immediate cause of the test failure (see
below).

>> 3. In test11, set shelltemp before filtering through gzip if
>> has("filterpipe") is false.
>
> This should not be needed, if piping through a filter doesn't work Vim
> should automatically use temp files.  Perhaps this is because of the
> problem in do_filter()?

You're right, when I add a FEAT_GUI_W32 check to the WIN3264 check in
do_filter() like I did in eval.c, the change to test11.in isn't
needed.  I have updated the patch (attached).

>> I suspect this patch fixes a number of potential filtering issues on the
>> Windows console.
>
> If there are problems that get fixed, we should have a test to verify
> that.

Agreed.  The confusing part is that I assume that other folks ran the
tests without issue up to now.  It's possible that either my build
choices or my environment exposed the bugs.  I build using "nmake -f
Make_mvc.mak FEATURES=HUGE MBYTE=yes".  If others can make the
unpatched test11 work using console vim with these settings, I'd want
to dig in to find out what's different between our systems.  That
said, I do think the bugs are real; I don't see how gzip filtering
could have worked in the console without these fixes.  So, I hesitate
to suggest a test without understanding this discrepancy.

-- Dave

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

ZyX wrote:

> Attached patch adds luaeval() documentation to doc/eval.txt.

Thanks, I'll include it soon.

--
TALL KNIGHT: When you have found the shrubbery, then you must cut down the
              mightiest tree in the forest ... with a herring.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

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

On 20/04/12 19:07, Daan van Rossum wrote:
> Hi all,
>
> Description:
>   Vim's restore session mechanism doesn't restore the buffer numbers properly.
Buffer #1 is skipped and the buffers in Session.vim are appended to it, so they
start at #2.
>
>
> Version:
>   7.3.495
>
>
> References to the same problem:
>  
http://larig.wordpress.com/2012/02/14/vim-sessions-and-the-missing-first-buffer/
>
>
> Reproduce problem:
>   vim a b
>    :ls
>    :mksession
>    :qa
>   vim -S
>    :ls
>
>
> Possible solution:
>   Add a workaround-function, say :bfrom1, that shifts all buffer numbers one
position to the left if the first buffer is wiped-out.  This fuction can then be
called in Session.vim after wiping buffer #1:
>    if exists('s:wipebuf')
>      silent exe 'bwipe ' . s:wipebuf
>      bfrom1
>    endif
>
>
> Best,
> Daan
>


AFAIK buffer numbers are not meant to persist between sessions, even
efter ":mksession" ":quit" "vim -S" — if you've used :bwipeout there are
"holes" in the list of buffer numbers; after reload those holes are not
preserved.

What is supposed to be preserved are buffer names (and full paths for
buffers whose 'buftype' is not "nofile") and windows.


Best regards,
Tony.
--
Most fish live underwater, which is a terrible place to have sex
because virtually anywhere you lie down there will be stinging crabs
and large quantities of little fish staring at you with buggy little
eyes.  So generally when two fish want to have sex, they swim around
and around for hours, looking for someplace to go, until finally the
female gets really tired and has a terrible headache, and she just
dumps her eggs right on the sand and swims away.  Then the male, driven
by some timeless, noble instinct for survival, eats the eggs.  So the
truth is that fish don't reproduce at all, but there are so many of
them that it doesn't make any difference.
		 -- Dave Barry, "Sex and the Single Amoeba: What Every
		    Teen Should Know"

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

Hi

I would like to propose this theme for GVim future feature  (new
options for "set clipboard")
For someone who know very well gvim source code, its simple to
implement (i think).

Context of problem:
----------------------------

I wonder, how i can enable auto copy of selected text into '+'
register in Ubuntu (to share clipboard between apps).
i have  set guioptions+=a

my test case (with behave mswin):
1) open gvim
2)shift-v, move cursor and Esc (select lines in visual mode)
3)go to firefox and click ctrl-v or ctrl-Insert

In Win xp this works perfectly. But not in X (my example is Ubuntu
11.10 )
I know that in X system this works different way and i tried to solve
this in this thread:

"gvim auto copy selected text to clipboard"
http://groups.google.com/group/vim_use/browse_thread/thread/d2d8516f9465301a/fae\
6c620e232af00?lnk=gst&q=vakulenko#fae6c620e232af00

http://stackoverflow.com/questions/10259366/gvim-auto-copy-selected-text-to-syst\
em-clipboard-to-share-it-with-apps

conclusion: its impossible configure gvim to auto copy selected buffer
in + register.
small resume of main (first) thread:

I have many proposition how to auto copy selected(visual) buffer in +
register.
But no one not work in way described in Subject. Major propositions:
1) use mouse click copy
2) ctrl-insert bind "y+
3) use third party clipboard.


There is no solutions but workarounds. Hence, it will be nice have
this feature in gvim.


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

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 63 by daddyez...@...: sed: RE error: illegal byte sequence
http://code.google.com/p/vim/issues/detail?id=63

What steps will reproduce the problem?
1. clone repo
2. ./configure
3. make

What version of the product are you using? On what operating system?

latest version 7.3.300+

Please provide any additional information below.

On osx I've some troubles compiling vim, this because this file:
runtime/tools/efm_perl.pl

em_perl.pl contains an UTF-8 char but the file isn't encoded correctly (?)

So I got:

perlpath=`./which.sh perl` && sed
-e "s+/usr/bin/perl+$perlpath+" ../runtime/tools/efm_perl.pl
>/usr/local/src/vim/HEAD/share/vim/vim73/tools/efm_perl.pl
sed: RE error: illegal byte sequence
make[1]: *** [installtools] Error 1

My locale is correctly UTF8

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

My fix at the moment is:

iconv -c -t UTF-8 ./runtime/tools/efm_perl.pl > ./runtime/tools/efm_perl.pl

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

Comment #1 on issue 63 by vega.james@...: sed: RE error: illegal byte
sequence
http://code.google.com/p/vim/issues/detail?id=63

efm_perl.pl is encoded as latin1, not UTF-8.

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

ÐÏÎÅÄÅÌØÎÉË, 23 ÁÐÒÅÌÑ 2012 Ç., 12:32:38 UTC+4 ÐÏÌØÚÏ×ÁÔÅÌØ Sergey Vakulenko
ÎÁÐÉÓÁÌ:
> Hi
>
> I would like to propose this theme for GVim future feature  (new
> options for "set clipboard")
> For someone who know very well gvim source code, its simple to
> implement (i think).
>
> Context of problem:
> ----------------------------
>
> I wonder, how i can enable auto copy of selected text into '+'
> register in Ubuntu (to share clipboard between apps).
> i have  set guioptions+=a
>
> my test case (with behave mswin):
> 1) open gvim
> 2)shift-v, move cursor and Esc (select lines in visual mode)
> 3)go to firefox and click ctrl-v or ctrl-Insert
>
> In Win xp this works perfectly. But not in X (my example is Ubuntu
> 11.10 )
> I know that in X system this works different way and i tried to solve
> this in this thread:
>
> "gvim auto copy selected text to clipboard"
>
http://groups.google.com/group/vim_use/browse_thread/thread/d2d8516f9465301a/fae\
6c620e232af00?lnk=gst&q=vakulenko#fae6c620e232af00
>
>
http://stackoverflow.com/questions/10259366/gvim-auto-copy-selected-text-to-syst\
em-clipboard-to-share-it-with-apps
>
> conclusion: its impossible configure gvim to auto copy selected buffer
> in + register.
> small resume of main (first) thread:
>
> I have many proposition how to auto copy selected(visual) buffer in +
> register.
> But no one not work in way described in Subject. Major propositions:
> 1) use mouse click copy
> 2) ctrl-insert bind "y+
> 3) use third party clipboard.
>
>
> There is no solutions but workarounds. Hence, it will be nice have
> this feature in gvim.

(G)Vim is already able to "copy" selected text to primary register (referenced
inside Vim as *), to synchronize it with clipboard register use things like
glipper/klipper/... (search for "clipboard manager" in your repository).

By the way, many (all) KDE applications use <C-S-Insert> shortcut to insert text
from primary register (bad, I was told this is hardcoded), Opera can be
configured to do this by pressing any key, you can also add a global shortcut to
do the job, but I do not know exactly what should you do in this case.

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

>> Hi.
>>
>> I tested on multi-monitor. But my patch have bits bug.
>> get_work_area() return rect absoluted of working area. So left/top should be
considered on multi-monitor.
>>
>> I updated patch.
>>
>> https://gist.github.com/2412212
>>
>> Thanks for your point.
>
>Great!  This has been nagging at me for a while.  I'll check out the new
>patch over the weekend.

I've tested out the new patch, and it seems to work just right, without
causing a regression for multiple monitors.

-WES

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

Hi Gary!

On So, 22 Apr 2012, Gary Johnson wrote:

> Case 1:
>     clipboard=unnamedplus,unnamed,autoselect,exclude:cons\|linux
>
>     Copy text from a GNOME Terminal by dragging the mouse over it
>     with the left button held down.
>
>     ":registers" shows selected text in the * register.  The
>     contents of the + and " registers are unchanged from before the
>     copy operation.
>
>     ":put" pastes the contents of the + register, not what I wanted.
>
> Case 2:
>     clipboard=unnamed,unnamedplus,autoselect,exclude:cons\|linux
>
>     Copy text from a GNOME Terminal as before.  ":registers" shows
>     the same results as before, as expected.
>
>     ":put" again pastes the contents of the + register.
>
> Case 3:
>     clipboard=unnamed,autoselect,exclude:cons\|linux
>
>     Copy text from a GNOME Terminal as before.  ":registers" shows
>     the same results as before, as expected.
>
>     ":put" now pastes the contents of the * register.
>
> So it appears that the only way to paste from the * register without
> explicitly naming it is to exclude "unnamedplus" from the
> 'clipboard', and that means that unnamed yanks from Vim go only to
> the * register and not the + register, which then means that Ctrl-V
> in Firefox won't paste that yanked text.  That's really fine with me
> since I paste into X applications other than Vim with the middle
> mouse button, not Ctrl-V, but it's not what the OP wanted.

That should probably be documented. Here is a doc patch:
diff --git a/runtime/doc/change.txt b/runtime/doc/change.txt
--- a/runtime/doc/change.txt
+++ b/runtime/doc/change.txt
@@ -977,6 +977,11 @@
                         current line).  This always works |linewise|, thus
                         this command can be used to put a yanked block as new
                         lines.
+                       If no register is specified, it depends on the 'cb'
+                       option, if 'cb' contains "unnamed", paste from
+                       * register |quotestar|, if 'cb' also contains
+                       "unnamedplus", use + register |quoteplus|, else paste
+                       from the unnamed register |quote_quote|.
                         The cursor is left on the first non-blank in the last
                         new line.
                         The register can also be '=' followed by an optional


regards,
Christian
--
Sind wohl solche Zahlzeichen möglich, die wenn ich das Blatt
herumkehre und alsdann ausspreche z.E. so viel bedeuten als die Hälfte
der vorhergehenden..
		 -- Georg Christoph Lichtenberg

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

Hi Sergey!

On Mo, 23 Apr 2012, Sergey Vakulenko wrote:

> Hi
>
> I would like to propose this theme for GVim future feature  (new
> options for "set clipboard")
> For someone who know very well gvim source code, its simple to
> implement (i think).
>
> Context of problem:
> ----------------------------
>
> I wonder, how i can enable auto copy of selected text into '+'
> register in Ubuntu (to share clipboard between apps).
> i have  set guioptions+=a
>
> my test case (with behave mswin):
> 1) open gvim
> 2)shift-v, move cursor and Esc (select lines in visual mode)
> 3)go to firefox and click ctrl-v or ctrl-Insert

What is the problem with yanking the selection first?

> In Win xp this works perfectly. But not in X (my example is Ubuntu
> 11.10 )
> I know that in X system this works different way and i tried to solve
> this in this thread:
>
> "gvim auto copy selected text to clipboard"
>
http://groups.google.com/group/vim_use/browse_thread/thread/d2d8516f9465301a/fae\
6c620e232af00?lnk=gst&q=vakulenko#fae6c620e232af00
>
>
http://stackoverflow.com/questions/10259366/gvim-auto-copy-selected-text-to-syst\
em-clipboard-to-share-it-with-apps
>
> conclusion: its impossible configure gvim to auto copy selected buffer
> in + register.

It is not. Simply yank the selection and with 'cb' set to unnamedplus,
you'll have the contents available to paste with Ctrl-C in firefox or
use a clipboard manager like parcellite or glipper or klipper or
autocutsel to keep both X11 buffers in sync.

> small resume of main (first) thread:
>
> I have many proposition how to auto copy selected(visual) buffer in +
> register.
> But no one not work in way described in Subject. Major propositions:
> 1) use mouse click copy
> 2) ctrl-insert bind "y+
> 3) use third party clipboard.
>
>
> There is no solutions but workarounds. Hence, it will be nice have
> this feature in gvim.

Anyway, I have a patch, that changes the behaviour of the 'cb' option
when 'autoselect' is included to always copy the selection in both X11
buffers. But you'll lose the X11 clipboard then and I don't think this
is really useful.

Mit freundlichen Grüßen
Christian
--
Stirbt der Bauer schon im Mai, wird ein Fremdenzimmer frei.

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

On 2012-04-23, Christian Brabandt wrote:
> Hi Gary!
>
> On So, 22 Apr 2012, Gary Johnson wrote:
>
> > Case 1:
> >     clipboard=unnamedplus,unnamed,autoselect,exclude:cons\|linux
> >
> >     Copy text from a GNOME Terminal by dragging the mouse over it
> >     with the left button held down.
> >
> >     ":registers" shows selected text in the * register.  The
> >     contents of the + and " registers are unchanged from before the
> >     copy operation.
> >
> >     ":put" pastes the contents of the + register, not what I wanted.
> >
> > Case 2:
> >     clipboard=unnamed,unnamedplus,autoselect,exclude:cons\|linux
> >
> >     Copy text from a GNOME Terminal as before.  ":registers" shows
> >     the same results as before, as expected.
> >
> >     ":put" again pastes the contents of the + register.
> >
> > Case 3:
> >     clipboard=unnamed,autoselect,exclude:cons\|linux
> >
> >     Copy text from a GNOME Terminal as before.  ":registers" shows
> >     the same results as before, as expected.
> >
> >     ":put" now pastes the contents of the * register.
> >
> > So it appears that the only way to paste from the * register without
> > explicitly naming it is to exclude "unnamedplus" from the
> > 'clipboard', and that means that unnamed yanks from Vim go only to
> > the * register and not the + register, which then means that Ctrl-V
> > in Firefox won't paste that yanked text.  That's really fine with me
> > since I paste into X applications other than Vim with the middle
> > mouse button, not Ctrl-V, but it's not what the OP wanted.
>
> That should probably be documented. Here is a doc patch:
> diff --git a/runtime/doc/change.txt b/runtime/doc/change.txt
> --- a/runtime/doc/change.txt
> +++ b/runtime/doc/change.txt
> @@ -977,6 +977,11 @@
>                         current line).  This always works |linewise|, thus
>                         this command can be used to put a yanked block as new
>                         lines.
> +                       If no register is specified, it depends on the 'cb'
> +                       option, if 'cb' contains "unnamed", paste from
> +                       * register |quotestar|, if 'cb' also contains
> +                       "unnamedplus", use + register |quoteplus|, else paste
> +                       from the unnamed register |quote_quote|.
>                         The cursor is left on the first non-blank in the last
>                         new line.
>                         The register can also be '=' followed by an optional

Hi Christian,

Because the presence of "unnamedplus" trumps "unnamed", I think it
would be more clear if the options were described in this order.

     if 'cb' contains "unnamedplus"
         paste from "+
     else if 'cb' contain "unnamed"
         paste from "*
     else
         paste from ""

In English, something like this.

     If no register is specified, it depends on the 'cb'
     option.  If 'cb' contains "unnamedplus", paste from
     the + register |quoteplus|.  Otherwise, if 'cb'
     contains "unnamed", paste from the * register
     |quote_star|.  Otherwise, paste from the unnamed
     register |quote_quote|.

Regards,
Gary

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

> AFAIK buffer numbers are not meant to persist between sessions, even
> efter ":mksession" ":quit" "vim -S" — if you've used :bwipeout there
> are "holes" in the list of buffer numbers; after reload those holes
> are not preserved.
>
> What is supposed to be preserved are buffer names (and full paths
> for buffers whose 'buftype' is not "nofile") and windows.
>
> Best regards,
> Tony.

You're right.

But still:
Using buffer numbers (B#s) is a very convenient way to work on many files.  It's
so good to know where you left stuff, without having to search for it first.
Having to re-learn the B#s after a session restore is a pain.

Is there a chance one could reorganize B#s at all within a live session (e.g.
within the Session.vim script)?  Or are the B#s so fundamental that allowing
them to change would involve big code changes?

Best,
Daan

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

Hi,

As the subject suggestions, I can't get the search highlight to work
from inside a function.  If I run it myself using the colon command
and typing it in.. then it works.

I managed to whittle my .vimrc file down to only the important part.
In case anyone is curious, I'm trying to simulate the regular
searching "slash key" to be used to only search and highlight, but
_not_ jump to the next match.  My idea was to just map \s to do it, as
seen below.

Anyways, here's what I have, which does not work for me.  I'm using
"VIM - Vi IMproved 7.3, Huge version without GUI." on Ubuntu 9.10.

Any tips greatly appreciated.  Thank you.

------- code below -------

function ChangeSearchRegister ()
   let @/ = "Change"
   set hlsearch
endfunction

nnoremap <leader>s :call ChangeSearchRegister()<CR>

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

On Mon, 23 Apr 2012, smu johnson wrote:

> As the subject suggestions, I can't get the search highlight to work
> from inside a function.  If I run it myself using the colon command
> and typing it in.. then it works.
>
> function ChangeSearchRegister ()
>  let @/ = "Change"
>  set hlsearch
> endfunction

Adding a "redraw" line after the "set hlsearch" line in the function
fixes the issue for me.

- Christian

--
               Not to be taken internally, literally or seriously.
Christian J. Robinson <heptite@...>      http://christianrobinson.name/

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

Thanks for the reply.

I have good news, and bad news:

The redraw thing only works if the search query (in my example,
"Change") is on the same page.  If you PigUp and PigDown away from it
before trying it out, the redraw thing doesn't take effect for the
potential highlights.

The good news is that a few people on Freenode #vim helped me
greatly.. and they provided me with this code that I stuck in
my .vimrc file, which so far seems to work in all cases without a
hitch:

" thanks to bairui, osse, and jamessan on Freenode for this
nmap <silent> <Leader>s :let @/ = input("highlight: ") <bar> set
hlsearch <CR>

On Apr 23, 4:00 pm, "Christian J. Robinson" <hept...@...> wrote:
> On Mon, 23 Apr 2012, smu johnson wrote:
> > As the subject suggestions, I can't get the search highlight to work
> > from inside a function.  If I run it myself using the colon command
> > and typing it in.. then it works.
>
> > function ChangeSearchRegister ()
> >  let @/ = "Change"
> >  set hlsearch
> > endfunction
>
> Adding a "redraw" line after the "set hlsearch" line in the function
> fixes the issue for me.
>
> - Christian
>
> --
>               Not to be taken internally, literally or seriously.
> Christian J. Robinson <hept...@...>      http://christianrobinson.name/

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

On Mon, Apr 23, 2012 at 11:06:15AM -0700, smu johnson wrote:
> Hi,

> As the subject suggestions, I can't get the search highlight to work
> from inside a function.

right -- it won't -- take it out (see below)

> If I run it myself using the colon command and typing it in..
> then it works.

> I managed to whittle my .vimrc file down to only the important part.
> In case anyone is curious, I'm trying to simulate the regular
> searching "slash key" to be used to only search and highlight, but
> _not_ jump to the next match.  My idea was to just map \s to do it, as
> seen below.

> Anyways, here's what I have, which does not work for me.  I'm using
> "VIM - Vi IMproved 7.3, Huge version without GUI." on Ubuntu 9.10.

> Any tips greatly appreciated.  Thank you.

> ------- code below -------

> function ChangeSearchRegister ()
>  let @/ = "Change"
>  set hlsearch
> endfunction

> nnoremap <leader>s :call ChangeSearchRegister()<CR>

I see you've already got something that works, but if you want
alternatives, here's one.

Your ChangeSearchRegister will work as you want if you take the
'set hlsearch' out of the function and put it after your call:

     nnoremap <leader>s :call ChangeSearchRegister()<CR>:set hlsearch<CR>

sc

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

What the problem do you have?

On Tuesday, April 24, 2012 4:44:44 AM UTC+9, William E. Skeith III wrote:
> >> Hi.
> >>
> >> I tested on multi-monitor. But my patch have bits bug.
> >> get_work_area() return rect absoluted of working area. So left/top should
be considered on multi-monitor.
> >>
> >> I updated patch.
> >>
> >> https://gist.github.com/2412212
> >>
> >> Thanks for your point.
> >
> >Great!  This has been nagging at me for a while.  I'll check out the new
> >patch over the weekend.
>
> I've tested out the new patch, and it seems to work just right, without
> causing a regression for multiple monitors.
>
> -WES

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

>On Tuesday, April 24, 2012 4:44:44 AM UTC+9, William E. Skeith III wrote:
>> >> Hi.
>> >>
>> >> I tested on multi-monitor. But my patch have bits bug.
>> >> get_work_area() return rect absoluted of working area. So left/top should
be considered on multi-monitor.
>> >>
>> >> I updated patch.
>> >>
>> >> https://gist.github.com/2412212
>> >>
>> >> Thanks for your point.
>> >
>> >Great!  This has been nagging at me for a while.  I'll check out the new
>> >patch over the weekend.
>>
>> I've tested out the new patch, and it seems to work just right, without
>> causing a regression for multiple monitors.
>>
>> -WES
>
>
>What the problem do you have?

??  There's no problem- I think the patch works perfectly.  (Perhaps you
skimmed over the word "without" in my last message?) : )

-WES

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

There's a copyright notice:

# Copyright (©) 2001 by Jörg Ziefle <joerg.ziefle@...>

The © and the ö are encoded in ISO 8859-1, aka latin1

> sed: RE error: illegal byte sequence

This looks to me like weirdness in the OS X implementation of sed.  Mine (GNU
sed version 4.2.1) has no trouble, with my own locale or en_US.UTF-8.

Regards, John

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

smu johnson wrote:
> In case anyone is curious, I'm trying to simulate the regular
> searching "slash key" to be used to only search and
> highlight, but _not_ jump to the next match.

Some good ideas are here:
http://vim.wikia.com/wiki/Highlight_all_search_pattern_matches

John

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

Cool.

> (Perhaps you skimmed over the word "without" in my last message?)

Yes.

On Tuesday, April 24, 2012 11:18:52 AM UTC+9, William E. Skeith III wrote:
> >On Tuesday, April 24, 2012 4:44:44 AM UTC+9, William E. Skeith III wrote:
> >> >> Hi.
> >> >>
> >> >> I tested on multi-monitor. But my patch have bits bug.
> >> >> get_work_area() return rect absoluted of working area. So left/top
should be considered on multi-monitor.
> >> >>
> >> >> I updated patch.
> >> >>
> >> >> https://gist.github.com/2412212
> >> >>
> >> >> Thanks for your point.
> >> >
> >> >Great!  This has been nagging at me for a while.  I'll check out the new
> >> >patch over the weekend.
> >>
> >> I've tested out the new patch, and it seems to work just right, without
> >> causing a regression for multiple monitors.
> >>
> >> -WES
> >
> >
> >What the problem do you have?
>
> ??  There's no problem- I think the patch works perfectly.  (Perhaps you
> skimmed over the word "without" in my last message?) : )
>
> -WES

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

Probably 4th attempt, wish me luck.

It can be visible when you type something like:

  fn( a,
         [](int x) {  // indent by +2 &sw, ok
             empty  // indent by +1 &sw, ok
  // indent by ... -3 &sw ???


If you type this in the normal portion of code (not inside lambda),
the last line indents with 1 &sw. But if you type it inside lambda,
the cursor is placed at the position where the calling function
begins.

If you just type {, it indents normally, like usual. If you type a
line ended with ; it's still ok, the next line continues with same
indent.

The same thing is when you use if, while, for, try - anything that
should be followed by just one line of indent, but next line should
not be indented.

I *suspect* this is a setting controlled by "n" option in cinoptions
(or "+", or maybe both have the same algorithm of counting the base
indent).

This problem cannot be solved by any combination of settings because
it simply behaves differently, depending on whether the cursor is
inside the lambda or not.

This happens with the default cinoptions, on vim 7.3

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