[patch] runtime/ftplugin/sql.vim
Hello David, this patch completes 'b:undo_ftplugin' in 'runtime/ftplugin/sql.vim'. -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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 --- runtime/ftplugin/sql.vim 2012-05-18 22:44:49.0 + +++ ../sql.vim 2012-05-18 22:42:42.0 + @@ -233,7 +233,8 @@ finish endif -let b:undo_ftplugin = "setl comments<" +let b:undo_ftplugin = "setl comments< formatoptions< define< omnifunc<" . + \ " | unlet! b:browsefilter b:match_words" " Don't load another plugin for this buffer let b:did_ftplugin = 1 sql.vim Description: application/wine-extension-vim
[patch] runtime/ftplugin/pyrex.vim
Hello Mario, this patch adds 'b:undo_ftplugin' to 'runtime/ftplugin/pyrex.vim'. -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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 --- runtime/ftplugin/pyrex.vim 2012-05-18 21:19:44.0 + +++ ../pyrex.vim 2012-05-18 22:22:56.0 + @@ -23,5 +23,7 @@ \ "All Files (*.*)\t*.*\n" endif +let b:undo_ftplugin = "unlet! b:browsefilter" + let &cpo = s:keepcpo unlet s:keepcpo pyrex.vim Description: application/wine-extension-vim
Re: [patch] runtime/ftplugin/occam.vim
> Hello Mario, > > this patch fixes a typo inside 'b:undo_ftplugin'. > Mail bounces. We should take over 'runtime/ftplugin/occam.vim'. : 129.12.21.31_does_not_like_recipient./Remote_host_said:_550_user_is_unknown_at_this_domain/Giving_up_on_129.12.21.31./ -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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
[patch] runtime/ftplugin/occam.vim
Hello Mario,
this patch fixes a typo inside 'b:undo_ftplugin'.
--
Regards,
Thilo
4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F
--
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
--- runtime/ftplugin/occam.vim 2012-05-18 21:19:44.0 +
+++ ../occam.vim 2012-05-18 22:15:37.0 +
@@ -42,7 +42,7 @@
"{{{ Undo settings
let b:undo_ftplugin = "setlocal shiftwidth< softtabstop< expandtab<"
\ . " formatoptions< comments< textwidth<"
- \ . "| unlet! b:browsefiler"
+ \ . "| unlet! b:browsefilter"
"}}}
let &cpo = s:keepcpo
occam.vim
Description: application/wine-extension-vim
[patch] runtime/ftplugin/ishd.vim
Hello Johannes, this patch adds 'b:undo_ftplugin' to 'runtime/ftplugin/ishd.vim'. -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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 --- runtime/ftplugin/ishd.vim 2012-05-18 21:19:44.0 + +++ ../ishd.vim 2012-05-18 22:07:59.0 + @@ -29,5 +29,7 @@ \ "All Files (*.*)\t*.*\n" endif +let b:undo_ftplugin = "setl fdm< | unlet! b:browsefilter b:match_ignorecase b:match_words" + let &cpo = s:cpo_save unlet s:cpo_save ishd.vim Description: application/wine-extension-vim
[patch] runtime/ftplugin/cs.vim
Hello Johannes, this patch adds 'b:undo_ftplugin' to 'runtime/ftplugin/cs.vim'. -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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 --- runtime/ftplugin/cs.vim 2012-05-18 22:00:22.0 + +++ ../cs.vim 2012-05-18 21:56:28.0 + @@ -25,5 +25,7 @@ \ "All Files (*.*)\t*.*\n" endif +let b:undo_ftplugin = "setl fo< com< | unlet! b:browsefilter" + let &cpo = s:keepcpo unlet s:keepcpo cs.vim Description: application/wine-extension-vim
[patch] runtime/ftplugin/art.vim
Hello Dorai, this patch adds 'b:undo_ftplugin' to 'runtime/ftplugin/art.vim' -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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 --- runtime/ftplugin/art.vim 2012-05-18 21:19:44.0 + +++ ../art.vim 2012-05-18 21:27:37.0 + @@ -13,3 +13,5 @@ setl lw-=if setl lw+=def-art-fun,deffacts,defglobal,defrule,defschema,for,schema,while + +let b:undo_ftplugin = "setl lw<" art.vim Description: application/wine-extension-vim
runtimefiles updated
Hello Bram, please find attached updates for: runtime/syntax/dirpager.vim runtime/syntax/dnsmasq.vim runtime/syntax/gnash.vim -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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 dirpager.vim Description: application/wine-extension-vim dnsmasq.vim Description: application/wine-extension-vim gnash.vim Description: application/wine-extension-vim
[patch] runtime/syntax/resolv.vim
Hello David, 'runtime/syntax/resolv.vim' uses '[-0-9A-Za-z_\.]' therefore it should handle cpoptions correctly. see ':h cpo-l' for details. -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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 --- runtime/syntax/resolv.vim 2012-05-18 14:57:49.0 + +++ ../resolv.vim 2012-05-18 20:52:46.0 + @@ -12,6 +12,9 @@ finish endif +let s:keepcpo= &cpo +set cpo&vim + " Errors, comments and operators syn match resolvError /./ syn match resolvComment /\s*[#;].*$/ contains=@Spell @@ -84,4 +87,7 @@ let b:current_syntax = "resolv" +let &cpo = s:keepcpo +unlet s:keepcpo + " vim: ts=8 ft=vim resolv.vim Description: application/wine-extension-vim
[patch] runtime/syntax/progress.vim
Hello Philip,
here is small patch for 'runtime/syntax/progress.vim' so that Vim highlights
spelling mistakes in comments only when editing a file with those settings:
:syntax on
:set spell
--
Regards,
Thilo
4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F
--
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
--- runtime/syntax/progress.vim 2012-05-18 20:42:06.0 +
+++ ../progress.vim 2012-05-18 20:40:27.0 +
@@ -99,8 +99,8 @@
" Strings. Handles embedded quotes.
" Note that, for some reason, Progress doesn't use the backslash, "\"
" as the escape character; it uses tilde, "~".
-syn region ProgressString matchgroup=ProgressQuote start=+"+ end=+"+ skip=+\~'\|\~\~+
-syn region ProgressString matchgroup=ProgressQuote start=+'+ end=+'+ skip=+\~'\|\~\~+
+syn region ProgressString matchgroup=ProgressQuote start=+"+ end=+"+ skip=+\~'\|\~\~+ contains=@Spell
+syn region ProgressString matchgroup=ProgressQuote start=+'+ end=+'+ skip=+\~'\|\~\~+ contains=@Spell
syn match ProgressIdentifier "\<[a-zA-Z_][a-zA-Z0-9_]*\>()"
@@ -123,7 +123,7 @@
" If you don't like white space on the end of lines, uncomment this:
" syn match ProgressSpaceError "\s\+$"
-syn region ProgressComment start="/\*" end="\*/" contains=ProgressComment,ProgressTodo,ProgressDebug
+syn region ProgressComment start="/\*" end="\*/" contains=ProgressComment,ProgressTodo,ProgressDebug,@Spell
syn region ProgressInclude start="^[ ]*[{]" end="[}]" contains=ProgressPreProc,ProgressOperator,ProgressString,ProgressComment
syn region ProgressPreProc start="&" end="\>" contained
progress.vim
Description: application/wine-extension-vim
[patch] runtime/syntax/ninja.vim
Hello Nicolas, here is small patch for 'runtime/syntax/ninja.vim' so that Vim highlights spelling mistakes in comments only when editing a file with those settings: :syntax on :set spell -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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 --- runtime/syntax/ninja.vim 2012-05-18 14:57:49.0 + +++ ../ninja.vim 2012-05-18 20:26:55.0 + @@ -15,7 +15,7 @@ syn case match -syn match ninjaComment /#.*/ +syn match ninjaComment /#.*/ contains=@Spell " Toplevel statements are the ones listed here and " toplevel variable assignments (ident '=' value). ninja.vim Description: application/wine-extension-vim
Re: Patch 7.3.523
Raymond - > src/version.c is missing a comma after 523 and as result VIM will not compile. Oops. Fixed now. - Bram -- BLACK KNIGHT: None shall pass. ARTHUR: I have no quarrel with you, brave Sir knight, but I must cross this bridge. BLACK KNIGHT: Then you shall die. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Patch 7.3.524
Patch 7.3.524 (after 7.3.523)
Problem:Missing comma.
Solution: Add the comma.
Files: src/version.c
*** ../vim-7.3.523/src/version.c2012-05-18 18:47:11.0 +0200
--- src/version.c 2012-05-18 21:52:26.0 +0200
***
*** 715,721
static int included_patches[] =
{ /* Add new patch number below this line */
/**/
! 523
/**/
522,
/**/
--- 715,723
static int included_patches[] =
{ /* Add new patch number below this line */
/**/
! 524,
! /**/
! 523,
/**/
522,
/**/
--
DENNIS: You can't expect to wield supreme executive power just 'cause some
watery tart threw a sword at you!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: [patch] runtime/indent/zimbu.vim
I wrote to Thilo Six: > > 'runtime/indent/zimbu.vim' uses line-continuation without cpo > > handling. This patch adds that. Though i am not exactly sure i did it > > right. Line-continuation happens inside a function with several > > 'return's surrounding. Please review. > > Thanks for the hint. The 'cpo' handling should be outside of the > function. It's used when sourcing the file, not when executing the > function. > > Unfortunately the script I use to check for 'cpo' handling doesn't catch > this. I probably need to explicitly check for a leading backslash. I updated my script. It's slower, but already caught several files with line continuation that don't set 'cpo'. Will update the runtime files when I have fine tuned this. -- DENNIS: Look, strange women lying on their backs in ponds handing out swords ... that's no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.3.523
src/version.c is missing a comma after 523 and as result VIM will not compile. -- 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
runtime/syntax/cl.vim
Hello Philip,
i noticed by looking at 'runtime/syntax/cl.vim' that it could make use of
'@Spell' so that Vim highlights spelling mistakes in comments only when editing
a cl file with those settings:
:syntax on
:set spell
--
Regards,
Thilo
4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F
--
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
--- runtime/syntax/cl.vim 2012-05-18 17:50:07.0 +
+++ ../cl.vim 2012-05-18 17:46:15.0 +
@@ -43,7 +43,7 @@
syn match clNeedsWork contained "NEED[S]*\s\s*WORK"
syn keyword clDebug contained debug
-syn match clComment "#.*$" contains=clTodo,clNeedsWork
+syn match clComment "#.*$" contains=clTodo,clNeedsWork,@Spell
syn region clProcedure oneline start="^\s*[{}]" end="$"
syn match clInclude "^\s*include\s.*"
@@ -63,8 +63,8 @@
syn match clNumber "\<\d\+\(u\=l\=\|lu\|f\)\>"
-syn region clString matchgroup=clQuote start=+"+ end=+"+ skip=+\\"+
-syn region clString matchgroup=clQuote start=+'+ end=+'+ skip=+\\'+
+syn region clString matchgroup=clQuote start=+"+ end=+"+ skip=+\\"+ contains=@Spell
+syn region clString matchgroup=clQuote start=+'+ end=+'+ skip=+\\'+ contains=@Spell
syn keyword clReserved ERROR EXIT INTERRUPT LOCKED LREPLY MODE MCOL MLINE MREPLY NULL REPLY V1 V2 V3 V4 V5 V6 V7 V8 V9 ZERO BYPASS GOING_BACK AAUTO ABORT ABORT ALIGN BIGE CONVERT FNUM GOBACK HANGUP JUSTIFY NEXIT OUTPUT RAUTO RAWDISPLAY RAWPRINT REPEAT SKIP TAB TRIM LCOUNT PCOUNT PLINES SLINES SCOLS MATCH LMATCH
cl.vim
Description: application/wine-extension-vim
Re: Issue 60 in vim: Netrw is broken [Patch included]
Comment #1 on issue 60 by francesc...@gmail.com: Netrw is broken [Patch included] http://code.google.com/p/vim/issues/detail?id=60 This was already fixed. -- 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
backupskip and writebackup
Changeset 1b584a6f446c pushed just a bit ago updates the help for writebackup and backupskip to include text about potential data loss if Vim fails on write. Presumably this is in response to a recent thread on both vim_dev and vim_use about a user who experienced this data loss: https://groups.google.com/forum/?fromgroups#!topic/vim_use/h1eHc7YSIq8 I have a problem with the fact that a user could have the default value of both writebackup and backupskip, and encounter the data loss, just by editing a file in the "wrong" directory. Granted, they get a nice error message telling them not to quit Vim until they've successfully saved the file, but they should know before they run into this situation that they're doing something risky. If the underlying data loss problem is not fixed, then I think backupskip should be set to a safer default. But, :help 'backupskip' indicates it's intended to allow shell commands to work which create a temp file, invoke an editor, then check the temp file for changes. So that probably isn't a good option. What if instead of setting 'writebackup' to off for the sake of crontab -e and others, we instead set 'backupcopy' to "yes"? This could be done internally or with a new option similar to 'backupskip', with 'backupskip' set to be empty by default. If the data loss issue is not fixed, at least make it clear in the help text that the safe way to disable backups on specific files, is to set the 'backup' option in a BufWritePre autocmd or something. Otherwise users who want backups for some directories but not others, may set 'backupskip' not realizing the danger, because :help 'backup' mentions that this can be done. Also, :help 'backup' mentions resetting 'writebackup', which is unsafe by itself. The warning needs to be placed there as well. -- 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
runtime/indent/liquid.vim
Hello Tim, looking at 'runtime/indent/liquid.vim' i notice it does not make use of 'b:undo_indent' though it sets 'indentexpr' and 'indentkeys' to nonstandard values. I am most probably wrong on the following so please review: 'runtime/indent/liquid.vim' uses '[^\n]' though it does not handle cpotions. -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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: runtime/ftplugin/zimbu.vim
Thilo Six wrote: > i have a question regarding 'runtime/ftplugin/zimbu.vim'. > I see 'b:undo_ftplugin' undoes somes things. But isn't > 'efm< tw< et< sts< sw<' missing? Yeah, that should be added. Thanks for noticing. > What about functions? Shouldn't we 'delf' them, too? I don't think so. When switching from one language to another the function can remain, so that it's only defined once on the first use of the language. -- OLD WOMAN: Well, how did you become king, then? ARTHUR: The Lady of the Lake, her arm clad in the purest shimmering samite, held Excalibur aloft from the bosom of the water to signify by Divine Providence ... that I, Arthur, was to carry Excalibur ... That is why I am your king! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] runtime/indent/zimbu.vim
Thilo Six wrote: > 'runtime/indent/zimbu.vim' uses line-continuation without cpo > handling. This patch adds that. Though i am not exactly sure i did it > right. Line-continuation happens inside a function with several > 'return's surrounding. Please review. Thanks for the hint. The 'cpo' handling should be outside of the function. It's used when sourcing the file, not when executing the function. Unfortunately the script I use to check for 'cpo' handling doesn't catch this. I probably need to explicitly check for a leading backslash. -- ARTHUR:Be quiet! I order you to shut up. OLD WOMAN: Order, eh -- who does he think he is? ARTHUR:I am your king! OLD WOMAN: Well, I didn't vote for you. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Patch 7.3.523
Patch 7.3.523
Problem:":diffupdate" doesn't check for files changed elsewhere.
Solution: Add the ! flag. (Christian Brabandt)
Files: runtime/doc/diff.txt, src/diff.c, src/ex_cmds.h
*** ../vim-7.3.522/runtime/doc/diff.txt 2010-08-15 21:57:16.0 +0200
--- runtime/doc/diff.txt2012-05-18 18:41:49.0 +0200
***
*** 178,184
nodiff" before hiding it.
*:diffu* *:diffupdate*
! :diffu[pdate] Update the diff highlighting and folds.
Vim attempts to keep the differences updated when you make changes to the
text. This mostly takes care of inserted and deleted lines. Changes within a
--- 178,184
nodiff" before hiding it.
*:diffu* *:diffupdate*
! :diffu[pdate][!] Update the diff highlighting and folds.
Vim attempts to keep the differences updated when you make changes to the
text. This mostly takes care of inserted and deleted lines. Changes within a
***
*** 187,192
--- 187,195
:diffupdate
+ If the ! is included Vim will check if the file was changed externally and
+ needs to be reloaded. It will prompt for each changed file, like `:checktime`
+ was used.
Vim will show filler lines for lines that are missing in one window but are
present in another. These lines were inserted in another file or deleted in
*** ../vim-7.3.522/src/diff.c 2010-09-21 16:56:29.0 +0200
--- src/diff.c 2012-05-18 18:45:09.0 +0200
***
*** 783,788
--- 783,797
goto theend;
}
+ /* :diffupdate! */
+ if (eap != NULL && eap->forceit)
+ for (idx_new = idx_orig; idx_new < DB_COUNT; ++idx_new)
+ {
+ buf = curtab->tp_diffbuf[idx_new];
+ if (buf_valid(buf))
+ buf_check_timestamp(buf, FALSE);
+ }
+
/* Write the first buffer to a tempfile. */
buf = curtab->tp_diffbuf[idx_orig];
if (diff_write(buf, tmp_orig) == FAIL)
*** ../vim-7.3.522/src/ex_cmds.h2012-02-13 00:01:38.0 +0100
--- src/ex_cmds.h 2012-05-18 18:37:56.0 +0200
***
*** 304,310
EX(CMD_display, "display", ex_display,
EXTRA|NOTRLCOM|TRLBAR|SBOXOK|CMDWIN),
EX(CMD_diffupdate,"diffupdate", ex_diffupdate,
! TRLBAR),
EX(CMD_diffget, "diffget", ex_diffgetput,
RANGE|EXTRA|TRLBAR|MODIFY),
EX(CMD_diffoff, "diffoff", ex_diffoff,
--- 304,310
EX(CMD_display, "display", ex_display,
EXTRA|NOTRLCOM|TRLBAR|SBOXOK|CMDWIN),
EX(CMD_diffupdate,"diffupdate", ex_diffupdate,
! BANG|TRLBAR),
EX(CMD_diffget, "diffget", ex_diffgetput,
RANGE|EXTRA|TRLBAR|MODIFY),
EX(CMD_diffoff, "diffoff", ex_diffoff,
*** ../vim-7.3.522/src/version.c2012-05-18 18:34:15.0 +0200
--- src/version.c 2012-05-18 18:39:13.0 +0200
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 523
/**/
--
"The future's already arrived - it's just not evenly distributed yet."
-- William Gibson
/// 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
Re: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
Ben Fritz wrote: On Thursday, May 17, 2012 1:07:52 PM UTC-5, Thilo Six wrote: To me absolutely yes. Obviously we will need to discuss and decide some more details/workflows but i think the consensus is broad enough to start getting it productive. Are you fine with using vim-dev as our mailinglist for all runtime related questions? One person I'd like to see buy into the idea is Dr. Chip, who has been silent so far on the "team maintenance" issue. He maintains some of the most complicated plugin files in the runtime. Chip, have you been following this thread? Hello! I've been on vacation this week, attending my daughter's graduation from Emory University. I have several concerns about this proposal: * vim.vim : there's a large block of code that I generate automatically in syntax/vim.vim. Any changes made in that block of code, which is marked in the syntax file, will be wiped out whenever I make an update there. * sh.vim : by default it supports borne shell; most (including myself) use either Korn/Posix or Bash. In my experience there's been a lot of narrowmindedness on this; folks use bash and complain that its not supporting bash by default, and those using Korn/Posix complain that its not supporting Korn/Posix by default. I've left it at Borne to encourage people to make a choice. There is a potential issue with maintainers imposing their view about the default. * tex.vim : I am trying to keep out package support. There are thousands if not tens of thousands of packages supporting various optional features in LaTeX; it is impractical to expect vim's syntax/tex.vim to support them all (and they may not even co-exist properly). syntax/tex.vim is already quite large enough without lots of package support. I've encouraged users to write after/syntax/tex/pkgname.vim files to support their packages, and to post them on vim.sf.net. I can foresee that we'll have maintainers imposing their package support into syntax/tex.vim, which is a potential problem of this approach. Well, I need to get some gas for my lawnmower. See you! Chip Campbell -- 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
Patch 7.3.522
Patch 7.3.522
Problem:Crash in vim_realloc() when using MEM_PROFILE.
Solution: Avoid using a NULL argument. (Dominique Pelle)
Files: src/eval.c
*** ../vim-7.3.521/src/eval.c 2012-05-18 12:06:58.0 +0200
--- src/eval.c 2012-05-18 18:19:25.0 +0200
***
*** 14643,14649
long growmin = (long)((p - start) * 2 + prevlen);
prevsize = grow50pc > growmin ? grow50pc : growmin;
}
! if ((newprev = vim_realloc(prev, prevsize)) == NULL)
{
do_outofmem_msg((long_u)prevsize);
failed = TRUE;
--- 14643,14651
long growmin = (long)((p - start) * 2 + prevlen);
prevsize = grow50pc > growmin ? grow50pc : growmin;
}
! newprev = prev == NULL ? alloc(prevsize)
! : vim_realloc(prev, prevsize);
! if (newprev == NULL)
{
do_outofmem_msg((long_u)prevsize);
failed = TRUE;
*** ../vim-7.3.521/src/version.c2012-05-18 18:07:57.0 +0200
--- src/version.c 2012-05-18 18:33:36.0 +0200
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 522,
/**/
--
ARTHUR:... and I am your king
OLD WOMAN: Ooooh! I didn't know we had a king. I thought we were an
autonomous collective ...
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
On Friday, May 18, 2012 12:54:56 AM UTC-5, Gary Johnson wrote: > On 2012-05-17, Thilo Six wrote: > > > I would require that we gain at least 7 individuals with commit access. > > This is to somewhat grant that always someone is around "who can do the > > job". > > Anyone who is interested to volunteer for this please speak up now. > > I am interested. > I am also interested, but I know practically nothing about most of the filetypes supported by Vim. I have a suggestion, as well. While I agree whatever repository Bram pulls from should have a small number of people with push access, people who would review changes before pushing them, I think we should have a secondary "dev" repository with push access given to pretty much any runtime file maintainer who wants it. This repository could then be cloned by each maintainer as their developmental version control, so that submitting changes to the team for review would be as simple as an "hg push" command. The reviewers would review changesets from this "dev" repository and pull them into the "stable" repository which Bram would then pull from. -- 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: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
On Friday, May 18, 2012 2:45:16 AM UTC-5, JohnBeckett wrote: > Kazunobu Kuriyama wrote: > > As a maintainer of a few runtime files, I have something to > > make sure of: Are there any changes for the current > > maintainers in what they observe--policy, obligations, or > > something similar to those, to maintain the runtime files > > they are in charge of? > > Nothing is definite, but I don't think so. What would be > different (I think) is that a maintainer would send updates to > someone or something other than Bram. The group maintainers > would review the change and periodically notify Bram that > updates were available. He would then incorporate them into the > Vim distribution, presumably after his own review. > I think this could really depend on the maintainer. We might ask each maintainer to indicate their desired level of involvement: 1. I want to maintain all changes to my file. Please don't touch it beyond what I send you. I commit to be responsive enough for this to work. 2. I want to do all "big" changes and feature additions, but "small" changes and bugfixes can be done by the team. I will maintain my files in a way that changes will not be lost from the runtime repository. 3. I want to remain the official maintainer of the file, but the file belongs to the Vim community. Do what you will with it, I'll submit changes like any other contributor. 4. I do not wish to be the maintainer anymore. Please take it on as a group effort or find someone else. -- 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
Patch 7.3.521
Patch 7.3.521
Problem:Using "z=" on a multi-byte character may cause a crash.
Solution: Don't use strlen() on an int pointer.
Files: src/spell.c
*** ../vim-7.3.520/src/spell.c 2012-01-10 22:26:12.0 +0100
--- src/spell.c 2012-05-18 18:01:58.0 +0200
***
*** 14494,14506
int p0 = -333;
int c0;
int did_white = FALSE;
/*
* Convert the multi-byte string to a wide-character string.
* Remove accents, if wanted. We actually remove all non-word characters.
* But keep white space.
*/
! n = 0;
for (s = inword; *s != NUL; )
{
t = s;
--- 14494,14508
int p0 = -333;
int c0;
int did_white = FALSE;
+ int wordlen;
+
/*
* Convert the multi-byte string to a wide-character string.
* Remove accents, if wanted. We actually remove all non-word characters.
* But keep white space.
*/
! wordlen = 0;
for (s = inword; *s != NUL; )
{
t = s;
***
*** 14521,14532
continue;
}
}
! word[n++] = c;
}
! word[n] = NUL;
/*
! * This comes from Aspell phonet.cpp.
* Converted from C++ to C. Added support for multi-byte chars.
* Changed to keep spaces.
*/
--- 14523,14534
continue;
}
}
! word[wordlen++] = c;
}
! word[wordlen] = NUL;
/*
! * This algorithm comes from Aspell phonet.cpp.
* Converted from C++ to C. Added support for multi-byte chars.
* Changed to keep spaces.
*/
***
*** 14711,14717
}
if (k > k0)
mch_memmove(word + i + k0, word + i + k,
! sizeof(int) * (STRLEN(word + i + k) + 1));
/* new "actual letter" */
c = word[i];
--- 14713,14719
}
if (k > k0)
mch_memmove(word + i + k0, word + i + k,
! sizeof(int) * (wordlen - (i + k) + 1));
/* new "actual letter" */
c = word[i];
***
*** 14739,14745
if (c != NUL)
wres[reslen++] = c;
mch_memmove(word, word + i + 1,
! sizeof(int) * (STRLEN(word + i + 1) + 1));
i = 0;
z0 = 1;
}
--- 14741,14747
if (c != NUL)
wres[reslen++] = c;
mch_memmove(word, word + i + 1,
! sizeof(int) * (wordlen - (i + 1) + 1));
i = 0;
z0 = 1;
}
*** ../vim-7.3.520/src/version.c2012-05-18 17:03:14.0 +0200
--- src/version.c 2012-05-18 18:06:29.0 +0200
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 521,
/**/
--
OLD WOMAN: King of the WHO?
ARTHUR:The Britons.
OLD WOMAN: Who are the Britons?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Spell correction ignores certain characters
Dominique Pelle wrote:
> Bram Moolenaar wrote:
>
> > Christian Brabandt wrote:
> >
> >> > >> When using the spell correction feature ("set spelllang=de_de spell")
> >> > >> a word containing a german "ß" (0xDF) is displayed incorrectly if it
> >> > >> is found to be misspelled:
> >> > >>
> >> > >> Wir wohnen nicht in der >>>Georgenkirchstraße<<<, sondern in der
> >> > >> >>>Hauptstraße<<<.
> >> > >>
> >> > >> In this sample "Georgenkirchstraße" is flagged as misspelled (as
> >> > >> opposed to "Hauptstraße") - which would be ok - but the "ß" in the
> >> > >> flagged word is not considered as a valid word character; hence the
> >> > >> word cannot be directly added (w/o creating a selection) to the
> >> > >> exception list with e.g. "zg".
> >> > >>
> >> > >
> >> > > While I can't say anything about it, I noticed that this crashes my vim
> >> > > with a slight variation of the above sentence:
> >> > >
> >> > > gdb --args ./vim -u NONE -U NONE -N -c ":put ='Wir wohnen nicht in der
> >> > > >>>Georgenkirch straße<<<, sondern in der >>>Hauptstraße<<<'" -c 'set
> >> > > spell spelllang=de
> >> > >
> >> > > [Vim starts and puts that sentence in the buffer]
> >> > > :norm! fsz=
> >> > >
> >> > > SIGSEGV, Segmentation fault.
> >> >
> >> > ...snip...
> >> >
> >> > I also see the German eszett not being highlighted by the
> >> > spelling checker (bug). However, I don't see any crash using
> >> > Linux x86 or Linux x86_64 with Vim-7.3.515. I used the latest
> >> > German dictionary which Vim downloaded automatically
> >> > when setting ':set spelllang=de'.
> >>
> >> I guess, *smp got invalid somehow. This patch prevents, that it gets
> >> overwritten:
> >>
> >> diff --git a/src/spell.c b/src/spell.c
> >> --- a/src/spell.c
> >> +++ b/src/spell.c
> >> @@ -14766,6 +14766,9 @@
> >> z = 0;
> >> k = 0;
> >> }
> >> + /* prevent overwriting of *smp pointer */
> >> + if (smp != slang->sl_sal.ga_data)
> >> + smp = (salitem_T *)slang->sl_sal.ga_data;
> >> }
> >
> > This patch doesn't make sense. It would suggest slang->sl_sal.ga_data
> > is changed, or that smp is changed. I don't see how that could happen.
> > Could this be a memory access error? I could not reproduce it though.
> >
> > When using valgrind I do find this:
> >
> > ==22362== Conditional jump or move depends on uninitialised value(s)
> > ==22362== at 0x81BD866: spell_soundfold_wsal (spell.c:14741)
> > ==22362== by 0x81BC11B: spell_soundfold (spell.c:14106)
> > ==22362== by 0x81BA588: stp_sal_score (spell.c:13189)
> >
> > Since word[] is just after smp and on the stack order is reversed, I
> > suspect the length of the mch_memmove is wrong.
>
> I'm not able to reproduce this Valgrind error. Nor can I reproduce
> the issue in this thread. For me, smp is always equal to
> slang->sl_sal.ga_data.
>
> Perhaps the bug happens only with some locale? What is your locale?
>
> When valgrind reports "uninitialized value(s)", it can help to add
> the valgrind command line option --track-origins=yes. It gives better
> error reporting at the cost of running slightly slower (which is why
> it's off by default).
I located the problem: using strlen() on an int pointer. Not a good
idea! :-)
This doesn't solve the highlighting, just the potential crash.
--
DENNIS: Oh, very nice. King, eh! I expect you've got a palace and fine
clothes and courtiers and plenty of food. And how d'you get that? By
exploiting the workers! By hanging on to outdated imperialist dogma
which perpetuates the social and economic differences in our society!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Spell correction ignores certain characters
Bram Moolenaar wrote:
> Christian Brabandt wrote:
>
>> > >> When using the spell correction feature ("set spelllang=de_de spell") a
>> > >> word containing a german "ß" (0xDF) is displayed incorrectly if it is
>> > >> found to be misspelled:
>> > >>
>> > >> Wir wohnen nicht in der >>>Georgenkirchstraße<<<, sondern in der
>> > >> >>>Hauptstraße<<<.
>> > >>
>> > >> In this sample "Georgenkirchstraße" is flagged as misspelled (as
>> > >> opposed to "Hauptstraße") - which would be ok - but the "ß" in the
>> > >> flagged word is not considered as a valid word character; hence the
>> > >> word cannot be directly added (w/o creating a selection) to the
>> > >> exception list with e.g. "zg".
>> > >>
>> > >
>> > > While I can't say anything about it, I noticed that this crashes my vim
>> > > with a slight variation of the above sentence:
>> > >
>> > > gdb --args ./vim -u NONE -U NONE -N -c ":put ='Wir wohnen nicht in der
>> > > >>>Georgenkirch straße<<<, sondern in der >>>Hauptstraße<<<'" -c 'set
>> > > spell spelllang=de
>> > >
>> > > [Vim starts and puts that sentence in the buffer]
>> > > :norm! fsz=
>> > >
>> > > SIGSEGV, Segmentation fault.
>> >
>> > ...snip...
>> >
>> > I also see the German eszett not being highlighted by the
>> > spelling checker (bug). However, I don't see any crash using
>> > Linux x86 or Linux x86_64 with Vim-7.3.515. I used the latest
>> > German dictionary which Vim downloaded automatically
>> > when setting ':set spelllang=de'.
>>
>> I guess, *smp got invalid somehow. This patch prevents, that it gets
>> overwritten:
>>
>> diff --git a/src/spell.c b/src/spell.c
>> --- a/src/spell.c
>> +++ b/src/spell.c
>> @@ -14766,6 +14766,9 @@
>> z = 0;
>> k = 0;
>> }
>> + /* prevent overwriting of *smp pointer */
>> + if (smp != slang->sl_sal.ga_data)
>> + smp = (salitem_T *)slang->sl_sal.ga_data;
>> }
>
> This patch doesn't make sense. It would suggest slang->sl_sal.ga_data
> is changed, or that smp is changed. I don't see how that could happen.
> Could this be a memory access error? I could not reproduce it though.
>
> When using valgrind I do find this:
>
> ==22362== Conditional jump or move depends on uninitialised value(s)
> ==22362== at 0x81BD866: spell_soundfold_wsal (spell.c:14741)
> ==22362== by 0x81BC11B: spell_soundfold (spell.c:14106)
> ==22362== by 0x81BA588: stp_sal_score (spell.c:13189)
>
> Since word[] is just after smp and on the stack order is reversed, I
> suspect the length of the mch_memmove is wrong.
I'm not able to reproduce this Valgrind error. Nor can I reproduce
the issue in this thread. For me, smp is always equal to slang->sl_sal.ga_data.
Perhaps the bug happens only with some locale? What is your locale?
When valgrind reports "uninitialized value(s)", it can help to add
the valgrind command line option --track-origins=yes. It gives better
error reporting at the cost of running slightly slower (which is why
it's off by default).
Regards
-- Dominique
--
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 7.3.519
His name is Matsushita Shougo. :)
On 5/18/12, Bram Moolenaar wrote:
>
> Patch 7.3.519
> Problem:When completefunction returns it cannot indicate end of
> completion
> mode.
> Solution: Recognize completefunction returning -3. (Mtsushita Shougo)
> Files:src/edit.c
>
>
> *** ../vim-7.3.518/src/edit.c 2012-04-30 18:18:43.0 +0200
> --- src/edit.c2012-05-18 16:35:06.0 +0200
> ***
> *** 5205,5213
> }
>
> /* Return value -2 means the user complete function wants to
> ! * cancel the complete without an error. */
> if (col == -2)
> return FAIL;
>
> /*
>* Reset extended parameters of completion, when start new
> --- 5205,5221
> }
>
> /* Return value -2 means the user complete function wants to
> ! * cancel the complete without an error.
> ! * Return value -3 does the same as -2 and leaves CTRL-X mode.*/
> if (col == -2)
> return FAIL;
> + if (col == -3)
> + {
> + ctrl_x_mode = 0;
> + edit_submode = NULL;
> + msg_clr_cmdline();
> + return FAIL;
> + }
>
> /*
>* Reset extended parameters of completion, when start new
> *** ../vim-7.3.518/src/version.c 2012-05-18 16:24:06.0 +0200
> --- src/version.c 2012-05-18 16:34:27.0 +0200
> ***
> *** 716,717
> --- 716,719
> { /* Add new patch number below this line */
> + /**/
> + 519,
> /**/
>
> --
> Looking at Perl through Lisp glasses, Perl looks atrocious.
>
> /// 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
>
--
- 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
Re: [patch] runtime/indent/zimbu.vim
Hello Bram, -- -- > 'runtime/indent/zimbu.vim' uses line-continuation without cpo handling. This > patch adds that. Though i am not exactly sure i did it right. > Line-continuation > happens inside a function with several 'return's surrounding. Please review. Additionally i think 'b:undo_indent' misses 'indentkeys< sw<'. -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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: Spell correction ignores certain characters
Christian Brabandt wrote:
> > >> When using the spell correction feature ("set spelllang=de_de spell") a
> > >> word containing a german "ß" (0xDF) is displayed incorrectly if it is
> > >> found to be misspelled:
> > >>
> > >> Wir wohnen nicht in der >>>Georgenkirchstraße<<<, sondern in der
> > >> >>>Hauptstraße<<<.
> > >>
> > >> In this sample "Georgenkirchstraße" is flagged as misspelled (as opposed
> > >> to "Hauptstraße") - which would be ok - but the "ß" in the flagged word
> > >> is not considered as a valid word character; hence the word cannot be
> > >> directly added (w/o creating a selection) to the exception list with
> > >> e.g. "zg".
> > >>
> > >
> > > While I can't say anything about it, I noticed that this crashes my vim
> > > with a slight variation of the above sentence:
> > >
> > > gdb --args ./vim -u NONE -U NONE -N -c ":put ='Wir wohnen nicht in der
> > > >>>Georgenkirch straße<<<, sondern in der >>>Hauptstraße<<<'" -c 'set
> > > spell spelllang=de
> > >
> > > [Vim starts and puts that sentence in the buffer]
> > > :norm! fsz=
> > >
> > > SIGSEGV, Segmentation fault.
> >
> > ...snip...
> >
> > I also see the German eszett not being highlighted by the
> > spelling checker (bug). However, I don't see any crash using
> > Linux x86 or Linux x86_64 with Vim-7.3.515. I used the latest
> > German dictionary which Vim downloaded automatically
> > when setting ':set spelllang=de'.
>
> I guess, *smp got invalid somehow. This patch prevents, that it gets
> overwritten:
>
> diff --git a/src/spell.c b/src/spell.c
> --- a/src/spell.c
> +++ b/src/spell.c
> @@ -14766,6 +14766,9 @@
> z = 0;
> k = 0;
> }
> + /* prevent overwriting of *smp pointer */
> + if (smp != slang->sl_sal.ga_data)
> + smp = (salitem_T *)slang->sl_sal.ga_data;
> }
This patch doesn't make sense. It would suggest slang->sl_sal.ga_data
is changed, or that smp is changed. I don't see how that could happen.
Could this be a memory access error? I could not reproduce it though.
When using valgrind I do find this:
==22362== Conditional jump or move depends on uninitialised value(s)
==22362==at 0x81BD866: spell_soundfold_wsal (spell.c:14741)
==22362==by 0x81BC11B: spell_soundfold (spell.c:14106)
==22362==by 0x81BA588: stp_sal_score (spell.c:13189)
Since word[] is just after smp and on the stack order is reversed, I
suspect the length of the mch_memmove is wrong.
--
ARTHUR: I've said I'm sorry about the old woman, but from the behind you
looked ...
DENNIS: What I object to is that you automatically treat me like an inferior...
ARTHUR: Well ... I AM king.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
[patch] runtime/indent/zimbu.vim
Hello Bram,
'runtime/indent/zimbu.vim' uses line-continuation without cpo handling. This
patch adds that. Though i am not exactly sure i did it right. Line-continuation
happens inside a function with several 'return's surrounding. Please review.
--
Regards,
Thilo
4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F
--
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/runtime/indent/zimbu.vim 2012-05-18 14:57:49.0 +
+++ zimbu.vim 2012-05-18 15:31:30.0 +
@@ -34,6 +34,9 @@
return 0
endif
+ let l:cpo_save = &cpo
+ set cpo&vim
+
" Taken from Python indenting:
" If the previous line is inside parenthesis, use the indent of the starting
" line.
@@ -70,6 +73,10 @@
\ "line('.') < " . (a:lnum - s:maxoff) . " ? dummy :"
\ . " synIDattr(synID(line('.'), col('.'), 1), 'name')"
\ . " =~ '\\(Comment\\|String\\|Char\\)$'")
+
+ let &cpo = l:cpo_save
+ unlet l:cpo_save
+
if pp > 0
return indent(prevLnum) + &sw
endif
zimbu.vim
Description: application/wine-extension-vim
runtime/ftplugin/zimbu.vim
Hello Bram, i have a question regarding 'runtime/ftplugin/zimbu.vim'. I see 'b:undo_ftplugin' undoes somes things. But isn't 'efm< tw< et< sts< sw<' missing? What about functions? Shouldn't we 'delf' them, too? -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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: home_replace() does not work with short path name on windows.
Yasuhiro Matsumoto wrote: > On Friday, April 20, 2012 11:13:40 PM UTC+9, Bram Moolenaar wrote: > > Why use the GetLongPathName function? It's not used anywhere in Vim. > > Can we use vim_FullName() with the force argument set to TRUE? > > > > I suppose this is only needed for MS-Windows. Since expanding a path is > > expensive we might first check if the "~" character appears in the > > string. > > You are right. Thanks. I have not received an update patch yet. Are you still working on this? -- Friends? I have lots of friends! In fact, I have all episodes ever made. /// 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
Patch 7.3.520
Patch 7.3.520
Problem:Gvim starts up slow on Unbuntu 12.04.
Solution: Move the call to gui_mch_init_check() to after fork(). (Yasuhiro
Matsumoto) Do check $DISPLAY being set.
Files: src/gui.c, src/gui_gtk_x11.c, src/proto/gui_gtk_x11.pro
*** ../vim-7.3.519/src/gui.c2011-10-20 21:27:57.0 +0200
--- src/gui.c 2012-05-18 16:53:14.0 +0200
***
*** 270,275
--- 270,281
}
/* Child */
+ #ifdef FEAT_GUI_GTK
+ /* Call gtk_init_check() here after fork(). See gui_init_check(). */
+ if (gui_mch_init_check() != OK)
+ exit(1);
+ #endif
+
# if defined(HAVE_SETSID) || defined(HAVE_SETPGID)
/*
* Change our process group. On some systems/shells a CTRL-C in the
***
*** 430,436
--- 436,452
#ifdef ALWAYS_USE_GUI
result = OK;
#else
+ # ifdef FEAT_GUI_GTK
+ /*
+ * Note: Don't call gtk_init_check() before fork, it will be called after
+ * the fork. When calling it before fork, it make vim hang for a while.
+ * See gui_do_fork().
+ * Use a simpler check if the GUI window can probably be opened.
+ */
+ result = gui.dofork ? gui_mch_early_init_check() : gui_mch_init_check();
+ # else
result = gui_mch_init_check();
+ # endif
#endif
return result;
}
*** ../vim-7.3.519/src/gui_gtk_x11.c2011-10-26 11:36:21.0 +0200
--- src/gui_gtk_x11.c 2012-05-18 17:00:45.0 +0200
***
*** 1414,1420
}
/*
! * Check if the GUI can be started. Called before gvimrc is sourced.
* Return OK or FAIL.
*/
int
--- 1414,1442
}
/*
! * Check if the GUI can be started. Called before gvimrc is sourced and
! * before fork().
! * Return OK or FAIL.
! */
! int
! gui_mch_early_init_check(void)
! {
! char_u *p;
!
! /* Guess that when $DISPLAY isn't set the GUI can't start. */
! p = mch_getenv((char_u *)"DISPLAY");
! if (p == NULL || *p == NUL)
! {
! gui.dying = TRUE;
! EMSG(_((char *)e_opendisp));
! return FAIL;
! }
! return OK;
! }
!
! /*
! * Check if the GUI can be started. Called before gvimrc is sourced but after
! * fork().
* Return OK or FAIL.
*/
int
***
*** 3050,3056
for (i = 0; i < (int)N_SELECTION_TARGETS; ++i)
{
! /* OpenOffice tries to use TARGET_HTML and fails when it doesn't
* return something, instead of trying another target. Therefore only
* offer TARGET_HTML when it works. */
if (!clip_html && selection_targets[i].info == TARGET_HTML)
--- 3072,3078
for (i = 0; i < (int)N_SELECTION_TARGETS; ++i)
{
! /* OpenOffice tries to use TARGET_HTML and fails when we don't
* return something, instead of trying another target. Therefore only
* offer TARGET_HTML when it works. */
if (!clip_html && selection_targets[i].info == TARGET_HTML)
*** ../vim-7.3.519/src/proto/gui_gtk_x11.pro2011-08-10 17:44:41.0
+0200
--- src/proto/gui_gtk_x11.pro 2012-05-18 16:54:28.0 +0200
***
*** 4,9
--- 4,10
void gui_mch_set_blinking __ARGS((long waittime, long on, long off));
void gui_mch_stop_blink __ARGS((void));
void gui_mch_start_blink __ARGS((void));
+ int gui_mch_early_init_check __ARGS((void));
int gui_mch_init_check __ARGS((void));
void gui_mch_show_tabline __ARGS((int showit));
int gui_mch_showing_tabline __ARGS((void));
*** ../vim-7.3.519/src/version.c2012-05-18 16:35:17.0 +0200
--- src/version.c 2012-05-18 16:45:30.0 +0200
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 520,
/**/
--
Bad programs can be written in any language.
/// 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
Re: Spell correction ignores certain characters
Will this get fixed in some official 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
Patch 7.3.519
Patch 7.3.519
Problem:When completefunction returns it cannot indicate end of completion
mode.
Solution: Recognize completefunction returning -3. (Mtsushita Shougo)
Files: src/edit.c
*** ../vim-7.3.518/src/edit.c 2012-04-30 18:18:43.0 +0200
--- src/edit.c 2012-05-18 16:35:06.0 +0200
***
*** 5205,5213
}
/* Return value -2 means the user complete function wants to
!* cancel the complete without an error. */
if (col == -2)
return FAIL;
/*
* Reset extended parameters of completion, when start new
--- 5205,5221
}
/* Return value -2 means the user complete function wants to
!* cancel the complete without an error.
!* Return value -3 does the same as -2 and leaves CTRL-X mode.*/
if (col == -2)
return FAIL;
+ if (col == -3)
+ {
+ ctrl_x_mode = 0;
+ edit_submode = NULL;
+ msg_clr_cmdline();
+ return FAIL;
+ }
/*
* Reset extended parameters of completion, when start new
*** ../vim-7.3.518/src/version.c2012-05-18 16:24:06.0 +0200
--- src/version.c 2012-05-18 16:34:27.0 +0200
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 519,
/**/
--
Looking at Perl through Lisp glasses, Perl looks atrocious.
/// 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
Patch 7.3.518
Patch 7.3.518
Problem:When 'encoding' is a double-byte encoding ":helptags" may not find
tags correctly.
Solution: Use vim_strbyte() instead of vim_strchr(). (Yasuhiro Matsumoto)
Files: src/ex_cmds.c
*** ../vim-7.3.517/src/ex_cmds.c2012-04-25 17:32:14.0 +0200
--- src/ex_cmds.c 2012-05-18 16:20:20.0 +0200
***
*** 6535,6541
p1 = vim_strchr(IObuff, '*'); /* find first '*' */
while (p1 != NULL)
{
! p2 = vim_strchr(p1 + 1, '*'); /* find second '*' */
if (p2 != NULL && p2 > p1 + 1) /* skip "*" and "**" */
{
for (s = p1 + 1; s < p2; ++s)
--- 6535,6544
p1 = vim_strchr(IObuff, '*'); /* find first '*' */
while (p1 != NULL)
{
! /* Use vim_strbyte() instead of vim_strchr() so that when
!* 'encoding' is dbcs it still works, don't find '*' in the
!* second byte. */
! p2 = vim_strbyte(p1 + 1, '*'); /* find second '*' */
if (p2 != NULL && p2 > p1 + 1) /* skip "*" and "**" */
{
for (s = p1 + 1; s < p2; ++s)
*** ../vim-7.3.517/src/version.c2012-05-18 12:49:33.0 +0200
--- src/version.c 2012-05-18 16:23:50.0 +0200
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 518,
/**/
--
If all you have is a hammer, everything looks like a nail.
When your hammer is C++, everything begins to look like a thumb.
-- Steve Hoflich, comp.lang.c++
/// 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
vim msi
Hello, I wrote simple vim msi installer. Package create shortcut on desktop and in start menu. Also add install directory to %PATH% enviroment variable so you can run vim from command line. https://github.com/petrkle/vim-msi/ Petr -- 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: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
Dominique Pellé : > Thilo Six wrote: >>> I would like to be able to comment >>> on checkins in a more formal way than emails. >> >> How exactly would that work? > > An image is worth a 1000 words. So here is a screenshot > illustrating how code reviews happen in Crucible: > > http://www.atlassian.com/en/software/crucible/overview/screenshot-tour/featureItems/0/featureItems/0/imageBinary/crucible-code-review-comments.png > > It shows the code changes as a colored diff by default. > By clicking on a line in the code, you can add comments (threaded). I know someone said it would be better to use Mercurial since that's what Vim itself is using, but pretty much the exact same comment functionality is supported in pull requests on GitHub. Maybe BitBucket has something similar too, though, it might be worth a look. Jan -- -[ OpenPGP key ID: 00A0FD5F ]- The most dangerous phrase in the language is, "We've always done it this way." -- Grace Hopper -- 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: Make tabs in conceal mode work like there is no concealing
Dominique Pelle wrote: > Bram Moolenaar wrote: > > > Currently there is the problem that if characters are concealed before a > > Tab then the position of the text after the Tab may change, depending on > > whether the gap that the Tab covers goes over the tab size. > > This is most noticeable at ":help index". > > > > We already have code to keep line wrapping in the same place when there > > are concealed characters. I think we should do the same for Tabs, so > > that the column alignment stays the same. That means that when there > > are concealed characters the virtual column is computed as if they are > > not concealed and the text after the Tab is positioned in the same place > > with and without concealed characters. > > Hi Bram > > That sounds exactly like a patch that I proposed. See this thread: > > http://www.mail-archive.com/vim_dev@googlegroups.com/msg16721.html > > I also noticed that todo.txt does not mention this patch (perhaps it > was forgotten). > It was suggested to create a test for this patch, but I did not > succeed creating the test. > > I found afterwards that the proposed patch was also fixing 2 other issues > as described in above link. Apparently I didn't add this patch to the todo list, awaiting comments for overlap with another patch and forgetting about it. I'll put them together so I can look at the details later. > > At the same time, it would be useful to do the opposite: Really ignore > > the concealed characters, also for line wrapping. This would be a > > conceal setting. > > That would also be useful. So that's still open. -- ARTHUR: Old woman! DENNIS: Man! ARTHUR: Man. I'm sorry. Old man, What knight live in that castle over there? DENNIS: I'm thirty-seven. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Make tabs in conceal mode work like there is no concealing
Bram Moolenaar wrote: > Currently there is the problem that if characters are concealed before a > Tab then the position of the text after the Tab may change, depending on > whether the gap that the Tab covers goes over the tab size. > This is most noticeable at ":help index". > > We already have code to keep line wrapping in the same place when there > are concealed characters. I think we should do the same for Tabs, so > that the column alignment stays the same. That means that when there > are concealed characters the virtual column is computed as if they are > not concealed and the text after the Tab is positioned in the same place > with and without concealed characters. Hi Bram That sounds exactly like a patch that I proposed. See this thread: http://www.mail-archive.com/vim_dev@googlegroups.com/msg16721.html I also noticed that todo.txt does not mention this patch (perhaps it was forgotten). It was suggested to create a test for this patch, but I did not succeed creating the test. I found afterwards that the proposed patch was also fixing 2 other issues as described in above link. > At the same time, it would be useful to do the opposite: Really ignore > the concealed characters, also for line wrapping. This would be a > conceal setting. That would also be useful. Regards -- Dominique -- 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
Make tabs in conceal mode work like there is no concealing
Currently there is the problem that if characters are concealed before a Tab then the position of the text after the Tab may change, depending on whether the gap that the Tab covers goes over the tab size. This is most noticeable at ":help index". We already have code to keep line wrapping in the same place when there are concealed characters. I think we should do the same for Tabs, so that the column alignment stays the same. That means that when there are concealed characters the virtual column is computed as if they are not concealed and the text after the Tab is positioned in the same place with and without concealed characters. At the same time, it would be useful to do the opposite: Really ignore the concealed characters, also for line wrapping. This would be a conceal setting. I'm sending this to Christian since he did some work in this area before. There is also the open issue of 'cursorline' being displayed to short, I think that's related. -- LARGE MAN: Who's that then? CART DRIVER: (Grudgingly) I dunno, Must be a king. LARGE MAN: Why? CART DRIVER: He hasn't got shit all over him. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Patch 7.3.517
Patch 7.3.517
Problem:Crash when using "vipvv". (Alexandre Provencio)
Solution: Don't let the text length become negative.
Files: src/ops.c
*** ../vim-7.3.516/src/ops.c2012-04-20 13:46:02.0 +0200
--- src/ops.c 2012-05-18 12:28:09.0 +0200
***
*** 3042,3047
--- 3042,3049
}
#endif
}
+ if (endcol == MAXCOL)
+ endcol = (colnr_T)STRLEN(p);
if (startcol > endcol
#ifdef FEAT_VIRTUALEDIT
|| is_oneChar
***
*** 3050,3057
bd.textlen = 0;
else
{
- if (endcol == MAXCOL)
- endcol = (colnr_T)STRLEN(p);
bd.textlen = endcol - startcol + oap->inclusive;
}
bd.textstart = p + startcol;
--- 3052,3057
*** ../vim-7.3.516/src/version.c2012-05-18 12:06:58.0 +0200
--- src/version.c 2012-05-18 12:48:51.0 +0200
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 517,
/**/
--
BODY:I'm not dead!
CART DRIVER: 'Ere. He says he's not dead.
LARGE MAN: Yes he is.
BODY:I'm not!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Patch 7.3.516
Patch 7.3.516
Problem:extend(o, o) may crash Vim.
Solution: Fix crash and add test. (Thinca and Hirohito Higashi)
Files: src/eval.c, src/testdir/test55.in, src/testdir/test55.ok
*** ../vim-7.3.515/src/eval.c 2012-04-30 17:35:44.0 +0200
--- src/eval.c 2012-05-18 12:02:44.0 +0200
***
*** 10191,10197
EMSG2(_("E737: Key already exists: %s"), hi2->hi_key);
break;
}
! else if (*action == 'f')
{
clear_tv(&di1->di_tv);
copy_tv(&HI2DI(hi2)->di_tv, &di1->di_tv);
--- 10191,10197
EMSG2(_("E737: Key already exists: %s"), hi2->hi_key);
break;
}
! else if (*action == 'f' && HI2DI(hi2) != di1)
{
clear_tv(&di1->di_tv);
copy_tv(&HI2DI(hi2)->di_tv, &di1->di_tv);
*** ../vim-7.3.515/src/testdir/test55.in2010-11-10 20:31:24.0
+0100
--- src/testdir/test55.in 2012-05-18 11:57:23.0 +0200
***
*** 352,357
--- 352,375
:let dict4copy = deepcopy(dict4)
:$put =(l == lcopy)
:$put =(dict4 == dict4copy)
+ :"
+ :" Pass the same List to extend()
+ :let l = [1, 2, 3, 4, 5]
+ :call extend(l, l)
+ :$put =string(l)
+ :"
+ :" Pass the same Dict to extend()
+ :let d = { 'a': {'b': 'B'}}
+ :call extend(d, d)
+ :$put =string(d)
+ :"
+ :" Pass the same Dict to extend() with "error"
+ :try
+ : call extend(d, d, "error")
+ :catch
+ : $put =v:exception[:15] . v:exception[-1:-1]
+ :endtry
+ :$put =string(d)
:endfun
:"
:call Test(1, 2, [3, 4], {5: 6}) " This may take a while
*** ../vim-7.3.515/src/testdir/test55.ok2010-11-10 20:31:24.0
+0100
--- src/testdir/test55.ok 2012-05-18 11:57:01.0 +0200
***
*** 111,113
--- 111,117
0
1
1
+ [1, 2, 3, 4, 5, 1, 2, 3, 4, 5]
+ {'a': {'b': 'B'}}
+ Vim(call):E737: a
+ {'a': {'b': 'B'}}
*** ../vim-7.3.515/src/version.c2012-04-30 21:09:38.0 +0200
--- src/version.c 2012-05-18 12:04:54.0 +0200
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 516,
/**/
--
I used to wonder about the meaning of life. But I looked it
up in the dictionary under "L" and there it was - the meaning
of life. It was less than I expected. - Dogbert
/// 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
Re: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
Thilo Six wrote: >> I would like to be able to comment >> on checkins in a more formal way than emails. > > How exactly would that work? An image is worth a 1000 words. So here is a screenshot illustrating how code reviews happen in Crucible: http://www.atlassian.com/en/software/crucible/overview/screenshot-tour/featureItems/0/featureItems/0/imageBinary/crucible-code-review-comments.png It shows the code changes as a colored diff by default. By clicking on a line in the code, you can add comments (threaded). > The more sophisticated the tools get the higher the bar for participants. > Email > is a low level tool which is plus. > By separating communication channels we could end up where we started. Yes, that's a risk. I'm thinking aloud here. I also like emails, but a higher level tool for code reviews can be useful in my experience. -- Dominique -- 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: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
Hello Kazunobu and John, Excerpt from John Beckett: > Kazunobu Kuriyama wrote: >> As a maintainer of a few runtime files, I have something to >> make sure of: Are there any changes for the current >> maintainers in what they observe--policy, obligations, or >> something similar to those, to maintain the runtime files >> they are in charge of? > > Nothing is definite, but I don't think so. What would be > different (I think) is that a maintainer would send updates to > someone or something other than Bram. The group maintainers > would review the change and periodically notify Bram that > updates were available. He would then incorporate them into the > Vim distribution, presumably after his own review. Yes thanks John. That is where we hopefully end up with. For users nothing changes. They can pull from Brams branch and get the current stable runtime tree. For maintainers two important things would change: 1) In future emails with updates go to instead to directly to Bram. 2) Currently each maintainer has the "master branch" of their runtimefiles at home. That led to the unfortunate situation that a maintainer could have overwritten previous fixes made to their files. The important change is in future the "master branch" is the staging repo under control of the team and you as a maintainer need to check prior to sending updates to us, that your changes are based on what is currently in the repo. This is the only way that others can fix your files, too. > > John > -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
Hello Dominique, Excerpt from Dominique Pellé: > John Beckett wrote: > >> Kazunobu Kuriyama wrote: >>> As a maintainer of a few runtime files, I have something to >>> make sure of: Are there any changes for the current >>> maintainers in what they observe--policy, obligations, or >>> something similar to those, to maintain the runtime files >>> they are in charge of? >> >> Nothing is definite, but I don't think so. What would be >> different (I think) is that a maintainer would send updates to >> someone or something other than Bram. The group maintainers >> would review the change and periodically notify Bram that >> updates were available. He would then incorporate them into the >> Vim distribution, presumably after his own review. >> >> John > > Does anybody know if there is something that can easily be > set up for code reviews? I use tortoisehg for that. http://tortoisehg.bitbucket.org/ > I would like to be able to comment > on checkins in a more formal way than emails. How exactly would that work? The more sophisticated the tools get the higher the bar for participants. Email is a low level tool which is plus. By separating communication channels we could end up where we started. > I've personally used Crucible > http://www.atlassian.com/software/crucible/overview > and I found that such code reviews help to catch errors, improve code quality, > learn from others comments and improve awareness of changes happening in > the source tree. I fully agree to this. > I'm not saying that we should use crucible (it's not free) but > something similar. > > In this page http://code.google.com/p/support/wiki/GettingStarted > I read "Source subtab -- You can elect to have non-project members > review your code." > I wonder whether this is enabled for the vim project and whether it's the > kind of review that Crucible offers. > > Ideally, it should add zero burden to checkins and any checkin could be > automatically reviewed. I leave it to those who actually will have commit access to the repo to decide which tools they use and how they want their workflow. > > Regards > -- Dominique > -- Regards, Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- 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: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
John Beckett wrote: > Kazunobu Kuriyama wrote: >> As a maintainer of a few runtime files, I have something to >> make sure of: Are there any changes for the current >> maintainers in what they observe--policy, obligations, or >> something similar to those, to maintain the runtime files >> they are in charge of? > > Nothing is definite, but I don't think so. What would be > different (I think) is that a maintainer would send updates to > someone or something other than Bram. The group maintainers > would review the change and periodically notify Bram that > updates were available. He would then incorporate them into the > Vim distribution, presumably after his own review. > > John Does anybody know if there is something that can easily be set up for code reviews? I would like to be able to comment on checkins in a more formal way than emails. I've personally used Crucible http://www.atlassian.com/software/crucible/overview and I found that such code reviews help to catch errors, improve code quality, learn from others comments and improve awareness of changes happening in the source tree. I'm not saying that we should use crucible (it's not free) but something similar. In this page http://code.google.com/p/support/wiki/GettingStarted I read "Source subtab -- You can elect to have non-project members review your code." I wonder whether this is enabled for the vim project and whether it's the kind of review that Crucible offers. Ideally, it should add zero burden to checkins and any checkin could be automatically reviewed. Regards -- Dominique -- 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: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
Kazunobu Kuriyama wrote: > As a maintainer of a few runtime files, I have something to > make sure of: Are there any changes for the current > maintainers in what they observe--policy, obligations, or > something similar to those, to maintain the runtime files > they are in charge of? Nothing is definite, but I don't think so. What would be different (I think) is that a maintainer would send updates to someone or something other than Bram. The group maintainers would review the change and periodically notify Bram that updates were available. He would then incorporate them into the Vim distribution, presumably after his own review. 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
Re: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
Hello, Thilo and those who have been actively discussed the runtime file issue. On May 18, 2012, at 6:37 AM, Thilo Six wrote: > > > Then we have decided that we change current maintenance model of runtimefiles > to > be a collaboration one and we use 'vim-dev' for future coordination. As a maintainer of a few runtime files, I have something to make sure of: Are there any changes for the current maintainers in what they observe--policy, obligations, or something similar to those, to maintain the runtime files they are in charge of? I think summary and conclusions of the discussion would be quite helpful for those who are possibly interested in the issue. Best regards, K.K. -- 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
