RE: More ^P/^N weirdness
Bram and Aaron,
Bram wrote:
> > I'm still finding the ^P/^N behaviour in insert mode kind of annoying.
> > I just did something like this:
> > - Edit a file with the text "numMatches" in it.
> > - Type "numMb" and hit ^P.
> > - It's a typo so no matches come up. In the meantime vim starts
> > madly searching through header files in the background.
> > - Hit , then "a" to give the text "numMa".
> > - Now it should find the right match. Vim still seems to be
> > searching in the background. Is it supposed to find the correct
> > match now straight away? It doesn't. Or is it up to me to hit
> > ^P again?
> > - If I hit ^P again, nothing happens. I can repeatedly hit it and
> > no matches are found and no menu appears (note: all this is
> > still while vim is searching in the background). In 6.3 this
> > would have given me the right match.
> > - So instead I try ^N. Now a menu appears with my original text
> > ("numMa") and the match I want ("numMatches"), but no matter how
> > many times I hit ^N it just stays stuck on the first item which
> > was my original text! It's stuck again in a similar way to what
> > I described in another email.
> >
> > What is supposed to happen when you hit then hit another letter
> > during completion mode?
>
> What version are you using? I fixed a problem with just before
> sending out Vim 7.
Yes, you did fix something, but the description above is what I saw in
the final 7.0 release.
Aaron wrote:
> > I still think ^N/^P should wrap around the matches found so far
> > while vim is searching in the background.
>
> This is not a new feature in vim7. This has been in the codebase
> for a while.
Previously searching in the background only began after using ^N/^P
enough times that all matches from the current file (and other open
buffers) had already been found. ^N/^P would work as you might expect
until then. You could ^N to get the following match, then ^P a couple
of times to get the previous match. Now this doesn't work while the
background searching is going on.
Would still really like an option to turn off the display of file
names that race past during the background search too. The only
reason for seeing this kind of thing is when it happens in the
foreground, so that you know vim is busy but making progress and soon
you'll be able to type again. When it happens in the background it's
not holding you up, and should keep what it's doing to itself. It's
good that it happens in the background, it's not so good that it tells
you about it in the foreground. Your eyes are automatically drawn to
areas where things are changing, but it's an unnecessary distraction.
Thanks,
Rob.
--
Robert Webb <[EMAIL PROTECTED]>,
Want to make polyhedra?
http://www.software3d.com/Stella.html
SVN and svn:eol-style
Hello Vim Developers, When I checkout vim7 with svn under WinXP Pro, my text files are all coming out as UNIX files (using LF instead of CR/LF). The svn program is designed to handle proper EOL for an operating system when a property called svn:eol-stype is set to "native". Am I supposed to do anything special to cause svn to give my text files to be stored as standard CR/LF files? -- Best regards, Bill
vim7 possible bug
All, Assume the buffer is as follows (between quotes): " Rabbits are really great rats are not so great ra " Now if my cursor is after the "ra" on the third line, and I do a c-n to see keyword completions, the "ra" disappears when the menu comes up. Is this desired? --Matt P.S. I know that bug reporting should have been before the release, but I just discovered this.
Re: Patch 7.0.001
Hi all, On 5/10/06, Gautam Iyer <[EMAIL PROTECTED]> wrote: On Tue, May 09, 2006 at 02:37:08PM +0200, Bram Moolenaar wrote: > Patch 7.0.001 > Problem:":set spellsuggest+=10" does not work. (Suresh Govindachar) > Solution: Add P_COMMA to the 'spellsuggest' flags. > Files: src/option.c Hi Bram, Will your patches be in the subversion source tree? I recently ran "svn update", and found no changes from vim7... Unfortunately sourceforge had encountered some unknown errors and I'm not able to log in to the CVS repository these two days. I'm trying to contact the administrators of sourceforge. But if this problem could not be resolved, I'll try to sync the code with the patches manually. Thanks, Gautam -- 'Common' Proof Techniques: 12. Proof by obfuscation -- A long plotless sequence of true and/or meaningless syntactically related statements. Regards, Edward L. Fox
Re: Behavior of synIDattr() varies
Yakov,
Yes. .vimrc and contents of ~/.vim would be different in two cases,
because $HOME is different. For example, if you have 'colorscheme
darkbrown' in your $HOME/.vimrc, this is probably missing or different
in the httpd $HOME
environment.
You need to find out value of $HOME in
the httpd environment and copy your ~/.vimrc to there,
(and maybe ~/.vim, too).
Tried that, but I use the standard color scheme so it didn't change
much. su'ing to the http user and executing 2html.vim from the shell
works as it should.
If that fails, I'd try to add $ENV{TERM}='xterm' to perl
syscall, or system("env TERM=xterm vim ...");
In theory, '-T xterm' is the same, as setting env.var. $TERM,.
but what if it's not ?
Interesting. I've added two lines to 2html.vim:
exe "normal! a$TERM is "
exe "normal! a".$TERM."\n"
to print out the used terminal on the generated XHTML document.
A "vim -T xterm -e [...]" perl syscall didn't force $TERM=xterm, but
$ENV{TERM}='xterm' did. -T still seemed to force xterm to be used
despite $TERM behind the scenes.
Despite all that, a mod_perl syscall backed synIDattr() still maps two
different regions to the same fg ID that are mapped to different ones in
a shell backed vim instance.
Thanks,
Thomas
Re: Omni-completion howto?
On 5/8/06, Robert Webb <[EMAIL PROTECTED]> wrote: I was also expecting there to be C++ support, but only C support is provided. Surely C++ is in wider use than C these days? There is a plugin you can download separately for this however: http://www.vim.org/scripts/script.php?script_id=1520 There is no c++ support because no one has completed it. Bram writes vim in C. As such, he made the C omnifunc. C++ is _much_ more complicated due to namespaces, class hierarchies, static functions, 'this' and many many more things. Feel free to help out with the C++ omni completion plugin if you'd like it to work.
Re: Patch 7.0.001
On Tue, May 09, 2006 at 02:37:08PM +0200, Bram Moolenaar wrote: > Patch 7.0.001 > Problem:":set spellsuggest+=10" does not work. (Suresh Govindachar) > Solution: Add P_COMMA to the 'spellsuggest' flags. > Files: src/option.c Hi Bram, Will your patches be in the subversion source tree? I recently ran "svn update", and found no changes from vim7... Thanks, Gautam -- 'Common' Proof Techniques: 12. Proof by obfuscation -- A long plotless sequence of true and/or meaningless syntactically related statements.
Re: Bug: :cn doesn't open folds when rhs of map
On 2006-05-09, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > Gary Johnson wrote: > > > Summary: > > > > By default, :cn should open a closed fold, and when executed as > > ":cn", it does so. But when :cn is the rhs of a map and the lhs > > of the map is typed, closed folds do not open. I think :cn > > should behave the same whether executed directly or as part of a > > map. > > Nope. If you make a mapping you need to open folds in the mapping. > > It's done this way to make it possible to move around in a mapping > without folds opening everywhere. It's simple to open a fold when you > want to. OK, I can understand that. Per Nikolai's suggestion, I added zv at the end of the mappings, which seems to work fine. Thank you both. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: 7.0 administrivia
> > Bram, what happens to Vim if you are suddenly incapacitated? Look at > > Exuberant Ctags: it's been in limbo for many months, since Darren > > Hiebert went AWOL. It seems like there's a lot of stuff that only you > > have the permissions to do. > > If my plain crashes then there might be a bit of a problem :-). With > Darren the problem also is that he is still there, just doesn't have > time to work on ctags. You can't take over a project if the author is > still there and doesn't release it. And it's not so easy to give away > your baby. I wouldn't think of it as 'giving away your baby', more like 'sending it off to school'. To risk over-extending a metaphor (too late!), but you've got to let vim expand and grow through other tutors, other environments, other ideas.. Maybe, who knows, one day vim will grow up, find a nice IDE and settle down.. ;-) Well, ok, enough with the metaphors, but I think an apprentice vim maintainer/pumpking or two wouldn't hurt. You'd retain final control, but not be the sole focus for vim development. And as long as your apprentices were on the same wavelength as to where you'd want to go with vim, there's no reason why vim should stray from the vision that you've set for it. (plus, having dictatorial powers in the case of a disagreement is always a nice thing..) Ed
Re: Bug: :cn doesn't open folds when rhs of map
Gary Johnson wrote: > Summary: > > By default, :cn should open a closed fold, and when executed as > ":cn", it does so. But when :cn is the rhs of a map and the lhs > of the map is typed, closed folds do not open. I think :cn > should behave the same whether executed directly or as part of a > map. Nope. If you make a mapping you need to open folds in the mapping. It's done this way to make it possible to move around in a mapping without folds opening everywhere. It's simple to open a fold when you want to. -- hundred-and-one symptoms of being an internet addict: 78. You find yourself dialing IP numbers on the phone. /// 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: More ^P/^N weirdness
Robert Webb wrote;
> I'm still finding the ^P/^N behaviour in insert mode kind of annoying.
> I just did something like this:
> - Edit a file with the text "numMatches" in it.
> - Type "numMb" and hit ^P.
> - It's a typo so no matches come up. In the meantime vim starts
> madly searching through header files in the background.
> - Hit , then "a" to give the text "numMa".
> - Now it should find the right match. Vim still seems to be
> searching in the background. Is it supposed to find the correct
> match now straight away? It doesn't. Or is it up to me to hit
> ^P again?
> - If I hit ^P again, nothing happens. I can repeatedly hit it and
> no matches are found and no menu appears (note: all this is
> still while vim is searching in the background). In 6.3 this
> would have given me the right match.
> - So instead I try ^N. Now a menu appears with my original text
> ("numMa") and the match I want ("numMatches"), but no matter how
> many times I hit ^N it just stays stuck on the first item which
> was my original text! It's stuck again in a similar way to what
> I described in another email.
>
> What is supposed to happen when you hit then hit another letter
> during completion mode?
What version are you using? I fixed a problem with just before
sending out Vim 7.
> I still think ^N/^P should wrap around the matches found so far while
> bim is searching in the background.
I didn't look into this, it's too complicated to fix just before a
release.
--
hundred-and-one symptoms of being an internet addict:
76. Your ISP regards you as a business partner rather than as a customer.
/// 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: Bug: :cn doesn't open folds when rhs of map
On 5/9/06, Gary Johnson <[EMAIL PROTECTED]> wrote:
By default, :cn should open a closed fold, and when executed as
":cn", it does so. But when :cn is the rhs of a map and the lhs
of the map is typed, closed folds do not open. I think :cn
should behave the same whether executed directly or as part of a
map.
Sadly, this isn't the case. I can't remember the specifics, but I've
discussed this with Bram. One solution is to add 'zv' at the end of
the mapping, as this will show the fold.
Perhaps you can use the new feedkeys()-function, using 'nt' for
{mode}, as 't' makes sure that the keys get interpreted as if typed
(and the 'n' makes sure they aren't remapped).
Actually, this gives me an idea to fix the mapping that I had to add 'zv' to:
noremap k :call feedkeys('n', 'nt')
(I use DVORAK, and I've swapped 't', 'n', and 's' with 'j', 'k', and 'l'.)
Thanks!
n.o.w.
Bug: :cn doesn't open folds when rhs of map
Summary: By default, :cn should open a closed fold, and when executed as ":cn", it does so. But when :cn is the rhs of a map and the lhs of the map is typed, closed folds do not open. I think :cn should behave the same whether executed directly or as part of a map. This behavior is the same in Vim-7.0 and Vim-6.4. I just noticed it now because I'm starting to work with some file types that open with folds initially closed. The behavior is also the same in vim built for SunOS 5.8 and in gvim on Windows XP. Replication Instructions: 1. Create the following test file, mary. --- cut here --- Mary had a little lamb, Its fleece was white as snow, And everywhere that Mary went, The lamb was sure to go. It followed her to school one day, Which was against the rule, And made the children laugh and play To see a lamb at school. --- cut here --- 2. Start vim in the same directory as mary. vim -N -u NONE 3. Execute the following vim commands. map :cn set foldmethod=expr set foldexpr=getline(v:lnum)!~'^$' grep lamb mary The foldexpr makes each paragraph a fold. 4. The file opens with the first paragraph/fold open and the second paragraph/fold closed, as it should. 5. Type twice. The second paragraph/fold remains closed. I believe this is a bug. 6. Execute :cp :cn The second paragraph/fold is now opened, as it should be. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: More ^P/^N weirdness
On 5/9/06, Robert Webb <[EMAIL PROTECTED]> wrote: I'm still finding the ^P/^N behaviour in insert mode kind of annoying. I still think ^N/^P should wrap around the matches found so far while bim is searching in the background. This is not a new feature in vim7. This has been in the codebase for a while. :help 'complete
RE: More ^P/^N weirdness
> Vim did not seem to search madly for matches, This happens when editing a C file with lots of header files included. Then it goes searching through all the system include files etc. It's during this process that completion acts weird. Takes about 16 seconds for the files I'm editing. Rob. -- Robert Webb <[EMAIL PROTECTED]>, Want to make polyhedra? http://www.software3d.com/Stella.html
Re: 7.0 administrivia
On 5/9/06, Matthew Winn <[EMAIL PROTECTED]> wrote:
On Tue, May 09, 2006 at 04:44:32PM +0200, Nikolai Weibull wrote:
> On 5/9/06, Matthew Winn <[EMAIL PROTECTED]> wrote:
> >On Tue, May 09, 2006 at 02:02:24PM +0200, Nikolai Weibull wrote:
> >> Well, there's always the following algorithm to consider:
> >>
> >> if (bram_is_unreasonable) {
> >> int new_child = fork();
> >> if (new_child) {
> >>// Let Bram continue in his thought-process
> >>return;
> >> }
> >>
> >> // Ah, this is now our little baby
> >> :
> >> :
> >> }
> >
> >And if fork() returns -1?
>
> It's obvious, isn't it?
Yes. The poor little baby never gets conceived. You should at least
issue a warning, or possibly loop until conception occurs.
A joke gets so much funnier the more you explain it, so here it goes.
If fork() returned -1, the baby was aborted, i.e., the fork of Vim was
aborted.
There, now it's a lot more fun.
n.o.w.
Re: 7.0 administrivia
On Tue, May 09, 2006 at 04:44:32PM +0200, Nikolai Weibull wrote:
> On 5/9/06, Matthew Winn <[EMAIL PROTECTED]> wrote:
> >On Tue, May 09, 2006 at 02:02:24PM +0200, Nikolai Weibull wrote:
> >> Well, there's always the following algorithm to consider:
> >>
> >> if (bram_is_unreasonable) {
> >> int new_child = fork();
> >> if (new_child) {
> >>// Let Bram continue in his thought-process
> >>return;
> >> }
> >>
> >> // Ah, this is now our little baby
> >> :
> >> :
> >> }
> >
> >And if fork() returns -1?
>
> It's obvious, isn't it?
Yes. The poor little baby never gets conceived. You should at least
issue a warning, or possibly loop until conception occurs.
P.S. Don't try this with vfork().
--
Matthew Winn ([EMAIL PROTECTED])
Re: 7.0 administrivia
On 5/9/06, Matthew Winn <[EMAIL PROTECTED]> wrote:
On Tue, May 09, 2006 at 02:02:24PM +0200, Nikolai Weibull wrote:
> Well, there's always the following algorithm to consider:
>
> if (bram_is_unreasonable) {
> int new_child = fork();
> if (new_child) {
>// Let Bram continue in his thought-process
>return;
> }
>
> // Ah, this is now our little baby
> :
> :
> }
And if fork() returns -1?
It's obvious, isn't it?
n.o.w.
P.S.
If not, then consider the boolean value -1 has in C.
D.S.
Re: More ^P/^N weirdness
On Tue, May 09, 2006 at 11:27:02PM +1000, Robert Webb wrote:
> I'm still finding the ^P/^N behaviour in insert mode kind of annoying.
> I just did something like this:
> - Edit a file with the text "numMatches" in it.
> - Type "numMb" and hit ^P.
> - It's a typo so no matches come up. In the meantime vim starts
> madly searching through header files in the background.
> - Hit , then "a" to give the text "numMa".
> - Now it should find the right match. Vim still seems to be
> searching in the background. Is it supposed to find the correct
> match now straight away? It doesn't. Or is it up to me to hit
> ^P again?
> - If I hit ^P again, nothing happens. I can repeatedly hit it and
> no matches are found and no menu appears (note: all this is
> still while vim is searching in the background). In 6.3 this
> would have given me the right match.
> - So instead I try ^N. Now a menu appears with my original text
> ("numMa") and the match I want ("numMatches"), but no matter how
> many times I hit ^N it just stays stuck on the first item which
> was my original text! It's stuck again in a similar way to what
> I described in another email.
>
> What is supposed to happen when you hit then hit another letter
> during completion mode?
>
> I still think ^N/^P should wrap around the matches found so far while
> bim is searching in the background.
I tried this (using a different "wrong" character since this e-mail
contains "numMb" in it). Vim did not seem to search madly for matches,
but I did notice one annoyance. After I got to the "numMa" stage, the
completion menu shoed two options: "numMa" and "numMatches", but
neither was highlighted. Hitting cycled through three states:
one or the other option was highlighted, or neither. Two of these
options have the same text, "numMa", in the buffer.
HTH --Benji Fisher
P.S. There have been times when hitting removed characters that I
had typed, and I had to re-type them. I have not been able to figure
out how to reproduce this. :-(
Re: 7.0 administrivia
On Tue, May 09, 2006 at 02:02:24PM +0200, Nikolai Weibull wrote:
> Well, there's always the following algorithm to consider:
>
> if (bram_is_unreasonable) {
> int new_child = fork();
> if (new_child) {
>// Let Bram continue in his thought-process
>return;
> }
>
> // Ah, this is now our little baby
> :
> :
> }
And if fork() returns -1?
--
Matthew Winn ([EMAIL PROTECTED])
More ^P/^N weirdness
I'm still finding the ^P/^N behaviour in insert mode kind of annoying.
I just did something like this:
- Edit a file with the text "numMatches" in it.
- Type "numMb" and hit ^P.
- It's a typo so no matches come up. In the meantime vim starts
madly searching through header files in the background.
- Hit , then "a" to give the text "numMa".
- Now it should find the right match. Vim still seems to be
searching in the background. Is it supposed to find the correct
match now straight away? It doesn't. Or is it up to me to hit
^P again?
- If I hit ^P again, nothing happens. I can repeatedly hit it and
no matches are found and no menu appears (note: all this is
still while vim is searching in the background). In 6.3 this
would have given me the right match.
- So instead I try ^N. Now a menu appears with my original text
("numMa") and the match I want ("numMatches"), but no matter how
many times I hit ^N it just stays stuck on the first item which
was my original text! It's stuck again in a similar way to what
I described in another email.
What is supposed to happen when you hit then hit another letter
during completion mode?
I still think ^N/^P should wrap around the matches found so far while
bim is searching in the background.
Thanks,
Rob.
--
Robert Webb <[EMAIL PROTECTED]>,
Want to make polyhedra?
http://www.software3d.com/Stella.html
Patch 7.0.001
Patch 7.0.001
Problem:":set spellsuggest+=10" does not work. (Suresh Govindachar)
Solution: Add P_COMMA to the 'spellsuggest' flags.
Files: src/option.c
*** ../vim-7.0.000/src/option.c Wed May 3 23:26:04 2006
--- src/option.cSun May 7 17:54:46 2006
***
*** 2294,2300
{(char_u *)0L, (char_u *)0L}
#endif
},
! {"spellsuggest", "sps", P_STRING|P_VI_DEF|P_EXPAND|P_SECURE,
#ifdef FEAT_SPELL
(char_u *)&p_sps, PV_NONE,
{(char_u *)"best", (char_u *)0L}
--- 2294,2300
{(char_u *)0L, (char_u *)0L}
#endif
},
! {"spellsuggest", "sps", P_STRING|P_VI_DEF|P_EXPAND|P_SECURE|P_COMMA,
#ifdef FEAT_SPELL
(char_u *)&p_sps, PV_NONE,
{(char_u *)"best", (char_u *)0L}
*** ../vim-7.0.000/src/version.cWed May 3 00:04:24 2006
--- src/version.c Tue May 9 14:23:20 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 1,
/**/
--
hundred-and-one symptoms of being an internet addict:
70. ISDN lines are added to your house on a hourly basis
/// 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: 7.0 administrivia
On 5/9/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> Bram, what happens to Vim if you are suddenly incapacitated? Look at
> Exuberant Ctags: it's been in limbo for many months, since Darren
> Hiebert went AWOL. It seems like there's a lot of stuff that only you
> have the permissions to do.
If my plain crashes then there might be a bit of a problem :-). With
Darren the problem also is that he is still there, just doesn't have
time to work on ctags. You can't take over a project if the author is
still there and doesn't release it. And it's not so easy to give away
your baby.
Well, there's always the following algorithm to consider:
if (bram_is_unreasonable) {
int new_child = fork();
if (new_child) {
// Let Bram continue in his thought-process
return;
}
// Ah, this is now our little baby
:
:
}
Peace.
n.o.w.
Re: vim7 & SID
Thomas wrote:
> I noticed that code like this stops working in vim7:
>
> fun! FooBar()
> echom 1
> endf
>
> let x = "Bar"
> call Foo{x}()
>
> Is this intentional? I quickly scanned through version7.txt but didn't
> find any info on this -- at least nothing I think of referring to this
> problem.
Please try out this patch and check for any side effects:
*** ../../vim-7.0/src/eval.cSun May 7 17:53:33 2006
--- eval.c Tue May 9 12:50:26 2006
***
*** 18963,18969
else if (lead > 0)
{
lead = 3;
! if (eval_fname_sid(lv.ll_exp_name != NULL ? lv.ll_exp_name : *pp))
{
/* It's "s:" or "" */
if (current_SID <= 0)
--- 18963,18970
else if (lead > 0)
{
lead = 3;
! if ((lv.ll_exp_name != NULL && eval_fname_sid(lv.ll_exp_name))
! || eval_fname_sid(*pp))
{
/* It's "s:" or "" */
if (current_SID <= 0)
--
hundred-and-one symptoms of being an internet addict:
67. Your hard drive crashes. You haven't logged in for two hours. You start
to twitch. You pick up the phone and manually dial your ISP's access
number. You try to hum to communicate with the modem. You succeed.
/// 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: conceal patch
Hi All, 1) Yes, it is still maintained, both against 6.4 and the new vim 7 tree. 2) However, the recent SF CVS outage has prevented me generating a up-to-date patch. (I've been too busy to have time to migrate over to subversion) Once SF's anon CVS is back online and synched, I'll be able to post up-to-date patches for 6.4 and 7. 3) I have obtained new webspace for hosting the patches, but this will have to wait until (2) above! 4) The patch does roughly the same thing on vim 7, except that the "ownsyntax" feature also allows you to set a different spelllang as well as a different syntax. Possibly useful for bilingual comments? :) Nicholas Cole wrote: > V. exciting that vim 7 is out. Does anyone know if the Conceal patch > is still maintained, and if it works with vim 7? I know at some point > there were hopes it might become official > > Best wishes, > > N. >
Re: vim7 & SID
Thomas wrote:
> I noticed that code like this stops working in vim7:
>
> fun! FooBar()
> echom 1
> endf
>
> let x = "Bar"
> call Foo{x}()
>
> Is this intentional? I quickly scanned through version7.txt but didn't
> find any info on this -- at least nothing I think of referring to this
> problem.
This is not an intentional change. If you replace by s: then it
works again.
--
hundred-and-one symptoms of being an internet addict:
60. As your car crashes through the guardrail on a mountain road, your first
instinct is to search for the "back" button.
/// 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: 7.0 administrivia
George Reilly wrote: > Congratulations on releasing Vim 7.0! It's been a long time coming, > but worth the wait. > > According to http://en.wikipedia.org/wiki/Vim_(text_editor) it's been > almost five years since Vim 6.0 was released. I hadn't realized it had > been so long. At what point did Vim 7.0 development start, as distinct > from the development of Vim 6.1 - 6.4? I would say after 6.3 was released. That was a bugfix version, I worked away a lot of outstanding problems before I started adding new features. That was in June 2004. > Bram, what happens to Vim if you are suddenly incapacitated? Look at > Exuberant Ctags: it's been in limbo for many months, since Darren > Hiebert went AWOL. It seems like there's a lot of stuff that only you > have the permissions to do. If my plain crashes then there might be a bit of a problem :-). With Darren the problem also is that he is still there, just doesn't have time to work on ctags. You can't take over a project if the author is still there and doesn't release it. And it's not so easy to give away your baby. -- Creating the world with Emacs: M-x let-there-be-light Creating the world with Vim: :make world /// 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///
vim7 & SID
Hi,
I noticed that code like this stops working in vim7:
fun! FooBar()
echom 1
endf
let x = "Bar"
call Foo{x}()
Is this intentional? I quickly scanned through version7.txt but didn't
find any info on this -- at least nothing I think of referring to this
problem.
Cheers,
Thomas.
Re: conceal patch
Nicholas Cole wrote: V. exciting that vim 7 is out. Does anyone know if the Conceal patch is still maintained, and if it works with vim 7? I know at some point there were hopes it might become official Best wishes, N. Sorry, I don't know anything about the Conceal patch, but I am very curious on why do you need the patch and how do you use vim with the patch? Best Regards, Vincent
