Re: netbeans connection when Vim is not compiled with netbeans_intg
On Sat, Nov 8, 2008 at 2:24 PM, Bram Moolenaar [EMAIL PROTECTED] wrote:
...
The place where you invoke mch_exit() looks a bit weird. Not sure if
this is the best solution. And when compiled without GUI (e.g.,
starting a small version of Vim) this exit won't be reached. Would
someone only use -nb with gvim?
The message should be defined in one place, not twice.
Right of course. I will try sending another patch fixing these points.
Good, thanks.
Attached is a patch that fixes the above issues. It's on top of
version 7.2.28 (subversion revision 1226).
BTW do you think an implementation of netbeans over Vim console is
acceptable as a Vim patch (as opposed to an external patch such as
those in http://groups.google.com/group/vim_dev/web/vim-patches).
If you can make the netbeans interface work for a Vim running in a
console, that sounds like a useful feature. I would include it if it
works properly. However, some programs using the netbeans interface
assume GUI features, such as menus. Thus it's probably only useful
for some applications.
I will give it a try.
Xavier
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: main.c
===
--- main.c (revision 1226)
+++ main.c (working copy)
@@ -246,7 +246,7 @@
mch_exit(0);
TIME_MSG(Allocated generic buffers);
-#ifdef NBDEBUG
+#if defined(FEAT_NETBEANS_INTG) defined(NBDEBUG)
/* Wait a moment for debugging NetBeans. Must be after allocating
* NameBuff. */
nbdebug_log_init(SPRO_GVIM_DEBUG, SPRO_GVIM_DLEVEL);
@@ -274,6 +274,7 @@
* --server...
* --socketid
* --windowid
+ * -nb
*/
early_arg_scan(params);
@@ -1503,13 +1504,15 @@
* argv[]. Used for the xterm-clipboard display.
*
* Also find the --server... arguments and --socketid and --windowid
+ * Also check -nb when netbeans_intg feature not compiled in
*/
/*ARGSUSED*/
static void
early_arg_scan(parmp)
mparm_T *parmp;
{
-#if defined(FEAT_XCLIPBOARD) || defined(FEAT_CLIENTSERVER)
+#if defined(FEAT_XCLIPBOARD) || defined(FEAT_CLIENTSERVER) \
+ || ! defined(FEAT_NETBEANS_INTG)
int argc = parmp-argc;
char **argv = parmp-argv;
int i;
@@ -1581,6 +1584,13 @@
else if (STRICMP(argv[i], --echo-wid) == 0)
echo_wid_arg = TRUE;
# endif
+# ifndef FEAT_NETBEANS_INTG
+ else if (strstr(argv[i], -nb) == argv[i])
+{
+mch_errmsg('-nb' cannot be used: not enabled at compile time\n);
+mch_exit(2);
+}
+# endif
}
#endif
}
@@ -2308,7 +2318,7 @@
#endif
)
{
-#ifdef NBDEBUG
+#if defined(FEAT_NETBEANS_INTG) defined(NBDEBUG)
/*
* This shouldn't be necessary. But if I run netbeans with the log
* output coming to the console and XOpenDisplay fails, I get vim
Re: [patch] fixed double call to XCloseDisplay() when Vim is built with -DEXITFREE
Dominique Pelle wrote: Attached patch fixes a bug with Vim-7.2.30 when built with GUI GTK with -DEXITFREE (configure --with-features=huge --enable-gui=gtk). It's a low priority bug since Vim is normally not built with -DEXITFREE. Only GTK GUI is affected (GTK2, athena, Motif are OK). From what I see, GTK takes care of calling XCloseDisplay() through atexit() so mch_free_mem() in os_unix.c should not call XCloseDisplay() before exit() is being called. Here is the error (among other errors) reported by valgrind memory checker: ==12828== Invalid read of size 4 ==12828==at 0x4431EE7: XCloseDisplay (in /usr/lib/libX11.so.6.2.0) ==12828==by 0x418F31E: (within /usr/lib/libgdk-1.2.so.0.9.1) ==12828==by 0x42F7083: exit (in /lib/tls/i686/cmov/libc-2.7.so) ==12828==by 0x8169EF0: mch_exit (os_unix.c:3060) ==12828==by 0x8104D20: getout (main.c:1340) ==12828==by 0x80CA8EE: ex_quit_all (ex_docmd.c:6281) ==12828==by 0x80C4994: do_one_cmd (ex_docmd.c:2621) ==12828==by 0x80C2215: do_cmdline (ex_docmd.c:1095) ==12828==by 0x8148D60: nv_colon (normal.c:5217) ==12828==by 0x8142301: normal_cmd (normal.c:1184) ==12828==by 0x8104A53: main_loop (main.c:1179) ==12828==by 0x810459B: main (main.c:938) ==12828== Address 0x45943b4 is 148 bytes inside a block of size 1,340 free'd ==12828==at 0x402268C: free (vg_replace_malloc.c:323) ==12828==by 0xF3E: _XFreeDisplayStructure (in /usr/lib/libX11.so.6.2.0) ==12828==by 0x4431FC5: XCloseDisplay (in /usr/lib/libX11.so.6.2.0) ==12828==by 0x8169D73: mch_free_mem (os_unix.c:2945) ==12828==by 0x813289B: free_all_mem (misc2.c:1122) ==12828==by 0x8169EE5: mch_exit (os_unix.c:3057) ==12828==by 0x8104D20: getout (main.c:1340) ==12828==by 0x80CA8EE: ex_quit_all (ex_docmd.c:6281) ==12828==by 0x80C4994: do_one_cmd (ex_docmd.c:2621) ==12828==by 0x80C2215: do_cmdline (ex_docmd.c:1095) ==12828==by 0x8148D60: nv_colon (normal.c:5217) ==12828==by 0x8142301: normal_cmd (normal.c:1184) ==12828==by 0x8104A53: main_loop (main.c:1179) ==12828==by 0x810459B: main (main.c:938) Attached patch fixes it. Thanks! -- hundred-and-one symptoms of being an internet addict: 203. You're an active member of more than 20 newsgroups. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: bad default shellxquote in Widows
Ben Fritz wrote: On Nov 6, 11:20 pm, Tony Mechelynck [EMAIL PROTECTED] wrote: To avoid passing a path with spaces in it, use the short form of the path, such as %:p:8 (this works only on Windows -- on Unix you can just backslash-escape the spaces). This will convert the path so that Program Files becomes PROGRA~1, My Documents MYDOCU~1 and, I think, Copy of startup.m COPYOF~1.M -- the same directories and files will be accessed, but without the need for quoting the path. Best regards, Tony. Ah yes, this would be a reasonable solution in the general case. I have two issues with it, however: 1. It would require separate logic for Unix vs. Windows, whereas simply fixing the default value of shellxquote and shellcmdflag for Windows would allow the same logic to be used. 2. In the particular plugin I was working on, which highlights errors in MATLAB scripts using the mlint utility, system() is used to pass a file name to mlint. One of the checks that mlint does is to ensure that the file name is formed from a legal MATLAB identifier. Using the short form of Windows path names, mlint will always return this error if the file name is longer than 8 characters (though incidentally, the file name is also invalid if it contains spaces, but theoretically the temporary directory it is stored in may have spaces in the path with no problems). So I think the better solution would be to fix the values of shellxquote and shellcmdflag, either by adding extra logic to the plugin, or by actually changing the defaults. For convienience, the suggested default values are: for windows, always: set shellxquote=\ for windows, when 'shell' does not contain sh somewhere: set shellcmdflag=/s\ /c This will place extra quotes around the entire command, and force the cmd.exe behavior that removes the first and last quote from the line if the first character is a quote. I think this should only be done for cmd.exe, not for command.com. So the check should not be 'shell' not matching sh but 'shell' matching cmd. I personally think that the current defaults break in enough cases that we should change them as suggested in this thread, but I can see the argument for keeping the current values to prevent plugins like taglist that escape quotes with backslashes depending on the value of shellxquote. Plugin developers may have assumed (as done in the taglist plugin) that if the cmd.exe shell is used, shellxquote will _not_ be equal to a character. Thus, setting shellxquote to \ causes code to execute that is not intended to run at all for the cmd.exe shell. Yes there is a risk. It's hard to tell what might break. -- hundred-and-one symptoms of being an internet addict: 205. You're constantly yelling at your spouse, family, roommate, whatever, for using the phone for stupid things...like talking. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Feature request? Cannot set the color of non selected entries in the wildmenu
Hi all, The only highlight concerning the wildmenu I'm aware of is 'WildMenu'. This lets me choose how the current match should be highlighted, but I can't set the style of other entries in that menu. AFAICT, Vim automatically uses the highlight style of the status bar. This is annoying, because I like to use colors such as dark grey / white for this kind of things (e.g., completion menu, tabs), so that the current entry is clearly visible. However, to do that, I would have to set the foregound color of the status bar to dark grey, resulting in a status bar not easily readable most of the time (when the wildmenu is not currently used). Is there a solution to this problem? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How can I send a patch?
Roberto Miura Honji wrote: I change something on vim code and some friends tell me that I would be send this to development group. How can I send this? The new function is: - Auto-complete using a tab key (like ctrl-p). - When the word have a '/' (linux separator of directories) auto-complete like a file (ctrl-x ctrl-f). - When the list search is returned, the tab can be used to scroll through the list. - when the previous char is space, tab, the cursor position is a col = 0 or ctrl-x ctrl-i is typed, the char tab is insert normally) I think that it's so cool to programmer that use the linux, actually terminal linux. The patch is: I have some trouble understanding how this works. If it works like CTRL-P, then why not use CTRL-P? At least that avoids the problem that someone wants to insert a Tab and gets completion instead. Your description sounds like it's a bit unpredictable. The patch is hard-coding things that should be flexible. For example, in MS-Windows the path separator is a backslash. And one should use 'isfname' to check if a character can be part of a file name. The code is also lacking support for multi-byte characters. Still some work to do! But before you spend time on that, we need to find out if we really want it to work this way. -- Spam seems to be something useful to novices. Later you realize that it's a bunch of indigestable junk that only clogs your system. Applies to both the food and the e-mail! /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: netbeans connection when Vim is not compiled with netbeans_intg
On Saturday 08 November 2008 10:12 am, Xavier de Gaye wrote: On Sat, Nov 8, 2008 at 2:24 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: ... The place where you invoke mch_exit() looks a bit weird. Not sure if this is the best solution. And when compiled without GUI (e.g., starting a small version of Vim) this exit won't be reached. Would someone only use -nb with gvim? The message should be defined in one place, not twice. Right of course. I will try sending another patch fixing these points. Good, thanks. Attached is a patch that fixes the above issues. It's on top of version 7.2.28 (subversion revision 1226). I hope the above is a typo -- for me subversion reports revision 1226 while vim is at 7.2.26 sc --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: netbeans connection when Vim is not compiled with netbeans_intg
On Saturday 08 November 2008 10:12 am, Xavier de Gaye wrote: On Sat, Nov 8, 2008 at 2:24 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: ... The place where you invoke mch_exit() looks a bit weird. Not sure if this is the best solution. And when compiled without GUI (e.g., starting a small version of Vim) this exit won't be reached. Would someone only use -nb with gvim? The message should be defined in one place, not twice. Right of course. I will try sending another patch fixing these points. Good, thanks. Attached is a patch that fixes the above issues. It's on top of version 7.2.28 (subversion revision 1226). oops -- please forgive the double post -- I so often hit Send and then engage my brain revision 1226 did indeed update my source to 7.2.28 but as it stands it will not compile for me (already noted in a previous post) sc --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Oldfiles?
Hello Vim Developers, After updating my runtime today, I noted the command `:ol[dfiles]'. Certainly `:h :ol' or `:h :oldfiles' works fine. However: :ol or :oldfiles produces `E492: Not an editor command'. It there an error in the helpfiles? This appears to also be true for v:oldfiles - i.e. no such thing. -- Best regards, Bill --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Update of the mail.vim syntax file
Hi All,
I just updated the mail.vim syntax file to include syntax folding. It
now supports folding away quoted text, headers, and signatures.
Does someone have comments? Issues are as follows:
1. Someone who has fdm=syntax will start composing new mail with all
text folded away (his signature, header, and quoted text). I
presume this is useless. I avoid this by putting an autocommand
that sets fdc=3 and fdl=9 for mail files. But perhaps this should
be done by default in the ftplugin file, if the user has
fdm=syntax.
2. Bram uses expression folding: I attach the snipped he sent to me
(off list). Perhaps this should go into the default ftplugin
file, and add documentation saying mail can be folded by
syntax/expression etc.
3. Would be nice to have the important header fields unfolded. But
that would involve splitting the header into multiple regions,
which might or might not be desirable.
GI
--
A plateau is a high form of flattery.
Vim syntax file
Language: Mail file
Previous Maintainer: Felix von Leitner [EMAIL PROTECTED]
Maintainer: Gautam Iyer [EMAIL PROTECTED]
Last Change: Fri 07 Nov 2008 11:22:29 PM PST
Quit when a syntax file was already loaded
if exists(b:current_syntax)
finish
endif
The mail header is recognized starting with a keyword: line and ending
with an empty line or other line that can't be in the header. All lines of
the header are highlighted. Headers of quoted messages (quoted with ) are
also highlighted.
Syntax clusters
syn cluster mailHeaderFields
contains=mailHeaderKey,mailSubject,mailHeaderEmail,@mailLinks
syn cluster mailLinks contains=mailURL,mailEmail
syn cluster mailQuoteExps
contains=mailQuoteExp1,mailQuoteExp2,mailQuoteExp3,mailQuoteExp4,mailQuoteExp5,mailQuoteExp6
syn case match
For From matching case is required. The From is not matched in quoted
emails
According to RFC 2822 any printable ASCII character can appear in a field
name, except ':'.
syn region mailHeader [EMAIL PROTECTED],@NoSpell start=^From
.*\d\d\d\d$ skip=^\s end=\v^[!-9;-~]*([^!-~]|$)me=s-1 fold
syn match mailHeaderKey contained contains=mailEmail,@NoSpell
^From\s.*\d\d\d\d$
Nothing else depends on case.
syn case ignore
Headers in properly quoted (with or ) emails are matched
syn region mailHeader keepend [EMAIL
PROTECTED],@mailQuoteExps,@NoSpell start=^\z(\(
\?\)*\)\v(newsgroups|x-([a-z\-])*|path|xref|message-id|from|((in-)?reply-)?to|b?cc|subject|return-path|received|date|replied):
skip=^\z1\s end=\v^\z1[!-9;-~]*([^!-~]|$)me=s-1 end=[EMAIL
PROTECTED]me=s-1 end=\v^\z1(\ ?)+me=s-1 fold
Usenet headers
syn match mailHeaderKey contained
contains=mailHeaderEmail,mailEmail,@NoSpell \v(^(\
?)*)@=(Newsgroups|Followup-To|Message-ID|Supersedes|Control):.*$
syn region mailHeaderKey contained
contains=mailHeaderEmail,mailEmail,@mailQuoteExps,@NoSpell start=\v(^(\
?)*)@=(to|b?cc): skip=,$ end=$
syn match mailHeaderKey contained
contains=mailHeaderEmail,mailEmail,@NoSpell \v(^(\ ?)*)@=(from|reply-to):.*$
syn match mailHeaderKey contained [EMAIL PROTECTED] \v(^(\
?)*)@=date:
syn match mailSubject contained \v^subject:.*$
syn match mailSubject contained [EMAIL PROTECTED] \v(^(\
?)+)@=subject:.*$
Anything in the header between and is an email address
syn match mailHeaderEmail contained [EMAIL PROTECTED] .\{-}
Mail Signatures. (Begin with -- , end with change in quote level)
syn region mailSignature keepend [EMAIL PROTECTED],@mailQuoteExps
start=^--\s$ end=^$ end=^\( \?\)\+me=s-1 fold
syn region mailSignature keepend contained [EMAIL
PROTECTED],@mailQuoteExps,@NoSpell start=^\z(\(\([a-z]\+\|[]|}]\)[
\t]*\)\+\)--\s$ end=^\z1[ \t]*\([a-z]\+\|[]|}]\)me=s-1 end=[EMAIL
PROTECTED]me=s-1 end=^\z1$ fold
Treat verbatim Text special.
syn region mailVerbatim[EMAIL PROTECTED] keepend start=^#v+$
end=^#v-$ fold
syn region mailVerbatimkeepend contained [EMAIL PROTECTED],@NoSpell
start=^\z(\( \?\)\+\)#v+$ start=^\z(\(\([a-z]\+\|[]|}]\)[ \t]*\)\+\)#v+$
end=^\z1[ \t]*\([a-z]\+\|[]|}]\)me=s-1 end=[EMAIL PROTECTED]me=s-1
end=^\z1#v-$ fold
URLs start with a known protocol or www,web,w3.
syn match mailURL [EMAIL PROTECTED]
`\v(((https?|ftp|gopher)://|(mailto|file|news):)[^'
]+|(www|web|w3)[a-z0-9_-]*\.[a-z0-9._-]+\.[^']+)[a-z0-9/]`
syn match mailEmail [EMAIL PROTECTED] \v[_=a-z\./[EMAIL PROTECTED]
Make sure quote markers in regions (header / signature) have correct color
syn match mailQuoteExp1contained \v^(\ ?)
syn match mailQuoteExp2contained \v^(\ ?){2}
syn match mailQuoteExp3contained \v^(\ ?){3}
syn match mailQuoteExp4contained \v^(\ ?){4}
syn match mailQuoteExp5contained \v^(\ ?){5}
syn match mailQuoteExp6contained \v^(\ ?){6}
syn match mailQuoteExp1
RE: Oldfiles?
Bill McCarthy wrote: After updating my runtime today, I noted the command `:ol[dfiles]'. That was for an experimental patch that Bram posted: http://groups.google.com/group/vim_dev/browse_thread/thread/20e72354ed4b2f42 I guess it will be a bit longer before the docs and the released code are in sync. John --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Update of the mail.vim syntax file
On 2008-11-08, Gautam Iyer [EMAIL PROTECTED] wrote: Hi All, I just updated the mail.vim syntax file to include syntax folding. It now supports folding away quoted text, headers, and signatures. Does someone have comments? Issues are as follows: 1. Someone who has fdm=syntax will start composing new mail with all text folded away (his signature, header, and quoted text). I presume this is useless. I avoid this by putting an autocommand that sets fdc=3 and fdl=9 for mail files. But perhaps this should be done by default in the ftplugin file, if the user has fdm=syntax. 2. Bram uses expression folding: I attach the snipped he sent to me (off list). Perhaps this should go into the default ftplugin file, and add documentation saying mail can be folded by syntax/expression etc. 3. Would be nice to have the important header fields unfolded. But that would involve splitting the header into multiple regions, which might or might not be desirable. Not to be a wet blanket, but I do have a couple of comments. 1. A proper signature is no more than 4 lines and appears at the very bottom of the message, so folding it seems hardly worthwhile. Other people's signatures should not be included in a reply. 2. Similarly, if your mailer includes any of your headers at all in the file it gives your editor, they should be few and at the very top of the file. Other people's headers need not be included in a reply. 3. If part of the message you are quoting is not important enough for you to need to refer to it as you're composing your reply, it's not important enough to include in the reply. Any part of a message that you would like to fold away should probably just be deleted from the message. Regards, Gary --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Sat, Nov 8, 2008 at 14:24, Bram Moolenaar [EMAIL PROTECTED] wrote: These patches are made by anyone who is interested in making a patch. I don't have time to look through them, especially if a patch gets changed a few times. So don't expect a good or bad comment from me. Unless it's something I really want to use myself or have looked at for some reason (e.g., I have been reviewing the Google Summer of Code stuff). Would patches that live in said repo that are in active use and prove stable have a higher chance of being reviewed? Personally, I suspect that such an agreement is what is lacking in order to get more people to test out patches. I know it's the main stopper for myself as I fear most work in that way will be useless, anyway. Some kind of way to add comments to the patches would be nice. But we need another system to be able to do that. I already suggested that someone could take the text and move it to a platform with more flexibility. If gut supports something like trac, that would be a neat way to get comments about the patches going. Otherwise, they could be put onto wiki discussions, into a forum or patches could be integrated in whatever is done with the scripts section. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Update of the mail.vim syntax file
* Gary Johnson [EMAIL PROTECTED] [081108 18:18]: Not to be a wet blanket, but I do have a couple of comments. 1. A proper signature is no more than 4 lines and appears at the very bottom of the message, so folding it seems hardly worthwhile. Other people's signatures should not be included in a reply. 2. Similarly, if your mailer includes any of your headers at all in the file it gives your editor, they should be few and at the very top of the file. Other people's headers need not be included in a reply. 3. If part of the message you are quoting is not important enough for you to need to refer to it as you're composing your reply, it's not important enough to include in the reply. Any part of a message that you would like to fold away should probably just be deleted from the message. Regards, Gary While I agree with you completely that these points hold when using Vim to compose a reply, they do not hold when using Vim to browse messages that have been received from others. (Too) many people don't use proper signatures and don't properly trim quoted material; and when using Vim to view raw messages, e.g. from a Maildir folder, there are usually many headers. ...Marvin --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Update of the mail.vim syntax file
* Gary Johnson [EMAIL PROTECTED] [081108 18:18]: Not to be a wet blanket, but I do have a couple of comments. 1. A proper signature is no more than 4 lines and appears at the very bottom of the message, so folding it seems hardly worthwhile. Other people's signatures should not be included in a reply. 2. Similarly, if your mailer includes any of your headers at all in the file it gives your editor, they should be few and at the very top of the file. Other people's headers need not be included in a reply. 3. If part of the message you are quoting is not important enough for you to need to refer to it as you're composing your reply, it's not important enough to include in the reply. Any part of a message that you would like to fold away should probably just be deleted from the message. Regards, Gary While I agree with you completely that these points hold when using Vim to compose a reply, they do not hold when using Vim to browse messages that have been received from others. (Too) many people don't use proper signatures and don't properly trim quoted material; and when using Vim to view raw messages, e.g. from a Maildir folder, there are usually many headers. ...Marvin --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Update of the mail.vim syntax file
On Sat, Nov 08, 2008 at 03:10:57PM -0800, Gary Johnson wrote: I just updated the mail.vim syntax file to include syntax folding. It now supports folding away quoted text, headers, and signatures. Does someone have comments? Issues are as follows: 1. Someone who has fdm=syntax will start composing new mail with all text folded away (his signature, header, and quoted text). I presume this is useless. I avoid this by putting an autocommand that sets fdc=3 and fdl=9 for mail files. But perhaps this should be done by default in the ftplugin file, if the user has fdm=syntax. 2. Bram uses expression folding: I attach the snipped he sent to me (off list). Perhaps this should go into the default ftplugin file, and add documentation saying mail can be folded by syntax/expression etc. 3. Would be nice to have the important header fields unfolded. But that would involve splitting the header into multiple regions, which might or might not be desirable. Not to be a wet blanket, but I do have a couple of comments. 1. A proper signature is no more than 4 lines and appears at the very bottom of the message, so folding it seems hardly worthwhile. Other people's signatures should not be included in a reply. 2. Similarly, if your mailer includes any of your headers at all in the file it gives your editor, they should be few and at the very top of the file. Other people's headers need not be included in a reply. 3. If part of the message you are quoting is not important enough for you to need to refer to it as you're composing your reply, it's not important enough to include in the reply. Any part of a message that you would like to fold away should probably just be deleted from the message. For similar reasons, I too thought syntax folding for mails was pointless. But Christian Brabandt sent me a preliminary folding patch. I accepted it, thinking that anyone who doesn't want folding needn't use fdm=syntax, and won't see change. However -- after using it a little I found it quite useful. However having the regions marked as folds makes it easy for you to delete / navigate (e.g. zk/zj zCdd, [z, ]z etc.). Further when I edit raw messages, folding away long headers is quite useful. That said -- if you don't think syntax folding is useful, don't use it, and don't clutter my mailbox. If you have constructive suggestions (esp. constructive suggestions with patches) let me know, GI -- Top Ten New Intel Slogans For The Pentium: 8.163362 It's Close Enough, We Say So pgpLT48rmhMf2.pgp Description: PGP signature
Re: [patch] fixed overlapping memcpy() in if_xcmdsrv.c
On 08/11/08 14:24, Bram Moolenaar wrote:
Dominique Pelle wrote:
While using Vim-7.2.30 built with GUI GTK (huge), I stumbled
upon this error with Valgrind memory checker:
==13326== Source and destination overlap in memcpy(0x4B5D8D8, 0x4B5D8E4, 13)
==13326==at 0x4024C92: memcpy (mc_replace_strmem.c:402)
==13326==by 0x8102E99: LookupName (if_xcmdsrv.c:1021)
==13326==by 0x810197E: DoRegisterName (if_xcmdsrv.c:303)
==13326==by 0x8101718: serverRegisterName (if_xcmdsrv.c:225)
==13326==by 0x81076D1: prepare_server (main.c:3379)
==13326==by 0x8104253: main (main.c:721)
Attached patch fixes it by calling mch_memmove() instead of memcpy().
Looking at the code, I found another place where the same problem would
also happen (also fixed in patch).
Some versions of memcpy() can handle overlaps, but I suppose it's not
guaranteed. Thanks for another patch.
Configure is supposed to check whether one of the system provided
string-move operations handle overlap. Here's what I see in the logs and
files produced by configure on my system:
-- in configure stdout/stderr:
checking whether memmove handles overlaps... yes
-- in src/auto/config.log
configure:15252: checking whether memmove handles overlaps
configure:15274: gcc -o conftest -O2 -fno-strength-reduce -Wall -L.
-rdynamic -Wl,-export-dynamic -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
-L/usr/local/lib conftest.c -lm -lncurses -lnsl -lacl -lattr -lgpm 5
conftest.c:10: warning: return type defaults to 'int'
configure:15278: $? = 0
configure:15284: ./conftest
configure:15288: $? = 0
configure:15310: result: yes
-- in src/auto/config.cache:
vim_cv_memmove_handles_overlap=${vim_cv_memmove_handles_overlap=yes}
-- in src/auto/config.h
/*
* If we cannot trust one of the following from the libraries, we use our
* own safe but probably slower vim_memmove().
*/
/* #undef USEBCOPY */
#define USEMEMMOVE 1
/* #undef USEMEMCPY */
-- in src/os_unix.h:
/* memmove is not present on all systems, use memmove, bcopy, memcpy or our
* own version */
/* Some systems have (void *) arguments, some (char *). If we use (char
*) it
* works for all */
#ifdef USEMEMMOVE
# define mch_memmove(to, from, len) memmove((char *)(to), (char
*)(from), len)
#else
# ifdef USEBCOPY
# define mch_memmove(to, from, len) bcopy((char *)(from), (char *)(to),
len)
# else
# ifdef USEMEMCPY
# define mch_memmove(to, from, len) memcpy((char *)(to), (char
*)(from), len)
# else
# define VIM_MEMMOVE /* found in misc2.c */
# endif
# endif
#endif
-- in src/misc2.c:
#ifdef VIM_MEMMOVE
/*
* Version of memmove() that handles overlapping source and destination.
* For systems that don't have a function that is guaranteed to do that
(SYSV).
*/
void
mch_memmove(dst_arg, src_arg, len)
void*src_arg, *dst_arg;
size_t len;
{
/*
* A void doesn't have a size, we use char pointers.
*/
char *dst = dst_arg, *src = src_arg;
/* overlap, copy backwards */
if (dst src dst src + len)
{
src += len;
dst += len;
while (len-- 0)
*--dst = *--src;
}
else /* copy forwards */
while (len-- 0)
*dst++ = *src++;
}
#endif
So I suppose mch_memmove should be used everywhere for moves of byte
strings (overlapping or not), and it will be resolved by bcopy, memmove,
memcpy or the owncoded function according to what configure has found.
Best regards,
Tony.
--
This Fortue Examined By INSPECTOR NO. 2-14
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: netrw - double quoted question mark
On 07/11/08 21:21, Pavol Juhas wrote: Hello, I just found that URLs that contain question mark cannot be loaded with the latest netrw v134. For example :view http://www.vim.org/scripts/script_search_results.php?keywords=netrw shows an empty buffer, because the URL that is passed to wget contains '\?'. The problem seems to go away after applying the attached patch. I am not sure if this is a good solution, because there is an error message about temporary file, which could not be deleted. Perhaps it would be better to replace exe Nread in plugin/netrw.vim autocommands with a call to function - in such case the URL could be passed without quoting and without worries that it may execute some vim commands on the side. Cheers, Pavol in a query string should be passed as amp; or as %26 though many web pages don't use this, even though the W3C HTML guidelines require it. I suppose that if netrw has problems with the question mark (maybe for internal reasons) it can always be passed as %3F (but of course not as %253F which would be double percent escaping and miss the goal). Best regards, Tony. -- Women are probably the main cause of free software starvation. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim syntax: highlight keyword not highlighted inside functions
On 07/11/08 08:08, François Ingelrest wrote: On Thu, Nov 6, 2008 at 22:41, Roberto Miura Honji[EMAIL PROTECTED] wrote: I'm using highlight inside a function and It's working. You get the same color highlighting inside and outside the function? For me the highlighting works inside functions for most statements, but not for the 'highlight' statement itself (see attached screenshot). Do you call the function? If you only define a function on foo.vim, this only will be defined. Try append a follow line in a foo.vim: call Foo() This doesn't make a difference. Actually, I'm not sure the syntax file checks that functions are called to highlight them. Yeah, looks like the syntax/vim.vim script doesn't recognise the same syntax groups for some statements when they are inside a function. With the default GUI colours, here's what I see: line wordisolated (= links to) inside func (= links to) highlight Comment guifg=white guibg=black highlight vimHighlight = Statement vimIsCommand Comment vimHiGroup = Type vimIsCommand guifg vimHiGuiFgBg = TypevimIsCommand = vimHiKeyListvimOper = Statement white vimHiGroup = Type vimIsCommand guibg vimHiGuiFgBg = TypevimIsCommand = vimHiKeyListvimOper = Statement black vimHiGroup = Type vimIsCommand syn sync fromstart syn vimSyntax = Statement vimIsCommand syncvimSynType = Type vimIsCommand fromstart vimSyncC = TypevimIsCommand filetype plugin indent on filetypevimFTCmd = Statement vimCommand = Statement plugin vimFTOption = Type vimIsCommand indent vimFTOption = Type vimIsCommand on vimFTOption = Type vimCommand = Statement The other ones that I tried were highlighted identically inside functions and out of them. I found this out by means of the following command (which gives four replies but 1 and 3 are equal, and so are 2 and 4, AFAICT): command -nargs=0 -bar WhatSyntax echomsg synIDattr(synID(line(.),col(.),0),name) synIDattr(synIDtrans(synID(line(.),col(.),0)),name) synIDattr(synID(line(.),col(.),1),name) synIDattr(synIDtrans(synID(line(.),col(.),1)),name) Notice the many instances of various syntax groups becoming vimIsCommand (which has no highlights defined) when inside a function block. Maybe contains=TOP should be added to the definition of the vimFuncBody syntax group? Dr.Chip, what do you think? Best regards, Tony. -- I've given up reading books; I find it takes my mind off myself. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Oldfiles?
On Sat 8-Nov-08 4:39pm -0600, John Beckett wrote: Bill McCarthy wrote: After updating my runtime today, I noted the command `:ol[dfiles]'. That was for an experimental patch that Bram posted: http://groups.google.com/group/vim_dev/browse_thread/thread/20e72354ed4b2f42 I guess it will be a bit longer before the docs and the released code are in sync. Thanks John, I apparently missed that thread. -- Best regards, Bill --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed overlapping memcpy() in if_xcmdsrv.c
On Sat, Nov 8, 2008 at 11:18 PM, Tony Mechelynck wrote: Configure is supposed to check whether one of the system provided string-move operations handle overlap. Here's what I see in the logs and files produced by configure on my system: snip So I suppose mch_memmove should be used everywhere for moves of byte strings (overlapping or not), and it will be resolved by bcopy, memmove, memcpy or the owncoded function according to what configure has found. You're right up til this point, but mch_memmove() should only be used where the bytes are overlapping, since it's so much less efficient than just a normal memcpy() and that loss is only justified when its extra feature is being used. memmove() should never be used in the vim sources. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Oldfiles?
On 08/11/08 22:16, Bill McCarthy wrote: Hello Vim Developers, After updating my runtime today, I noted the command `:ol[dfiles]'. Certainly `:h :ol' or `:h :oldfiles' works fine. However: :ol or :oldfiles produces `E492: Not an editor command'. It there an error in the helpfiles? This appears to also be true for v:oldfiles - i.e. no such thing. I can't find when that command and variables were added; however they don't exist in tiny or small builds if Vim, which don't include the expression-evaluation feature. This (or the equivalent) is the important line in the output of the :version command: Huge version with GTK2-GNOME GUI. Features included (+) or not (-): If the first word here is Tiny or Small you don't need to look further -- in that case your Vim version hasn't got what it takes to use the :oldfiles command or the v:oldfiles variable. OTOH if your Vim version is too old it might not jibe with the latest runtimes anymore. In that case here are the relevant :version lines: VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 7 2008 03:49:22) Included patches: 1-30 If the second line is not present it means No patches included. The above (7.2.30) is the latest version as of this version, AFAIK. Best regards, Tony. -- I've seen better heads on half a pint of beer. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
