Re: Question about :find completion support in Vim 7.3b
On Wed, Aug 4, 2010 at 1:16 PM, Nazri Ramliy wrote: > which call expand_in_path(), which in turns call globpath(), fails with > the exact same argument "c:/src/vim/**", "misc*" and 0 for path, file and > expand_options, respectively. > > Help! I think I found the solution. "recursive" should be reset to FALSE before calling expand_in_path in gen_expand_wildcards(). I'll submit a patch soon. I'm also working on a test script to test the find completion stuff. I'll send a patch for that one too, soon. 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
Re: Question about :find completion support in Vim 7.3b
On Wed, Aug 4, 2010 at 4:47 PM, Nazri Ramliy wrote:
> On Wed, Aug 4, 2010 at 1:16 PM, Nazri Ramliy wrote:
>> which call expand_in_path(), which in turns call globpath(), fails with
>> the exact same argument "c:/src/vim/**", "misc*" and 0 for path, file and
>> expand_options, respectively.
>>
>> Help!
>
> I think I found the solution. "recursive" should be reset to FALSE before
> calling expand_in_path in gen_expand_wildcards().
>
> I'll submit a patch soon.
Patch attached (0001).
>
> I'm also working on a test script to test the find completion stuff.
>
> I'll send a patch for that one too, soon.
>
Preliminary patch attached (0002). It only test for relative path
with '**' notation.
Obviously there should be more path values that it should test but I gotta
run now and I think that having a preliminary test is much better than having
no test at all. This one runs fine on unix.
I'm also attaching a third patch (0003) that (BLINDLY) adds test73.out to the
other platforms. It is added here so that others can try it out.
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
From 99bfc4658184e10a01db239bba8e91da42b580b2 Mon Sep 17 00:00:00 2001
From: Nazri Ramliy
Date: Wed, 4 Aug 2010 17:16:17 +0800
Subject: [PATCH 1/3] find completion: use globpath for both windows and unix
---
src/misc1.c | 22 +++---
1 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/src/misc1.c b/src/misc1.c
index b0f7e91..99b021d 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9578,14 +9578,10 @@ expand_in_path(gap, pattern, flags)
char_u *curdir;
garray_T path_ga;
int i;
-# ifdef WIN3264
-char_u *file_pattern;
-# else
char_u *files = NULL;
char_u *s; /* start */
char_u *e; /* end */
char_u *paths = NULL;
-# endif
if ((curdir = alloc((unsigned)MAXPATHL)) == NULL)
return 0;
@@ -9594,20 +9590,6 @@ expand_in_path(gap, pattern, flags)
expand_path_option(curdir, &path_ga);
vim_free(curdir);
path_list = (char_u **)(path_ga.ga_data);
-# ifdef WIN3264
-if ((file_pattern = alloc((unsigned)MAXPATHL)) == NULL)
- return 0;
-for (i = 0; i < path_ga.ga_len; i++)
-{
- if (STRLEN(path_list[i]) + STRLEN(pattern) + 2 > MAXPATHL)
- continue;
- STRCPY(file_pattern, path_list[i]);
- STRCAT(file_pattern, "/");
- STRCAT(file_pattern, pattern);
- mch_expandpath(gap, file_pattern, EW_DIR|EW_ADDSLASH|EW_FILE);
-}
-vim_free(file_pattern);
-# else
for (i = 0; i < path_ga.ga_len; i++)
{
if (paths == NULL)
@@ -9654,7 +9636,6 @@ expand_in_path(gap, pattern, flags)
}
vim_free(files);
-# endif
return gap->ga_len;
}
@@ -9795,7 +9776,10 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags)
{
#if defined(FEAT_SEARCHPATH)
if (*p != '.' && !vim_ispathsep(*p) && (flags & EW_PATH))
+ {
+ recursive = FALSE;
add_pat = expand_in_path(&ga, p, flags);
+ }
else
#endif
add_pat = mch_expandpath(&ga, p, flags);
--
1.7.2.1.6.g61bf12
From 4be95b821c6542c5c69932e8fa90ad4416af498a Mon Sep 17 00:00:00 2001
From: Nazri Ramliy
Date: Wed, 4 Aug 2010 10:38:25 +0800
Subject: [PATCH 2/3] Test script for testing find completion
---
src/testdir/Makefile |2 +-
src/testdir/test73.in | 18 ++
src/testdir/test73.ok |3 +++
3 files changed, 22 insertions(+), 1 deletions(-)
create mode 100644 src/testdir/test73.in
create mode 100644 src/testdir/test73.ok
diff --git a/src/testdir/Makefile b/src/testdir/Makefile
index f970b26..4951dc2 100644
--- a/src/testdir/Makefile
+++ b/src/testdir/Makefile
@@ -23,7 +23,7 @@ SCRIPTS = test1.out test2.out test3.out test4.out test5.out test6.out \
test54.out test55.out test56.out test57.out test58.out \
test59.out test60.out test61.out test62.out test63.out \
test64.out test65.out test66.out test67.out test68.out \
- test69.out test70.out test71.out test72.out
+ test69.out test70.out test71.out test72.out test73.out
SCRIPTS_GUI = test16.out
diff --git a/src/testdir/test73.in b/src/testdir/test73.in
new file mode 100644
index 000..ca8750c
--- /dev/null
+++ b/src/testdir/test73.in
@@ -0,0 +1,18 @@
+Tests for find completion.
+
+STARTTEST
+:!mkdir -p Xfind/in/path
+:!echo Holy Grail > Xfind/file.txt
+:!echo Jimmy Hoffa > Xfind/in/file.txt
+:!echo E.T.> Xfind/in/path/file.txt
+:set path=Xfind/**
+:set nocp
+:find file
+:w! test.out
+:find file
+:w >>test.out
+:find file
+:w >>test.out
+:qa!
+ENDTEST
+
diff --git a/src/testdir/test73.ok b/src/testdir/test73.ok
new file mode 100644
index 000..bf1d433
--- /dev/null
+++ b/src/testdir/test73.ok
@@ -0,0 +1,3 @@
+Holy Grail
+Jimmy Hoffa
+E.T.
--
1.7.2.1.6.g61bf12
From 054274787c07e6bb0dc03bc9ca628ea8f7bd49b8 Mon Sep 17 00:00:00 2001
From: Nazri Ramliy
Date: Wed, 4 Aug 2010 17:21:24 +0800
Subject: [PATCH 3/3] Add find
Re: [bug] runtime/ftplugin/quickfix.vim should be renamed to qf.vim
Lech Lorens wrote: > The changeset 68e394361c added a file runtime/ftplugin/quickfix.vim > which should be sourced for quickfix windows. It is not since the type > for the quickfix window is 'qf' as set in src/quickfix.c in line 2632. > As a result - the quickfix titles do not work by default. Ah, yes. I do prefer the name "quickfix", but since "qf" is in the code for a long time we should keep that. -- If someone questions your market projections, simply point out that your target market is "People who are nuts" and "People who will buy any damn thing". Nobody is going to tell you there aren't enough of those people to go around. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: syntax/diff.vim minor bug and locale problem
On Tue, Aug 3, 2010 at 9:47 PM, Jakson A. Aquino wrote: > On Tue, Aug 3, 2010 at 5:39 PM, Bram Moolenaar wrote: >> >> Jakson A. Aquino wrote: >> >>> When running diff without options, removed lines are separated of >>> added ones by '^---$'. This pattern gets interpreted as diffRemoved >>> when it is not. I think the pattern can be classified as diffLine. If >>> I'm not interpreting it wrongly the attached patch fix this tiny bug. >> >> Yeah, diffRemoved is not right, I'll include the change. >> >>> Locale problem: The diff in languages other than English may generate >>> output that doesn't match the patterns for diffOnly, diffDiffer, etc. >>> because diff messages get translated in some languages. To fix this >>> for my locale (pt_BR.UTF-8) I've put in my >>> ~/.vim/after/syntax/diff.vim the following lines: >>> >>> syn match diffOnly "^[A-Z].*" >>> syn match diffIdentical "^[A-Z].*" >>> syn match diffDiffer "^[A-Z].*" >>> syn match diffBDiffer "^[A-Z].*" >>> syn match diffIsA "^[A-Z].*" >>> syn match diffNoEOL "^[A-Z].*" >>> syn match diffCommon "^[A-Z].*" >>> >>> I repeated the same pattern because sometimes I use the terminal >>> emulator in English and the above patterns will still be fine. A more >>> general solution would be to define the above syntax elements first >>> using the pattern "^\S.*" and, then, define the other syntax elements. >>> This approach would have at least one shortcoming: the distinction >>> between diffOnly, diffidentical, etc. would be lost. >> >> But using the same pattern will mean one of them wins, you can leave out >> all the others. >> >> I think the only real solution would be to include the translations. >> I found the German one, but most others result in English for me. >> >> syn match diffOnly "^Only in .*" >> syn match diffOnly "^Nur in .*" > > One problem of using translations is that it will be necessary to > track them because they may change. For example, "apenas" and > "somente" are both Portuguese translations for "only". The first one > is used in Ubuntu 10.04 and the second in Debian unstable. Ubuntu and > Debian currently carry different versions of the package diffutils. I > wrote the script getStrings.sh to automatically get the strings out of > .po files. Then I manually edited the output with Vim and added the > result to syntax/diff.vim. For Portuguese, I manually added the other > translation to "Only". Were you thinking in something like this? I > retrieved the translations of the attached diff.vim from the Debian > unstable package of diffutils (version 3.0). There are translations > for the following locales: > > ca cs da de el eo es fi fr ga gl he hu id it ja lv ms nl pl pt_BR ro > ru sr sv tr uk vi zh_CN zh_TW > > I attached the getStrings and vim.diff files. I've improved the getStrings.sh script. There is no need anymore of manually editing the generated difftranslations.vim file. One has just to :read it into syntax/diff.vim. I've downloaded the diffutils source from: http://packages.debian.org/sid/diffutils Best regards, Jakson Aquino -- 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 getStrings.sh Description: Bourne shell script
Patch for src/testdir
Attached is a minor patch to three tests in src/testdir: src/testdir/test1.in Wrap comments consistently. src/testdir/test17.ok src/testdir/test17a.in Fix typo. src/testdir/test30.in Use 'copy /b' instead of 'cat' for win32. Test now works on Windows. 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 johnb-testdir.diff Description: Binary data
Re: syntax/diff.vim minor bug and locale problem
On Wed, Aug 4, 2010 at 7:27 AM, Jakson A. Aquino wrote: > On Tue, Aug 3, 2010 at 9:47 PM, Jakson A. Aquino > wrote: >> On Tue, Aug 3, 2010 at 5:39 PM, Bram Moolenaar wrote: >>> >>> Jakson A. Aquino wrote: >>> When running diff without options, removed lines are separated of added ones by '^---$'. This pattern gets interpreted as diffRemoved when it is not. I think the pattern can be classified as diffLine. If I'm not interpreting it wrongly the attached patch fix this tiny bug. >>> >>> Yeah, diffRemoved is not right, I'll include the change. >>> Locale problem: The diff in languages other than English may generate output that doesn't match the patterns for diffOnly, diffDiffer, etc. because diff messages get translated in some languages. To fix this for my locale (pt_BR.UTF-8) I've put in my ~/.vim/after/syntax/diff.vim the following lines: syn match diffOnly "^[A-Z].*" syn match diffIdentical "^[A-Z].*" syn match diffDiffer "^[A-Z].*" syn match diffBDiffer "^[A-Z].*" syn match diffIsA "^[A-Z].*" syn match diffNoEOL "^[A-Z].*" syn match diffCommon "^[A-Z].*" I repeated the same pattern because sometimes I use the terminal emulator in English and the above patterns will still be fine. A more general solution would be to define the above syntax elements first using the pattern "^\S.*" and, then, define the other syntax elements. This approach would have at least one shortcoming: the distinction between diffOnly, diffidentical, etc. would be lost. >>> >>> But using the same pattern will mean one of them wins, you can leave out >>> all the others. >>> >>> I think the only real solution would be to include the translations. >>> I found the German one, but most others result in English for me. >>> >>> syn match diffOnly "^Only in .*" >>> syn match diffOnly "^Nur in .*" >> >> One problem of using translations is that it will be necessary to >> track them because they may change. For example, "apenas" and >> "somente" are both Portuguese translations for "only". The first one >> is used in Ubuntu 10.04 and the second in Debian unstable. Ubuntu and >> Debian currently carry different versions of the package diffutils. I >> wrote the script getStrings.sh to automatically get the strings out of >> .po files. Then I manually edited the output with Vim and added the >> result to syntax/diff.vim. For Portuguese, I manually added the other >> translation to "Only". Were you thinking in something like this? I >> retrieved the translations of the attached diff.vim from the Debian >> unstable package of diffutils (version 3.0). There are translations >> for the following locales: >> >> ca cs da de el eo es fi fr ga gl he hu id it ja lv ms nl pl pt_BR ro >> ru sr sv tr uk vi zh_CN zh_TW >> >> I attached the getStrings and vim.diff files. > > I've improved the getStrings.sh script. There is no need anymore of > manually editing the generated difftranslations.vim file. One has just > to :read it into syntax/diff.vim. > > I've downloaded the diffutils source from: > http://packages.debian.org/sid/diffutils I think this is my last improvement to the script which now: 1) Downloads the diffutils source code 2) Unpacks the .tar.bz2 archive 3) Generates the difftranslations.vim file 4) Opens the difftranlations.vim and syntax/diff.vim in Vim (split window). The only two things to do manually is to adjust the path to syntax/diff.vim and to add the difftranslation.vim lines into the appropriate place of syntax/diff.vim. Best regards, Jakson -- 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 getStrings.sh Description: Bourne shell script
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote:
> On Wed, Aug 4, 2010 at 4:39 AM, Bram Moolenaar wrote:
> >> Attached is the fix on top of Revision: 7d1044b27e.
> >
> > Thanks and sorry, I suppose I caused this problem.
>
> That is minuscule compared to all the problems that I have caused with
> all this find-completion stuff :)
>
> Prove (this will show that I'm still naive at grokking vim source code):
>
> We shouldn't have to write window-specific code for the find completion
> because apparently f_globpath() works fine on both unix and windows and
> it happily uses globpath() to do its job.
>
> To cut a long story short, I found this out while writing a test script
> for testing the find completion stuff.
>
> With that realization I'm going to investigate why is it that on
> windows, globpath() as used in the expand_in_path() function fails to do
> its jobs when it works just fine when used in f_globpath(), with the
> exact same set of arguments.
>
> I'm attaching a patch to produce my "debug" version of eval.c and
> misc1.c which will show this problem for those who would like to help in
> investigating this.
>
> On windows, doing
>
> :echo globpath("c:/src/vim/**", "misc*")
>
> calls f_globpath(), which in turn calls globpath() with the arguments
> "c:/src/vim/**", "misc*" and 0 for path, file and expand_options,
> respectively and it successfully gives
>
> c:\src\vim\src\misc1.c
> c:\src\vim\src\misc2.c
> c:\src\vim\src\proto\misc1.c
> c:\src\vim\src\proto\misc2.c
> c:\src\vim\src\ObjC\misc1.obj
> c:\src\vim\src\ObjC\misc2.obj
> c:\src\vim\src\ObjG\misc1.obj
> c:\src\vim\src\ObjG\misc2.obj
>
> while doing
>
> :set path=c:/src/vim/**
> :find misc
>
> which call expand_in_path(), which in turns call globpath(), fails with
> the exact same argument "c:/src/vim/**", "misc*" and 0 for path, file and
> expand_options, respectively.
If the arguments are the same the returned values should be the same.
You will need to use a debugger to find out what really happens.
I noticed another problem: with 'path' set to "./**" and in an empty
buffer :find completion crashes. I fixed it.
Maybe I'll have time to look at the completion code, looks like you are
getting lost.
--
The process for understanding customers primarily involves sitting around with
other marketing people and talking about what you would to if you were dumb
enough to be a customer.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: [PATCH] Add options for opening dropped files in new tabs
On 3 August 2010 23:28, Lech Lorens wrote:
> On 03-Aug-2010 Michael Trim wrote:
>> The attached patch adds two options which together allow dropped files
>> to always be loaded as tabs instead of in the current window or a
>> split window. Files loaded via the Windows shell extension ("Edit
>> with existing Vim...") should also be affected, since the shell
>> extension sends a WM_DROPFILES message to the exisiting Vim window.
>>
>> This seems like something that should be possible with AutoCmds or
>> something, but my Googlings [1] didn't come up with anything except
>> other people wanting this type of behaviour [2].
>>
>> It would be nice if this patch could find its way into 7.3, but I
>> realise it is a bit late.
>>
>> [1] http://www.google.com/search?q=vim+open+dropped+file+new+tab
>> [2]
>> http://stackoverflow.com/questions/1891513/can-i-force-gvim-to-open-dragged-in-files-in-a-new-tab
>
>
> Aren't the 'dropnewtab' and 'dropsplit' mutually exclusive? If so,
> wouldn't it be better if there was a single setting (e.g.
> 'drop') which could have a value of either "split" or "newtab"?
...and to be consistent with startup arguments (-o/-O/-p) there should
also be a value for "vertical split". This is how MacVim works
(although this behavior is implemented as a Preference in the MacVim
app and not as a Vim option).
I haven't looked at the patch but if implemented as one option (as
Lech suggested) then I'd support the inclusion of such a patch.
(Which would mean I could get rid of my hack in MacVim to support this
behavior.)
Björn
--
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
Re: syntax/diff.vim minor bug and locale problem
Jakson A. Aquino wrote: > >> When running diff without options, removed lines are separated of > >> added ones by '^---$'. This pattern gets interpreted as diffRemoved > >> when it is not. I think the pattern can be classified as diffLine. If > >> I'm not interpreting it wrongly the attached patch fix this tiny bug. > > > > Yeah, diffRemoved is not right, I'll include the change. > > > >> Locale problem: The diff in languages other than English may generate > >> output that doesn't match the patterns for diffOnly, diffDiffer, etc. > >> because diff messages get translated in some languages. To fix this > >> for my locale (pt_BR.UTF-8) I've put in my > >> ~/.vim/after/syntax/diff.vim the following lines: > >> > >> syn match diffOnly "^[A-Z].*" > >> syn match diffIdentical "^[A-Z].*" > >> syn match diffDiffer"^[A-Z].*" > >> syn match diffBDiffer "^[A-Z].*" > >> syn match diffIsA "^[A-Z].*" > >> syn match diffNoEOL "^[A-Z].*" > >> syn match diffCommon"^[A-Z].*" > >> > >> I repeated the same pattern because sometimes I use the terminal > >> emulator in English and the above patterns will still be fine. A more > >> general solution would be to define the above syntax elements first > >> using the pattern "^\S.*" and, then, define the other syntax elements. > >> This approach would have at least one shortcoming: the distinction > >> between diffOnly, diffidentical, etc. would be lost. > > > > But using the same pattern will mean one of them wins, you can leave out > > all the others. > > > > I think the only real solution would be to include the translations. > > I found the German one, but most others result in English for me. > > > > syn match diffOnly "^Only in .*" > > syn match diffOnly "^Nur in .*" > > One problem of using translations is that it will be necessary to > track them because they may change. For example, "apenas" and > "somente" are both Portuguese translations for "only". The first one > is used in Ubuntu 10.04 and the second in Debian unstable. Ubuntu and > Debian currently carry different versions of the package diffutils. I > wrote the script getStrings.sh to automatically get the strings out of > .po files. Then I manually edited the output with Vim and added the > result to syntax/diff.vim. For Portuguese, I manually added the other > translation to "Only". Were you thinking in something like this? I > retrieved the translations of the attached diff.vim from the Debian > unstable package of diffutils (version 3.0). There are translations > for the following locales: > > ca cs da de el eo es fi fr ga gl he hu id it ja lv ms nl pl pt_BR ro > ru sr sv tr uk vi zh_CN zh_TW > > I attached the getStrings and vim.diff files. I don't know what others think, but I kind of like it. The patterns need to start with "^" to make them match only at the start of the line. There are a few duplicates, e.g., between China and Taiwan. This will only work in utf-8. Using scriptencoding and an "if" should work, like what's done in syntax/tex.vim. If you can fix this I think I should include it. -- The average life of an organization chart is six months. You can safely ignore any order from your boss that would take six months to complete. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: syntax/diff.vim minor bug and locale problem
On Wed, Aug 4, 2010 at 8:20 AM, Bram Moolenaar wrote:
>
> Jakson A. Aquino wrote:
>
>> >> When running diff without options, removed lines are separated of
>> >> added ones by '^---$'. This pattern gets interpreted as diffRemoved
>> >> when it is not. I think the pattern can be classified as diffLine. If
>> >> I'm not interpreting it wrongly the attached patch fix this tiny bug.
>> >
>> > Yeah, diffRemoved is not right, I'll include the change.
>> >
>> >> Locale problem: The diff in languages other than English may generate
>> >> output that doesn't match the patterns for diffOnly, diffDiffer, etc.
>> >> because diff messages get translated in some languages. To fix this
>> >> for my locale (pt_BR.UTF-8) I've put in my
>> >> ~/.vim/after/syntax/diff.vim the following lines:
>> >>
>> >> syn match diffOnly "^[A-Z].*"
>> >> syn match diffIdentical "^[A-Z].*"
>> >> syn match diffDiffer "^[A-Z].*"
>> >> syn match diffBDiffer "^[A-Z].*"
>> >> syn match diffIsA "^[A-Z].*"
>> >> syn match diffNoEOL "^[A-Z].*"
>> >> syn match diffCommon "^[A-Z].*"
>> >>
>> >> I repeated the same pattern because sometimes I use the terminal
>> >> emulator in English and the above patterns will still be fine. A more
>> >> general solution would be to define the above syntax elements first
>> >> using the pattern "^\S.*" and, then, define the other syntax elements.
>> >> This approach would have at least one shortcoming: the distinction
>> >> between diffOnly, diffidentical, etc. would be lost.
>> >
>> > But using the same pattern will mean one of them wins, you can leave out
>> > all the others.
>> >
>> > I think the only real solution would be to include the translations.
>> > I found the German one, but most others result in English for me.
>> >
>> > syn match diffOnly "^Only in .*"
>> > syn match diffOnly "^Nur in .*"
>>
>> One problem of using translations is that it will be necessary to
>> track them because they may change. For example, "apenas" and
>> "somente" are both Portuguese translations for "only". The first one
>> is used in Ubuntu 10.04 and the second in Debian unstable. Ubuntu and
>> Debian currently carry different versions of the package diffutils. I
>> wrote the script getStrings.sh to automatically get the strings out of
>> .po files. Then I manually edited the output with Vim and added the
>> result to syntax/diff.vim. For Portuguese, I manually added the other
>> translation to "Only". Were you thinking in something like this? I
>> retrieved the translations of the attached diff.vim from the Debian
>> unstable package of diffutils (version 3.0). There are translations
>> for the following locales:
>>
>> ca cs da de el eo es fi fr ga gl he hu id it ja lv ms nl pl pt_BR ro
>> ru sr sv tr uk vi zh_CN zh_TW
>>
>> I attached the getStrings and vim.diff files.
>
> I don't know what others think, but I kind of like it.
>
> The patterns need to start with "^" to make them match only at the start
> of the line.
>
> There are a few duplicates, e.g., between China and Taiwan.
I also found one duplicate between locales "id" and "ms". I fixed it.
> This will only work in utf-8. Using scriptencoding and an "if" should
> work, like what's done in syntax/tex.vim.
Added.
> If you can fix this I think I should include it.
The patch to syntax/diff.vim is attached. I also attached the
getStrings.sh again because I added a few lines of code to find
duplicated lines in the difftranslations.vim.
Best regards,
Jakson
--
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
getStrings.sh
Description: Bourne shell script
diff -r 734196b073e0 runtime/syntax/diff.vim
--- a/runtime/syntax/diff.vim Wed Aug 04 12:39:44 2010 +0200
+++ b/runtime/syntax/diff.vim Wed Aug 04 09:05:30 2010 -0300
@@ -7,6 +7,7 @@
if exists("b:current_syntax")
finish
endif
+scriptencoding utf-8
syn match diffOnly "^Only in .*"
syn match diffIdentical "^Files .* and .* are identical$"
@@ -16,8 +17,274 @@
syn match diffNoEOL "^No newline at end of file .*"
syn match diffCommon "^Common subdirectories: .*"
-" German
-syn match diffOnly "^Nur in .*"
+" ca
+syn match diffOnly "^Només a .*: .*$"
+syn match diffIdentical "^Els fitxers .* i .* són idèntics$"
+syn match diffDiffer "^Els fitxers .* i .* difereixen$"
+syn match diffBDiffer "^Els fitxers .* i .* difereixen$"
+syn match diffIsA "^El fitxer .* és un .* mentre que el fitxer .* és un .*$"
+syn match diffNoEOL "^No hi ha cap caràcter de salt de línia al final del fitxer"
+syn match diffCommon "^Subdirectoris comuns: .* i .*$"
+
+" cs
+syn match diffOnly "^Pouze v .*: .*$"
+syn match diffIdentical "^Soubory .* a .* jsou identické$"
+syn match diffDiffer "^Soubory .* a .* jsou různé$"
+syn match diffBDiffer "^Soubory .* a .* jsou různé$"
+syn match diffIsA "^Soubor .* je .* pokud soubor .* je .*$"
+syn match diffNoEOL "^Chybí znak ko
Re: syntax/diff.vim minor bug and locale problem
Jakson A. Aquino wrote: > >> I attached the getStrings and vim.diff files. > > > > I don't know what others think, but I kind of like it. > > > > The patterns need to start with "^" to make them match only at the start > > of the line. > > > > There are a few duplicates, e.g., between China and Taiwan. > > I also found one duplicate between locales "id" and "ms". I fixed it. > > > This will only work in utf-8. =A0Using scriptencoding and an "if" should > > work, like what's done in syntax/tex.vim. > > Added. > > > If you can fix this I think I should include it. > > The patch to syntax/diff.vim is attached. I also attached the > getStrings.sh again because I added a few lines of code to find > duplicated lines in the difftranslations.vim. Thanks. This looks good, I'll include it. It's kind of fun. -- A)bort, R)etry, D)o it right this time /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Patch for src/testdir
John Beckett wrote: > Attached is a minor patch to three tests in src/testdir: > > src/testdir/test1.in > Wrap comments consistently. > > src/testdir/test17.ok > src/testdir/test17a.in > Fix typo. > > src/testdir/test30.in > Use 'copy /b' instead of 'cat' for win32. > Test now works on Windows. I'll include it, thanks. -- A)bort, R)etry, B)ang it with a large hammer /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Question about :find completion support in Vim 7.3b
On Wed, Aug 4, 2010 at 7:20 PM, Bram Moolenaar wrote:
> If the arguments are the same the returned values should be the same.
> You will need to use a debugger to find out what really happens.
I did. The problem is due to the static nature of "recursive" in
gen_expand_wildcards().
Please see my patches to fix this in an earlier follow-up message [1].
> I noticed another problem: with 'path' set to "./**" and in an empty
> buffer :find completion crashes. I fixed it.
Thanks. I'll add this check to the test script.
> Maybe I'll have time to look at the completion code, looks like you are
> getting lost.
The light bulb turned on for me when I insert a debug message to print
the value of "recursive" at the top of gen_expand_wildcards().
It revealed that when doing
:echo globpath("c:/src/**", "misc*")
globpath() is called with recursive set to FALSE, while doing
:find misc
globpath() is called with recursive set to TRUE, which is why it
doesn't work the
same way.
The patch attached in [1] seems to fix that. With that patch the find
completion
uses the same code for both windows and unix.
nazri.
[1] http://article.gmane.org/gmane.editors.vim.devel/27663
--
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
[Win32] common dialogs of gVim cannot input some Unicode characters from IME
For example, I work with Windows Xp Simplified Chinese Edition. There's a character 'CIRCLED NUMBER TWENTY' - U+2473, beyond the character set of ACP (system active codepage) CP936. While it can be copyed and pasted into the textbox of Find and Replace dialog, but it can't be inputed directly from windows IME (the inputed character will be the question mark '?'). It puzzled me for a long time. I finally found the reason that ANSI Version functions such as DispatchMessageA and IsDialogMessageA will Ignore the WM_WCHAR message. The attachment 2274_uime.patch.gz is the patch for vim 7.2.446, 2477_uime.patch.gz is for 7.3d revision 2...@mercurial. Best regards, Yanwei. -- -- 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 2274_uime.patch.gz Description: GNU Zip compressed data 2477_uime.patch.gz Description: GNU Zip compressed data
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote:
> On Wed, Aug 4, 2010 at 7:20 PM, Bram Moolenaar wrote:
> > If the arguments are the same the returned values should be the same.
> > You will need to use a debugger to find out what really happens.
>
> I did. The problem is due to the static nature of "recursive" in
> gen_expand_wildcards().
> Please see my patches to fix this in an earlier follow-up message [1].
Yeah, I included this now. I fixed a memory leak and moved the
concatenation of strings to a separate function.
> > I noticed another problem: with 'path' set to "./**" and in an empty
> > buffer :find completion crashes. =A0I fixed it.
>
> Thanks. I'll add this check to the test script.
>
> > Maybe I'll have time to look at the completion code, looks like you are
> > getting lost.
>
> The light bulb turned on for me when I insert a debug message to print
> the value of "recursive" at the top of gen_expand_wildcards().
> It revealed that when doing
>
> :echo globpath("c:/src/**", "misc*")
>
> globpath() is called with recursive set to FALSE, while doing
>
> :find misc
>
> globpath() is called with recursive set to TRUE, which is why it
> doesn't work the
> same way.
>
> The patch attached in [1] seems to fix that. With that patch the find
> completion
> uses the same code for both windows and unix.
OK. I also set recursive back to TRUE to stay on the safe side.
--
hundred-and-one symptoms of being an internet addict:
1. You actually wore a blue ribbon to protest the Communications Decency Act.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: [Win32] common dialogs of gVim cannot input some Unicode characters from IME
Yanwei Jia wrote: > For example, I work with Windows Xp Simplified Chinese Edition. There's a > character 'CIRCLED NUMBER TWENTY' - U+2473, beyond the character set of ACP > (system active codepage) CP936. While it can be copyed and pasted into the > textbox of Find and Replace dialog, but it can't be inputed directly from > windows IME (the inputed character will be the question mark '?'). > > It puzzled me for a long time. I finally found the reason that ANSI Version > functions such as DispatchMessageA and IsDialogMessageA will Ignore the > WM_WCHAR message. > > The attachment 2274_uime.patch.gz is the patch for vim 7.2.446, > 2477_uime.patch.gz is for 7.3d revision 2...@mercurial. Thanks. Can a few people verify this works OK with different compilers? -- hundred-and-one symptoms of being an internet addict: 2. You kiss your girlfriend's home page. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Corrupt display with multi-byte 'listchars'
Using a recent version of the vim73 repo (e037ee8598b3), the below steps show some display corruption. >From Vim's source directory, use the attached test.vim as follows and perform a search for "text" -- /text. $ vim -u test.vim -N runtime/syntax/tex.vim Namely, the cursor is displayed in an incorrect position but 'ga' does show that it is on the 't' from "texTypeSize". Also, the search causes a fold to open and remnants of the 'foldtext' is still displayed. ":redraw!" will clear the remnants of the 'foldtext' but the other display corruption still exists. Issuing ":set list!" to toggle the list characters on and off will show that the cursor is at the start of the match, as expected, and that enabling 'list' changes the display of items other than those being covered by 'list'. For example, some of the groups listed in the contains list for texCmdGroup get garbled when 'list' is enabled. So far, I've only been able to reproduce this when viewing the tex syntax file. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- 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 test.vim Description: Binary data
Re: [Win32] common dialogs of gVim cannot input some Unicode characters from IME
On Wed, 4 Aug 2010, Bram Moolenaar wrote: Yanwei Jia wrote: The attachment 2274_uime.patch.gz is the patch for vim 7.2.446, 2477_uime.patch.gz is for 7.3d revision 2...@mercurial. Can a few people verify this works OK with different compilers? It compiles fine for me under Cygwin's gcc-3. I didn't test it beyond compiling since I don't use IME (and, in fact, have no idea how to use it). - Christian -- Christian J. Robinson -- 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
Re: Question about :find completion support in Vim 7.3b
On Wed, Aug 4, 2010 at 12:46 PM, Bram Moolenaar wrote:
>
> Nazri Ramliy wrote:
>
>> On Wed, Aug 4, 2010 at 7:20 PM, Bram Moolenaar wrote:
>> > If the arguments are the same the returned values should be the same.
>> > You will need to use a debugger to find out what really happens.
>>
>> I did. The problem is due to the static nature of "recursive" in
>> gen_expand_wildcards().
>> Please see my patches to fix this in an earlier follow-up message [1].
>
> Yeah, I included this now. I fixed a memory leak and moved the
> concatenation of strings to a separate function.
>
>> > I noticed another problem: with 'path' set to "./**" and in an empty
>> > buffer :find completion crashes. =A0I fixed it.
>>
>> Thanks. I'll add this check to the test script.
>>
>> > Maybe I'll have time to look at the completion code, looks like you are
>> > getting lost.
>>
>> The light bulb turned on for me when I insert a debug message to print
>> the value of "recursive" at the top of gen_expand_wildcards().
>> It revealed that when doing
>>
>> :echo globpath("c:/src/**", "misc*")
>>
>> globpath() is called with recursive set to FALSE, while doing
>>
>> :find misc
>>
>> globpath() is called with recursive set to TRUE, which is why it
>> doesn't work the
>> same way.
>>
>> The patch attached in [1] seems to fix that. With that patch the find
>> completion
>> uses the same code for both windows and unix.
>
> OK. I also set recursive back to TRUE to stay on the safe side.
Seems to work well; the speedup is noticeable on WinXP.
Nazri, for the future, you may want to try and add path completion for :cd
Ajit
--
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
Re: Corrupt display with multi-byte 'listchars'
On Wed, Aug 4, 2010 at 12:04 PM, James Vega wrote: > So far, I've only been able to reproduce this when viewing the tex > syntax file. That would be because tex.vim added 'ambiwidth=double' to its modeline in changeset f8f81a88a047. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- 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
Vim 7.3d ready for beta testing
Hello Vim users, Announcing: Vim (Vi IMproved) version 7.3d BETA This is a BETA release of Vim 7.3. It consists of Vim 7.2 plus all patches, updated runtime files and some more. 7.3d is for a large part the same as 7.3c, but the MS-Windows executables have been build with MSVC 2008. They should now work on Windows 2000 too. The install and uninstall problems for 64 bit systems have been fixed (I hope). Please report every problem you find! The 7.3 release should not contain a problem because you didn't report it. The biggest additions since 7.2: - Persistent undo, undo for reload - Blowfish encryption, also encrypt the swap file - Conceal text (note: since 7.3a 'conc' was renamed to 'cole') - Lua interface - Python 3 interface I will no longer include new features in 7.3, it's only testing now. Once you have installed Vim 7.3d BETA you can find details about the changes since Vim 7.2 with: :help version-7.3 Testing --- Please especially test the persistent undo and encryption. These need to work reliably. Report anything that isn't right. That includes a crash but also a typo in the documentation and a missing file. Gratitude - If you like Vim, this is the way to say thanks: http://iccf-holland.org/clinic.html Where to get it --- The best way to obtain the latest Vim 7.3 is using Mercurial. Summary: hg clone https://vim.googlecode.com/hg/ vim cd vim hg update vim73 More information here: http://www.vim.org/mercurial.php All downloadable files can be found below this directory: ftp://ftp.vim.org/pub/vim/unstable/ Direct link to the MS-Windows self-installing executable: ftp://ftp.vim.org/pub/vim/unstable/pc/gvim73d.exe Information about which files to download for what system (don't use the links, they are still for Vim 7.2): http://www.vim.org/download.php A list of mirror sites can be found here: http://www.vim.org/mirrors.php An overview of the files below "unstable": UNIX: unix/vim-7.3d.tar.bz2 sources + runtime files, bzip2 compressed MS-WINDOWS one-size-fits-all: pc/gvim73d.exe self-installing, includes all runtime files VARIOUS: doc/vim73dhtml.zip help files converted to HTML MS-WINDOWS separate files: pc/vim73drt.zip runtime files pc/gvim73d.zip GUI binary for Windows 95/98/NT/2000/XP pc/gvim73dole.zip GUI binary with OLE support pc/gvim73d_s.zipGUI binary for Windows 3.1 (untested) pc/vim73dd32.zipconsole version for MS-DOS/Windows 95/98 pc/vim73dw32.zipconsole version for Windows NT/2000/XP pc/vim73dsrc.zipsources for PC (with CR-LF) DIFFS TO PREVIOUS RELEASE: unix/vim-7.3c-7.3d.diff.gz sources + runtime files Omitted in this version are: - Extra and lang archives, these are now included in the main source and runtime archives. - The 16-bit DOS, OS/2 and Amiga versions, these are obsolete. Mailing lists - For user questions you can turn to the Vim mailing list. There are a lot of tips, scripts and solutions. You can ask your Vim questions, but only if you subscribe. See http://www.vim.org/maillist.php#vim If you want to help Vim development, discuss new features or get the latest patches, subscribe to the vim-dev mailing list. See http://www.vim.org/maillist.php#vim-dev Subject specific lists: Multi-byte issues: http://www.vim.org/maillist.php#vim-multibyte Macintosh issues: http://www.vim.org/maillist.php#vim-mac Before you ask a question you should search the archives, someone may already have given the answer. Reporting bugs -- Send them to . Please describe the problem precisely. All the time spent on answering mail is subtracted from the time that is spent on improving Vim! Always give a reproducible example and try to find out which settings or other things influence the appearance of the bug. Try starting without your own vimrc file: "vim -u NONE". Try different machines if possible. See ":help bugs" in Vim. Send me a patch if you can! Happy Vimming! -- hundred-and-one symptoms of being an internet addict: 3. Your bookmark takes 15 minutes to scroll from top to bottom. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [Win32] common dialogs of gVim cannot input some Unicode characters from IME
At 2010-08-04 23:46:23, "Bram Moolenaar" wrote: > >JiaYanwei wrote: > >> For example, I work with Windows Xp Simplified Chinese Edition. There's a >> character 'CIRCLED NUMBER TWENTY' - U+2473, beyond the character set of ACP >> (system active codepage) CP936. While it can be copyed and pasted into the >> textbox of Find and Replace dialog, but it can't be inputed directly from >> windows IME (the inputed character will be the question mark '?'). >> >> It puzzled me for a long time. I finally found the reason that ANSI Version >> functions such as DispatchMessageA and IsDialogMessageA will Ignore the >> WM_WCHAR message. >> >> The attachment 2274_uime.patch.gz is the patch for vim 7.2.446, >> 2477_uime.patch.gz is for 7.3d revision 2...@mercurial. > >Thanks. > >Can a few people verify this works OK with different compilers? I have just compiled it with msvc2005 express & mingw and also have tested it. It works ok. ps: I have got a same waring many times while compile it by vc2005: warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss This warning is useful for the IDE since soure maybe modified by it. But we don't compile vim with the IDE, so... could we add "/wd4819" to CFLAGS to disable it? > >-- >hundred-and-one symptoms of being an internet addict: >2. You kiss your girlfriend's home page. > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ >///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ >\\\download, build and distribute -- http://www.A-A-P.org/// > \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Corrupt display with multi-byte 'listchars'
On Wed, Aug 4, 2010 at 12:49 PM, James Vega wrote: > On Wed, Aug 4, 2010 at 12:04 PM, James Vega wrote: >> So far, I've only been able to reproduce this when viewing the tex >> syntax file. > > That would be because tex.vim added 'ambiwidth=double' to its modeline > in changeset f8f81a88a047. Apparently, some of the characters I use in my 'listchars' settings (Middle Dot (U+00B7) and Section Sign (U+00A7)) have ambiguous width. I can workaround the issue with Middle Dot by using Dot Operator (U+22C5) instead, but the only replacement I've found for Section Sign is Paragraph Separator (U+2029). Only problem with that is it's considered whitespace, so it doesn't display anything useful. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- 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
Re: Corrupt display with multi-byte 'listchars'
James Vega wrote: > Using a recent version of the vim73 repo (e037ee8598b3), the below steps > show some display corruption. > > From Vim's source directory, use the attached test.vim as follows and > perform a search for "text" -- /text. > > $ vim -u test.vim -N runtime/syntax/tex.vim > > Namely, the cursor is displayed in an incorrect position but 'ga' does > show that it is on the 't' from "texTypeSize". Also, the search causes > a fold to open and remnants of the 'foldtext' is still displayed. > > ":redraw!" will clear the remnants of the 'foldtext' but the other > display corruption still exists. > > Issuing ":set list!" to toggle the list characters on and off will show > that the cursor is at the start of the match, as expected, and that > enabling 'list' changes the display of items other than those being > covered by 'list'. For example, some of the groups listed in the > contains list for texCmdGroup get garbled when 'list' is enabled. > > So far, I've only been able to reproduce this when viewing the tex > syntax file. That's because of this modeline: " vim: ts=8 fdm=marker ambw=double It sets 'ambiwidth' to "double" after setting 'listchars'. That's what is causing the trouble, because the 0xb7 character is then suddenly double width. I think the way to solve it is to disallow changing 'ambiwith' when it causes 'listchars' or 'fillchars' to become invalid. I'll make a patch for that. Perhaps we should remove 'ambiwidth' from that modeline? -- Everybody wants to go to heaven, but nobody wants to die. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [PATCH] Add options for opening dropped files in new tabs
On 4 August 2010 12:20, björn wrote:
> On 3 August 2010 23:28, Lech Lorens wrote:
>> On 03-Aug-2010 Michael Trim wrote:
>>> The attached patch adds two options which together allow dropped files
>>> to always be loaded as tabs instead of in the current window or a
>>> split window. Files loaded via the Windows shell extension ("Edit
>>> with existing Vim...") should also be affected, since the shell
>>> extension sends a WM_DROPFILES message to the exisiting Vim window.
>>>
>>> This seems like something that should be possible with AutoCmds or
>>> something, but my Googlings [1] didn't come up with anything except
>>> other people wanting this type of behaviour [2].
>>>
>>> It would be nice if this patch could find its way into 7.3, but I
>>> realise it is a bit late.
>>>
>>> [1] http://www.google.com/search?q=vim+open+dropped+file+new+tab
>>> [2]
>>> http://stackoverflow.com/questions/1891513/can-i-force-gvim-to-open-dragged-in-files-in-a-new-tab
>>
>>
>> Aren't the 'dropnewtab' and 'dropsplit' mutually exclusive? If so,
>> wouldn't it be better if there was a single setting (e.g.
>> 'drop') which could have a value of either "split" or "newtab"?
>
> ...and to be consistent with startup arguments (-o/-O/-p) there should
> also be a value for "vertical split". This is how MacVim works
> (although this behavior is implemented as a Preference in the MacVim
> app and not as a Vim option).
>
> I haven't looked at the patch but if implemented as one option (as
> Lech suggested) then I'd support the inclusion of such a patch.
> (Which would mean I could get rid of my hack in MacVim to support this
> behavior.)
>
> Björn
The two options as implemented in the patch are not mutually
exclusive, though they could perhaps be better named:
- nodropnewtab + nodropsplit (default) = current behaviour, where
dropped files will be opened in a (horizontally) split window if Ctrl
is held or the current buffer has unsaved changes.
- nodropnewtab + dropsplit = dropped files are always opened in a
split window, unless Ctrl is held.
- dropnewtab + nodropsplit = same as the current behaviour but with
tabs, i.e. dropped files will be opened in a tab if Ctrl is held or
the current buffer has unsaved changes.
- dropnewtab + dropsplit = dropped files are always opened in a new
tab, unless Ctrl is held.
The patch as it stands is quite simple and only introduces a couple of
lines of extra code, most of the rest being for the config options and
documentation. It would be fairly simple to add vertical splitting as
well.
Perhaps the options could be:
dropsplittype = { vertical, horizontal, tab }
dropsplitalways = boolean
I'm not sure that it makes sense to combine the options, as they are
handled separately anyway and all the possible combinations are valid.
--Mike
--
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
Re: [PATCH] Add options for opening dropped files in new tabs
On 4 August 2010 21:01, Michael Trim wrote: > > The two options as implemented in the patch are not mutually > exclusive, though they could perhaps be better named: > - nodropnewtab + nodropsplit (default) = current behaviour, where > dropped files will be opened in a (horizontally) split window if Ctrl > is held or the current buffer has unsaved changes. > - nodropnewtab + dropsplit = dropped files are always opened in a > split window, unless Ctrl is held. > - dropnewtab + nodropsplit = same as the current behaviour but with > tabs, i.e. dropped files will be opened in a tab if Ctrl is held or > the current buffer has unsaved changes. > - dropnewtab + dropsplit = dropped files are always opened in a new > tab, unless Ctrl is held. I see. Well, then this patch is somewhat irrelevant for MacVim anyway as MacVim does not support holding modifier keys when dropping files, so I will withdraw from this thread... Björn -- 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
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: > On Wed, Aug 4, 2010 at 7:20 PM, Bram Moolenaar wrote: > > If the arguments are the same the returned values should be the same. > > You will need to use a debugger to find out what really happens. > > I did. The problem is due to the static nature of "recursive" in > gen_expand_wildcards(). > Please see my patches to fix this in an earlier follow-up message [1]. > > > I noticed another problem: with 'path' set to "./**" and in an empty > > buffer :find completion crashes. =A0I fixed it. > > Thanks. I'll add this check to the test script. The test script works OK on Unix, but on MS-Windows it only finds two of the three files. Also interactively, so this appears to be a problem in the implementation. I already changed it to use three separate "mkdir" commands, as "mkdir -p" doesn't work on MS-Windows (and some old Unixen too). I used an edit command instead of ":!echo" to make it portable. What I can't figure out is a portable way to delete the created directories. "rmdir /s /q Xfind" should work, but it gives an error for the /s option... -- The goal of science is to build better mousetraps. The goal of nature is to build better mice. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Problem with latest vimdiff
Using the latest vim73, changeset c945fdb34ce3, Wed Aug 04 20:55:44 2010 +0200, the two windows of a vimdiff display can get out of sync. To demonstrate the problem, cd to the vim/src directory and execute this command. vim -d -N -u NONE -i NONE <(hg cat -r ae22c450546c if_cscope.c) <(hg cat -r 4269a0673478 if_cscope.c) The results are affected by the size of the changed regions and the number of lines in the terminal. For this example, I used an 80x24 xterm. The cursor will be in the upper left corner of the left window. Type j 6 times and the cursor will move down the window as it should. Type j again so that the cursor enters the top of the added lines and observe that the right window scrolls down and is no longer aligned with the left window. Type k and observe that the right window scrolls up but is still not aligned. Type k again and the right window continues to scroll up, one line at a time, until the cursor reaches the top of the left window, at which point the two windows are again properly aligned. :version VIM - Vi IMproved 7.3e BETA (2010 Aug 4, compiled Aug 4 2010 13:24:29) Compiled by garyj...@... Normal version with GTK2 GUI. Features included (+) or not (-): -arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path +find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse +mouseshape -mouse_dec +mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra -perl +persistent_undo +postscript +printer -profile -python -python3 +quickfix +reltime -rightleft -ruby +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "$VIM/gvimrc" user gvimrc file: "$HOME/.gvimrc" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/home/garyjohn/src/Linux/vim-7.3-hg/share/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -DXTHREADS -D_RE ENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/u sr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/ freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/gli b-2.0/include -g -O2 -I/usr/X11R6/include Linking: gcc -L/usr/X11R6/lib -L/usr/local/lib -o vim -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1 .0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lXt -lm -lncurses -lsel inux -lacl -lgpm OS is RHEL4. 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
Re: Vim 7.3d ready for beta testing
On Aug 4, 12:15 pm, Bram Moolenaar wrote: > > I will no longer include new features in 7.3, it's only testing now. > I assume bug fixes don't count as new features and can still be included. About how long until 7.3 is out of beta entirely, do you think? -- 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
PHP Omnicompletion
As per numerous requests I've been told to post here to get my updated phpcomplete.vim script (http://www.vim.org/scripts/script.php? script_id=3171) included as the default in 7.3. How does one go about doing that? -- 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
BUG: ``E685: Internal error: func_unref()'' when using delfunction on local function varible containing a dictionary function
Attached script causes a error when sourced using
vim -u NONE -c 'set nocompatible' -c 'so ~/tmp/vim/test-bug.vim
Error message:
Error detected while processing /home/zyx/tmp/vim/test-bug.vim:
line8:
E685: Internal error: func_unref()
E685: Internal error: func_unref()
Tested on vim-7.2.442 and vim-7.3 revision
2493:ed997d0ceb2674b8fb3d707130647197c5cf8f83.
function! GetFunction()
let r={}
execute "function r.f()\n".
\"endfunction"
let F=r.f
delfunction F
endfunction
call GetFunction()
signature.asc
Description: This is a digitally signed message part.
Re: Corrupt display with multi-byte 'listchars'
On 04/08/10 20:54, Bram Moolenaar wrote: James Vega wrote: Using a recent version of the vim73 repo (e037ee8598b3), the below steps show some display corruption. From Vim's source directory, use the attached test.vim as follows and perform a search for "text" -- /text. $ vim -u test.vim -N runtime/syntax/tex.vim Namely, the cursor is displayed in an incorrect position but 'ga' does show that it is on the 't' from "texTypeSize". Also, the search causes a fold to open and remnants of the 'foldtext' is still displayed. ":redraw!" will clear the remnants of the 'foldtext' but the other display corruption still exists. Issuing ":set list!" to toggle the list characters on and off will show that the cursor is at the start of the match, as expected, and that enabling 'list' changes the display of items other than those being covered by 'list'. For example, some of the groups listed in the contains list for texCmdGroup get garbled when 'list' is enabled. So far, I've only been able to reproduce this when viewing the tex syntax file. That's because of this modeline: " vim: ts=8 fdm=marker ambw=double It sets 'ambiwidth' to "double" after setting 'listchars'. That's what is causing the trouble, because the 0xb7 character is then suddenly double width. I think the way to solve it is to disallow changing 'ambiwith' when it causes 'listchars' or 'fillchars' to become invalid. I'll make a patch for that. Perhaps we should remove 'ambiwidth' from that modeline? I guess the error is mine. A few days ago Dr. Chip asked my help about a problem he had with various kinds of double angle math operators and brackets, wondering how to represent the \ll and \gg codes that can appear in, I think, TeX. Some of these double angled glyphs were displayed (in his gvim but not in mine) in what looked like half of a double-width glyph, and I mentioned the 'ambiwidth' option. However I didn't realize that it was for use in a syntax script for general consumption. I suppose I should have stressed, more than I did, the fact that 'ambiwidth' should be set on or off in correlation with the needs of whatever 'guifont' (or, maybe, terminal font) one is using. It is a global option, and as such dangerous to use in a modeline, which is meant to set only local options. The 'encoding' option has recently been disallowed in modelines. Setting 'guifont' is usually harmless, except that going from a Latin font to a Chinese one or vice-versa could throw 'ambiwidth' out of whack, and that setting 'ambiwidth' on may render 'listchars' and/or 'fillchars' invalid if they include ambiguous-width characters. Forbidding any change of 'guifont' or 'ambiwidth' in modelines might be viewed as too harsh ... or is it? Best regards, Tony. -- Cahn's Axiom: When all else fails, read the instructions. -- 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
Re: Corrupt display with multi-byte 'listchars'
On Thu, 5 Aug 2010, Tony Mechelynck wrote: Forbidding any change of 'guifont' or 'ambiwidth' in modelines might be viewed as too harsh ... or is it? For what it's worth, I would never want 'guifont' to be changed by a modeline, and I tend to think 'ambiwidth' should not be settable by a modeline either. I'll go further and say that in my opinion, any of the options that are global only should not be settable by a modeline. There is just too much potential for it to cause problems. - Christian -- Christian J. Robinson -- 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
Vim Update on my repository
My repository has moved. It was: http://www.sim1.us:8080/svn/vim_stuff. Login was Anonymous, password was blank It is now: http://www.sim1.us:8443/svn/vim_stuff. Login is still "Anonymous" and password should still be blank. Got a new server and had to reinstall everything. Mark -- 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
Re: PHP Omnicompletion
On Thu, Aug 5, 2010 at 3:20 AM, Shawn B. wrote: > As per numerous requests I've been told to post here to get my updated > phpcomplete.vim script (http://www.vim.org/scripts/script.php? > script_id=3171) included as the default in 7.3. How does one go about > doing that? In general you'd contact the maintainer of the currently provided script and see if you can have your changes included. Alternatively, and if the above has failed for some reason, is there some general consensus that your version is superior to the currently provided script? Regards, Doug -- 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
