Re: Time to remove naming restrictions?
On 10/3/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: On 10/1/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: One thing that really annoys me with Vim is the limits it emposes on what names are legal for user-defined functions and commands. I know the reason for these restrictions, but I don't think they make much sense, especially so for user-defined commands. I realize that overriding :quit does have its implications, but done carefully, this does allow for some interesting effects. So, why not lift the restrictions on valid names for user-defined functions and commands? That is, give me good reasons for why they should be maintained and I'll drop this request. Predictability. As in what? That :quit always works as documented? Sure, that's great, but if that's the problem, the restriction should be limited to commands already defined. And what happens when more commands are added? Hell, then they'll break the user-defined commands with the same name. Big deal; that's life, you'll get over it - everyone does, eventually. I really don't see the big difference between user-defined commands clashing with built-in commands and user-defined commands clashing with each other. It'll happen; unless you start adding prefixes or namespaces or some other way of separating your commands. But then you lose out on simplicity. You don't want to type :NOWCommand (given that NOW is my prefix), and I don't want to type :Command; I want to type :command. Sure, it only saves my fingers from giving up on me for so long, but every little bit helps. I guess my problem is that I want - and I've always wanted - the flexibility of Emacs coupled with the simplicity and efficiency of Vim's command set and modes. I guess that's why I nitpick at things such as this. nikolai :command -bar Command ... :cabbrev command Command and then you'll wonder why you can't define a new user-command but it's your funeral. You can (via source); cabbrev don't affect sourced scritps. Yakov
Re: Fwd: Do Not Reply To This Message:Re: Time to remove naming restrictions?
Nikolai Weibull wrote: I keep getting this f**king message every time I post to vim-dev. Seriously, wtf? nikolai (awaiting another notification for this mail not getting through) -- Forwarded message -- From: System Administrator [EMAIL PROTECTED] Date: 2 Oct 2006 14:19:05 -0400 Subject: Do Not Reply To This Message:Re: Time to remove naming restrictions? To: Nikolai Weibull [EMAIL PROTECTED] [...] Yeah, I get them too. It means someone at knbt discontinued his mail account (or got it cancelled) without going to the trouble of unsubscribing from Vim. Since the pseudo-bounce does not include the address in question, there's no way to know who it was. You can either blacklist [EMAIL PROTECTED] in your mail reader (e.g. by creating a new filter rule, 'if From: is [EMAIL PROTECTED] then Move to Trash'), or treat it in whatever manner you treat spam. And since the bounce doesn't go thru the list (it goes direct to the poster), no one can filter the bounces away in our place. Best regards, Tony.
Re: Do Not Reply To This Message:Re: Time to remove naming restrictions?
Nikolai Weibull wrote: [...] So anyway, I guess my request is for Felix von Leitner, or whoever doesn't maintain this mailing list anymore (according to earlier discussions on similar subjects), to remove the offending email address from the mailing address. Thanks. nikolai P.S. Sorry about the extra traffic about this. D.S. The problem is, not only the KNBT pseudo-bounce is misdirected, it is incomplete. In particular, it doesn't say which address was not found, so all Felix (or Bram or someone) can know is that someone @knbt.com is no longer a valid address. But they can't go forcibly unsubscribing _every_ @knbt.com subscriber, can they? Quite probably there are more than one. Best regards, Tony.
Re: Fwd: Do Not Reply To This Message:Re: Time to remove naming restrictions?
Ali Akcaagac wrote: On Tue, 2006-10-03 at 11:34 +0200, A.J.Mechelynck wrote: You can either blacklist [EMAIL PROTECTED] in your mail reader (e.g. by creating a new filter rule, 'if From: is [EMAIL PROTECTED] then Move to Trash'), or treat it in whatever manner you treat spam. Hello, I'm getting these mails as well I think this is definately no solution. Think about new people who like joining this mailinglist in regard of contributing or giving feedback to this list. You definately don't want them to blacklist half a dozen unwanted emails before they can finally start posting something or participating to this mailinglist. mfg, Ali Akcaagac It's not half a dozen unwanted emails. It's just one email address, i.e., [EMAIL PROTECTED] -- these false bounces all come from the same source. If you feel up to it, write [EMAIL PROTECTED] telling them their mail routers are misconfigured (you can use my mail to Yakov in this thread as a kind of boilerplate). You can also point him to http://www.spamcop.net/fom-serve/cache/329.html . But don't expect quick and accurate action, that postmaster could quite possibly be an arrogant blockhead wo won't do anything you suggest to him for his own good. Best regards, Tony.
Re: compilation of regular expressions/ enhancement?
Marc Weber wrote: When doing something like map([a,b],matchstr(v:val, \(.\))) will the regular expression \(.\) be compiled on every iteration? How about this: for l in lines if l =~regex ... ? I noticed this beeing slow compared to executing grep once ago. If this is an issue, there might be the solution introducing a compiled regular expression as used in python additional to Number, String, Funcref, List, Dictionary What do you think? Would this be an enhancement? Marc Weber \(.\) is equivalent to . in this case. \(\) is never necessary around the whole pattern; in a substitute, \(.\) can be useful as part of a larger pattern if you want to refer to it as \1 to \9 or via submatch(). About a compiled regular expression type, I don't think it would be useful since we already have :g and :vimgrep. IMO the bigger overhead in your example is in the for and if constructs. Best regards, Tony.
Patch 7.0.113
Patch 7.0.113
Problem:Using CTRL-L in Insert completion when there is no current match
may cause a crash. (Yukihiro Nakadaira)
Solution: Check for compl_leader to be NULL
Files: src/edit.c
*** ../vim-7.0.112/src/edit.c Thu Sep 14 11:07:08 2006
--- src/edit.c Tue Oct 3 14:57:47 2006
***
*** 3206,3212
for (cp = compl_shown_match-cp_next; cp != NULL
cp != compl_first_match; cp = cp-cp_next)
{
! if (ins_compl_equal(cp, compl_leader,
(int)STRLEN(compl_leader)))
{
p = cp-cp_str;
--- 3206,3213
for (cp = compl_shown_match-cp_next; cp != NULL
cp != compl_first_match; cp = cp-cp_next)
{
! if (compl_leader == NULL
! || ins_compl_equal(cp, compl_leader,
(int)STRLEN(compl_leader)))
{
p = cp-cp_str;
*** ../vim-7.0.112/src/version.cTue Oct 3 15:02:11 2006
--- src/version.c Tue Oct 3 15:20:13 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 113,
/**/
--
I recommend ordering large cargo containers of paper towels to make up
whatever budget underruns you have. Paper products are always useful and they
have the advantage of being completely flushable if you need to make room in
the storage area later.
(Scott Adams - The Dilbert principle)
/// 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///
Re: Autocommand-Event for Clipboard-Changed
Bram Moolenaar wrote: Suresh Govindachar wrote: Is it possible to add an autocommand-event for Clipboard Changed? Not really. This is not something that happens inside Vim. Polling for changes in the system is not really something I would like to add to Vim. Bram -- would you be willing to give out a bit of code that will send a remote message to vim? Some function, perhaps SendCmd2Vim(string). That way it'll be simple for folks to make their own external programs to send a command to vim via the already available remote vim stuff. Presumably the code snippet wouldn't be a Part of Vim itself; maybe something for vim.sf.net? Just an idea... Chip Campbell
Patch 7.0.115
Patch 7.0.115
Problem:When 'ignorecase' is set, Insert mode completion only adds foo
and not Foo when both are found.
A found match isn't displayed right away when 'completeopt' does
not have menu or menuone.
Solution: Do not ignore case when checking if a completion match already
exists. call ins_compl_check_keys() also when not using a popup
menu. (Yukihiro Nakadaira)
Files: src/edit.c
*** ../vim-7.0.114/src/edit.c Tue Oct 3 15:22:00 2006
--- src/edit.c Tue Oct 3 14:57:47 2006
***
*** 2157,2163
do
{
if (!(match-cp_flags ORIGINAL_TEXT)
!ins_compl_equal(match, str, len)
match-cp_str[len] == NUL)
return NOTDONE;
match = match-cp_next;
--- 2157,2163
do
{
if (!(match-cp_flags ORIGINAL_TEXT)
!STRNCMP(match-cp_str, str, len) == 0
match-cp_str[len] == NUL)
return NOTDONE;
match = match-cp_next;
***
*** 4042,4048
if (got_int)
break;
/* Fill the popup menu as soon as possible. */
! if (pum_wanted() type != -1)
ins_compl_check_keys(0);
if ((ctrl_x_mode != 0 ctrl_x_mode != CTRL_X_WHOLE_LINE)
--- 4042,4048
if (got_int)
break;
/* Fill the popup menu as soon as possible. */
! if (type != -1)
ins_compl_check_keys(0);
if ((ctrl_x_mode != 0 ctrl_x_mode != CTRL_X_WHOLE_LINE)
*** ../vim-7.0.114/src/version.cTue Oct 3 15:36:09 2006
--- src/version.c Tue Oct 3 15:46:15 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 115,
/**/
--
The budget process was invented by an alien race of sadistic beings who
resemble large cats.
(Scott Adams - The Dilbert principle)
/// 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///
Re: Autocommand-Event for Clipboard-Changed
Charles E Campbell Jr wrote:
Bram Moolenaar wrote:
Suresh Govindachar wrote:
Is it possible to add an autocommand-event for Clipboard Changed?
Not really. This is not something that happens inside Vim. Polling for
changes in the system is not really something I would like to add to Vim.
Bram -- would you be willing to give out a bit of code that will send a
remote message to vim?
Some function, perhaps SendCmd2Vim(string). That way it'll be simple
for folks to make their
own external programs to send a command to vim via the already available
remote vim stuff.
Presumably the code snippet wouldn't be a Part of Vim itself; maybe
something for vim.sf.net?
Just an idea...
Chip Campbell
:call remote_send({server}, {string}[, {idvar}])
:let x = remote_expr({server}, {string}[, {idvar}])
etc.
For other programs: there are two protocols used: Windows and X11. You may
want to dig into the Vim source to see how it does it. The server code (or the
X11 server code?) is in src/if_xcmdsrv.c. The client code may be in eval.c or
something -- look for Vim functions with names starting remote_ (or C
functions with names starting f_remote_). In the source I have here
(7.0.114) there is an #ifdef FEAT_CLIENTSERVER at eval_c line 13051.
Best regards,
Tony.
Patch 7.0.116
Patch 7.0.116
Problem:64 bit Windows version reports 32 bit in the :version output.
(M. Veerman)
Solution: Change the text for Win64.
Files: src/version.c
*** ../vim-7.0.115/src/version.cTue Oct 3 15:49:20 2006
--- src/version.c Tue Oct 3 16:29:31 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 116,
/**/
***
*** 962,966
--- 964,972
MSG_PUTS(_(\nMS-Windows 16/32 bit GUI version));
# else
+ # ifdef _WIN64
+ MSG_PUTS(_(\nMS-Windows 64 bit GUI version));
+ # else
MSG_PUTS(_(\nMS-Windows 32 bit GUI version));
+ # endif
# endif
if (gui_is_win32s())
--
Article in the first Free Software Magazine: Bram Moolenaar studied electrical
engineering at the Technical University of Delft and graduated in 1985 on a
multi-processor Unix architecture.
Response by dimator: Could the school not afford a proper stage for the
ceremony?
/// 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///
Patch 7.0.117
Patch 7.0.117
Problem:Using extend on a syntax item inside a region with keepend, an
intermediate item may be truncated.
When applying the keepend and there is an offset to the end
pattern the highlighting of a contained item isn't adjusted.
Solution: Use the seen_keepend flag to remember when to apply the keepend
flag. Adjust the keepend highlighting properly. (Ilya Bobir)
Files: src/syntax.c
*** ../vim-7.0.116/src/syntax.c Thu Apr 27 01:58:59 2006
--- src/syntax.cTue Oct 3 17:00:44 2006
***
*** 977,982
--- 977,983
{
stateitem_T *cur_si;
int i;
+ int seen_keepend;
if (startofline)
{
***
*** 1002,1008
/*
* Need to update the end of a start/skip/end that continues from the
* previous line. And regions that have keepend, because they may
! * influence contained items.
* Then check for items ending in column 0.
*/
i = current_state.ga_len - 1;
--- 1003,1012
/*
* Need to update the end of a start/skip/end that continues from the
* previous line. And regions that have keepend, because they may
! * influence contained items. If we've just removed extend
! * (startofline == 0) then we should update ends of normal regions
! * contained inside keepend because extend could have extended
! * these keepend regions as well as contained normal regions.
* Then check for items ending in column 0.
*/
i = current_state.ga_len - 1;
***
*** 1010,1019
--- 1014,1026
for ( ; i keepend_level; --i)
if (CUR_STATE(i).si_flags HL_EXTEND)
break;
+
+ seen_keepend = FALSE;
for ( ; i current_state.ga_len; ++i)
{
cur_si = CUR_STATE(i);
if ((cur_si-si_flags HL_KEEPEND)
+ || (seen_keepend !startofline)
|| (i == current_state.ga_len - 1 startofline))
{
cur_si-si_h_startpos.col = 0; /* start highl. in col 0 */
***
*** 1021,1026
--- 1028,1036
if (!(cur_si-si_flags HL_MATCHCONT))
update_si_end(cur_si, (int)current_col, !startofline);
+
+ if (!startofline (cur_si-si_flags HL_KEEPEND))
+ seen_keepend = TRUE;
}
}
check_keepend();
***
*** 2564,2569
--- 2574,2580
{
int i;
lpos_Tmaxpos;
+ lpos_Tmaxpos_h;
stateitem_T *sip;
/*
***
*** 2583,2605
break;
maxpos.lnum = 0;
for ( ; i current_state.ga_len; ++i)
{
sip = CUR_STATE(i);
if (maxpos.lnum != 0)
{
limit_pos_zero(sip-si_m_endpos, maxpos);
! limit_pos_zero(sip-si_h_endpos, maxpos);
limit_pos_zero(sip-si_eoe_pos, maxpos);
sip-si_ends = TRUE;
}
! if (sip-si_ends
!(sip-si_flags HL_KEEPEND)
!(maxpos.lnum == 0
|| maxpos.lnum sip-si_m_endpos.lnum
|| (maxpos.lnum == sip-si_m_endpos.lnum
!maxpos.col sip-si_m_endpos.col)))
! maxpos = sip-si_m_endpos;
}
}
--- 2594,2623
break;
maxpos.lnum = 0;
+ maxpos_h.lnum = 0;
for ( ; i current_state.ga_len; ++i)
{
sip = CUR_STATE(i);
if (maxpos.lnum != 0)
{
limit_pos_zero(sip-si_m_endpos, maxpos);
! limit_pos_zero(sip-si_h_endpos, maxpos_h);
limit_pos_zero(sip-si_eoe_pos, maxpos);
sip-si_ends = TRUE;
}
! if (sip-si_ends (sip-si_flags HL_KEEPEND))
! {
! if (maxpos.lnum == 0
|| maxpos.lnum sip-si_m_endpos.lnum
|| (maxpos.lnum == sip-si_m_endpos.lnum
!maxpos.col sip-si_m_endpos.col))
! maxpos = sip-si_m_endpos;
! if (maxpos_h.lnum == 0
! || maxpos_h.lnum sip-si_h_endpos.lnum
! || (maxpos_h.lnum == sip-si_h_endpos.lnum
!maxpos_h.col sip-si_h_endpos.col))
! maxpos_h = sip-si_h_endpos;
! }
}
}
*** ../vim-7.0.116/src/version.cTue Oct 3 16:30:40 2006
--- src/version.c Tue Oct 3 16:59:50 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 117,
/**/
--
For humans, honesty is a matter of degree. Engineers are always honest in
matters of technology and human relationships. That's why it's a good idea
to keep engineers away from customers, romantic interests, and other people
who can't handle the truth.
(Scott Adams - The Dilbert principle)
/// Bram
Re: Autocommand-Event for Clipboard-Changed
Charles Campbell wrote: Bram Moolenaar wrote: Suresh Govindachar wrote: Is it possible to add an autocommand-event for Clipboard Changed? Not really. This is not something that happens inside Vim. Polling for changes in the system is not really something I would like to add to Vim. Bram -- would you be willing to give out a bit of code that will send a remote message to vim? Some function, perhaps SendCmd2Vim(string). That way it'll be simple for folks to make their own external programs to send a command to vim via the already available remote vim stuff. Presumably the code snippet wouldn't be a Part of Vim itself; maybe something for vim.sf.net? I don't know what you mean with would you be willing. src/if_xcmdsrv.c contains info for writing a C program. os_mswin.c also has some code that can be used for Win32. It's not easy, of course. I can't remember seeing a program that actually does this. -- Engineers will go without food and hygiene for days to solve a problem. (Other times just because they forgot.) (Scott Adams - The Dilbert principle) /// 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///
Re: [macvim] modifiers should be applied to special keys too (patch)
Nicolas Weber wrote: Hmmm Im having a problem. Ctrl-A, ctrl-e, ctrl-k, ctrl-u, etc. dont seem to work anymore. I have these lines in my vimrc: The attached patch should fix this problem as well (again the diff is against vim svn). The problem was that chars like ^A (ctrl-a) were sent with MOD_MASK_CTRL set. I worked around this by adding the lines /* remove CTRL from keys that already have it */ if (key_char 0x20) vimModifiers = ~MOD_MASK_CTRL; I don't know if this the right solution, but it works. At least on my system. :-P I tried the patch, but it appears that CTRL-F and CTRL-B no longer work in Normal mode. They do something in Insert mode after CTRL-V. It looks like this patch needs more careful testing. Perhaps you should make a list of keys with various modifiers that need to be tried to verify the code works correctly. -- Engineers are always delighted to share wisdom, even in areas in which they have no experience whatsoever. Their logic provides them with inherent insight into any field of expertise. This can be a problem when dealing with the illogical people who believe that knowledge can only be derived through experience. (Scott Adams - The Dilbert principle) /// 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///
Patch 7.0.118
Patch 7.0.118
Problem:printf() does not do zero padding for strings.
Solution: Do allow zero padding for strings.
Files: src/message.c
*** ../vim-7.0.117/src/message.cSun Sep 3 16:39:51 2006
--- src/message.c Tue Oct 3 15:41:44 2006
***
*** 4124,4131
case 'c':
case 's':
length_modifier = '\0';
- zero_padding = 0;/* turn zero padding off for string
- conversions */
str_arg_l = 1;
switch (fmt_spec)
{
--- 4124,4129
*** ../vim-7.0.117/src/version.cTue Oct 3 17:04:21 2006
--- src/version.c Tue Oct 3 17:20:11 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 118,
/**/
--
While it's true that many normal people whould prefer not to _date_ an
engineer, most normal people harbor an intense desire to _mate_ with them,
thus producing engineerlike children who will have high-paying jobs long
before losing their virginity.
(Scott Adams - The Dilbert principle)
/// 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///
Re: compilation of regular expressions/ enhancement?
Hi Tony.
Of course this was a trivial example.
I was grepping the output of jar - content-texfile to find the packages
of a java-class.
Currently I'm using this function.
I'm invoking this function for up to 40 files or more.. That depends on
how many modules I have imported.
let type_pattern =
'\zs\('.func_name.'\)\%(\s*,\s*\%('.func_name.'\)\)*\ze\s*::'
if line =~ type_pattern
This is no longer that simple.
But I can do a deepcopy and use filter.. But then I'll no longer able to get
the line numbers..
My question was meant to be more general as my example given in the last
post.
Greetings Marc
function! vl#dev#haskell#modules_list_cache_jump#ScanModuleForFunctions(file)
a function is recognized as function if the looks like
a b c = ...
and a is no keyword (data, new\=type, instance)
let func_name = '\w\+'
let no_f_pattern = '\%(\%(\%(new\)\=type\)\|data\)'
pattern1 / 2 matches
1) function_name arg1 arg2 =
2) arg1 `function_name` arg2 =
let f_pattern1 = '\zs'.func_name.'\ze\%(\s\+\w\+\)*\s*='
let f_pattern2 = '\w\+\s*`\zs\w\+\ze`\s*\w\+\s*='
let f_pattern = '^\s*\%(\%('.f_pattern1.'\)\|\%('.f_pattern2.'\)\)'
let result = {}
for line_nr in range(0,len(a:file)-1)
let line = a:file[line_nr]
if line =~ no_f_pattern
continue
endif
if line =~ f_pattern
let result[matchstr(line, f_pattern1)]={impl: line_nr}
endif
endfor
add type declarations.. doesn't recognize lists (a, b :: ) yet.
Is needed to get the function names eg of
newtype Cont r a = Cont { runCont :: (a - r) - r }
let type_pattern =
'\zs\('.func_name.'\)\%(\s*,\s*\%('.func_name.'\)\)*\ze\s*::'
let g:tp = type_pattern
for line_nr in range(0,len(a:file)-1)
let line = a:file[line_nr]
if line =~ type_pattern
let list = split(matchstr(line, type_pattern),'\s*,\s*')
for func_name in list
if exists(result['.func_name.'])
let result[func_name]['type'] = line_nr
else
let result[func_name]={type: line_nr}
endif
endfor
endif
endfor
return result
endfunction
Re: Autocommand-Event for Clipboard-Changed
On 10/3/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Bram Moolenaar wrote: Suresh Govindachar wrote: Is it possible to add an autocommand-event for Clipboard Changed? Not really. This is not something that happens inside Vim. Polling for changes in the system is not really something I would like to add to Vim. Bram -- would you be willing to give out a bit of code that will send a remote message to vim? Some function, perhaps SendCmd2Vim(string). That way it'll be simple for folks to make their own external programs to send a command to vim via the already available remote vim stuff. Charles, What's wrong with doing system(vim --remote-xxx yyy zzz) in any programming language ? Yakov
Re: compilation of regular expressions/ enhancement?
Marc Weber wrote:
Hi Tony.
Of course this was a trivial example.
I was grepping the output of jar - content-texfile to find the packages
of a java-class.
Currently I'm using this function.
I'm invoking this function for up to 40 files or more.. That depends on
how many modules I have imported.
let type_pattern =
'\zs\('.func_name.'\)\%(\s*,\s*\%('.func_name.'\)\)*\ze\s*::'
if line =~ type_pattern
This is no longer that simple.
But I can do a deepcopy and use filter.. But then I'll no longer able to get
the line numbers..
My question was meant to be more general as my example given in the last
post.
Greetings Marc
When you don't need backrefs, use \%( rather than \( -- it may be marginally
faster.
I still don't see the advantage of compiling regexps while scripts remain
interpreted.
Best regards,
Tony.
Re: compilation of regular expressions/ enhancement?
On 10/3/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: I still don't see the advantage of compiling regexps while scripts remain interpreted. Well, storing the compiled regex is surely a lot faster. However, I don't think that's the way to do it for VimScript, as it isn't really parsed, it's just executed line-by-line. What /would/ make sense is to cache the compiled regexes so that regexes used in a loop won't have to be compiled as often. That's a fairly trivial fix, although I'm not going to perform it. nikolai
Re: Do Not Reply To This Message
A.J.Mechelynck wrote: [snip] The problem is, not only the KNBT pseudo-bounce is misdirected, it is incomplete. In particular, it doesn't say which address was not found, so all Felix (or Bram or someone) can know is that someone @knbt.com is no longer a valid address. But they can't go forcibly unsubscribing _every_ @knbt.com subscriber, can they? Quite probably there are more than one. Anyone knows how much of [EMAIL PROTECTED] are subscribed ? If they are not many we can even do manual check(s)... Best regards, Tony. -- For robots (please don't mail me there): [EMAIL PROTECTED] My real email is ilya @ same domain
Re: Autocommand-Event for Clipboard-Changed
Hi Charles, On 10/3/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Bram Moolenaar wrote: Suresh Govindachar wrote: Is it possible to add an autocommand-event for Clipboard Changed? Not really. This is not something that happens inside Vim. Polling for changes in the system is not really something I would like to add to Vim. Bram -- would you be willing to give out a bit of code that will send a remote message to vim? Some function, perhaps SendCmd2Vim(string). That way it'll be simple for folks to make their own external programs to send a command to vim via the already available remote vim stuff. Presumably the code snippet wouldn't be a Part of Vim itself; maybe something for vim.sf.net? Just an idea... Chip Campbell Are you referring to a sample code similar to the xcmdsrv_client.c file under the $VIM/tools directory? This sample code shows how to send commands to a remote Vim from a C program in Unix systems running X-Windows. A similar sample code for MS-Windows is needed. - Yegappan
Re: [macvim] modifiers should be applied to special keys too (patch)
Hi, I tried the patch, but it appears that CTRL-F and CTRL-B no longer work in Normal mode. They do something in Insert mode after CTRL-V. CTRL-F and CTRL-B work for me in Normal mode (they scroll forward/ backward). I'm using mac gvim svn (patches 1-110) and the second version of my patch. Can you give more detailed instructions on how to reproduce the problem? It looks like this patch needs more careful testing. Perhaps you should make a list of keys with various modifiers that need to be tried to verify the code works correctly. I made a small list ( http://macvim.blogspot.com/2006/10/keyboard- handling-patch.html ), I'll add further items as problems arise. Bye, Nico
Re: Autocommand-Event for Clipboard-Changed
Yegappan Lakshmanan wrote: Are you referring to a sample code similar to the xcmdsrv_client.c file under the $VIM/tools directory? This sample code shows how to send commands to a remote Vim from a C program in Unix systems running X-Windows. A similar sample code for MS-Windows is needed. Looks like Bram is a precognitive! Yep, that's what I meant. Regards, Chip Campbell
Re: compilation of regular expressions/ enhancement?
Marc Weber wrote: When doing something like map([a,b],matchstr(v:val, \(.\))) will the regular expression \(.\) be compiled on every iteration? How about this: for l in lines if l =~regex ... ? How about :help profile ? ;) [...]
Re: Time to remove naming restrictions?
On Tue, 3 Oct 2006 at 10:30am, A.J.Mechelynck wrote: Nikolai Weibull wrote: On 10/1/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: One thing that really annoys me with Vim is the limits it emposes on what names are legal for user-defined functions and commands. I know the reason for these restrictions, but I don't think they make much sense, especially so for user-defined commands. I realize that overriding :quit does have its implications, but done carefully, this does allow for some interesting effects. So, why not lift the restrictions on valid names for user-defined functions and commands? That is, give me good reasons for why they should be maintained and I'll drop this request. Predictability. As in what? That :quit always works as documented? Sure, that's great, but if that's the problem, the restriction should be limited to commands already defined. And what happens when more commands are added? Hell, then they'll break the user-defined commands with the same name. Big deal; that's life, you'll get over it - everyone does, eventually. I really don't see the big difference between user-defined commands clashing with built-in commands and user-defined commands clashing with each other. It'll happen; unless you start adding prefixes or namespaces or some other way of separating your commands. But then you lose out on simplicity. You don't want to type :NOWCommand (given that NOW is my prefix), and I don't want to type :Command; I want to type :command. Sure, it only saves my fingers from giving up on me for so long, but every little bit helps. I guess my problem is that I want - and I've always wanted - the flexibility of Emacs coupled with the simplicity and efficiency of Vim's command set and modes. I guess that's why I nitpick at things such as this. nikolai :command -bar Command ... :cabbrev command Command and then you'll wonder why you can't define a new user-command but it's your funeral. It's still not perfect though; the cabbrev will be expanded even if it's not at the start (but that may be not-so-bad if you use :verbose command, :vertical command, etc.) Best regards, Tony. You can use the Vim7 expr abbreviation in combination of getcmdpos() and getcmdtype() to make this a lot more reliable, and avoid expanding everywhere. I have created the cmdalias.vim plugin (http://www.vim.org/script.php?script_id=745) just to address this problem (as it bothered me as well). The only case this breaks is the debug mode because of a bug in Vim (the expression itself is executed in the debug mode). Another oddity in using this approach is the history. If you execute: :command what will end up getting stored in the history is: :Command which means you have to remember to use the righ case while retrieving the last command (:comUp will not work). -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Time to remove naming restrictions?
On 10/3/06, Hari Krishna Dara [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: One thing that really annoys me with Vim is the limits it emposes on what names are legal for user-defined functions and commands. Another oddity in using this approach is the history. If you execute: :command what will end up getting stored in the history is: :Command which means you have to remember to use the righ case while retrieving the last command (:comUp will not work). Argh. This is exactly why all the hacks one has to employ never really quite make it. There's always some base you haven't covered, some point you can't reach. Seriously, if people want to f**k up their session, let them. No one who isn't prepared to get burned is going to override :quit. No one who isn't prepared for an unpredictable future (is there a second kind?) is going to install a plugin that adds a command called :vfold. Let us who really want our Vim to be what we want it to be have the tools to make it so. I'm obviously not the only person who feels this way. And I haven't even spent time writing a plugin to circumvent this, like Hari has. nikolai
Chaining of function calls
So you can't write :call object.method().results_method() in VimScript. But it would be sweet if one could. Can't find anything in the TODO on this. Any plans for the future? nikolai
Re: Chaining of function calls
On 10/3/06, Nikolai Weibull [EMAIL PROTECTED] wrote: So you can't write :call object.method().results_method() in VimScript. But it would be sweet if one could. Can't find anything in the TODO on this. Any plans for the future? But you can write :let _ = object.method().results_method() Sort of an ugly hack, though, if you don't care about results_method()s result (or it doesn't have one). nikolai
Re: Chaining of function calls
On 10/3/06, Nikolai Weibull [EMAIL PROTECTED] wrote: On 10/3/06, Nikolai Weibull [EMAIL PROTECTED] wrote: So you can't write :call object.method().results_method() in VimScript. But it would be sweet if one could. Can't find anything in the TODO on this. Any plans for the future? But you can write :let _ = object.method().results_method() And of course :call call(object.method().results_method) but that's plain horrendous under the circumstances. Sorry about the IRC-session-style messages. I'll stop now. nikolai
Re: Time to remove naming restrictions?
Argh. This is exactly why all the hacks one has to employ never really quite make it. There's always some base you haven't covered, some point you can't reach. Seriously, if people want to f**k up their session, let them. No one who isn't prepared to get burned is going to override :quit. No one who isn't prepared for an unpredictable future (is there a second kind?) is going to install a plugin that adds a command called :vfold. Let us who really want our Vim to be what we want it to be have the tools to make it so. I'm obviously not the only person who feels this way. And I haven't even spent time writing a plugin to circumvent this, like Hari has. There's about 4 lines of vim source code which you need to remove so that you can have lower-case user commands. You're not interested in making your own patch? regards, Peter On Yahoo!7 Messenger - IM with Windows Live Messenger friends. http://au.messenger.yahoo.com
