Wish list for a more powerful search in Vim

[Yegappan Lakshmanan]

Hi all,

My wish list for extending the Vim search feature:

1. When searching for a pattern, pressing a key at the search prompt
should jump to the next or previous match.
2. After jumping multiple times from the search prompt, pressing the
escape key should restore the cursor to the original cursor position
before the search.
3. Pressing backspace at the search prompt to erase a few characters and
then typing additional characters should start the search from the
previously matched position and not from the original position.
4. As characters are typed at the search prompt, all the matching text
should be highlighted (multiple matches). This can be turned on/off by
an option.

I know there are some Vim plugins that support some of these features.
But it will be useful to extend the built-in Vim feature to support these
features.

Thanks,
Yegappan

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Patch 7.4.2038

[Bram Moolenaar]

Patch 7.4.2038 (after 7.4.2036)
Problem:Small build still fails.
Solution:   Adjust more #ifdefs.
Files:  src/globals.h, src/buffer.c


*** ../vim-7.4.2037/src/globals.h   2016-07-10 19:03:47.703212491 +0200
--- src/globals.h   2016-07-14 22:55:21.435444809 +0200
***
*** 325,335 
  EXTERN scid_T current_SID INIT(= 0);
  #endif
  
- #if defined(FEAT_EVAL) || defined(FEAT_SYN_HL)
  /* Magic number used for hashitem "hi_key" value indicating a deleted item.
   * Only the address is used. */
  EXTERN char_u hash_removed;
- #endif
  
  
  EXTERN intscroll_region INIT(= FALSE); /* term supports scroll region */
--- 325,333 
*** ../vim-7.4.2037/src/buffer.c2016-07-14 22:09:35.095660862 +0200
--- src/buffer.c2016-07-14 22:57:30.393557338 +0200
***
*** 743,753 
  #ifdef FEAT_JOB_CHANNEL
  channel_buffer_free(buf);
  #endif
- #ifdef FEAT_AUTOCMD
- aubuflocal_remove(buf);
  
  buf_hashtab_remove(buf);
  
  if (autocmd_busy)
  {
/* Do not free the buffer structure while autocommands are executing,
--- 743,754 
  #ifdef FEAT_JOB_CHANNEL
  channel_buffer_free(buf);
  #endif
  
  buf_hashtab_remove(buf);
  
+ #ifdef FEAT_AUTOCMD
+ aubuflocal_remove(buf);
+ 
  if (autocmd_busy)
  {
/* Do not free the buffer structure while autocommands are executing,
*** ../vim-7.4.2037/src/version.c   2016-07-14 22:34:13.250016499 +0200
--- src/version.c   2016-07-14 23:01:09.210353547 +0200
***
*** 760,761 
--- 760,763 
  {   /* Add new patch number below this line */
+ /**/
+ 2038,
  /**/

-- 
"Intelligence has much less practical application than you'd think."
  -- Scott Adams, Dilbert.

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

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.2036

[Tony Mechelynck]

On Thu, Jul 14, 2016 at 10:09 PM, Bram Moolenaar  wrote:
>
> Patch 7.4.2036
> Problem:Looking up a buffer by number is slow if there are many.
> Solution:   Use a hashtab.
> Files:  src/structs.h, src/buffer.c

This introduces several messages in the Tiny build for buffer.c, which
fails as follows (Huge build compiles and links normally):

gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1   -o objects/buffer.o
buffer.c
In file included from vim.h:1818:0,
 from buffer.c:28:
buffer.c: In function ‘buf_hashtab_remove’:
structs.h:1099:70: error: ‘hash_removed’ undeclared (first use in this function)
 #define HASHITEM_EMPTY(hi) ((hi)->hi_key == NULL || (hi)->hi_key ==
_removed)
  ^
buffer.c:370:10: note: in expansion of macro ‘HASHITEM_EMPTY’
 if (!HASHITEM_EMPTY(hi))
  ^
structs.h:1099:70: note: each undeclared identifier is reported only
once for each function it appears in
 #define HASHITEM_EMPTY(hi) ((hi)->hi_key == NULL || (hi)->hi_key ==
_removed)
  ^
buffer.c:370:10: note: in expansion of macro ‘HASHITEM_EMPTY’
 if (!HASHITEM_EMPTY(hi))
  ^
buffer.c: In function ‘buflist_findnr’:
structs.h:1099:70: error: ‘hash_removed’ undeclared (first use in this function)
 #define HASHITEM_EMPTY(hi) ((hi)->hi_key == NULL || (hi)->hi_key ==
_removed)
  ^
buffer.c:2624:10: note: in expansion of macro ‘HASHITEM_EMPTY’
 if (!HASHITEM_EMPTY(hi))
  ^
buffer.c: At top level:
buffer.c:366:1: warning: ‘buf_hashtab_remove’ defined but not used
[-Wunused-function]
 buf_hashtab_remove(buf_T *buf)
 ^
Makefile:2770: recipe for target 'objects/buffer.o' failed
make: *** [objects/buffer.o] Error 1
exit status 2


Best regards,
Tony.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using file name with quickfix commands

[Bram Moolenaar]

Ramel Eshed wrote:

> > Strange.  Oh, perhaps it's because this "mybuf" is near the start of the
> > buffer list?  I reversed the search order, thinking that there is a
> > higher chance of searching for a newer buffer.
> > 
> > You can try changing buflist_findname_stat() from:
> > 
> > for (buf = lastbuf; buf != NULL; buf = buf->b_prev)
> > 
> > To:
> > 
> > for (buf = firstbuf; buf != NULL; buf = buf->b_next)
> > 
> > You can also try adding a new buffer after filling the quickfix list and
> > calling setbufvar() on that one.
> > 
> > Anyway, how relevant is calling setbufvar() 4 times?
> > Can you use a buffer number instead of a name (would be more reliable
> > anyway)?
> > 
> When adding the buffer after filling the quickfix list it takes 3.7s
> instead of 6.5. When using buffer number it takes 0.15s if the buffer
> is the last one, but it's still slow (3.1s) if the buffer was created
> before the list.
>
> I not sure if this specific use case is relevant (It was relevant to
> me, before I made some optimizations to my script...), but I'm sure
> that there are many other operations which involve searching in the
> buffers list that can slow down Vim when there are many quickfix
> items.

Please try this again after patch 7.4.2036.  The lookup of a buffer by
number should be a lot faster.

> Anyway, I don't think that saving all the buffers of the search
> results by default is a good idea. This way you can easily find
> yourself dealing with 4 digits buffer numbers while you have only few
> that you're actually working on.

A user is not really expected to deal with buffer numbers, there are
many other ways to find the right buffer.

In the other thread the discussion about the disadvantages of not
storing a file as a buffer were relevant.  Also, adding an option to all
quickfix commands that add an entry is not nice.

There are other ways to end up with lots of buffers, it is good to make
that fast anyway.


-- 
GALAHAD: No, please.  Please! I can defeat them!  There's only a hundred.
GIRLS:   He will beat us easily.  We haven't a chance.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Patch 7.4.2037

[Bram Moolenaar]

Patch 7.4.2037 (after 7.4.2036)
Problem:Small build fails.
Solution:   Adjust #ifdefs.
Files:  src/hashtab.c


*** ../vim-7.4.2036/src/hashtab.c   2016-04-03 22:44:32.399625762 +0200
--- src/hashtab.c   2016-07-14 22:31:31.812382393 +0200
***
*** 29,36 
  
  #include "vim.h"
  
- #if defined(FEAT_EVAL) || defined(FEAT_SYN_HL) || defined(PROTO)
- 
  #if 0
  # define HT_DEBUG /* extra checks for table consistency  and statistics */
  
--- 29,34 
***
*** 72,77 
--- 70,76 
  ht->ht_mask = HT_INIT_SIZE - 1;
  }
  
+ #if defined(FEAT_EVAL) || defined(FEAT_SYN_HL) || defined(PROTO)
  /*
   * Free the array of a hash table.  Does not free the items it contains!
   * If "ht" is not freed then you should call hash_init() next!
***
*** 105,110 
--- 104,110 
  }
  hash_clear(ht);
  }
+ #endif
  
  /*
   * Find "key" in hashtable "ht".  "key" must not be NULL.
***
*** 478,482 
  
  return hash;
  }
- 
- #endif
--- 478,480 
*** ../vim-7.4.2036/src/version.c   2016-07-14 22:09:35.095660862 +0200
--- src/version.c   2016-07-14 22:32:41.931354748 +0200
***
*** 760,761 
--- 760,763 
  {   /* Add new patch number below this line */
+ /**/
+ 2037,
  /**/

-- 
You cannot propel yourself forward by patting yourself on the back.

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

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Is it very difficult to hide cmd window when calling 'system()' on windows ? (#922)

[Bram Moolenaar]

skywind wrote:

> > I am on the fence on this one.
> > If Vim shells out to run something and that something is taking a _very_ 
> > long time, your Vim is essentially hung.
> > This happens to me frequently.
> > At least with the Window there, I can close it, which returns an error to 
> > Vim (via the system() call) and I get my Vim back.
> > Without that I have to terminate Vim, and that is a real pain.
> > 
> > David 
> --
> So, how can you stop these __very__ long time tasks from non-windows
> platform, which won't pop up a cmd window ?
> 
> __very__ long time tasks are supposed to be launched via async jobs in
> the latest vim version.
> 
> Could windows gvim stop the child processes by a Ctrl_C/Ctril_Break ?
> 
> There is an internal win32 message loop at line 4159 of os_win32.c:
> 
> https://github.com/vim/vim/blob/master/src/os_win32.c#L4159
> 
> which is used to update gui while waiting for child process finished.
> 
> Can we add a Ctrl_C/Ctrl_Break detection there to allow user stop a
> long time running process ? 
> 
> (I haven't read the whole part of os_win32.c, just do some search and
> find this
> routine.)
> 
> If the child processes of 'system()' could be stop by
> ctrl_break/ctrl_c, could we make `system()` act the same way to the
> other vim versions ?

I'm not sure if that can be made to work.  CTRL-Break sometimes behaves
strange.

On Unix you would use "kill" to stop the process.  On MS-Windows you can
use the task manager for this, right?

In general I don't mind the flickering, it's feedback that something is
happening.  (I liked to hear my harddisk rattling, to know how busy it
is, SSDs broke that.  I liked to hear my modem produce noise, so that I
knew what was going over the line. Now I have fiber...).

-- 
### Hiroshima 45, Chernobyl 86, Windows 95 ###

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

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Patch 7.4.2036

[Bram Moolenaar]

Patch 7.4.2036
Problem:Looking up a buffer by number is slow if there are many.
Solution:   Use a hashtab.
Files:  src/structs.h, src/buffer.c


*** ../vim-7.4.2035/src/structs.h   2016-07-10 22:11:11.858751521 +0200
--- src/structs.h   2016-07-14 21:37:09.432147507 +0200
***
*** 1753,1758 
--- 1753,1761 
  unsigned int b_fab_mrs;   /* Max record size  */
  #endif
  int   b_fnum; /* buffer number for this file. */
+ char_ub_key[VIM_SIZEOF_INT * 2 + 1];
+   /* key used for buf_hashtab, holds b_fnum as
+  hex string */
  
  int   b_changed;  /* 'modified': Set to TRUE if something 
in the
   file has been changed and not written out. */
*** ../vim-7.4.2035/src/buffer.c2016-07-10 22:11:11.854751580 +0200
--- src/buffer.c2016-07-14 22:03:42.204827897 +0200
***
*** 350,355 
--- 350,377 
  }
  
  /*
+  * A hash table used to quickly lookup a buffer by its number.
+  */
+ static hashtab_T buf_hashtab;
+ 
+ static void
+ buf_hashtab_add(buf_T *buf)
+ {
+ sprintf((char *)buf->b_key, "%x", buf->b_fnum);
+ if (hash_add(_hashtab, buf->b_key) == FAIL)
+   EMSG(_("E931: Buffer cannot be registered"));
+ }
+ 
+ static void
+ buf_hashtab_remove(buf_T *buf)
+ {
+ hashitem_T *hi = hash_find(_hashtab, buf->b_key);
+ 
+ if (!HASHITEM_EMPTY(hi))
+   hash_remove(_hashtab, hi);
+ }
+ 
+ /*
   * Close the link to a buffer.
   * "action" is used when there is no longer a window for the buffer.
   * It can be:
***
*** 723,728 
--- 745,753 
  #endif
  #ifdef FEAT_AUTOCMD
  aubuflocal_remove(buf);
+ 
+ buf_hashtab_remove(buf);
+ 
  if (autocmd_busy)
  {
/* Do not free the buffer structure while autocommands are executing,
***
*** 1703,1708 
--- 1728,1735 
   * functions for dealing with the buffer list
   */
  
+ static int  top_file_num = 1; /* highest file number */
+ 
  /*
   * Add a file name to the buffer list.  Return a pointer to the buffer.
   * If the same file name already exists return a pointer to that buffer.
***
*** 1715,1722 
   *if the buffer already exists.
   * This is the ONLY way to create a new buffer.
   */
- static int  top_file_num = 1; /* highest file number */
- 
  buf_T *
  buflist_new(
  char_u*ffname,/* full path of fname or relative */
--- 1742,1747 
***
*** 1729,1734 
--- 1754,1762 
  stat_Tst;
  #endif
  
+ if (top_file_num == 1)
+   hash_init(_hashtab);
+ 
  fname_expand(curbuf, , );   /* will allocate ffname */
  
  /*
***
*** 1907,1912 
--- 1935,1941 
}
top_file_num = 1;
}
+   buf_hashtab_add(buf);
  
/*
 * Always copy the options from the current buffer.
***
*** 2579,2597 
  #endif
  
  /*
!  * find file in buffer list by number
   */
  buf_T *
  buflist_findnr(int nr)
  {
! buf_T *buf;
  
  if (nr == 0)
nr = curwin->w_alt_fnum;
! /* Assume newer buffers are used more often, start from the end. */
! for (buf = lastbuf; buf != NULL; buf = buf->b_prev)
!   if (buf->b_fnum == nr)
!   return buf;
  return NULL;
  }
  
--- 2608,2629 
  #endif
  
  /*
!  * Find a file in the buffer list by buffer number.
   */
  buf_T *
  buflist_findnr(int nr)
  {
! char_ukey[VIM_SIZEOF_INT * 2 + 1];
! hashitem_T*hi;
  
  if (nr == 0)
nr = curwin->w_alt_fnum;
! sprintf((char *)key, "%x", nr);
! hi = hash_find(_hashtab, key);
! 
! if (!HASHITEM_EMPTY(hi))
!   return (buf_T *)(hi->hi_key
!- ((unsigned)(curbuf->b_key - (char_u *)curbuf)));
  return NULL;
  }
  
*** ../vim-7.4.2035/src/version.c   2016-07-14 20:37:03.884826159 +0200
--- src/version.c   2016-07-14 22:06:04.862738847 +0200
***
*** 760,761 
--- 760,763 
  {   /* Add new patch number below this line */
+ /**/
+ 2036,
  /**/

-- 
GALAHAD: No. Look, I can tackle this lot single-handed!
GIRLS:   Yes, yes, let him Tackle us single-handed!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

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

--- 
You received this message because you are subscribed to the 

Patch 7.4.2035

[Bram Moolenaar]

Patch 7.4.2035
Problem:On Solaris with ZFS the ACL may get removed.
Solution:   Always restore the ACL for Solaris ZFS. (Danek Duvall)
Files:  src/fileio.c


*** ../vim-7.4.2034/src/fileio.c2016-07-10 22:11:11.870751341 +0200
--- src/fileio.c2016-07-14 20:33:57.407544979 +0200
***
*** 4709,4717 
  if (perm >= 0)/* set perm. of new file same as old file */
(void)mch_setperm(wfname, perm);
  #ifdef HAVE_ACL
! /* Probably need to set the ACL before changing the user (can't set the
!  * ACL on a file the user doesn't own). */
  if (!backup_copy)
mch_set_acl(wfname, acl);
  #endif
  #ifdef FEAT_CRYPT
--- 4709,4725 
  if (perm >= 0)/* set perm. of new file same as old file */
(void)mch_setperm(wfname, perm);
  #ifdef HAVE_ACL
! /*
!  * Probably need to set the ACL before changing the user (can't set the
!  * ACL on a file the user doesn't own).
!  * On Solaris, with ZFS and the aclmode property set to "discard" (the
!  * default), chmod() discards all part of a file's ACL that don't 
represent
!  * the mode of the file.  It's non-trivial for us to discover whether 
we're
!  * in that situation, so we simply always re-set the ACL.
!  */
! # ifndef HAVE_SOLARIS_ZFS_ACL
  if (!backup_copy)
+ # endif
mch_set_acl(wfname, acl);
  #endif
  #ifdef FEAT_CRYPT
*** ../vim-7.4.2034/src/version.c   2016-07-14 20:24:59.351396346 +0200
--- src/version.c   2016-07-14 20:34:53.154732074 +0200
***
*** 760,761 
--- 760,763 
  {   /* Add new patch number below this line */
+ /**/
+ 2035,
  /**/

-- 
DINGO:   And after the spanking ... the oral sex.
GALAHAD: Oh, dear! Well, I...
GIRLS:   The oral sex ...  The oral sex.
GALAHAD: Well, I suppose I could stay a BIT longer.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Patch 7.4.2034

[Bram Moolenaar]

Patch 7.4.2034 (after 7.4.2032)
Problem:Build fails with some version of MinGW. (illusorypan)
Solution:   Recognize mingw32. (Ken Takata, closes #921)
Files:  src/Make_cyg_ming.mak


*** ../vim-7.4.2033/src/Make_cyg_ming.mak   2016-07-13 20:54:39.498772534 
+0200
--- src/Make_cyg_ming.mak   2016-07-14 20:13:27.753449147 +0200
***
*** 149,155 
  
  # Get the default ARCH.
  ifndef ARCH
! ARCH := $(shell $(CC) -dumpmachine | sed -e 's/-.*//' -e 's/_/-/')
  endif
  
  
--- 149,155 
  
  # Get the default ARCH.
  ifndef ARCH
! ARCH := $(shell $(CC) -dumpmachine | sed -e 's/-.*//' -e 's/_/-/' -e 
's/^mingw32$$/i686/')
  endif
  
  
*** ../vim-7.4.2033/src/version.c   2016-07-13 22:43:47.774233938 +0200
--- src/version.c   2016-07-14 20:13:53.173080357 +0200
***
*** 760,761 
--- 760,763 
  {   /* Add new patch number below this line */
+ /**/
+ 2034,
  /**/

-- 
DINGO: Wicked wicked Zoot ... she is a bad person and she must pay the
   penalty.  And here in Castle Anthrax, we have but one punishment
   ... you must tie her down on a bed ... and spank her.  Come!
GIRLS: A spanking!  A spanking!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: lambda again

[Nikolay Aleksandrovich Pavlov]

2016-07-14 9:43 GMT+03:00 mattn :
> On Thursday, July 14, 2016 at 12:49:58 PM UTC+9, ZyX wrote:
>> 2016-07-13 19:17 GMT+03:00 mattn :
>> > On Wednesday, July 13, 2016 at 4:11:59 AM UTC+9, Bram Moolenaar wrote:
>> >
>> > Well, I wonder this lambda will be useful. At the first, we hoped to call 
>> > statements in lambda. But the implementation you will include into vim 
>> > can't do because it only allow expressions. It's similar to python's 
>> > lambda. python's one doesn't allow statements. So usecase are limited to 
>> > use. I don't have strong opinion but I'm thinking that this is an new 
>> > expresssion or language for the lambda. It will demand to learn the new 
>> > expression for the users.
>>
>> Vim has `execute()`. Python-3 has `exec()` function (Python-2 has it
>> as a statement). Lambdas do not usually allow statements because they
>> are to be used in contexts which requires return value (e.g. in Python
>> this is sorted()/list.sort(), defaultdict(), re.sub[n] (BTW, it is
>> good idea to have `substitute(s, pattern, funcref, flags)` to work
>> like `substitute(s, pattern, '\=funcref(submatch(0), submatch(1), …)',
>> flags)`)). Lambdas are also used as a replacement for
>> `functools.partial` (python)/`function(fref, args, self)` (VimL) in
>> cases when they do not apply (e.g. when one needs to fix not the
>> first, but second or other arguments), but this requires closures.
>
> execute() doesn't have scope. So:
>
> call execute("let a = 1")
> echo 1
>
> This define new variable in global scope. I want anonymous function. If 
> execute() works with the scope, for example "let a = 1" mean "let l:a = 1", 
> It's so great.

`execute()` uses whatever scope it is called in, just as :execute
does. Your test is invalid, check execute() *inside a function*, there
is no reason why `execute()` should yield anything different in your
test. With Python’s `exec` you would see exactly the same results.

>
>> If you need lambda with statement then most likely you are going to
>> create unreadable code. Good lambdas are *small*, all examples you
>> have shown in documentation are either
>>
>> 1. More readable with new lambda style. It is absolutely not needed to
>> write `return` and `a:` in `sort()` or `map()` callbacks.
>> 2. Not practical. I still want to see an example of timer callback
>> which is used for more practical applications then testing timers
>> (like your echo) and yet is more readable with your variant of lambda
>> among variants a) :function, b) new lambda style (+ execute()!) and c)
>> your lambda style.
>
> The arrow operator which bram suggested is new, I think.

“I have (seen) a plugin that uses timers/jobs/etc with the following
code [link] and think that if there were lambdas implemented according
to my suggestion it would be more readable if rewritten as [code].”

Current suggestion has three points behind it:

1. sort() and map() callbacks will be more readable now. Both are fine
if lambdas are expression-only. I would say that substitute() could
also accept funcref in place of \=.
2. Other languages which have lambdas (e.g. Python) accept expressions
as a lambda body.
3. I know languages which have anonymous function allowing statements
and requiring `return` (e.g. C++). But

a) here they are usually not called “lambdas” (though specifically
C++ named its feature “lambda function”): these may be “anonymous
functions” (where it is a simple extension to function definition
syntax, e.g. lua with `function foo(a) return a end` vs `foo =
(function(a) return a end)`, JavaScript is similar; you cannot really
call such an extension “lambda function”), “arrow functions” (ES6,
though it also has anonymous functions), “closures” (Rust), etc,
b) I know exactly no languages where lambdas allow statements
*and* require continuation characters to span through multiple lines
and
c) some of such languages (Perl, Ruby, Rust (though it requires
omitting semicolon)) follow convention “result of last statement in
the block is the return value of the function”.

Though I should say that wikipedia states that “lambda function” and
“anonymous function” are essentially the same thing and 3.a mostly
expresses why I have certain expectations when I hear this term. 3.b
is a requirement if you really want commands in VimL lambdas. 3.c is
not applicable for VimL.

>
>> 3. Needs closures and not lambdas. I would not really say that your
>> example with multiline lambda used for counter generator is better
>> then with :function. Though it actually needs no closures in the
>> current state:
>>
>> function s:counter(x)
>> let d = {'x': a:x}
>> function d.counter()
>> let self.x += 1
>> return self.x
>> endfunction
>> return d.counter
>> endfunction
>>
>> And there is no new language, expressions are already used in a number
>> of places.
>
> --
> --
> You received 

Re: [vim/vim] Is it very difficult to hide cmd window when calling 'system()' on windows ? (#922)

[skywind3000]

> I am on the fence on this one.
> If Vim shells out to run something and that something is taking a _very_ long 
> time, your Vim is essentially hung.
> This happens to me frequently.
> At least with the Window there, I can close it, which returns an error to Vim 
> (via the system() call) and I get my Vim back.
> Without that I have to terminate Vim, and that is a real pain.
> 
> David 
--
So, how can you stop these __very__ long time tasks from non-windows platform, 
which won't pop up a cmd window ?

__very__ long time tasks are supposed to be launched via async jobs in the 
latest vim version.

Could windows gvim stop the child processes by a Ctrl_C/Ctril_Break ?

There is an internal win32 message loop at line 4159 of os_win32.c:

https://github.com/vim/vim/blob/master/src/os_win32.c#L4159

which is used to update gui while waiting for child process finished.

Can we add a Ctrl_C/Ctrl_Break detection there to allow user stop a long time 
running process ? 

(I haven't read the whole part of os_win32.c, just do some search and find this
routine.)

If the child processes of 'system()' could be stop by ctrl_break/ctrl_c, could 
we make `system()` act the same way to the other vim versions ?







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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vim function argument default value

[LCD 47]

On 13 July 2016, Yang Luo  wrote:
> 
> I write a function like this:
> function InsertNumber(start, end, step)
> 
> let i = a:start
> 
> let curr_line = 0
> 
> while i <= a:end
> if a:step <= 0
> echo "Error: step cannot <=0."
> break
> endif
> 
> call append(curr_line, i)
> 
> let i += a:step
> 
> let curr_line += 1
> 
> endwhile
> endfunction
> 
> 
> when I call this function, I type this:
> :echo InsertNumber(8,10,1)
> 8
> 9
> 10
> 
> 
> 1) How can I give arguement "step" a default value(eg: 1) when define the 
> function?
> like a C function:
> void C_func(int a, int b_have_default_val = 1)
> {
> 
> ;
> }

Use optional arguments:

function! InsertNumber(start, end, ...)
let step = a:0 > 0 ? a:1 : 1
...
endfunction

> 2)
> I want to print number like this, how to do it?
> 08
> 09
> 10

call append(curr_line, printf("%02d", i))

/lcd

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Is it very difficult to hide cmd window when calling 'system()' on windows ? (#922)

[David Fishburn]

On Thu, Jul 14, 2016 at 4:02 AM, Linwei  wrote:

> Taglist (or tagbar) is the top-1 rated plugin in vim.org, many windows
> gvim users are using it in their every day work. But the system() window
> (Taglist using system() to invoke ctags.exe) will pop up on the windows
> taskbar each time when a new file is open or a file is closed, which is
> very annoying:
>
> As system() is a very commonly used function in many plugins.
>
> I wonder is there a irresistible reason to show that cmd window on windows
> taskbar ?
> Why invoking system() can be slient in other vim/gvim versions ?
> Is it possible to hide the cmd window on windows taskbar ?
> Can we choose some alternative apis like WinExec(..., SW_HIDE) to solve
> this problem ?
> Or at least can we add an option to system() on windows to use SW_HIDE ?
>
> Could system() on windows become as smooth as other versions some day ?
>

I am on the fence on this one.
If Vim shells out to run something and that something is taking a _very_
long time, your Vim is essentially hung.
This happens to me frequently.
At least with the Window there, I can close it, which returns an error to
Vim (via the system() call) and I get my Vim back.
Without that I have to terminate Vim, and that is a real pain.

David

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Is it very difficult to hide cmd window when calling 'system()' on windows ? (#922)

[Charles]

On Thu, Jul 14, 2016 at 4:45 PM, Linwei  wrote:

> Will the official gvim adopt this important patch ?
> Patching each new release myself is really awful.
>

It's quite effortless if you use the hg mirror and maintain the patches
with mq. Then to update to new version just run

hg qpop -a
hg update
hg qpush -a

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Is it very difficult to hide cmd window when calling 'system()' on windows ? (#922)

[Charles]

If you compile vim yourself, you can simply change SW_SHOWMINNOACTIVE to
SW_HIDE in https://github.com/vim/vim/blob/master/src/os_win32.c#L4131.

I have used this patch for years (unfortunately I forget the source of the
patch) then just add let $VIM_SYSTEM_HIDECONSOLE=1 to vimrc or toggle the
value when necessary.

# HG changeset patch
# Parent 0e6eb1e63bdf24b9e60221a9a8131b2307f4a2b0
# Parent  00323db61d6eb59456994fc9aa8306583263cba8

diff -r 00323db61d6e src/os_win32.c
--- a/src/os_win32.cTue Jul 12 11:58:21 2016 +0700
+++ b/src/os_win32.cTue Jul 12 11:58:22 2016 +0700
@@ -4128,7 +4128,14 @@
  * Don't activate the window to keep focus on Vim.
  */
 if ((options & SHELL_DOOUT) && !mch_windows95() && !gui_is_win32s())
-si.wShowWindow = SW_SHOWMINNOACTIVE;
+{
+char *vim_system_hideconsole;
+vim_system_hideconsole = getenv("VIM_SYSTEM_HIDECONSOLE");
+if (vim_system_hideconsole != NULL && strcmp(vim_system_hideconsole,
"0") != 0)
+si.wShowWindow = SW_HIDE;
+else
+si.wShowWindow = SW_SHOWMINNOACTIVE;
+}
 else
 si.wShowWindow = SW_SHOWNORMAL;
 si.cbReserved2 = 0;


On Thu, Jul 14, 2016 at 3:02 PM, Linwei  wrote:

> Taglist (or tagbar) is the top-1 rated plugin in vim.org, many windows
> gvim users are using it in their every day work. But the system() window
> (Taglist using system() to invoke ctags.exe) will pop up on the windows
> taskbar each time when a new file is open or a file is closed, which is
> very annoying:
>
> Opening multiple files with CtrlP.vim, my laptop seems to be hacked by
> some virus:
> [image: cmdhide]
> 
>
> (Taglist will generate tags for each new file if g:Taglist_Show_Menu has
> been set, Tagbar may do same thing with some necessary option).
>
> opening multiple files or open a file or close a file are frequently used
> in gvim, and many plugins may use system() a lot to invoke external
> executables. Experience of vim or gtk/gnome gvim and macvim are far more
> better than gvim on windows for a long time.
>
> As system() is a very commonly used function in many plugins.
> I wonder is there a irresistible reason to show that cmd window on windows
> taskbar ?
> Why invoking system() can be slient in other vim/gvim versions ?
> Is it possible to hide the cmd window on windows taskbar ?
> Can we choose some alternative apis like WinExec(..., SW_HIDE) to solve
> this problem ?
> Or at least can we add an option to system() on windows to use SW_HIDE ?
>
> Could system() on windows become as smooth as other versions some day ?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> , .
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vim-cpp updated

[mattn]

On Thursday, July 14, 2016 at 3:44:54 PM UTC+9, mattn wrote:
> Next update. Added "auto" and quotes binary literals for C++14.
> 
> 
> https://gist.githubusercontent.com/mattn/86de0abdac858ed8ff5756bb286e6916/raw/7c9d850996ca1e42181de05cf6749ac887bfbcab/gistfile1.diff
> 
> Thanks.

Sorry, please wait merge until this issue will be solved.

https://github.com/vim-jp/vim-cpp/pull/40

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vim-cpp updated

[mattn]

On Thursday, July 14, 2016 at 3:44:54 PM UTC+9, mattn wrote:
> Next update. Added "auto" and quotes binary literals for C++14.
> 
> 
> https://gist.githubusercontent.com/mattn/86de0abdac858ed8ff5756bb286e6916/raw/7c9d850996ca1e42181de05cf6749ac887bfbcab/gistfile1.diff
> 
> Thanks.

Sorry, please wait merge until this issue will be solved.

https://github.com/vim-jp/vim-cpp/pull/40

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: lambda again

[Ken Takata]

Hi mattn,

2016/7/14 Thu 15:43:11 UTC+9 mattn wrote:
> On Thursday, July 14, 2016 at 12:49:58 PM UTC+9, ZyX wrote:
> > 2016-07-13 19:17 GMT+03:00 mattn :
> > > On Wednesday, July 13, 2016 at 4:11:59 AM UTC+9, Bram Moolenaar wrote:
> > >
> > > Well, I wonder this lambda will be useful. At the first, we hoped to call 
> > > statements in lambda. But the implementation you will include into vim 
> > > can't do because it only allow expressions. It's similar to python's 
> > > lambda. python's one doesn't allow statements. So usecase are limited to 
> > > use. I don't have strong opinion but I'm thinking that this is an new 
> > > expresssion or language for the lambda. It will demand to learn the new 
> > > expression for the users.
> > 
> > Vim has `execute()`. Python-3 has `exec()` function (Python-2 has it
> > as a statement). Lambdas do not usually allow statements because they
> > are to be used in contexts which requires return value (e.g. in Python
> > this is sorted()/list.sort(), defaultdict(), re.sub[n] (BTW, it is
> > good idea to have `substitute(s, pattern, funcref, flags)` to work
> > like `substitute(s, pattern, '\=funcref(submatch(0), submatch(1), …)',
> > flags)`)). Lambdas are also used as a replacement for
> > `functools.partial` (python)/`function(fref, args, self)` (VimL) in
> > cases when they do not apply (e.g. when one needs to fix not the
> > first, but second or other arguments), but this requires closures.
> 
> execute() doesn't have scope. So:
> 
> call execute("let a = 1")
> echo 1
> 
> This define new variable in global scope. I want anonymous function. If 
> execute() works with the scope, for example "let a = 1" mean "let l:a = 1", 
> It's so great.

Currently "{args -> expr}" has its own scope.

  :echo {-> execute("let a = 1")}()
  :echo a
  E121: Undefined variable: a
  E15: Invalid expression: a


BTW, because of its own scope, the following code doesn't work:

  let list = [ /* some data */ ]
  let l:threshold = 10
  filter(list, {idx, val -> val > l:threshold})

As ZyX pointed out, function() can be used (but redundant):

  filter(list, function({th, idx, val -> val > th}, [l:threshold]))

Closure might be useful for this, but it would be the next step.


Regards,
Ken Takata

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vim-cpp updated

[mattn]

Next update. Added "auto" and quotes binary literals for C++14.


https://gist.githubusercontent.com/mattn/86de0abdac858ed8ff5756bb286e6916/raw/7c9d850996ca1e42181de05cf6749ac887bfbcab/gistfile1.diff

Thanks.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: lambda again

[mattn]

On Thursday, July 14, 2016 at 12:49:58 PM UTC+9, ZyX wrote:
> 2016-07-13 19:17 GMT+03:00 mattn :
> > On Wednesday, July 13, 2016 at 4:11:59 AM UTC+9, Bram Moolenaar wrote:
> >
> > Well, I wonder this lambda will be useful. At the first, we hoped to call 
> > statements in lambda. But the implementation you will include into vim 
> > can't do because it only allow expressions. It's similar to python's 
> > lambda. python's one doesn't allow statements. So usecase are limited to 
> > use. I don't have strong opinion but I'm thinking that this is an new 
> > expresssion or language for the lambda. It will demand to learn the new 
> > expression for the users.
> 
> Vim has `execute()`. Python-3 has `exec()` function (Python-2 has it
> as a statement). Lambdas do not usually allow statements because they
> are to be used in contexts which requires return value (e.g. in Python
> this is sorted()/list.sort(), defaultdict(), re.sub[n] (BTW, it is
> good idea to have `substitute(s, pattern, funcref, flags)` to work
> like `substitute(s, pattern, '\=funcref(submatch(0), submatch(1), …)',
> flags)`)). Lambdas are also used as a replacement for
> `functools.partial` (python)/`function(fref, args, self)` (VimL) in
> cases when they do not apply (e.g. when one needs to fix not the
> first, but second or other arguments), but this requires closures.

execute() doesn't have scope. So:

call execute("let a = 1")
echo 1

This define new variable in global scope. I want anonymous function. If 
execute() works with the scope, for example "let a = 1" mean "let l:a = 1", 
It's so great.

> If you need lambda with statement then most likely you are going to
> create unreadable code. Good lambdas are *small*, all examples you
> have shown in documentation are either
> 
> 1. More readable with new lambda style. It is absolutely not needed to
> write `return` and `a:` in `sort()` or `map()` callbacks.
> 2. Not practical. I still want to see an example of timer callback
> which is used for more practical applications then testing timers
> (like your echo) and yet is more readable with your variant of lambda
> among variants a) :function, b) new lambda style (+ execute()!) and c)
> your lambda style.

The arrow operator which bram suggested is new, I think.

> 3. Needs closures and not lambdas. I would not really say that your
> example with multiline lambda used for counter generator is better
> then with :function. Though it actually needs no closures in the
> current state:
> 
> function s:counter(x)
> let d = {'x': a:x}
> function d.counter()
> let self.x += 1
> return self.x
> endfunction
> return d.counter
> endfunction
> 
> And there is no new language, expressions are already used in a number
> of places.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.