Patch 7.3.889
Patch 7.3.889
Problem:Can't build with Ruby 2.0 on a 64 bit system.
Solution: Define rb_fix2int and rb_num2int. (Kohei Suzuki)
Files: src/if_ruby.c
*** ../vim-7.3.888/src/if_ruby.c2013-03-07 15:16:16.0 +0100
--- src/if_ruby.c 2013-04-12 15:25:26.0 +0200
***
*** 88,93
--- 88,101
# define rb_int2big rb_int2big_stub
#endif
+ #if defined(DYNAMIC_RUBY_VER) DYNAMIC_RUBY_VER = 20 \
+SIZEOF_INT SIZEOF_LONG
+ /* Ruby 2.0 defines a number of static functions which use rb_fix2int and
+ * rb_num2int if SIZEOF_INT SIZEOF_LONG (64bit) */
+ # define rb_fix2int rb_fix2int_stub
+ # define rb_num2int rb_num2int_stub
+ #endif
+
#include ruby.h
#ifdef RUBY19_OR_LATER
# include ruby/encoding.h
***
*** 352,357
--- 360,376
{
return dll_rb_int2big(x);
}
+ #if defined(DYNAMIC_RUBY_VER) DYNAMIC_RUBY_VER = 20 \
+SIZEOF_INT SIZEOF_LONG
+ long rb_fix2int_stub(VALUE x)
+ {
+ return dll_rb_fix2int(x);
+ }
+ long rb_num2int_stub(VALUE x)
+ {
+ return dll_rb_num2int(x);
+ }
+ #endif
#if defined(DYNAMIC_RUBY_VER) DYNAMIC_RUBY_VER = 20
VALUE
rb_float_new_in_heap(double d)
*** ../vim-7.3.888/src/version.c2013-04-12 14:42:35.0 +0200
--- src/version.c 2013-04-12 15:24:15.0 +0200
***
*** 730,731
--- 730,733
{ /* Add new patch number below this line */
+ /**/
+ 889,
/**/
--
Hit any key to continue is very confusing when you have two keyboards.
/// 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/groups/opt_out.
Patch 7.3.890
Patch 7.3.890
Problem:Test 79 fails on Windows. (Michael Soyka)
Solution: Add comment below line causing an error.
Files: src/testdir/test79.in
*** ../vim-7.3.889/src/testdir/test79.in2013-03-19 17:42:10.0
+0100
--- src/testdir/test79.in 2013-04-13 11:16:38.0 +0200
***
*** 206,216
STARTTEST
:set magic
:set cpo
! /^TEST/
j:s/A./\=submatch(0)/
j:s/B./\=submatch(0)/
/^Q$
:s/Q[^\n]Q/\=submatch(0).foobar/
ENDTEST
TEST_7:
--- 206,217
STARTTEST
:set magic
:set cpo
! /^TEST_7/
j:s/A./\=submatch(0)/
j:s/B./\=submatch(0)/
/^Q$
:s/Q[^\n]Q/\=submatch(0).foobar/
+ : Avoid :s error breaks dotest map on Windows.
ENDTEST
TEST_7:
*** ../vim-7.3.889/src/version.c2013-04-14 16:18:52.0 +0200
--- src/version.c 2013-04-14 16:21:14.0 +0200
***
*** 730,731
--- 730,733
{ /* Add new patch number below this line */
+ /**/
+ 890,
/**/
--
Hit any key to continue it said, but nothing happened after F sharp.
/// 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/groups/opt_out.
Re: [patch] Store vimrc and gvimrc in your ~/.vim, ~\vimfiles\ directory
On 13-Apr-2013 Bram Moolenaar b...@moolenaar.net wrote: Thanks. Thus only when ~/.vimrc does not exist then ~/.vim/vimrc will be used. That should work for places where a new Vim is installed. For older Vim versions one would have to create a ~/.vimrc file that sources ~/.vim/vimrc. Do we want to change the priority? I meant not to confuse people if by any chance they have both ~/.vimrc and ~/.vim/vimrc. Is there anything else for Vim configuration that is outside of ~/.vim? AFAIK the location of all the other stuff can be controlled by one or another setting. -- Cheers, Lech -- -- 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/groups/opt_out.
Re: [Patch] Refine listed tags with regex
On 29-Mar-2013 Cody Cutler ccut...@csail.mit.edu wrote: Hello list. The attached patch allows optional regexs to be passed to :tj and friends. these regexs is then used to further refine available tags before they are printed. This patch is useful when you have many tags for a single identifier. For example, suppose a large C++ project has initialize() methods for 100s of classes. Going through the list of tags printed by :tj is tedious. Most of the time I know additional information about the identifier I am looking for like the containing object type or source filename. The text after the '/' in the argument is used as a regex (unless a '/' is the first character of the tag identifier, then the text after the second '/' is used) to match against the other tag fields (which often contains the containing type name). If a '!' is present, text after it is used to match against filenames. With this patch you can type: :tj initialize/SomeClass to list all tags that also contain SomeClass in their other fields or :ts initialize/!arch/amd64 to list all tags matching initialize that contain arch/amd64 in the containing file's pathname. Or a mix: :ts initialize/SomeClass!arch/amd64 The '/' and '!' characters were chosen somewhat arbitrarily--I'm not sure if they are a safe choice. Any comments are appreciated. I've been thinking about your proposed patch and I would have one problem with it: it doesn't seem intuitive and although I do work with software projects with quite large amounts of source code, I don't think I would use it much (because I wouldn't be able to remember all the quirks of the command). However, I think that there is a very simple solution to your problem which does not require changing the behaviour of Vim itself: create a command in VimL which will do everything you need. For this command I would use the following: - input() – for getting the name of the tag to jump to, - taglist() – to get a list of tags matching what the user chose to view, - input() – to get the name of the class, - input() – to get the file name pattern, - match() – to filter the tag list returned by taglist() with the criteria based on the values input by the user, - setqflist(), setloclist() – to create a list displayed in the quickfix window (:copen, :lopen), - inputlist() – perhaps instead of using setqflist() to make the experience akin to using :tselect. I believe that using such a command should be much more pleasant than poring through hundreds of lines of output generated by grep. And it has the potential of being more user-friendly – whenever you use input(), you can help the user by providing a hint in the prompt. What do you think? I'll be happy to hear from you. -- Cheers, Lech -- -- 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/groups/opt_out.
Patch 7.3.892
Patch 7.3.892 (after 7.3.891)
Problem:Still mering problems for viminfo history.
Solution: Do not merge lines when writing, don't write old viminfo lines.
Files: src/ex_getln.c, src/ex_cmds.c, src/proto/ex_getln.pro
*** ../vim-7.3.891/src/ex_getln.c 2013-04-14 16:26:08.0 +0200
--- src/ex_getln.c 2013-04-14 23:12:37.0 +0200
***
*** 68,74
static inthist_char2type __ARGS((int c));
! static intin_history __ARGS((int, char_u *, int, int));
# ifdef FEAT_EVAL
static intcalc_hist_idx __ARGS((int histype, int num));
# endif
--- 68,74
static inthist_char2type __ARGS((int c));
! static intin_history __ARGS((int, char_u *, int, int, int));
# ifdef FEAT_EVAL
static intcalc_hist_idx __ARGS((int histype, int num));
# endif
***
*** 5397,5407
* If 'move_to_front' is TRUE, matching entry is moved to end of history.
*/
static int
! in_history(type, str, move_to_front, sep)
int type;
char_u *str;
int move_to_front; /* Move the entry to the front if it
exists */
int sep;
{
int i;
int last_i = -1;
--- 5397,5408
* If 'move_to_front' is TRUE, matching entry is moved to end of history.
*/
static int
! in_history(type, str, move_to_front, sep, writing)
int type;
char_u *str;
int move_to_front; /* Move the entry to the front if it
exists */
int sep;
+ int writing;/* ignore entries read from viminfo */
{
int i;
int last_i = -1;
***
*** 5419,5424
--- 5420,5426
* well. */
p = history[type][i].hisstr;
if (STRCMP(str, p) == 0
+!(writing history[type][i].viminfo)
(type != HIST_SEARCH || sep == p[STRLEN(p) + 1]))
{
if (!move_to_front)
***
*** 5513,5519
}
last_maptick = -1;
}
! if (!in_history(histype, new_entry, TRUE, sep))
{
if (++hisidx[histype] == hislen)
hisidx[histype] = 0;
--- 5515,5521
}
last_maptick = -1;
}
! if (!in_history(histype, new_entry, TRUE, sep, FALSE))
{
if (++hisidx[histype] == hislen)
hisidx[histype] = 0;
***
*** 6032,6039
* This allocates history arrays to store the read history lines.
*/
void
! prepare_viminfo_history(asklen)
int asklen;
{
int i;
int num;
--- 6034,6042
* This allocates history arrays to store the read history lines.
*/
void
! prepare_viminfo_history(asklen, writing)
int asklen;
+ int writing;
{
int i;
int num;
***
*** 6041,6047
int len;
init_history();
! viminfo_add_at_front = (asklen != 0);
if (asklen hislen)
asklen = hislen;
--- 6044,6050
int len;
init_history();
! viminfo_add_at_front = (asklen != 0 !writing);
if (asklen hislen)
asklen = hislen;
***
*** 6073,6080
* new.
*/
int
! read_viminfo_history(virp)
vir_T *virp;
{
int type;
long_ulen;
--- 6076,6084
* new.
*/
int
! read_viminfo_history(virp, writing)
vir_T *virp;
+ int writing;
{
int type;
long_ulen;
***
*** 6090,6096
int sep = (*val == ' ' ? NUL : *val);
if (!in_history(type, val + (type == HIST_SEARCH),
! viminfo_add_at_front, sep))
{
/* Need to re-allocate to append the separator byte. */
len = STRLEN(val);
--- 6094,6100
int sep = (*val == ' ' ? NUL : *val);
if (!in_history(type, val + (type == HIST_SEARCH),
! viminfo_add_at_front, sep, writing))
{
/* Need to re-allocate to append the separator byte. */
len = STRLEN(val);
***
*** 6120,6125
--- 6124,6132
return viminfo_readline(virp);
}
+ /*
+ * Finish reading history lines from viminfo. Not used when writing viminfo.
+ */
void
finish_viminfo_history()
{
***
*** 6216,6222
{
p = round == 1 ? history[type][i].hisstr
: viminfo_history[type][i];
! if (p != NULL)
{
--num_saved;
fputc(hist_type2char(type, TRUE), fp);
--- 6223,6229
{
p = round == 1 ?
Re: [Patch] Refine listed tags with regex
lech.lor...@gmail.com (Lech Lorens) - Sun, Apr 14, 2013 at 11:04:33PM +0200 On 29-Mar-2013 Cody Cutler ccut...@csail.mit.edu wrote: Hello list. The attached patch allows optional regexs to be passed to :tj and friends. these regexs is then used to further refine available tags before they are printed. This patch is useful when you have many tags for a single identifier. For example, suppose a large C++ project has initialize() methods for 100s of classes. Going through the list of tags printed by :tj is tedious. Most of the time I know additional information about the identifier I am looking for like the containing object type or source filename. The text after the '/' in the argument is used as a regex (unless a '/' is the first character of the tag identifier, then the text after the second '/' is used) to match against the other tag fields (which often contains the containing type name). If a '!' is present, text after it is used to match against filenames. With this patch you can type: :tj initialize/SomeClass to list all tags that also contain SomeClass in their other fields or :ts initialize/!arch/amd64 to list all tags matching initialize that contain arch/amd64 in the containing file's pathname. Or a mix: :ts initialize/SomeClass!arch/amd64 The '/' and '!' characters were chosen somewhat arbitrarily--I'm not sure if they are a safe choice. Any comments are appreciated. I've been thinking about your proposed patch and I would have one problem with it: it doesn't seem intuitive and although I do work with software projects with quite large amounts of source code, I don't think I would use it much (because I wouldn't be able to remember all the quirks of the command). I agree that appending a '/' followed by a regex is not a very intuitive way to specify the info for the search but I don't think it is less intuitive than the current state since :tj and company already treat '/' specially if it is the first character of search string (which is why the paragraph explaining my patch's usage is so long -- I wanted to be clear that the original functionality was preserved). There's really not much to remember! If :tj generates a huge list of tags, just append a / with a search pattern. If you haven't tried the patch yet, you should give it a whirl! However, I think that there is a very simple solution to your problem which does not require changing the behaviour of Vim itself: create a command in VimL which will do everything you need. For this command I would use the following: - input() ??? for getting the name of the tag to jump to, - taglist() ??? to get a list of tags matching what the user chose to view, - input() ??? to get the name of the class, - input() ??? to get the file name pattern, - match() ??? to filter the tag list returned by taglist() with the criteria based on the values input by the user, - setqflist(), setloclist() ??? to create a list displayed in the quickfix window (:copen, :lopen), - inputlist() ??? perhaps instead of using setqflist() to make the experience akin to using :tselect. Cool, thanks for this. One reason I submitted the patch was to see what other ways people deal with this situation -- I've had a hard time finding other solutions. I would love a solution in base though. Thanks Lech. -- -- 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/groups/opt_out.
Re: Patch 7.3.892
Hi, Bram .viminfo merging logic works fine. Thanks! Best Regards, Hirohito Higashi -- -- 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/groups/opt_out.
Command line completion doesn't use . and ,, in path: Bug?
Hello, Hitting tab after entering a partial argument to :find will offer suggestions for completing the command line by searching inside non-trivial components of the 'path' -- but it does not search in . and in ,, components of the path. Here's what I see: On vim's command line, the following finds the possible completions :find ./foo/blah/blee[hit the tab key] but the following (without the leading ./) will not: :find foo/blah/blee[hit the tab key] Some more examples: verbose set path? path=.,,c:/opt/vim,c:/opt/vim/** Last set from C:\opt\vim\700_vimrc Hitting tab after :find 700 does find the above 700_vimrc file. Also, :find *vimrc*[hit tab] finds lots of matches. But :find *foo*[hit tab] does not find a foo that exists in the current directory. My other settings: verbose set wildchar? wildchar=Tab Last set from C:\opt\vim\vim73\runtime\vimrc_example.vim verbose set wildmode? wildmode=list:longest,full Last set from C:\opt\vim\700_vimrc It has been this way with various versions of vim; my current vim is: VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 21 2013 18:17:56) MS-Windows 64-bit GUI version with OLE support Included patches: 1-831 Thanks, --Suresh -- -- 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/groups/opt_out.
Re: Command line completion doesn't use . and ,, in path: Bug?
Hi Suresh! On Mon, Apr 15, 2013 at 10:22 AM, Suresh Govindachar sgovindac...@yahoo.com wrote: Hitting tab after entering a partial argument to :find will offer suggestions for completing the command line by searching inside non-trivial components of the 'path' -- but it does not search in . and in ,, components of the path. Here's what I see: On vim's command line, the following finds the possible completions :find ./foo/blah/blee[hit the tab key] but the following (without the leading ./) will not: :find foo/blah/blee[hit the tab key] I'm trying to reproduce the problem but couldn't: My setup: d:\foodir /s (i leave out the . and .. entries to slim down the lines below) Directory of D:\foo 15/04/2013 01:41 PM 9 foo.txt 15/04/2013 01:41 PM10 food.txt 15/04/2013 01:32 PMDIR opt Directory of D:\foo\opt 15/04/2013 01:44 PMDIR vim Directory of D:\foo\opt\vim 15/04/2013 01:32 PM11 700_vimrc 15/04/2013 01:33 PM10 fish.txt 15/04/2013 01:33 PM12 fish.txt d:\foogvim -u NONE -U NONE :set cp wildchar=Tab wildmode=list:longest,full :set path=.,,d:/foo/opt/vim,d:/foo/opt/vim/** :pwd D:\foo Now doing :find opt/vim/fiTab Shows fish.txt and finger.txt as the candidates. :find opt\vim\fish.txt And doing :find *foo* Shows foo.txt and food.txt as the candidates. Is there anything different in my settings here that might not show the problem that you're seeing? Regards, nazri -- -- 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/groups/opt_out.
Re: Command line completion doesn't use . and ,, in path: Bug?
On Mon, Apr 15, 2013 at 1:56 PM, Nazri Ramliy ayieh...@gmail.com wrote: 15/04/2013 01:32 PM11 700_vimrc 15/04/2013 01:33 PM10 fish.txt 15/04/2013 01:33 PM12 fish.txt One of those fishes should really be a finger.txt ;) nazri -- -- 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/groups/opt_out.
