Re: Syntax highlighter should work on extensions .l++ .lxx .y++ .yxx .yy
> So can you suggest a patch? Sure, attaching patch. -- -- 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. --- runtime/filetype.vim 2014-02-24 23:27:22.0 -0800 +++ runtime/filetype.vim 2014-02-24 23:30:42.0 -0800 @@ -1014,7 +1014,7 @@ au BufNewFile,BufRead *.ld setf ld " Lex -au BufNewFile,BufRead *.lex,*.l setf lex +au BufNewFile,BufRead *.lex,*.l,*.lxx,*.l++ setf lex " Libao au BufNewFile,BufRead */etc/libao.conf,*/.libao setf libao @@ -2405,7 +2405,7 @@ au BufNewFile,BufRead *.xsl,*.xslt setf xslt " Yacc -au BufNewFile,BufRead *.yy setf yacc +au BufNewFile,BufRead *.yy,*.yxx,*.y++ setf yacc " Yacc or racc au BufNewFile,BufRead *.y call s:FTy()
Re: Neovim
On 25 February 2014, Jan Larres wrote: > LCD 47 : > > On 25 February 2014, Jan Larres wrote: > >> LCD 47 : > >>> In my opinion the way forward is for enough people to > >>> start reading the code, patiently and diligently, in their own > >>> rhythm. Once there is a critical mass of developers who actually > >>> understand the code, and see it as just old, rather than terrible > >>> or evil, we might see progress. > >> > >> This sounds like a good idea in theory, but I don't think Vim's > >> current development model lends itself to that. How do you > >> determine if someome "actually understands" the code? > > [...] > > > > You don't. It isn't relevant, the goal is not to give merit > > bages, but to actually evolve as a group. From this point of view, > > the process (how the patches are submitted, who gets to say what > > goes in and when, and so on) are just details. > > But it's not just details. That's the point. A flexible and > transparent development model (transparent as in "people will be able > to gauge the success of inclusion of their patches, or at least will > receive official feedback in a reasonable amount of time") is crucial > for motivating potential contributors. How would your suggested > evolving concretely improve things otherwise? People will just > magically contribute better patches at some point? [...] I was actually pointing the other direction. If I were more knowledgeable of the code, I would be more inclined and / or able to give meaningful feedback when something like the multithreading patch is posted, rather than shrug it off as outside my comfort zone. Apply that to a number of regulars, and you'd get an actually functioning group. It's only at that point that it would make sense to start talking about improving the process, fork the project, or whatever else you see fit. /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/groups/opt_out.
Re: [patch] Use rubyarchhdrdir if it exists
James McCoy wrote: > In Ruby 2.x, there exists RbConfig::CONFIG['rubyarchhdrdir'] which > should be used instead of constructing the path from > RbConfig::CONFIG['rubyhdrdir'] and RbConfig::CONFIG['arch']. The > attached patch does this. Thanks, I'll put it on the todo list. -- BLACK KNIGHT: Come on you pansy! [hah] [parry thrust] [ARTHUR chops the BLACK KNIGHT's right arm off] ARTHUR:Victory is mine! [kneeling] We thank thee Lord, that in thy merc- [Black Knight kicks Arthur in the head while he is praying] The Quest for the Holy Grail (Monty Python) /// 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] Add '-' to iskeyword in ftpligin/css.vim
Thank you. I'll post again if I find that the problem can't be fixed without changing 'iskeyword'. Until that, please ignore the patch. 2014-02-25 13:15 GMT+09:00 Bram Moolenaar : > > Masanori Ogino wrote: > > > CSS defines words which contain '-'. This change lets syntax files for > CSS > > highlight such words correctly. > > If the problem is in the syntax file, then fix it in the syntax file. > Changing 'iskeyword' has lots of side effects, better avoid that. > > -- > ARTHUR:A scratch? Your arm's off! > BLACK KNIGHT: No, it isn't. > ARTHUR:Well, what's that then? > BLACK KNIGHT: I've had worse. > The Quest for the Holy Grail (Monty > Python) > > /// 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 > /// > -- Masanori Ogino http://twitter.com/omasanori http://gplus.to/omasanori -- -- 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: Can't build if_perl if -Dusethreads is specified.
On Tuesday, February 25, 2014 1:46:18 PM UTC+9, mattn wrote: > I need to add small fix about this patch. Please wait. Done. Updated https://gist.github.com/mattn/9202034 -- -- 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: Can't build if_perl if -Dusethreads is specified.
I need to add small fix about this patch. Please wait. -- -- 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: Can't build if_perl if -Dusethreads is specified.
On Tuesday, February 25, 2014 1:34:30 PM UTC+9, Bram Moolenaar wrote: > Yasuhiro Matsumoto wrote: > > > When -Dusethreads is specified for building perl, build stops with error. > > Below is a patch. > > > > https://gist.github.com/mattn/9202034 > > > > I tested this on: > > > > linux perl 5.14 & --enable-perlinterp=yes (OK) > > linux perl 5.14 & --enable-perlinterp=dynamic (OK) > > linux perl 5.16 & --enable-perlinterp=yes (OK) > > linux perl 5.16 & --enable-perlinterp=dynamic (OK) > > linux perl 5.18 & --enable-perlinterp=yes (OK) > > linux perl 5.18 & --enable-perlinterp=dynamic (OK) > > linux perl 5.19 & --enable-perlinterp=yes (OK) > > linux perl 5.19 & --enable-perlinterp=dynamic (OK) > > windows strawberry perl 5.16 & DYNAMIC_PERL=yes (OK) > > > What is the error being fixed? So that people who run into that problem > > knows this patch will fix it. gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DDYNAMIC_PERL_DLL=\"libperl.a\" -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/mattn/perl516/lib/5.14.4/x86_64-linux/CORE -o objects/if_perl.o auto/if_perl.c if_perl.xs:172:0: warning: "Perl_croak_nocontext" redefined [enabled by default] /home/mattn/perl516/lib/5.14.4/x86_64-linux/CORE/embed.h:1731:0: note: this is the location of the previous definition if_perl.xs:389:1: error: unknown type name 'perl_key' make: *** [objects/if_perl.o] Error 1 -- -- 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: Perl's new feature 'signatures' break syntax for prototype.
On Mon, Feb 24, 2014 at 07:52:47PM -0800, mattn wrote:
> perl 5.19.9 include signatures feature, and it will be released on 5.20 .
> The feature break syntax of sub-routine prototype. For example, signatures
> allow to write like follow.
>
> sub foo($class, $a, $b = sub(){ warn "foo" }) {
> # ...
> }
>
> Below is a patch.
>
> https://gist.github.com/mattn/9185175
You should submit the patch to https://github.com/vim-perl/vim-perl if
it isn't already fixed there.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
--
--
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: Can't build if_perl if -Dusethreads is specified.
Yasuhiro Matsumoto wrote: > When -Dusethreads is specified for building perl, build stops with error. > Below is a patch. > > https://gist.github.com/mattn/9202034 > > I tested this on: > > linux perl 5.14 & --enable-perlinterp=yes (OK) > linux perl 5.14 & --enable-perlinterp=dynamic (OK) > linux perl 5.16 & --enable-perlinterp=yes (OK) > linux perl 5.16 & --enable-perlinterp=dynamic (OK) > linux perl 5.18 & --enable-perlinterp=yes (OK) > linux perl 5.18 & --enable-perlinterp=dynamic (OK) > linux perl 5.19 & --enable-perlinterp=yes (OK) > linux perl 5.19 & --enable-perlinterp=dynamic (OK) > windows strawberry perl 5.16 & DYNAMIC_PERL=yes (OK) What is the error being fixed? So that people who run into that problem knows this patch will fix it. -- MARTHA'S WAY: Don't throw out all that leftover wine. Freeze into ice cubes for future use in casseroles and sauces. MY WAY: What leftover wine? /// 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: Can't build if_perl if -Dusethreads is specified.
Sorry typo. On Tuesday, February 25, 2014 12:46:53 PM UTC+9, mattn wrote: > When -Dusethreads is specified for building perl, build stops with error. > Below is a patch. When -Dusethreads is NOT specified for building perl, And building with --enable-perlinterp=dynamic, build stops with error. Below is a patch. -- -- 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: Syntax highlighter should work on extensions .l++ .lxx .y++ .yxx .yy
Yuri Vic wrote: > When lex/yacc are used to generate C++ compatible sources, these > extensions are used. However, vim syntax highlighter doesn't currently > recognize them. I think these extensions should be added. > As a reference, GNU automake recognizes them: > http://ftp.gnu.org/old-gnu/Manuals/automake-1.6.1/html_node/automake_35.html > There is also a conflict for .ll extension: automake thinks it is also > lex, when currently it is commonly used as llvm code. So it is better > to keep .ll as llvm. So can you suggest a patch? -- No letters of the alphabet were harmed in the creation of this message. /// 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] Add '-' to iskeyword in ftpligin/css.vim
Masanori Ogino wrote: > CSS defines words which contain '-'. This change lets syntax files for CSS > highlight such words correctly. If the problem is in the syntax file, then fix it in the syntax file. Changing 'iskeyword' has lots of side effects, better avoid that. -- ARTHUR:A scratch? Your arm's off! BLACK KNIGHT: No, it isn't. ARTHUR:Well, what's that then? BLACK KNIGHT: I've had worse. The Quest for the Holy Grail (Monty Python) /// 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.
Perl's new feature 'signatures' break syntax for prototype.
perl 5.19.9 include signatures feature, and it will be released on 5.20 .
The feature break syntax of sub-routine prototype. For example, signatures
allow to write like follow.
sub foo($class, $a, $b = sub(){ warn "foo" }) {
# ...
}
Below is a patch.
https://gist.github.com/mattn/9185175
Thanks.
- Yasuhiro Matsumoto
--
--
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.
Can't build if_perl if -Dusethreads is specified.
When -Dusethreads is specified for building perl, build stops with error. Below is a patch. https://gist.github.com/mattn/9202034 I tested this on: linux perl 5.14 & --enable-perlinterp=yes (OK) linux perl 5.14 & --enable-perlinterp=dynamic (OK) linux perl 5.16 & --enable-perlinterp=yes (OK) linux perl 5.16 & --enable-perlinterp=dynamic (OK) linux perl 5.18 & --enable-perlinterp=yes (OK) linux perl 5.18 & --enable-perlinterp=dynamic (OK) linux perl 5.19 & --enable-perlinterp=yes (OK) linux perl 5.19 & --enable-perlinterp=dynamic (OK) windows strawberry perl 5.16 & DYNAMIC_PERL=yes (OK) 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/groups/opt_out.
Re: Problem with Python 3.4
reported to python bug tracker http://bugs.python.org/issue20763 -- Yukihiro Nakadaira - yukihiro.nakada...@gmail.com -- -- 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] Add '-' to iskeyword in ftpligin/css.vim
CSS defines words which contain '-'. This change lets syntax files for CSS
highlight such words correctly.
--
Masanori Ogino
http://twitter.com/omasanori
http://gplus.to/omasanori
--
--
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.
# HG changeset patch
# User Masanori Ogino
# Date 1393299459 -32400
# Node ID 4f809c57124580ca6dc2d05bdbdb6cb78ea3a3fe
# Parent 10d35c8b50e3243419568294751094edab272a73
Add '-' to iskeyword in ftplugin/css.vim.
CSS defines words which contain '-'. This change lets syntax files for CSS
highlight such words correctly.
diff --git a/runtime/ftplugin/css.vim b/runtime/ftplugin/css.vim
--- a/runtime/ftplugin/css.vim
+++ b/runtime/ftplugin/css.vim
@@ -6,18 +6,19 @@
if exists("b:did_ftplugin")
finish
endif
let b:did_ftplugin = 1
let s:cpo_save = &cpo
set cpo&vim
-let b:undo_ftplugin = "setl com< cms< inc< fo< ofu<"
+let b:undo_ftplugin = "setl com< cms< inc< fo< ofu< isk<"
setlocal comments=s1:/*,mb:*,ex:*/ commentstring&
setlocal formatoptions-=t formatoptions+=croql
setlocal omnifunc=csscomplete#CompleteCSS
+setlocal iskeyword+=-
let &l:include = '^\s*@import\s\+\%(url(\)\='
let &cpo = s:cpo_save
unlet s:cpo_save
Re: Add Apache's ProxyPassMatch keyword to apache.vim
Adam Matan wrote: > Apache's ProxyPassMatch directive > (http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassmatch) > is not recognised as a keyword in vim. > I've added the directive to apache's syntax file and attached the > diff. It is my first contribution to vim, so please let me know if the > diff format is correct. The maintainer for that file is in the header. Please send the patch to him. -- ARTHUR:I command you as King of the Britons to stand aside! BLACK KNIGHT: I move for no man. The Quest for the Holy Grail (Monty Python) /// 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] Add option to disable insert completion message in shortmess
+1 to this. On Tuesday, December 31, 2013 1:01:55 PM UTC+1, Shougo wrote: > Hi, Bram. > > > > I created the patch for adding option to disable insert completion message in > > shortmess. > > Because, the completion message is not useful for powered users. > > But it clears previous command line messages and flicks command line. > > So I think this message can be disabled like other messages by option. > > > > > > "Why do you use Vim?" > > "Because, Vim is avalable." > > > > Dark Vim Master(暗黒美夢王/Uncock Vim Awe) Shougo / My Vim is Dark(neo-plugins) > powered. > > -- -- 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.
Syntax highlighter should work on extensions .l++ .lxx .y++ .yxx .yy
When lex/yacc are used to generate C++ compatible sources, these extensions are used. However, vim syntax highlighter doesn't currently recognize them. I think these extensions should be added. As a reference, GNU automake recognizes them: http://ftp.gnu.org/old-gnu/Manuals/automake-1.6.1/html_node/automake_35.html There is also a conflict for .ll extension: automake thinks it is also lex, when currently it is commonly used as llvm code. So it is better to keep .ll as llvm. vim-7.4.110_3 Yuri -- -- 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: Neovim
LCD 47 : > On 25 February 2014, Jan Larres wrote: >> LCD 47 : >>> In my opinion the way forward is for enough people to start >>> reading the code, patiently and diligently, in their own rhythm. >>> Once there is a critical mass of developers who actually understand >>> the code, and see it as just old, rather than terrible or evil, we >>> might see progress. >> >> This sounds like a good idea in theory, but I don't think Vim's >> current development model lends itself to that. How do you determine >> if someome "actually understands" the code? > [...] > > You don't. It isn't relevant, the goal is not to give merit bages, > but to actually evolve as a group. From this point of view, the process > (how the patches are submitted, who gets to say what goes in and when, > and so on) are just details. But it's not just details. That's the point. A flexible and transparent development model (transparent as in "people will be able to gauge the success of inclusion of their patches, or at least will receive official feedback in a reasonable amount of time") is crucial for motivating potential contributors. How would your suggested evolving concretely improve things otherwise? People will just magically contribute better patches at some point? Even if that were to happen that would still require Bram to spend time reviewing all of them, so we're back to square one as that is exactly what he doesn't have enough time to do. Like I said, it's a good idea in theory but I don't think it would work out without any other changes. If it could work out something like that would most likely have already happened by now given how long Vim has been around. -Jan -- -[ OpenPGP key ID: 00A0FD5F ]- Technological progress has merely provided us with more efficient means for going backwards. -- Aldous Huxley -- -- 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: Neovim
On 25 February 2014, Jan Larres wrote: > LCD 47 : > > In my opinion the way forward is for enough people to start > > reading the code, patiently and diligently, in their own rhythm. > > Once there is a critical mass of developers who actually understand > > the code, and see it as just old, rather than terrible or evil, we > > might see progress. > > This sounds like a good idea in theory, but I don't think Vim's > current development model lends itself to that. How do you determine > if someome "actually understands" the code? [...] You don't. It isn't relevant, the goal is not to give merit bages, but to actually evolve as a group. From this point of view, the process (how the patches are submitted, who gets to say what goes in and when, and so on) are just details. /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/groups/opt_out.
Re: Neovim
On 24 February 2014, Marc Weber wrote: [...] > Thus its even more important that we try to turn Vim into kind of > "business" model - because "specialization" is the engine of todays > world - even more for complex software like Vim. What I'm saying is, it takes _knowledge_ to move forward. Now, some amount of knowledge can be bought (making a business out of your project, hiring people etc.), some other amount can be borrowed (using frameworks, libraries, and the like), and yet some amount can be obtained as a gift (the open source way). However, in my experience most of it has to be earned. It is seldom if ever achieved by spontaneous generation. :) http://en.wikipedia.org/wiki/Spontaneous_generation [...] > What tarruda is doing is the right thing [...] I actually like this project too. I'm just pointing out it's better to think first and then do the work, rather than do the work then find out you should have spent more time thinking first. *shrug* /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/groups/opt_out.
Re: Neovim
LCD 47 : > In my opinion the way forward is for enough people to start reading > the code, patiently and diligently, in their own rhythm. Once there is > a critical mass of developers who actually understand the code, and see > it as just old, rather than terrible or evil, we might see progress. This sounds like a good idea in theory, but I don't think Vim's current development model lends itself to that. How do you determine if someome "actually understands" the code? By submitting refactoring patches, or enough patches in general? But several people already have submitted many patches, and many of the needed refactorings, like getting rid of global variables, actually require bigger changes, and Bram would probably be (understandably) reluctant to include them right away. The result of that would be that they just sit in the todo list like so many other patches. I think the best solution to this would be to get rid of the "one branch with patches" model and instead have at least a stable and a development branch, with more people than just Bram being able to commit to the development branch. Bigger changes like refactorings or the new regex engine even could get their own feature branch. That's what VCSs like Mercurial are good at, but it's not being made use of at the moment. With this model the stable branch would be used for releases and by people who care most about stability, and people who are willing to try out new features could use the development branch(es). Unless they disable swap files that shouldn't even be a big risk in general. I'm sure this approach would also motivate more people to contribute when they don't feel like it's a gamble whether their changes will ever actually make it in. -Jan -- -[ OpenPGP key ID: 00A0FD5F ]- If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him. -- Cardinal De Richelieu -- -- 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: Neovim
> In my opinion the way forward is for enough people to start reading > the code, patiently and diligently, in their own rhythm. Once there is > a critical mass of developers who actually understand the code, Which will never happen because those people today who want to code might no longer choose C for good reasons (for such a large project) And more than that - starting with Vim',s code base is a huge undertaking. Rule of thumb: Reviewing code takes 50% of the time it took the author to write ! (Which means a lot of time -> nobody can do this in his/her spare time IMHO - without sacrifying family personal goals and the like) Thus its even more important that we try to turn Vim into kind of "business" model - because "specialization" is the engine of todays world - even more for complex software like Vim. Libraries such as libuv just do that: they forward the task of having unique interfaces to a central place - and often its a good idea. I asked in 2010 whether Bram would be willing to spend more time on Vim if he got payed (didn't get a reply that time): reference: https://groups.google.com/forum/#!topic/vim_dev/43b6gsHh4Ok If he had I would have tried starting crowd funding campaigns that time. And that's why I hope that tarruda turns this into a business (for everyone) - so that he (and others) can keep working on their code plugins / parts of vim. Whatever the outcome will be - we'll be smarter afterwards :) What did I learn from the mailinglist recently? The more the merrier. The usual problem is that people have to give up to make a living (eg ensime project), quote from its readme: "A quick note on status: Events in my life have conspired to give me less free time to work on ENSIME." And this is happening to a lot of open source projects (wasting a lot of time of those people who invested some time on such - eg my writing the first ensime frontend for Vim - which I had to give up for time/money reasons, too). What tarruda is doing is the right thing - and I hope that he creates kind of market place for proposals/ people joining them (offering funding) / and programmers saying "for this money I'll get the job done". Then we'll have a healthy community (IMHO). Again - you are free to think differently. I'm pretty sure that tarruda will break a lot of things (by accident). But there is still a chance for paying off in the long run. Marc Weber -- -- 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: Neovim
On 24 February 2014, Diego Viola wrote: > I don't understand, Bram says "It's much better to improve what we > have." which is good and reasonable to me. I agree with this. > > But then we have people like Thiago de Arruda (aka tarruda) who have > worked very hard on multithreading support for Vim, and his patches > didn't make it into mainline Vim. > > So how can we "improve what we have" when 99% of the patches are > ignored or rejected according to most developers? I believe you miss the big picture here. At this point, virtually nobody aside from Bram understands the code well enough to make "big" changes. The other "main" developers are just people that know enough about the code to scratch their own itches. These people post patches occasionally (and Bram usually includes their patches), but their interest is generally limited to particular pieces of Vim, and don't have either the motivation or the resources to look anywhere else. As a result, what happens when an "outsider" posts something as far reaching as the recent timeout / async patch, or the multithreading patch, is that Bram is reluctant to write an in-depth analysis (he has been at this for 20+ years, he has a job, a life, and he already has his hands full just from maintaining Vim as it is), and nobody else really feels qualified to post a meaningful answer. The only somewhat informed feedback the author receives is then a few vague and / or opinionated rants that rarely go beyond pointing out the obvious. Then the author concludes that nobody cares, feels offended, takes it personally, and posts frustrated calls to arms on YC. There, they manage to receive a deluge of way more opinionated, way less informed rants about anything and everything Vim except the actual patch, and things slowly loop back to the statu quo ante. On the other hand, most of these far reaching "outsider" patches are, actually, less than perfect. That's to be expected too, partly because what they are trying to do is objectively hard (if it weren't, it would have been done long ago), and partly because the authors don't read the code end to end before starting to write their patch, to make sure their changes doesn't interact badly with other parts of Vim. That's actually the kind of feedback they would expect from the list. But, as I explained above, this doesn't happen. Rinse and repeat. > Sorry, I do have great respect for Bram Moolenaar and his work, I just > don't understand this development model at all. > > Perhaps the fork could have been avoided if the development model was > more reasonable? I don't know. If you think Bram should just merge all these crowd-acclaimed patches, no question asked, you'd be wrong too (IMO, of course). See f.i. what other people have to say about Vim, even without experimental patches: https://news.ycombinator.com/item?id=6668453 As I see it (and for what it's still worth), the way forward is not to lower the standards for accepting patches. It isn't to rewrite Vim from scratch in Haskell, Javascript, Rust, Go, or whatever other language of the day. It isn't to refactor it to use libuv, or other revolutionary library of the day. And it certainly isn't to compile yet another list of flaws, or another wish list. In my opinion the way forward is for enough people to start reading the code, patiently and diligently, in their own rhythm. Once there is a critical mass of developers who actually understand the code, and see it as just old, rather than terrible or evil, we might see progress. /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/groups/opt_out.
syntax highlighting for gnuplot
Hello, I have created an updated version of the gnuplot syntax highlighting file for vim. It is available at http://www.vim.org/scripts/script.php?script_id=4873. The version of gnuplot.vim by John Hoelzel that ships with vim is 11 years out of date, and the only other one I found was by Jim Eberle in 2006 (http://www.vim.org/scripts/script.php?script_id=1737). Many new commands/keywords have been added to gnuplot in the interim, and my gnuplot.vim is much more complete than the old ones. I would like to have this file considered for inclusion in the standard vim distribution, and I would be happy to maintain it if that happens. I haven't ben able to get in touch with the original maintainer--his SF account and website appear to be inactive. Gnuplot users: please let me know if you notice any omissions/bugs, or have questions/comments on the script itself. Vim people: this is my first crack at creating a syntax file like this, and although it works beautifully for me I'd appreciate pointers if you notice anything wrong or missing. Thanks, Andy -- -- 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.
Add Apache's ProxyPassMatch keyword to apache.vim
Hi, Apache's ProxyPassMatch directive (http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassmatch) is not recognised as a keyword in vim. I've added the directive to apache's syntax file and attached the diff. It is my first contribution to vim, so please let me know if the diff format is correct. Best, Adam Matan Problem:Vim Apache syntax lacks the ProxyPassMatch keyword Solution: Add ProxyPassMatch to apache.vim Files: vim/runtime/syntax/apache.vim --- a/runtime/syntax/apache.vim Mon Feb 24 03:32:00 2014 +0100 +++ b/runtime/syntax/apache.vim Mon Feb 24 11:29:09 2014 +0200 @@ -157,7 +157,7 @@ syn keyword apacheDeclaration PerlFreshRestart PerlSendHeader syn keyword apacheDeclaration php_value php_flag php_admin_value php_admin_flag syn match apacheSection "<\/\=\(Proxy\|ProxyMatch\)[^>]*>" contains=apacheAnything -syn keyword apacheDeclaration AllowCONNECT NoProxy ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyIOBufferSize ProxyMaxForwards ProxyPass ProxyPassReverse ProxyPassReverseCookieDomain ProxyPassReverseCookiePath ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxyTimeout ProxyVia +syn keyword apacheDeclaration AllowCONNECT NoProxy ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyIOBufferSize ProxyMaxForwards ProxyPass ProxyPassMatch ProxyPassReverse ProxyPassReverseCookieDomain ProxyPassReverseCookiePath ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxyTimeout ProxyVia syn keyword apacheDeclaration RewriteBase RewriteCond RewriteEngine RewriteLock RewriteLog RewriteLogLevel RewriteMap RewriteOptions RewriteRule syn keyword apacheOption inherit syn keyword apacheDeclaration BrowserMatch BrowserMatchNoCase SetEnvIf SetEnvIfNoCase -- -- 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. diff -r 10d35c8b50e3 runtime/syntax/apache.vim --- a/runtime/syntax/apache.vim Mon Feb 24 03:32:00 2014 +0100 +++ b/runtime/syntax/apache.vim Mon Feb 24 11:32:28 2014 +0200 @@ -157,7 +157,7 @@ syn keyword apacheDeclaration PerlFreshRestart PerlSendHeader syn keyword apacheDeclaration php_value php_flag php_admin_value php_admin_flag syn match apacheSection "<\/\=\(Proxy\|ProxyMatch\)[^>]*>" contains=apacheAnything -syn keyword apacheDeclaration AllowCONNECT NoProxy ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyIOBufferSize ProxyMaxForwards ProxyPass ProxyPassReverse ProxyPassReverseCookieDomain ProxyPassReverseCookiePath ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxyTimeout ProxyVia +syn keyword apacheDeclaration AllowCONNECT NoProxy ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyIOBufferSize ProxyMaxForwards ProxyPass ProxyPassMatch ProxyPassReverse ProxyPassReverseCookieDomain ProxyPassReverseCookiePath ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxyTimeout ProxyVia syn keyword apacheDeclaration RewriteBase RewriteCond RewriteEngine RewriteLock RewriteLog RewriteLogLevel RewriteMap RewriteOptions RewriteRule syn keyword apacheOption inherit syn keyword apacheDeclaration BrowserMatch BrowserMatchNoCase SetEnvIf SetEnvIfNoCase <>
Re: Neovim
On Monday, February 24, 2014 10:29:38 AM UTC+1, Jan Larres wrote: > So in > addition to the refactoring I think that a more flexible development > model that is not dependent on just one person and an antiquated > 'patches' system could definitely improve things. That, however, is something that could be done without changing a line of code, right? -- -- 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: Neovim
OK I'm sorry about that, that was an exaggeration. Sorry. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- 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: Neovim
On Mon Feb 02/24/14 at 8:01, Diego Viola wrote: > But then we have people like Thiago de Arruda (aka tarruda) who have > worked very hard on multithreading support for Vim, and his patches > didn't make it into mainline Vim. > > So how can we "improve what we have" when 99% of the patches are ignored > or rejected according to most developers? I've only been following this list for about a year now, but I can already see that your last paragraph seems unnecessarily negative and the numbers seem pulled from thin air. *99%* of patches are rejected? Really? And *according to most developers*? Really? More realism would help, I think. P -- We have not been faced with the need to satisfy someone else's requirements, and for this freedom we are grateful. Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System -- -- 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] Make 'lispwords' a global-local option
> Currently the 'lispwords' setting is global, yet three filetypes attempt > to change it on filetype/indent load: scheme, clojure, and art. > > Scheme and Clojure, in particular, are two very different Lisp variants, > but both modify 'lispwords' to influence their indenting. Both filetypes > also call `setlocal lispwords<` in undo hooks to unset the local value > of the setting, but of course, this does not work. > > The following attached patches make the 'lispwords' setting global-local > to allow different Lisps to use this setting concurrently: > > > Sounds like a nice idea. I always wondered why lispwords is global :) -- -- 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: Neovim
I don't understand, Bram says "It's much better to improve what we have." which is good and reasonable to me. I agree with this. But then we have people like Thiago de Arruda (aka tarruda) who have worked very hard on multithreading support for Vim, and his patches didn't make it into mainline Vim. So how can we "improve what we have" when 99% of the patches are ignored or rejected according to most developers? Sorry, I do have great respect for Bram Moolenaar and his work, I just don't understand this development model at all. Perhaps the fork could have been avoided if the development model was more reasonable? I don't know. Diego -- -- 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: Neovim
Vundle vs Vam vs .. issues showed that users don't need 100% satisfaction in all cases - projects can still be successful. Eg I mean: Vundle depends on vim-scripts.org - and vim-scripts org maps scripts from www.vim.org to urls by title - and some title occur more than once. Thus there is a chance that you cannot install what you want. (There have been 1-2 issues) - still Vundle hase incredibly many users. So the important question is: Which regressions will be critical to masses and which won't? Time will tell. I'm happy that this "experiment" is taking place. If you don't try to succeed - you failed from the beginning IMHO. Marc Weber -- -- 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: Neovim
Michel Albert : > Partial refactoring is harder (depending on the case, a *lot* harder) > and will take longer but is not risking as much. And not to forget, > has a chance to get merged into the mainline code. The problem with this approach is that everything would still have to go through Bram, which is one of the major hold-ups for many patches that already exist and that arguably improve things. Bram is certainly doing a great job with the time he has available, but he's still a bottleneck as he is only one person. That has led to the todo list getting longer instead of shorter and many patches, including three different approaches for asynchronous processes, just languishing there. So in addition to the refactoring I think that a more flexible development model that is not dependent on just one person and an antiquated 'patches' system could definitely improve things. Jan -- -[ OpenPGP key ID: 00A0FD5F ]- Great minds have purposes, others have wishes. Little minds are tamed and subdued by misfortune; but great minds rise above them. -- Washington Irving -- -- 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: Neovim
> So many years of usage experience went into vim. This means the existing code > addresses a vast number of corner cases which crept up during the years. that's why Bram wants a test for every patch ;) I don't have the expertise to say which path would be the best for neovim, but at least tests should make refactoring a lot easier. I'm more worried about refactoring the code and, at the same time, change / add stuff (like the new plugin system) -- -- 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: Neovim
On Sunday, 23 February 2014 23:51:48 UTC+1, MarcWeber wrote: > Excerpts from Diego Viola's message of Sun Feb 23 09:29:16 + 2014: > > > I would like to start by saying that I admire your work on Vim, I've > > > been using it for quite some time now and I really enjoy using Vim > > > every day. > > For a long time quite some things did bother me. They don't affect > > regular users only editing texts. But they do affect programmers who > > want to write fancy extensions. There are "workarounds", such as > > vimproc, vim-addon-async (eg for async communications), but at least the > > -async workaround is a ugly hack. sample features it provides: > > - ruby debugging > > - php debugging > > - ruby/scala/python repl with completion > > I'm not going into details. the wiki link below lists more (please add > > or edit if you think I'm wrong - you can do so) > > > > I personally get annoyed always when not having touched ~/.vimrc and get > > vi instead of vim (without file name completion - I really think such > > things should be fixed - who is using vi behaviour for what reasons? > > > > If you want some vi behaviour it is the time to tell tarruda about what > > you care. > > > > Another simple use case is: :ruby and :py commands cannot be interrupted > > by ctrl-c like (viml) - and the viml implementation is based on gtk > > event loops (gui) which also runs resize viml autocommands arbitrarely. > > > > Of course you can workaround it - but being ablte to abort an infinite > > loop you wrote by accident is helpful - or if a script takes too long > > for whatever reasons. > > > > tarruda will put if_* into separate threads (I hope he'll succeed) - > > and that might fix such small things. > > > > So there are quite a lot of "weak" reasons summing up IMHO. > > > > I've posted about this list earlier: > > http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html > > > > Bram is right: In current state Vim does get most use cases done > > "reasonably well". In fact it would have been me starting such a > > crowd funding project if I would have been satisfied with C/C++ (But I'm > > not). > > > > There are alternatives, eg rust: rust-lang.org - but I'm unsure how > > stable it is at the moment (eg the release doesn't compile the > > rust-csv library at http://www.rust-ci.org/projects/). That's why I > > personally limited myself to writing down what I'd like to change. > > > > For a lot of users neovim might not change too much - but for those who > > want fancy features it could make a big difference - if tarruda gets > > things done the way he described. > > > > Some of you may remember my thread and my page: http://mawercer.de/vim.php > > I forwarded all people to tarruda who either filled in this form or told > > me that they'd assist. So those about 5-7 people will get contacted by > > him hopefully. > > > > Despite all flaws Vim is still the editor of my choice. > > Patching is a lot of work, rewriting would be a lot of work, > > alternatives exist (eg Yi, written in Haskell) - so finding "one true > > upstream" without splitting the community is not simple. > > > > Is it worth the effort? Depends on your use cases - It might be that Vim > > lives as long as the linux kernel - so the future might be even longer > > than its past - who knows? Then it will pay off for sure (IMHO). > > > > Was it the first fork? No, See YZis short description here: > > http://www.freehackers.org/VimIntegration > > (YZis dropped VimL only supporting lua - and most Vimmers depend on a > > lot of viml plugins ..) > > > > I hope that NeoVim will succeed - and that we don't split community too > > much. > > > > Marc Weber While I agree that there are a couple of things in vim which are annoying, I /think/ (correct me if I'm wrong) Bram was primarily addressing another issue: Total vs Partial refactoring. In my opinion total refactoring is rarely a good idea. The more time and effort went into a project, the riskier it gets. So many years of usage experience went into vim. This means the existing code addresses a vast number of corner cases which crept up during the years. Total refactoring risks an insane amount of regressions. Partial refactoring is harder (depending on the case, a *lot* harder) and will take longer but is not risking as much. And not to forget, has a chance to get merged into the mainline code. The "total refactoring path" is something that pains a lot of the open-source world. It happens so often that an existing project is forked by people who intend to re-write it in a better way. Their intentions are noble. But only few of them succeed. -- -- 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 subscri
