usr_4[34].txt cosmetics
Hi folks, it is said, that translators are the best profreaders. Sometimes, I make annotations. Let's see what I have: # type: Plain text #: usr_43.txt:61 # FIXME: ticks around maplocalleader, not dquotes, for it's an option msgid Likewise, the mapping for \\\c\ will disappear when editing another buffer. The \:map buffer\ command creates a mapping that is local to the current buffer. This works with any mapping command: \:map!\, \:vmap\, etc. The |LocalLeader| in the mapping is replaced with the value of \maplocalleader\. # type: Plain text #: usr_44.txt:501 #, no-wrap # FIXME shouldn't that be C++ syntax msgid The \:runtime!\ command searches 'runtimepath' for all \syntax/c.vim\ files.\n This makes the C syntax be defined like for C files. If you have replaced this one the\n c.vim syntax file, or added items with an extra file, these will be loaded as\n well.\n After loading the C syntax items the specific C++ items can be defined.\n For example, add keywords that are not used in C: \n # type: Plain text #: usr_44.txt:513 #, no-wrap # FIXME s,It,A script, msgid Now consider the Perl language. It consists of two distinct parts: a\n documentation section in POD format, and a program written in Perl itself.\n The POD section starts with \=head\ and ends with \=cut\.\n You want to define the POD syntax in one file, and use it from the Perl\n syntax file. The \:syntax include\ command reads in a syntax file and stores\n the elements it defined in a syntax cluster. For Perl, the statements are as\n follows: \n # type: Plain text #: usr_44.txt:668 # FIXME comma after b:current_syntax msgid Choose a good, descriptive name for your syntax file. Use lowercase letters and digits. Don't make it too long, it is used in many places: The name of the syntax file \name.vim\, 'filetype', b:current_syntax the start of each syntax group (nameType, nameStatement, nameString, etc). Thanks and merry christmas, flori -- vimhelp-de: http://www.florianrehnisch.de/vimhelp/ --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: latest runtime files merged into vim_extended.git
Christian MICHON, 23.12.2008:
On Tue, Dec 23, 2008 at 3:39 AM, Markus Heidelberg
markus.heidelb...@web.de wrote:
quick feedback after a cloning of vim_mainline: tons of commits are
due to git-svn merged commits and syncing with CVS.
could this be avoided ? maybe some commits can be squashed.
Why should I squash only to loose/cripple history? Furthermore squashing
makes sense for something like topic branches, which are deleted
afterwards. The git repo is based on the official svn repo. The
'git-svn' branch, that is merged into the 'vim' branch, directly
reflects the svn branch 'vim7.2' and is not a topic branch. A branch
('vim') cannot be based on another ('git-svn') when I squash commits. I
just have to merge.
if I have a look at the gitk visual feedback, I would expect a linear
history (this is how vim evolves).
This is how vim seems to evolve. Possibly Bram develops various topics
in parallel and merges the mature topics together, too. Whether with
help of an SCM or not. But that's another thing than vim_extended
anyway.
I see you've a lot of branches in your vim_extended repo, hence a lot
of merge, but most of these merges are actually empty (no difference,
no patch).
So actually the history you're preserving is very complicated and
could be simplified: this is what I meant.
Yes, I knew what you meant. But simplification of the history is not
possible while keeping topic branches. Well, the history will be
simplified by 1 level, when the repo is not based on SVN anymore, but
that's it.
The reason for all the git-svn merged merge commits is that the 'vim'
branch is not totally equal to 'git-svn'. It contains two additional
commits, so it can't resolve as a fast-forward merge anymore and
git-svn merged commits are created.
I actually created a vim repo using patches and tarballs only,
avoiding to sync with CVS/SVN for that purpose. I extracted the
dates/timestamps from version.c to mimick what I would get from a
cvs/svn import, and all commits are artificially from Bram.
So the history can be linear there too!
As already stated in my previous mail, the 'vim' branch can only be
linear, when not being based on SVN anymore.
I saw just now another post requesting for commit access. Beside the
point it's granted with git by default (just clone the repo and host
yours somewhere), I would disagree on the push access.
why? because the current vim distribution and patch models are based
on central approach, not distributed.
This is your argument against push access?
But giving push access is just that: one central repository for several
persons, instead of having several repos, each dedicated to one person.
if you're using git (great!), I'd rather stick to a decentralized
workflow than a centralized one.
if you're allowing push access to your public git repo, what stops an
accidental deletion of a branch ?
The same reason that stops me from deleting branches: we just know what
we are doing. If you just call 'git push' with the right settings in
.git/config, you cannot delete a branch. Hence the guideline.
(remember there's no trace of such deletion, and it's very hard to
recover from it, unless it's your public repo and you're the only one
pushing into it)
There's git-reflog, making it easy to recover a deleted branch.
Then we shouldn't use distributed tools at all, because Bram's
development model is central? That doesn't make sense.
I was not clear: I'd love Bram to move to a distributed model. We can
always use git for forks/experiments and patching/merging/testing.
What's already done in vim_extended.
I'd rather not use git to recreate another central repo: is this clearer now ?
You have created a central repo yourself as well as me.
It's not the purpose to be an alternative to sending patches to Bram.
Maybe, but not necessarily. But I don't understand the relation between
this statement and the push access or the distributed/central model.
Well, I don't understand the argument against push access at all.
potential/accidental deletion of branches on your public repo is 1
example (see above).
Everyone with push access can delete branches, me too.
But recovering is easy.
as for the guidelines you mentioned, I think Bram should be involved,
shouldn't he ?
Bram hasn't anything to do with theses repositories. The guidelines
should just cover things like formatting of commit messages, branch
access, awareness of rewriting history with rebase/commit-amend.
ok, I understand now.
or is this some repo you never intend to sync back to
vim ?
What gets back into mainline depends on Bram. vim_extended is not fork,
it just sits on top of Vim.
so I guess it's fine: stick with your workflow and allow push access
if you want :)
I think some questions/answers from above become superfluous now :)
Thanks for the feedback
Markus
Re: In Windows, :ruby command is not works around socket
In case, that subject will not be correctly recognized by mail
clients, I'm trying to continue old thread In Windows, :ruby
command is not works around socket [1]:
1 Jul., 04:00 todesking wrote:
I found a ruby command's bug on Windows VIM.
:ruby require 'open-uri'
:ruby open('http://google.com/')
= SocketError: `initialize': getaddrinfo: non-recoverable
failure in
name resolution.
:ruby open('http://66.249.89.147')
= vim dies
I can confirm that bug still persist in recent VIM (7.2, Included
patches: 1-69).
I can confirm as well, that proposed patch fixes that (I have
modified this according Bram's proposal with initialization of
argc = 1 and removing typecasting).
--
Anton
[1] Original thread In Windows, :ruby command is not works
around socket
http://groups.google.com/group/vim_dev/browse_thread/thread/528607752ef92e68
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
[PATCH] Confirmation dialog instead of warning when closing tab with the mouse
Hi, Currently if I use the mouse to close a tab (click the close button on Mac, right-click tab and select close on pop-up menu on Windows) when there is a modified buffer I get the following warning message: E37: No write since last change (add ! to override) This is kind of unhelpful since you can't add ! using the mouse only. The attached patch fixes this problem by displaying the Save changes dialog instead of the warning message in the above scenario. I think it is as simple as calling conf tabclose instead of tabclose in handle_tabmenu() (at least the comment before that function seems to imply that it is only called when the user interacts with the GUI tabline using the mouse), but correct me if I'm wrong. Björn --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- normal.c.diff Description: Binary data
Re: usr_4[34].txt cosmetics
On Fri, Dec 26, 2008 at 6:49 AM, Florian Rehnisch wrote: Hi folks, it is said, that translators are the best profreaders. ;-) Sometimes, I make annotations. Let's see what I have: # type: Plain text #: usr_43.txt:61 # FIXME: ticks around maplocalleader, not dquotes, for it's an option msgid Likewise, the mapping for \\\c\ will disappear when editing another buffer. The \:map buffer\ command creates a mapping that is local to the current buffer. This works with any mapping command: \:map!\, \:vmap\, etc. The |LocalLeader| in the mapping is replaced with the value of \maplocalleader\. I disagree with this - maplocalleader isn't an option, it's a variable. 'options' should be quoted in the vim help, and variables should be double quoted. # type: Plain text #: usr_44.txt:501 #, no-wrap # FIXME shouldn't that be C++ syntax msgid The \:runtime!\ command searches 'runtimepath' for all \syntax/c.vim\ files.\n This makes the C syntax be defined like for C files. If you have replaced this one the\n c.vim syntax file, or added items with an extra file, these will be loaded as\n well.\n After loading the C syntax items the specific C++ items can be defined.\n For example, add keywords that are not used in C: \n No, I think this one is right as well. Though it could probably be phrased slightly better, I believe it's trying to say that All C syntax items will be defined like for C files. I'd suggest this patch as a clarification: diff --git a/doc/usr_44.txt b/doc/usr_44.txt index f5506b4..e37bfd5 100644 --- a/doc/usr_44.txt +++ b/doc/usr_44.txt @@ -492,10 +492,10 @@ one for C by using the following command: :runtime! syntax/c.vim -The :runtime! command searches 'runtimepath' for all syntax/c.vim files. -This makes the C syntax be defined like for C files. If you have replaced the -c.vim syntax file, or added items with an extra file, these will be loaded as -well. +The :runtime! command searches 'runtimepath' for all syntax/c.vim files +and loads them each. This makes every C syntax item be loaded just like they +would for C files. If you have replaced the c.vim syntax file, or added items +with an extra file, these will be loaded as well. After loading the C syntax items the specific C++ items can be defined. For example, add keywords that are not used in C: # type: Plain text #: usr_44.txt:513 #, no-wrap # FIXME s,It,A script, msgid Now consider the Perl language. It consists of two distinct parts: a\n documentation section in POD format, and a program written in Perl itself.\n The POD section starts with \=head\ and ends with \=cut\.\n You want to define the POD syntax in one file, and use it from the Perl\n syntax file. The \:syntax include\ command reads in a syntax file and stores\n the elements it defined in a syntax cluster. For Perl, the statements are as\n follows: \n I agree here. diff --git a/doc/usr_44.txt b/doc/usr_44.txt index f5506b4..7aa324a 100644 --- a/doc/usr_44.txt +++ b/doc/usr_44.txt @@ -503,9 +503,10 @@ For example, add keywords that are not used in C: This works just like in any other syntax file. -Now consider the Perl language. It consists of two distinct parts: a -documentation section in POD format, and a program written in Perl itself. -The POD section starts with =head and ends with =cut. +Now consider the Pere language. There are two distinct types of files that +need Perl syntax highlighting: a documentation section in POD format, and +a program written in Perl itself. The POD section starts with =head and +ends with =cut. You want to define the POD syntax in one file, and use it from the Perl syntax file. The :syntax include command reads in a syntax file and stores the elements it defined in a syntax cluster. For Perl, the statements are as # type: Plain text #: usr_44.txt:668 # FIXME comma after b:current_syntax msgid Choose a good, descriptive name for your syntax file. Use lowercase letters and digits. Don't make it too long, it is used in many places: The name of the syntax file \name.vim\, 'filetype', b:current_syntax the start of each syntax group (nameType, nameStatement, nameString, etc). Yep. diff --git a/doc/usr_44.txt b/doc/usr_44.txt index f5506b4..d6609f9 100644 --- a/doc/usr_44.txt +++ b/doc/usr_44.txt @@ -663,7 +663,7 @@ as an example will save you a lot of time. Choose a good, descriptive name for your syntax file. Use lowercase letters and digits. Don't make it too long, it is used in many places: The name of -the syntax file name.vim, 'filetype', b:current_syntax the start of each +the syntax file name.vim, 'filetype', b:current_syntax, the start of each syntax group (nameType, nameStatement, nameString, etc). Start with a check for b:current_syntax. If it is defined, some other Thanks and merry
Re: usr_4[34].txt cosmetics
Dnia 26-12-2008 Matt Wozniski m...@drexel.edu pisze: diff --git a/doc/usr_44.txt b/doc/usr_44.txt index f5506b4..7aa324a 100644 --- a/doc/usr_44.txt +++ b/doc/usr_44.txt @@ -503,9 +503,10 @@ For example, add keywords that are not used in C: This works just like in any other syntax file. -Now consider the Perl language. It consists of two distinct parts: a -documentation section in POD format, and a program written in Perl itself. -The POD section starts with =head and ends with =cut. +Now consider the Pere language. There are two distinct types of files that +need Perl syntax highlighting: a documentation section in POD format, and +a program written in Perl itself. The POD section starts with =head and +ends with =cut. You want to define the POD syntax in one file, and use it from the Perl syntax file. The :syntax include command reads in a syntax file and stores the elements it defined in a syntax cluster. For Perl, the statements are as Typo: Perl, not Pere: diff --git a/doc/usr_44.txt b/doc/usr_44.txt index f5506b4..7aa324a 100644 --- a/doc/usr_44.txt +++ b/doc/usr_44.txt @@ -503,9 +503,10 @@ For example, add keywords that are not used in C: This works just like in any other syntax file. -Now consider the Perl language. It consists of two distinct parts: a -documentation section in POD format, and a program written in Perl itself. -The POD section starts with =head and ends with =cut. +Now consider the Perl language. There are two distinct types of files that +need Perl syntax highlighting: a documentation section in POD format, and +a program written in Perl itself. The POD section starts with =head and +ends with =cut. You want to define the POD syntax in one file, and use it from the Perl syntax file. The :syntax include command reads in a syntax file and stores the elements it defined in a syntax cluster. For Perl, the statements are as -- Cheers, Lech --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Vim SEGV
I found a SEGV that I can reproduce reliably, but can't seem to track down. It SEGVs without gdb or valgrind, doesn't SEGV under valgrind, and SEGVs under gdb. The steps that I'm using to reproduce this are complicated, and possibly very specific to the version of the runtime files and such that I'm using, but I'm hoping that a log of the backtrace + valgrind log can help someone to track it down. GDB shows: Program received signal SIGSEGV, Segmentation fault. 0xb8063424 in __kernel_vsyscall () (gdb) bt #0 0xb8063424 in __kernel_vsyscall () #1 0xb7885956 in kill () from /lib/i686/cmov/libc.so.6 #2 0x08137c79 in may_core_dump () at os_unix.c:3070 #3 0x08137c10 in mch_exit (r=1) at os_unix.c:3035 #4 0x080db39c in getout (exitval=1) at main.c:1344 #5 0x08100ea0 in preserve_exit () at misc1.c:8371 #6 0x0813617c in deathtrap (sigarg=11) at os_unix.c:1057 #7 signal handler called #8 0x08079b32 in deref_func_name (name=0x90546a5 netrw#Explore(0,0,0+0,''), lenp=0xbf87d4ec) at eval.c:7833 #9 0x0808b2e5 in trans_function_name (pp=0xbf87d574, skip=0, flags=1, fdp=0xbf87d554) at eval.c:20395 #10 0x0807389e in ex_call (eap=0xbf87d608) at eval.c:3271 #11 0x080a0d5b in do_one_cmd (cmdlinep=0xbf87da44, sourcing=1, cstack=0xbf87d740, fgetline=0, cookie=0x0) at ex_docmd.c:2622 #12 0x0809e834 in do_cmdline (cmdline=0x9126bb0 call netrw#Explore(0,0,0+0,''), getline=0, cookie=0x0, flags=11) at ex_docmd.c:1096 #13 0x080a6562 in do_ucmd (eap=0xbf87db78) at ex_docmd.c:5989 #14 0x080a0d32 in do_one_cmd (cmdlinep=0xbf87dfb4, sourcing=1, cstack=0xbf87dcb0, fgetline=0, cookie=0x0) at ex_docmd.c:2613 #15 0x0809e834 in do_cmdline (cmdline=0x91165c6 E, getline=0, cookie=0x0, flags=11) at ex_docmd.c:1096 #16 0x0809e0f1 in do_cmdline_cmd (cmd=0x91165c6 E) at ex_docmd.c:702 #17 0x080997f0 in ex_debug (eap=0xbf87e0c8) at ex_cmds2.c:301 #18 0x080a0d5b in do_one_cmd (cmdlinep=0xbf87e504, sourcing=0, cstack=0xbf87e200, fgetline=0x80b4047 getexline, cookie=0x0) at ex_docmd.c:2622 #19 0x0809e834 in do_cmdline (cmdline=0x0, getline=0x80b4047 getexline, cookie=0x0, flags=0) at ex_docmd.c:1096 #20 0x081188af in nv_colon (cap=0xbf87e5f0) at normal.c:5233 #21 0x08111f9b in normal_cmd (oap=0xbf87e690, toplevel=1) at normal.c:1200 #22 0x080db0e3 in main_loop (cmdwin=0, noexmode=0) at main.c:1183 #23 0x080dac41 in main (argc=1, argv=0xbf87e894) at main.c:942 Valgrind gives: 1 errors in context 1 of 1: Invalid read of size 4 at 0x8088402: find_var_in_ht (eval.c:18815) by 0x8088277: find_var (eval.c:18769) by 0x8079B16: deref_func_name (eval.c:7831) by 0x808B2E4: trans_function_name (eval.c:20395) by 0x807389D: ex_call (eval.c:3271) by 0x80A0D5A: do_one_cmd (ex_docmd.c:2622) by 0x809E833: do_cmdline (ex_docmd.c:1096) by 0x80A6561: do_ucmd (ex_docmd.c:5989) by 0x80A0D31: do_one_cmd (ex_docmd.c:2613) by 0x809E833: do_cmdline (ex_docmd.c:1096) by 0x809E0F0: do_cmdline_cmd (ex_docmd.c:702) by 0x80997EF: ex_debug (ex_cmds2.c:301) Address 0x4d9ebbc is 916 bytes inside a block of size 2,048 free'd at 0x4022B8A: free (vg_replace_malloc.c:323) by 0x81037B6: vim_free (misc2.c:1625) by 0x80D7F8C: hash_may_resize (hashtab.c:467) by 0x80D7C5C: hash_add_item (hashtab.c:254) by 0x80D7BD4: hash_add (hashtab.c:227) by 0x8088E54: set_var (eval.c:19189) by 0x8072C7F: set_var_lval (eval.c:2787) by 0x80721B1: ex_let_one (eval.c:2403) by 0x80711B2: ex_let_vars (eval.c:1858) by 0x8071163: ex_let (eval.c:1823) by 0x80A0D5A: do_one_cmd (ex_docmd.c:2622) by 0x809E833: do_cmdline (ex_docmd.c:1096) I can give any more information anyone might need. I've been reproducing this by doing :debug Explore, stepping to line 300, then quitting from debug mode - but I would not be at all shocked if that doesn't work for others. I'll keep trying to track it down, but Dominique seems to really have a knack for finding these sorts of problems, so maybe he can shorten the bug-hunting time. :-) ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] Confirmation dialog instead of warning when closing tab with the mouse
björn, 26.12.2008: Hi, Currently if I use the mouse to close a tab (click the close button on Mac, right-click tab and select close on pop-up menu on Windows) when there is a modified buffer I get the following warning message: E37: No write since last change (add ! to override) This is kind of unhelpful since you can't add ! using the mouse only. Sorry for hijacking the thread, but while playing around I noticed that a tabpage cannot be closed with the menu item File-Close (:close) for me. Typing :close worked, so I looked at runtime/menu.vim: \ :if winheight(2) 0 Bar \ confirm enew Bar \ else Bar \ confirm close Bar \ endifCR winheight(2) always returns -1 for me, when on a tabpage without vertically or horizontally split windows. Maybe there is something wrong with it, but what's the intention of the :enew in a close item at all? The attached patch fixes this problem by displaying the Save changes dialog instead of the warning message in the above scenario. I think it is as simple as calling conf tabclose instead of tabclose in handle_tabmenu() (at least the comment before that function seems to imply that it is only called when the user interacts with the GUI tabline using the mouse), but correct me if I'm wrong. Works at least with GTK+ 2 on Linux. Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
