Re: BOF Vim 8 - Suggestions
Marcus Aurelius wrote: [...] If the user wants to edit long lines, (s)he cannot write a quick mapping on-the-fly, because he needs something like this: map buffer silent up gk imap buffer silent up C-ogk map buffer silent down gj imap buffer silent down C-ogj map buffer silent home ghome imap buffer silent home C-oghome map buffer silent end gend imap buffer silent end C-ogend ***May i suggest a new command (or a standard plugin that is easy to find) that would do all of the above in one easy step?*** Optionally, the user could want this too: setlocal linebreak setlocal nolist Necessary for linebreak setlocal display+=lastline I'm not sure if it's OK or if it's going too far :-) [...] The following (among others) are set once and for all in my vimrc: set nojoinspaces set selection=inclusive keymodel=startsel set mousemodel=popup selectmode=mouse,key set laststatus=2 set display=lastline set list listchars=tab:\|_,eol:¶ silent! set listchars+=nbsp:~ Up, Down move up/down by screen lines j k (default) move down/up by file lines map Down gj imapDown C-Ogj map Upgk imapUpC-Ogk No problem for me, and no need to change them from file to file. Best regards, Tony.
Re: BOF Vim 8 - Suggestions
Georg Dahn wrote: Hi! --- A.J.Mechelynck [EMAIL PROTECTED] wrote: map Down gj imapDown C-Ogj map Upgk imapUpC-Ogk IMHO these mappings are a better choice: noremap Down gj noremap Up gk inoremap expr Down pumvisible() ? \ltDown : \ltC-Ogj inoremap expr Up pumvisible() ? \ltUp : \ltC-Ogk These two are V7 only, so: if exists(*pumvisible) inoremap expr Down pumvisible() ? \ltDown : \ltC-Ogj inoremap expr Up pumvisible() ? \ltUp : \ltC-Ogj else inoremap Down C-Ogj inoremap Up C-Ogk endif With this the cursor keys still work with the popup menu. In addition I define the following mappings: noremap S-Down gj noremap S-Up gk inoremap S-Down C-OghC-Ogj inoremap S-Up C-OghC-Ogk nnoremap S-Down ghC-Ogj nnoremap S-Up ghC-Ogk With these mappings invoking the selection mode works more consistently with above mappings. No problem for me, and no need to change them from file to file. I fully agree with this. Best wishes, Georg Best regards, Tony.
Re: BOF Vim 8 - Suggestions
--- A.J.Mechelynck [EMAIL PROTECTED] escreveu: Georg Dahn wrote: Hi! --- A.J.Mechelynck [EMAIL PROTECTED] wrote: These two are V7 only, so: if exists(*pumvisible) inoremap expr Down pumvisible() ? \ltDown : \ltC-Ogj inoremap expr Up pumvisible() ? \ltUp : \ltC-Ogj else inoremap Down C-Ogj inoremap Up C-Ogk endif (...) noremap S-Down gj noremap S-Up gk inoremap S-Down C-OghC-Ogj inoremap S-Up C-OghC-Ogk nnoremap S-Down ghC-Ogj nnoremap S-Up ghC-Ogk With these mappings invoking the selection mode works more consistently with above mappings. This is getting complicated... That's why i suggested a single command that unified all of this, and would not conflict with pop-up menus or anything. __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/
7.0.188 - problem with directory browser?
hello, in version 7.0.188 (I am on windows xp, us) nothing works when I select '..' when browsing a directory. has anyone seen this? is this something peculiar to my installation, a bug, or a feature? thanks! -- // mailto: Denis Perelyubskiy lists at overwhelmTAKECAPITALSOUT dot net // icq : 12359698
Re: 7.0.188 - problem with directory browser?
On Fri 26-Jan-07 10:46pm -0600, Denis Perelyubskiy wrote: in version 7.0.188 (I am on windows xp, us) nothing works when I select '..' when browsing a directory. has anyone seen this? is this something peculiar to my installation, a bug, or a feature? I reported this problem to Chip on 1/9. He responded with a fixed version (108c) on 1/10. It works fine here. Do you have an older version? You will need to go to Dr Chip's Vim Page for the current one: http://mysite.verizon.net/astronaut/vim/index.html -- Best regards, Bill
Re: 7.0.188 - problem with directory browser?
Denis, On Sat 27-Jan-07 1:26am -0600, Bill McCarthy wrote: On Fri 26-Jan-07 10:46pm -0600, Denis Perelyubskiy wrote: in version 7.0.188 (I am on windows xp, us) nothing works when I select '..' when browsing a directory. has anyone seen this? is this something peculiar to my installation, a bug, or a feature? I reported this problem to Chip on 1/9. He responded with a fixed version (108c) on 1/10. It works fine here. Do you have an older version? You will need to go to Dr Chip's Vim Page for the current one: http://mysite.verizon.net/astronaut/vim/index.html That site contains an older version. I've copied Chip on this note. Hopefully he will update his site (unless other problems were discovered with that fix). -- Best regards, Bill
Re: A doubt with syntax region
Hi Andy :)
* Andy Wokula [EMAIL PROTECTED] dixit:
DervishD schrieb:
That is, the contained item is swallowing part of the start
match!. I thought that when the match for start was performed, the
matched test wasn't tried for any other match, including contained
items. Obviously, I was wrong (or I misunderstood the entire issue), and
I don't know if, just using regions, I can have a match like this:
example{{weird} and some mor{}e text}
^
that is, that the first opening brace is not swallowed by the
contained syntax item. As you can see, the contained item must be
allowed to start with {.
:h :syn-matchgroup
| In a start or end pattern that is highlighted with matchgroup the
| contained items of the region are not used. This can be used to avoid
e.g.
syntax region SomeRegion matchgroup=SomeRegion start=\I\i*{ ...
I thought that you cannot use matchgroup with the same group as
the region group. That is, that the only use of matchgroup was to
have a region highlighted the region color and the separators
highlighted in a *different* color. I didn't carry a test for this!
Moreover, I considered that if you used the same group both for the
region and for matchgroup, you will end up with the entire region
highlighted with the group color: the text withing the region because
you issued a syntax region Group and the separators because you did
the matchgroup thing. So, I didn't even consider that the *inside* of
the region won't be colored at all.
This is for sure my fault, I misunderstood this because I didn't
noticed this paragraph:
In a start or end pattern that is highlighted with matchgroup the
contained items of the region are not used. This can be used to avoid
that a contained item matches in the start or end pattern match. When
using transparent, this does not apply to a start or end pattern
match that is highlighted with matchgroup.
Sorry for the inconvenience, I really thought I had read all the
relevant help for this issue, I'm embarrased O:
Thanks a lot, Andy, for your kind answer with the solution :)
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
Maintaining patterns
Hi all :) Another weird question O:) Let's suppose that I search frequently for a very complex pattern. This is easy to do using a keymap, for example. But let's assume that I also search frequently using the same pattern preceded by an arbitrary char *AND* followed by the same char. The char varies from search to search. In Perl I would store the complex pattern in some scalar, but I don't know how to do it in VimL. Probably it can be done with let and eval, but it won't work for syntax highlighting, AFAIC. Moreover, if I'm writing a syntax file and have a lot of syntax items that contains the same complex pattern preceded and followed by a character (this is only an example), that's difficult to maintain because each time I have to change the complex pattern I have to change it everywhere. Please note that this cannot be fixed modifying the pattern adding an whatever\? atom at the front and end of it, because the whatever MUST be present at BOTH ends. For the syntax highlighting, using contains solves the issue, but again, this doesn't work for searches. In the end, the problem is to be able to reuse a pattern, no matter if in a search, substitute, syntax highlighting, etc. And not, \z(\) is not a solution because it only works in start= in syntax regions. Is there a way of storing a pattern and reusing it in searchs, substitutions, syntax highlighting, etc? Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: Maintaining patterns
DervishD wrote: Hi all :) Another weird question O:) Let's suppose that I search frequently for a very complex pattern. This is easy to do using a keymap, for example. But let's assume that I also search frequently using the same pattern preceded by an arbitrary char *AND* followed by the same char. The char varies from search to search. In Perl I would store the complex pattern in some scalar, but I don't know how to do it in VimL. Probably it can be done with let and eval, but it won't work for syntax highlighting, AFAIC. In Vim you can store the pattern in a variable or in a register. At the keyboard, you can recall a register in Command-line or Insert/Replace modes by hitting Ctrl-R followed by the register name (e.g. ^R/ to recall the latest search pattern, ^Rw to recall register w, ^R= followed by an expression then Enter to evaluate that expression, etc.) When interacting with Vim at the keyboard, you can also recall the previously used pattern from search history (using Up and Down after hitting / or ? ) and modify it on the command-line before hitting Enter (or Esc to abord) on the modified pattern. Or you can use :let to set @/ (the search register) and immediately do searches based on the new value. For instance, to repeat the latest search but as a self-standing word: :let @/ = '\' . @/ . '\' Moreover, if I'm writing a syntax file and have a lot of syntax items that contains the same complex pattern preceded and followed by a character (this is only an example), that's difficult to maintain because each time I have to change the complex pattern I have to change it everywhere. Please note that this cannot be fixed modifying the pattern adding an whatever\? atom at the front and end of it, because the whatever MUST be present at BOTH ends. Any ex-command (including the :syntax command) can be constructed as a string expression, argument of the :exe command. Part of it can be the constant part of the pattern, use the . (concatenate) operator to cancatenate strings (any of these can be variables). In :exe as in :echo, if there are more than one operands, they are concatenated with intervening spaces. Here's a silly example: let s:pattern = 'azertyuiopqsdfyghjklmwxcvbn' ... fun DefineSynMatch(groupname, FirstPart, LastPart) exe 'syn match' \ a:groupname '' \ . a:FirstPart \ . s:pattern \ . a:LastPart \ . '' endfun For the syntax highlighting, using contains solves the issue, but again, this doesn't work for searches. In the end, the problem is to be able to reuse a pattern, no matter if in a search, substitute, syntax highlighting, etc. And not, \z(\) is not a solution because it only works in start= in syntax regions. Is there a way of storing a pattern and reusing it in searchs, substitutions, syntax highlighting, etc? Thanks a lot in advance :) Raúl Núñez de Arenas Coronado Best regards, Tony.
Re: Maintaining patterns
Hi Tony :) Once more, Antoine came to the rescue :)) You're great, dude :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: In Perl I would store the complex pattern in some scalar, but I don't know how to do it in VimL. Probably it can be done with let and eval, but it won't work for syntax highlighting, AFAIC. In Vim you can store the pattern in a variable or in a register. At the keyboard, you can recall a register in Command-line or Insert/Replace modes by hitting Ctrl-R followed by the register name (e.g. ^R/ to recall the latest search pattern, ^Rw to recall register w, ^R= followed by an expression then Enter to evaluate that expression, etc.) Yes, I knew this, but I thought that patterns were special in the sense that they couldn't be stored in a register (well, really I thought that only buffer text could be stored in a register). When interacting with Vim at the keyboard, you can also recall the previously used pattern from search history (using Up and Down after hitting / or ? ) and modify it on the command-line before hitting Enter (or Esc to abord) on the modified pattern. Cool! Or you can use :let to set @/ (the search register) and immediately do searches based on the new value. For instance, to repeat the latest search but as a self-standing word: :let @/ = '\' . @/ . '\' And I just forgot completely about the search register. My fault :( Moreover, if I'm writing a syntax file and have a lot of syntax items that contains the same complex pattern preceded and followed by a character (this is only an example), that's difficult to maintain because each time I have to change the complex pattern I have to change it everywhere. Please note that this cannot be fixed modifying the pattern adding an whatever\? atom at the front and end of it, because the whatever MUST be present at BOTH ends. Any ex-command (including the :syntax command) can be constructed as a string expression, argument of the :exe command. Again, I thought that syntax could be used in eval but not with exe. I definitely must study the VimL syntax in the structural level as shown in :help expression-syntax and think of any ex-command as an ex-command and not as syntax command, text manipulation commands, etc. Being vim an editor and not a programming language, I find sometimes difficult not to categorize its capabilities. I just tend to forget that VimL is a real programming language. Tony, again you've not only solved my doubt, but gave me an important lesson about VimL. I owe you yet another one. I just hope someday I will be able to return at least part of your kindness with me. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: Maintaining patterns
DervishD wrote: [...] Tony, again you've not only solved my doubt, but gave me an important lesson about VimL. I owe you yet another one. I just hope someday I will be able to return at least part of your kindness with me. Raúl Núñez de Arenas Coronado I used to be a teacher, and I don't believe that the best teacher is the one who gives the most students a failing note. To me, the greatest reward for a teacher lies in watching his students' successes. :-) Best regards, Tony.
Re: Regular Expression Question
print(This is 1.\n);print(This is 2.); print(This is 3.\n); I would like the above to be formated like (which is just adding in the newline a print that may not have it, but only if it does not have it): print(This is 1.\n);print(This is 2.); print(This is 3.\n); I presume you mean that second section to read print(This is 1.\n);print(This is 2.\n); print(This is 3.\n); adding in that \n after 2. On the assumption that you don't have quotation-marks escaped in your strings such as print (She said \hello\ to me); you should be able to do something like %s/print\s*(\s*[^]*\(\\n\)\@!\ze/\\n/g which should catch most of the non-pathological cases. If quotes can span lines, such as print (this is a really long string) then you can change [^]* to \_[^]* I just noticed that I also need to support the following as well: print (small string); print ( This is a very long string); and I need to format it as so: print (small string\n); print ( This is a very long string\n); Ideally, I would like to do this in one command and I would also like to understand the regex itself. So, given the above, here is what I understand of the regex pattern: %s/print\s*(\s*[^]*\(\\n\)\@!\ze/\\n/g % - globally s - substitute / - delimeter print\s*(\s* - my phrase to match including zero or more matching spaces at the end print, then a literal paren then zero or more spaces up until the quote [^]* - then everything that is not a quote (zero or more) ( - The beginning of the group ??? \\n - literal \n ) - End group \@! - Nothing, requires no match behind ??? - my ending quote to match in the pattern print () / - ??? \\n - literal \n / - delimeter g- each occurrence on the line Then we have the spanning multiple lines option: \_ [^]* so, \_ - match text over multiple lines (Is this like another regex engine, like the one sed uses?) [^]*- everything but a quote (zero or more) Does this make since? The area I am having difficulty with is / and how the grouping is working. Thanks in advance, Sean
Strange behavior when auto-indenting C++ code
I'm getting different formatting results when auto-indenting
than when I use the = command. Basically:
In order to be sure that there isn't some side effect from some
of my other configuration stuff, I invoke vim with:
vim -N -u NONE -U NONE toto.cc
Following that, I enter the following commands:
:set sw=4
:set cinoptions=(0U0
:set cindent
I then enter input mode, and enter:
Foo::Foo( int i, double d )
: i( i )
, d( ::func( d
)
)
{
}
What appears on the screen (and in the file) is what I want:
Foo::Foo( int i, double d )
: i( i )
, d( ::func( d
)
)
{
}
Now, however, I select the entire code (using V), and enter =,
to reformat the function. I then get:
Foo::Foo( int i, double d )
: i( i )
, d( ::func( d
)
)
{
}
For some reason, the first line is indented, and the second
isn't. Where as I would expect that both forms of indenting
would give the same results.
Any ideas what I'm doing wrong?
(FWIW: I'm using vim 6.4, compiled with just about all of the
available options, on a Sun Sparc under Solaris 2.8. I've
compiled it with the X11-Motif GUI, but the above behavior is
observable even in non-GUI mode.)
--
James Kanze (GABI Software) email:[EMAIL PROTECTED]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Re: Regular Expression Question
print (small string); print ( This is a very long string); and I need to format it as so: print (small string\n); print ( This is a very long string\n); Ideally, I would like to do this in one command and I would also like to understand the regex itself. So, given the above, here is what I understand of the regex pattern: %s/print\s*(\s*[^]*\(\\n\)\@!\ze/\\n/g % - globally s - substitute / - delimeter print\s*(\s* - my phrase to match including zero or more matching spaces at the end print, then a literal paren then zero or more spaces up until the quote [^]* - then everything that is not a quote (zero or more) Doing well up through here... ( - The beginning of the group ??? \\n - literal \n ) - End group \@! - Nothing, requires no match behind ??? You've got the understanding right (though those parens are \( and \) with backslashes). Those four lines in concert assert that a literal \n doesn't come before the current point. Without the grouping, it would only assure that the previous atom (in this case, the n) didn't appear here, so you'd have problems with things like print(terminal n) because it sees the terminal n so it doesn't do the substitution. By grouping them, you assert and when you get to this point [before the closing quote] and there isn't a literal backslash-en here, then we match In here, you're missing the \ze which means when doing the replacement, treat it as though the thing we're substituting ended here, even though there's more stuff we're looking for (namely, the double-quote that's next) - my ending quote to match in the pattern print () correct / - ??? This is standard substitution...the slash is the break between the search and its replacement. The ampersand is the whole previous match. In this case, it's slightly tweaked because of the \ze that we used...the thing we replace goes up through (but not including) the second double-quote. So it drops in everything from print through the end of the internal string (sans-closing-quote) \\n - literal \n correct...appending the literal \n you want. / - delimeter g- each occurrence on the line Then we have the spanning multiple lines option: \_ [^]* that's \_[ not \_ [ \_ - match text over multiple lines (Is this like another regex engine, like the one sed uses?) It's a vim thing: :help /\_ should drop you in the fray. It prefixes (infixes?)a number of atoms that could include whitespace, so for your change, you'd likely want to do something like change the \s atoms to \_s to include newlines. Does this make since? The area I am having difficulty with is / and how the grouping is working. Hopefully this sheds some light on matters and helps you tweak your own regexps in the future. If you have any questions, feel free to ask. -tim
Re: Regular Expression Question
Tim Chase wrote: print (small string); print ( This is a very long string); and I need to format it as so: print (small string\n); print ( This is a very long string\n); Ideally, I would like to do this in one command and I would also like to understand the regex itself. So, given the above, here is what I understand of the regex pattern: %s/print\s*(\s*[^]*\(\\n\)\@!\ze/\\n/g % - globally s - substitute / - delimeter print\s*(\s* - my phrase to match including zero or more matching spaces at the end print, then a literal paren then zero or more spaces up until the quote [^]* - then everything that is not a quote (zero or more) Doing well up through here... ( - The beginning of the group ??? \\n - literal \n ) - End group \@! - Nothing, requires no match behind ??? You've got the understanding right (though those parens are \( and \) with backslashes). Those four lines in concert assert that a literal \n doesn't come before the current point. Without the grouping, it would only assure that the previous atom (in this case, the n) didn't appear here, so you'd have problems with things like print(terminal n) because it sees the terminal n so it doesn't do the substitution. By grouping them, you assert and when you get to this point [before the closing quote] and there isn't a literal backslash-en here, then we match In here, you're missing the \ze which means when doing the replacement, treat it as though the thing we're substituting ended here, even though there's more stuff we're looking for (namely, the double-quote that's next) - my ending quote to match in the pattern print () correct / - ??? This is standard substitution...the slash is the break between the search and its replacement. The ampersand is the whole previous match. In this case, it's slightly tweaked because of the \ze that we used...the thing we replace goes up through (but not including) the second double-quote. So it drops in everything from print through the end of the internal string (sans-closing-quote) \\n - literal \n correct...appending the literal \n you want. / - delimeter g- each occurrence on the line Then we have the spanning multiple lines option: \_ [^]* that's \_[ not \_ [ \_ - match text over multiple lines (Is this like another regex engine, like the one sed uses?) It's a vim thing: :help /\_ should drop you in the fray. It prefixes (infixes?)a number of atoms that could include whitespace, so for your change, you'd likely want to do something like change the \s atoms to \_s to include newlines. Does this make since? The area I am having difficulty with is / and how the grouping is working. Hopefully this sheds some light on matters and helps you tweak your own regexps in the future. If you have any questions, feel free to ask. -tim Yes, this helps greatly. Thanks again Tim. Sean
Trying to compile Vim under SUSE 10.1
Hello, I am getting the following error when I try to compile under SUSE 10.1: --8-- make: *** No rule to make target `../runtime/vim32x32.xpm', needed by `objects/gui_x11.o'. Stop. --8-- Any idea? Thanks, -Jeff -Jeff
RE: Regular Expression Question
I hope you don't mind a non-vim solution, but I used to run into this
problem all the time when I wanted to match tabbing for debugging/status
messages that would come to the screen. I just got so sick and tired of
hopping through the code to add a tab here, remove a tab there, etc.,
that I'd just bunch together all the string constants in one place, at
the top. Eg:
const char
*msg_help[] = {
usage: %s [-options] [infile [outfile]]\n,
\toptions:\n,
\t\t-h\thelp\n,
\t\t-l\tlong (detailed) output\n,
(const char *)0
};
const char
dbg_rdferr[] = %s: cannot open \%s\ for reading\n,
dbg_wrferr[] = %s: cannot open \%s\ for writing\n,
...
and have everything even visually aligned in one place. Would also let
me reuse the same strings as needed (eg, %d as an input to sscanf(),
%02X as a 2-digit output to fprintf(), etc.) without having to wonder
if I mistyped something that would only break when some rarely-used
piece of code would run.
Then, once all your strings are in a row, just look for
\n[,;]$
and every string with the necessary newline at the end should be
highlighted. Any string that's *not* highlighted (ie, would be missing
the trailing newline) would, umm, would *not*, stand out.
Granted, that's not a vimmy solution to your problem, but it's a little
habit I got myself into, and for me at least, it made life a little
easier.
Any help?
Re: Regular Expression Question
Gene Kwiecinski wrote:
I hope you don't mind a non-vim solution, but I used to run into this
problem all the time when I wanted to match tabbing for debugging/status
messages that would come to the screen. I just got so sick and tired of
hopping through the code to add a tab here, remove a tab there, etc.,
that I'd just bunch together all the string constants in one place, at
the top. Eg:
const char
*msg_help[] = {
usage: %s [-options] [infile [outfile]]\n,
\toptions:\n,
\t\t-h\thelp\n,
\t\t-l\tlong (detailed) output\n,
(const char *)0
};
const char
dbg_rdferr[] = %s: cannot open \%s\ for reading\n,
dbg_wrferr[] = %s: cannot open \%s\ for writing\n,
...
and have everything even visually aligned in one place. Would also let
me reuse the same strings as needed (eg, %d as an input to sscanf(),
%02X as a 2-digit output to fprintf(), etc.) without having to wonder
if I mistyped something that would only break when some rarely-used
piece of code would run.
Then, once all your strings are in a row, just look for
\n[,;]$
and every string with the necessary newline at the end should be
highlighted. Any string that's *not* highlighted (ie, would be missing
the trailing newline) would, umm, would *not*, stand out.
Granted, that's not a vimmy solution to your problem, but it's a little
habit I got myself into, and for me at least, it made life a little
easier.
Any help?
Yes, I'l try it.
Thanks,
Sean
Re: Maintaining patterns
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: [...] Tony, again you've not only solved my doubt, but gave me an important lesson about VimL. I owe you yet another one. I just hope someday I will be able to return at least part of your kindness with me. I used to be a teacher, and I don't believe that the best teacher is the one who gives the most students a failing note. To me, the greatest reward for a teacher lies in watching his students' successes. :-) I think exactly the same :) In fact, the thing I regret the most regarding vim is that I'm not proficient enough in VimL to help people in the list, and since vim is an editor and not a programming language, and so it has commands to deal with text etc. ,learning VimL won't be as easy as learning the other languages I already know. It took a month to really master Perl, studying and practicing intensively, which, in hours, was much more than the time I took to master C, for example. VimL will take much longer, I'm afraid, but I'll try my best to do it, in return for all the help I'm receiving from you and the other people in the list (Tim Chase comes to mind, but I won't give more names because I'm going to forget someone). Again, thanks a lot :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
:g/regex/m0 possible move to buffer
I frequently use the :g command with m0 or m$ to move the matching text to the beginning or end of the current buffer. How can I move the matching lines to a new buffer/tab? Thanks, Kevin
Re: :g/regex/m0 possible move to buffer
I frequently use the :g command with m0 or m$ to move the matching text to the beginning or end of the current buffer. How can I move the matching lines to a new buffer/tab? I don't know of a one-pass way to do this easily, but you can either of the following which I've used in the past to do this: 1) do the above, and then delete the gathered lines and paste them elsewhere or 2) :let @a='' | g/pattern/d A go to the other buffer/tab/window and aP to dump the contents that have been deleted to the a register. I don't know if it would choke vim to do something like :g/regex/d| wincmd p | put | wincmd p (which might need to have the wincmd p changed to exec wincmd p if there are problems with the pipe) Just a few ideas. -tim
gvim and Unicode
I've been a long-time user of vi editors on Windows (lemmy and an older version of vim) and now am looking for a vi editor for Windows that supports the Unicode encodings (such as UTF-8, UTF-16, etc.) So I installed the latest gvim, version 7, but am disappointed that on my system at least (Windows XP), it doesn't recognize UTF-8 documents, so characters outside of the ASCII range are not being rendered properly (it appears gvim assumes the documents are ISO-8859 encoded.) In addition, in the documentation and menus, I see nothing mentioned about Unicode, UTF-8 encoding, etc. So what's going on? I was under the impression that in gvim I'd have a UTF-8 capable editor. Thanks! Jon Noring -- View this message in context: http://www.nabble.com/gvim-and-Unicode-tf3125527.html#a8659825 Sent from the Vim - General mailing list archive at Nabble.com.
RE: Returning perl hashes
David.Fishburn asked
Vim 7
WinXP SP2
Is it possible to return a Perl hash as a Vim List or
Dictionary?
I can say that Vim's support for scripting in perl is such that
whatever you are trying to do can be done. However, ...
I am pretty new to Perl but need it's features for my extension.
I have no clue what you mean by:
I need to return rows and columns of data which is perfect for a
Vim List or Dictionary.
So if you want to see an indication of how it can be done,
please indicate how you want some simple hash such as {a=1, b=2,
c=3} to end up inside vim script.
--Suresh
Re: gvim and Unicode
On sobota 27 styczeń 2007, vim@vim.org wrote: (it appears gvim assumes the documents are ISO-8859 encoded.) In addition, in the documentation and menus, I see nothing mentioned about Unicode, UTF-8 encoding, etc. :help utf-8 :help unicode m.
Re: gvim and Unicode
Jon Noring wrote: I've been a long-time user of vi editors on Windows (lemmy and an older version of vim) and now am looking for a vi editor for Windows that supports the Unicode encodings (such as UTF-8, UTF-16, etc.) So I installed the latest gvim, version 7, but am disappointed that on my system at least (Windows XP), it doesn't recognize UTF-8 documents, so characters outside of the ASCII range are not being rendered properly (it appears gvim assumes the documents are ISO-8859 encoded.) In addition, in the documentation and menus, I see nothing mentioned about Unicode, UTF-8 encoding, etc. So what's going on? I was under the impression that in gvim I'd have a UTF-8 capable editor. Thanks! Jon Noring gvim does support Unicode, but it may be easier or harder depending on your OS and its settings. The easiest is of course if you start gvim in a Unicode locale, or, on Unix, if you run a version compiled for the GTK2 toolkit (which uses Unicode by default). Here is a code snippet which you can paste into your vimrc to enable support for Unicode in all versions which have Unicode support compiled-in. if has(multi_byte) if not, we need to recompile if enc !~? '^u' if the locale 'encoding' starts with u or U then Unicode is already set if tenc == '' let tenc = enc save the keyboard charset endif set enc=utf-8to support Unicode fully, we need to be able to represent all Unicode codepoints in memory endif set fencs=ucs-bom,utf-8,latin1 setg bomb default for new Unicode files setg fenc=latin1 default for files created from scratch else echomsg 'Warning: Multibyte support is not compiled-in.' endif You must also set a 'guifont' which includes the glyphs you will need, but most fonts don't cover the whole range of assigned Unicode codepoints from U+ (well, U+0020 since 0-1F are not printable) to U+10 (well, U+10FFFD since anything ending in FFFE or is invalid). If you are like me, you will have to set different fonts at different times depending on what languages you're editing at any particular moment. Courier New has (in my experience) a wide coverage for alphabetic languages (Latin, Greek, Cyrillic, Hebrew, Arabic); for Far Eastern scripts you will need some other font such as FZ FangSong or MingLiU. With the above settings, Unicode files will be recognised when possible: - Any file starting with a BOM will be properly recognised as the appropriate Unicode encoding (out of, IIUC, UTF-8, UTF-16be, UTF-16le, UTF-32be and UTF-32le). - Files with no BOM will still be recognised as UTF-8 if they include nothing that is invalid in UTF-8. - Fallback is to Latin1. - The above means that 7-bit US-ASCII will be diagnosed as UTF-8; this is not a problem as long as you don't add to them any characters with the high bit set, since the codepoints U+ to U+007F have both the same meaning and the same representation in ASCII and UTF-8. The first time you add a character above 0x7F to such a file, you will have to save it with, for instance, :setlocal fenc=latin1 :w if you want it to be encoded in Latin1. From then on, the file (containing one or more bytes with high bit set in combinations invalid in UTF-8) will be recognised as Latin1 by the 'fileencodings' heuristics set above. - It also means that for non-UTF-8 Unicode files with no BOM, or in general for anything not autodetected (such as 8-bit files other than Latin1), you will have to specify the encoding yourself (e.g. :e ++enc=utf-16le filename.txt). Also with the above settings, new files will be created in Latin1. To create a new file in UTF-8, use for instance :enew :setlocal fenc=utf-8 See :help Unicode :help 'encoding' :help 'termencoding' :help 'fileencodings' :help 'fileencoding' :help 'bomb' :help ++opt HTH, Tony.
viminfo - bad craziness
On Slackware with vim 7.0.109 and a test config that results in 'verbose set viminfo?' putting out viminfo='20,50,s10,h Last set from /usr/share/vim/vimrc my .viminfo file is not limited to 20 command line entries. On W2K with vim 7.0 and a developing config I get the reverse: no explicit setting of :100 in 'viminfo' (or a thousand desperately attempted variants) works and no combo of history and viminfo works unless history is set and comes *after* 'viminfo'. Then, finally, mercifully, I get a decent sized command history. Incidental questions are why the defaults are so ridiculously low and why the syntax is so sadistic, but that's trivial - point is, something seems broke. What I get for playing around with an old Windows box. I never noticed anything amiss in Slack because it just happened to do what I wanted. There, I happen to have set viminfo='100,50,s10,h,n~/.vim/viminfo set history=100 on successive lines in my ~/.vimrc. Anyway - probably missing something obvious. But I re-read the help a few times and only saw one patch regarding viminfo (and it wasn't this issue) and don't recall it coming up on the list, so thought I'd mention it.
Re: Perl debugger
I thought I could confiure vim so that the perl plugin works such that I can run perl -wc from the plugin menu and have vim show the code with errors for example. Or rather simply run the perl script in the debugger where presumably vim acts as a window into perl executon and stepping through the code. On 1/26/07, Suresh Govindachar [EMAIL PROTECTED] wrote: Marc Bernstein asked: Please send some pointers about how to point vim to one of my perl installations (activeperl and cygwin ). What does the preceding mean? What are you trying to do? Any vimrc setup required (or viminfo)? --Suresh
Re: viminfo - bad craziness
On 2007-01-26 (Fri) 19:39:21 [-0500], J wrote: On Slackware with vim 7.0.109 and a test config that results in 'verbose set viminfo?' putting out viminfo='20,50,s10,h Last set from /usr/share/vim/vimrc my .viminfo file is not limited to 20 command line entries. Disregard this garbage - talking about history and yet forgot to also check the value of history in a default config - here, history is set to 50 in the global vimrc, so that's where that's coming from. Point is, Windows is borked.
Re: gvim and Unicode
On Fri 26-Jan-07 4:17pm -0600, Jon Noring wrote: In addition, in the documentation and menus, I see nothing mentioned about Unicode, UTF-8 encoding, etc. Hmm, if I simply type (in 7.0.188): :helpg \utf\|unicode\c I get 407 hits. You can move from one to the next with :cn or view them all in a quickfix window with :cw. -- Best regards, Bill
Re: Perl debugger
An easier way to step through Perl code during execution is the Perl TK debugger. Run your Perl program as follows: perl -d:ptkdb programname.pl From: Marc Bernstein [EMAIL PROTECTED] To: Suresh Govindachar [EMAIL PROTECTED] CC: vim@vim.org Subject: Re: Perl debugger Date: Fri, 26 Jan 2007 16:37:26 -0800 I thought I could confiure vim so that the perl plugin works such that I can run perl -wc from the plugin menu and have vim show the code with errors for example. Or rather simply run the perl script in the debugger where presumably vim acts as a window into perl executon and stepping through the code. On 1/26/07, Suresh Govindachar [EMAIL PROTECTED] wrote: Marc Bernstein asked: Please send some pointers about how to point vim to one of my perl installations (activeperl and cygwin ). What does the preceding mean? What are you trying to do? Any vimrc setup required (or viminfo)? --Suresh _ FREE online classifieds from Windows Live Expo buy and sell with people you know http://clk.atdmt.com/MSN/go/msnnkwex001001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06
