Re: how to ignore stderr in filter
Hi bill! On Sa, 22 Aug 2009, bill lam wrote: > Another problem for filter. I found that vim will get both stdout and > stderr from a filter. eg > > cat foo > #/bin/sh > ls --funny > echo abc > > execute :%!foo will copy all of the following to vim buffer > > ls: unrecognized option `--funny' > Try `ls --help' for more information. > abc > > It it possible to exclude output from stderr? set srr=">%s" :h 'srr' regards, Christian -- It is illegal to rob a bank and then shoot at the bank teller with a water pistol. [real standing law in Louisana, United States of America] --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
How to check file is modified or open in 2 or more windows?
I want to write a function which do if the file is modified if there is 2 or more windows of that file exec 'e .' else split window exec 'e .' endif endif Thanks Miao --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: how to ignore stderr in filter
On Tue, 01 Sep 2009, Christian Brabandt wrote: > set srr=">%s" Thanks, but when I tried to :set srr=">%s" in command mode, then verified :set srr? it returned ishellredir= instead of ">%s" -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Applying highlighting matches to second column only?
Hi, I'm trying to highlight specific letters in words in a specific column. I have a file looking like this word_1 long_word_1 word_2 long_word_2 word_3 long_word_3 ... where word_n are all different and of varying (or equal) length, and long_word_n are all different but of the same length. word_n and long_word_n are separated by white space. I want to highlight every letter, e.g., 'A', in long_word_n, but not in word_n. Question: How do I limit my match to apply to only the second column? My current code (below) is too greedy -- the match is on every occurrence of A (or a) in each line. Current code: syn match myA "[Aa]\+" highlight myA guifg=black guibg=yellow Cheers /JN --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Applying highlighting matches to second column only?
> I'm trying to highlight specific letters in words in a specific column. > I have a file looking like this > > word_1 long_word_1 > word_2 long_word_2 > word_3 long_word_3 > ... > > where word_n are all different and of varying (or equal) length, and > long_word_n are all different but of the same length. word_n and > long_word_n are separated by white space. > > I want to highlight every letter, e.g., 'A', in long_word_n, but not in > word_n. > > Question: How do I limit my match to apply to only the second column? > > My current code (below) is too greedy -- the match is on every > occurrence of A (or a) in each line. > > Current code: > > syn match myA "[Aa]\+" > highlight myA guifg=black guibg=yellow You might try using the pattern \(^\w*\s\+\w*\)\@<=[Aa] as in syn match myA "\(^\w*\s\+\w*\)\@<=[aA]" which seems to do what you describe. -tim --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: how to ignore stderr in filter
On Tue, September 1, 2009 11:03 am, bill lam wrote: > On Tue, 01 Sep 2009, Christian Brabandt wrote: >> set srr=">%s" > > Thanks, but when I tried to :set srr=">%s" in command mode, then > verified :set srr? it returned > ishellredir= > > instead of ">%s" Sorry, you should enter: set srr=>%s regards, Christian -- :wq! --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vim 7.1 - sh.vim syntax file - unwarranted syntax error detected.
Hi
Dr Chip sent me his v109 sh.vim to try, but...
This handles my two line test case, but the OP's script is still not
highlighted correctly; the line is
eval [ \"\${SCREEN_FONT$vc}\" ] &&
eval CONSOLE_FONT$vc=3D\${CONSOLE_=
FONT$vc:-\${SCREEN_FONT$vc}}
The highlighting is still not handling escaped quotes in evals well.
My test case used echo so that the result would be a valid script, but
it was a poor choice, the following would have been better.
eval [ \"Lorem\" ]
eval ipsum
With these convoluted eval expressions IMO rendering them perfectly is
not so desirable, but getting the parsing state (f.ex. in or out of a
quoted string) right so that the rest of the file highlights properly
is desirable.
Regards, John
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: how to ignore stderr in filter
On Tue, 01 Sep 2009, Christian Brabandt wrote: > set srr=>%s Thank you for prompt reply. It works like a charm. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Vim Tips wiki
The September edition of the Vim Tips home page is now available: http://vim.wikia.com/ The featured tip concerns the dreaded Caps Lock key and offers an alternative for typing CAPS in insert mode, while *not* typing JJJUU after switching back to normal mode. Thanks to those who have helped by saying "Remove" at: http://vim.wikia.com/wiki/User:JohnBeckett/Rich_text_editor Anyone with a Wikia logon, please add your name to the above. I am hoping to boost the wiki's Google rank with some changes: http://vim.wikia.com/wiki/User:JohnBeckett/Search_engine_optimization Any SEO ideas are welcome. John --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: goto line depending on exit code of filter
On Tue, 01 Sep 2009, Tony Mechelynck wrote: > external program generate the required number as a return code: IIRC, > return codes are limited to one byte, and those above 127 may have a > special meaning (generated by the OS maybe). Tony, you are correct. I don't why it seemed to work last time I tested. How can I store content of the current buffer and restore it in case of error? like the following pseudo code let tmp=% %!filter if v:xhell_error | set %=tmp | endif -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Always open help window above current window
In the help for the 'help' command it states the following: -8<8<8<8<8<--- :h[elp] Open a window and display the help file in read-only mode. If there is a help window open already, use that one. Otherwise, if the current window uses the full width of the screen or is at least 80 characters wide, the help window will appear just above the current window. Otherwise the new window is put at the very top. -8<8<8<8<8<--- However, I have the 'splitbelow' option set and my help windows always open below the current window. This is consistent with the help for 'splitbelow' but not for the help for 'help'. Is this a bug in the help or the behaviour of 'help' when splitbelow is set? What I'd really like is for the help window to _always_ appear above the current window (as stated in the above help text), ignoring the value of 'splitbelow'. Is there any easy way I can do that? Spencer -- <<< Eagles may soar, but weasels don't get sucked into jet engines >>> 11:29am up 4 days 17:23, 1 user, load average: 1.74, 1.62, 1.41 Registered Linux User #232457 | LFS ID 11703 --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to check file is modified or open in 2 or more windows?
Miao Jiang wrote: > I want to write a function which do > if the file is modified >if there is 2 or more windows of that file > exec 'e .' >else > split window > exec 'e .' >endif > endif > > Thanks > Miao > > > > > solved. check file modified or not use &modified check window numbers of buffer I write a function. function GetWindowCount(expr) let cur_buf_id=bufnr(a:expr) let cur_buf_cnt=0 let i=1 while 1 let buf_id=winbufnr(i) if buf_id==cur_buf_id let cur_buf_cnt=cur_buf_cnt+1 endif if buf_id==-1 break end let i=i+1 endwhile return cur_buf_cnt endfunction --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: expand variable to command line
Thank you guys, but that doesn't expand the variable. This solution uses Netrw and works only if my variable was a path. The point is not to execute the command so I can continue typing it after the variable was expanded, do some changes to the string which was expanded etc. -- Regards, Aarto On Mon, Aug 31, 2009 at 10:00 PM, Gary Johnson wrote: > > On 2009-08-31, Aarto Matti wrote: > > Hello, > > > > How to print an expanded variable into vim command line? For some > > reason I would like to map e.g. F12 to complete edit command with vim > > user files path. I would do something like: > > > > :map :edit expand($VIM) > > > > What it prints is > > > > :edit expand($VIM) > > > > and I want > > > > :edit /usr/share/vim > > Just use this: > >:map :edit $VIM > > If you want to actually edit $VIM and not add more to the path > before executing that command, use this: > >:map :edit $VIM > > Regards, > Gary > > > On Mon, Aug 31, 2009 at 9:28 PM, Tim Chase wrote: > > Several ways: > > :map :edit =expand($VIM) > :map :exec "edit ".expand($VIM) > > -tim > > --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: expand variable to command line
> Thank you guys, but that doesn't expand the variable. This solution uses
> Netrw and works only if my variable was a path. The point is not to execute
> the command so I can continue typing it after the variable was expanded, do
> some changes to the string which was expanded etc.
then try a variant of one of my suggestions (it removes one level
of "" from my previous post):
:nnoremap :e =$VIM
all typed literally ("<" and ">" and "-" characters as shown)
-tim
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: expand variable to command line
Yes, that's what I needed. Thanks again!
On Tue, Sep 1, 2009 at 2:29 PM, Tim Chase wrote:
>
> > Thank you guys, but that doesn't expand the variable. This solution uses
> > Netrw and works only if my variable was a path. The point is not to
> execute
> > the command so I can continue typing it after the variable was expanded,
> do
> > some changes to the string which was expanded etc.
>
> then try a variant of one of my suggestions (it removes one level
> of "" from my previous post):
>
> :nnoremap :e =$VIM
>
> all typed literally ("<" and ">" and "-" characters as shown)
>
> -tim
>
>
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
How to display edited lines of the file
Hi, Is there a way to highlight modified lines while editing a file? Burak --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to display edited lines of the file
set cursorlineset cursorcolumn On Tue, Sep 1, 2009 at 7:49 AM, Bu Rak wrote: > Hi, > > Is there a way to highlight modified lines while editing a file? > > Burak > > > > --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to display edited lines of the file
> Is there a way to highlight modified lines while editing a file? I don't think there's any stand-alone way to do this, but you can use DiffOrig :help DiffOrig which allows you do diff the current buffer with the original file contents. If the diff ever gets out of sync, you can force a resync with ":diffupdate" -tim --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to display edited lines of the file
On Tue, Sep 1, 2009 at 3:29 PM, Xian Chen wrote: > set cursorlineset cursorcolumn > > This only shows where the cursor is now, not the modified lines. --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
My function needs to be sourced twice. Why?
Hi,
I'm trying to write a function in vimscript that would toggle a value either
to its default value, or to an other value. Here is what I wrote.
" Toggles value to default or other
function! ToggleValue(value, default, other)
exec 'let evalvalue = '.a:value
if evalvalue == a:default
exec 'let '.a:value.' = '.a:other
else
exec 'let '.a:value.' = '.a:default
endif
exec 'let '.a:value
endfunction
This seems to work, e.g.
:let g:foo = 0
:call ToggleValue("g:foo", 0, 1) "prints g:foo #0
:call ToggleValue("g:foo", 0, 1) "prints g:foo #1
:call ToggleValue("g:foo", 0, 1) "prints g:foo #0
However, I don't understand why, to get it working, I need to source my
vimrc twice.
Can someone give me a hint?
Thank you!
--
Christophe-Marie Duquesne
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: My function needs to be sourced twice. Why?
Christophe-Marie Duquesne wrote:
> Hi,
>
> I'm trying to write a function in vimscript that would toggle a value
> either to its default value, or to an other value. Here is what I wrote.
>
> " Toggles value to default or other
> function! ToggleValue(value, default, other)
> exec 'let evalvalue = '.a:value
> if evalvalue == a:default
> exec 'let '.a:value.' = '.a:other
> else
> exec 'let '.a:value.' = '.a:default
> endif
> exec 'let '.a:value
> endfunction
>
> This seems to work, e.g.
> :let g:foo = 0
> :call ToggleValue("g:foo", 0, 1) "prints g:foo #0
> :call ToggleValue("g:foo", 0, 1) "prints g:foo #1
> :call ToggleValue("g:foo", 0, 1) "prints g:foo #0
>
> However, I don't understand why, to get it working, I need to source
> my vimrc twice.
>
> Can someone give me a hint?
Hmm -- it seemed to work fine for me with but a single sourcing.
However, the results I got were
g:foo #1
g:foo #0
g:foo #1
which seems correct to me (a quiet initialize g:foo to zero, toggle to
1, toggle to 0, toggle to 1).
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: My function needs to be sourced twice. Why?
Yes,
I'm answering my own mail : the function was already defined elsewhere (I
had written a file in .vim/plugin/ where I wanted to define this function,
and I had forgotten to remove it. I just lost 2 hours :$
On Tue, Sep 1, 2009 at 3:31 PM, Charles Campbell <
charles.e.campb...@nasa.gov> wrote:
>
> Christophe-Marie Duquesne wrote:
> > Hi,
> >
> > I'm trying to write a function in vimscript that would toggle a value
> > either to its default value, or to an other value. Here is what I wrote.
> >
> > " Toggles value to default or other
> > function! ToggleValue(value, default, other)
> > exec 'let evalvalue = '.a:value
> > if evalvalue == a:default
> > exec 'let '.a:value.' = '.a:other
> > else
> > exec 'let '.a:value.' = '.a:default
> > endif
> > exec 'let '.a:value
> > endfunction
> >
> > This seems to work, e.g.
> > :let g:foo = 0
> > :call ToggleValue("g:foo", 0, 1) "prints g:foo #0
> > :call ToggleValue("g:foo", 0, 1) "prints g:foo #1
> > :call ToggleValue("g:foo", 0, 1) "prints g:foo #0
> >
> > However, I don't understand why, to get it working, I need to source
> > my vimrc twice.
> >
> > Can someone give me a hint?
> Hmm -- it seemed to work fine for me with but a single sourcing.
> However, the results I got were
>
> g:foo #1
> g:foo #0
> g:foo #1
>
> which seems correct to me (a quiet initialize g:foo to zero, toggle to
> 1, toggle to 0, toggle to 1).
>
> Regards,
> Chip Campbell
>
>
> >
>
--
Christophe-Marie Duquesne
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: expand variable to command line
Sorry, maybe I should open a new topic, but it's relevant to this one also. How to do the same but without mapping to keyboard key. For instance I call my custom function EditVim() and it would drop me to command which already contains ":e /usr/share/vim". In other word I can simulate pressing ":". -- Aarto --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Use terminal colors in GUI Vim?
On Tue, Sep 1, 2009 at 9:31 AM, Nathan Neff wrote: > On Mon, Aug 31, 2009 at 8:19 PM, Patrick Gen-Paul wrote: >> I used ":hi + copy/paste" to create a color scheme that reflects my >> xterm's default colors. >> >> Pleas find attached the color scheme file I created manually via >> copy/paste and a few substitutions + the relevant stanza of my >> .Xdefaults file so all you need to do is replace my terminal color >> definitions by yours. > > Thanks Glen -- I tried your colorscheme, and it looks a lot like mine. > > I'll go through the colors 1 by 1 when I have time -- in the meantime, I'll > use your colorscheme :-) > > --Nate > Sorry, I meant Patrick-Gen Paul. --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Use terminal colors in GUI Vim?
On Mon, Aug 31, 2009 at 8:19 PM, Patrick Gen-Paul wrote: > I used ":hi + copy/paste" to create a color scheme that reflects my > xterm's default colors. > > Pleas find attached the color scheme file I created manually via > copy/paste and a few substitutions + the relevant stanza of my > .Xdefaults file so all you need to do is replace my terminal color > definitions by yours. Thanks Glen -- I tried your colorscheme, and it looks a lot like mine. I'll go through the colors 1 by 1 when I have time -- in the meantime, I'll use your colorscheme :-) --Nate --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Use terminal colors in GUI Vim?
Patrick Gen-Paul wrote: > I used ":hi + copy/paste" to create a color scheme that reflects my > xterm's default colors. > > Pleas find attached the color scheme file I created manually via > copy/paste and a few substitutions + the relevant stanza of my > .Xdefaults file so all you need to do is replace my terminal color > definitions by yours. > > :%s/#ii/#jj/g (e.g.) > > Would be nice if someone could suggest an automated solution, though. > The hicolors plugin can help with this: http://mysite.verizon.net/astronaut/vim/index.html#HICOLORS (cutting edge) http://vim.sourceforge.net/scripts/script.php?script_id=1081 (stable) I used simple.vimrc: set nocp syn on filetype plugin on and the following: vim -u simple.vimrc :he hicolors (place cursor atop a color) (place cursor atop "WriteColorscheme") (pick a name for the colorscheme) Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Suggest a vim task for a college workshop
On 25/08/09 19:08, Erik Falor wrote:
> On Tue, Aug 25, 2009 at 09:25:51AM -0700, Ben Fritz wrote:
>> 1. Vim is a very powerful tool with plenty of advantages over other
>> tools.
>> 2. Vim is complex, but there are ways to learn how to use it
>> effectively.
>
> Most of my colleagues who use Vim at work do not use it to its full
> potential. For instance, I haven't encountered a single one who was
> aware of text objects. Most folks are content to learn only 10% of
> Vim's unique functionality. I suspect that's true for most people who
> use any software. But it's especially sad in the case of Vim since
> they really are missing out on a lot.
>
> I believe that any approach that emphasizes using Vim's help system
> will do them the greatest service in the long-term. And if you teach
> them to effectively search and navigate the help system, it should
> also have the effect of getting them hooked. You'll be showing them
> that:
> 1) Vim isn't really *that* hard because it comes with so much good
> documentation.
> 2) Vim has an overwhelming number of features, but I can learn
> about them at my own pace because I know where to look for
> help.
> 3) Vim's normal-mode and ex-mode commands all adhere to
> well-defined conventions with respect to addresses and motions.
> Once I master that, it's just a matter of remembering the names
> of some commands. Oh, there is tab completion for the ex-mode
> commands! That means I really only need to memorize a few
> normal mode commands!
>
>> Start them out with a pre-configured Vim with a lot of "bells and
>> whistles" such as syntax highlighting already enabled for them. Maybe
>> even install a snippet or skeleton plugin that pre-populates most of a
>> C program for them. TagList would not be out of the question.
>
> I would also show off Vim's insert-mode completion capabilities. That
> is something that programmers coming from an IDE very much rely on.
>
>> 3. Vim's help tells you basically EVERYTHING you need to know about
>> the editor.
>>
>> This step is VERY important. Without knowledge of :help, Vim is
>> basically useless, and a new user will never get beyond basic editing.
>> If time permits, I would even demonstrate CTRL-D with a :help topic,
>> and :helpgrep.
>
> Please make time to show this aspect of the help system off. I also
> encourage you to point out that they can use Ctrl-] and Ctrl-T to
> navigate via helptags.
Rather than Ctrl-D, I would demonstrate 'wildmenu' (Tab) with a help
topic. ":helpgrep" is essential indeed.
>
> The :options command along with :mkvimrc would be a good thing to
> throw into a hand-out. Vim is very, very configurable. These
> commands are a good way to explore all of those settings.
hm. Never used :mkvimrc myself. My vimrc is something I built little by
little, starting with
runtime vimrc_example.vim
then adding one command (if block, rather) above it when I got messages
in the "wrong" language
if has('unix')
language messages C
else
language messages en
endif
(I already had a double-boot system by that time, and Windows and Unix
versions didn't accept the same arguments here)
the rest came after the call to vimrc_exmple.vim, starting with
filetype indent off
after a lot of searching why Vim was high-handedly changing my
indentation and how to prevent it
...etc... (YMMV).
I did (rather early) check every possible option, but I didn't use
:mkvimrc, I added the changes, with the appropriate "if has(" or "if
exists(" wrappers to avoid errors in different versions (such as
vim-minimal vs. vim-enhanced vs. vim-x11 on Linux, vs. vim.exe vs.
gvim.exe on Windows.
>
> In addition to the great resources Ben Fritz pointed to, you can also
> direct new users to #vim on irc.freenode.net.
>
not to forget the vim_use (and possibly vim_multibyte etc.) Google
Group, which I don't think Ben mentioned.
Best regards,
Tony.
--
"Nuclear war can ruin your whole compile."
-- Karl Lehenbauer
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
RE: improving the :join command
>as you may know, :join suffers from a serious performance issue, when >joining many lines ( in the order of 10 thousands or more lines). No disrespect intended, but *why* in B'Harni's Dark Name would you want to join >1 lines into 1?!? Any 'vi' variant is a *line*-based editor, which presumed a modest line-size for each. Juggling lines back and forth is easy, but heaving huge MB-sized chunks o' text is just obscene. Add to that syntax-based highlighting, multiple colors, etc., and all the processing required for just *1* line adds exponentially to the amount of work involved, let alone cursor motions, etc. Dunno, but to me, that seems like using a text editor to edit a .jpg or .gif or something, ie, not the right tool for the job, even if, through herculean contortions and torturing the editor's functionality, it *can* be done. I'd, if anything, edit the file as needed, save it, then use 'sed', 'tr', etc., to post-process it accordingly. No overhead for syntax, colorschemes, etc. Ie, use the right tool for the job. --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Suggest a vim task for a college workshop
On 26/08/09 17:48, Vlad Dogaru wrote: > > Ben Fritz wrote: >> >> >> >> On Aug 25, 8:14 pm, Ken Bloom wrote: >>> >>> When I first got interested in vim, it was because I watched people do >>> vi's relatively simple navigation things -- being able to move a word at >>> a time, delete a word, replace a word with simple keystrokes. >>> >>> But I don't think these make for a good tutorial. >>> >> >> Agreed. This is why I suggest having them do it with some rudimentary >> knowledge, then doing it in front of them on a projector or something. >> They will see all the fancy stuff and a few of them might become >> interested. > > Thanks to everyone for your input. We will probably give them a program > and a makefile, so they can use make, copen and friends along with > editing. As it is, many of them come from a background of Borland's C++ > environment, not latest-and-greatest Eclipse and the like, so hopefully > we'll get a positive response. > > Cheers, > Vlad Don't deride Turbo C, I used it on Dos and it already had a decent keyboard-driven editor, plus excellent syntax help on the C language, and it came with an outstanding debugger. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 118. You are on a first-name basis with your ISP's staff. --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: improving the :join command
Hi Gene! On Di, 01 Sep 2009, Gene Kwiecinski wrote: > No disrespect intended, but *why* in B'Harni's Dark Name would you > want to join >1 lines into 1?!? There might be usecases. Data is growing rapidly today, and I myself had to manage automatically generated text-files of several hundred MB of size. Plus there have occasionally been questions on this list regarding joining lines. Well just one simple test: #v+ ~$ for i in 1 2 4 8 16 32 64 128; do seq 1 $(($i*1000)) > tempfile echo "joining $i kilo lines" time vim -u NONE -N -c ':%join|:q!' tempfile; done #v- and compare the timings yourself. Doesn't this look like a bug to you? > Any 'vi' variant is a *line*-based editor, which presumed a modest > line-size for each. Juggling lines back and forth is easy, but heaving > huge MB-sized chunks o' text is just obscene. Add to that syntax-based > highlighting, multiple colors, etc., and all the processing required for > just *1* line adds exponentially to the amount of work involved, let > alone cursor motions, etc. Well Vim is an editor. Shouldn't it be able to join properly millions of lines, even if that sounds strange? The power of vim comes from the fact, that you can do many different manipulations very efficiently and does not limit you. Plus :h limits does not talk about joining only a couple of lines ;) > Dunno, but to me, that seems like using a text editor to edit a .jpg or > .gif or something, ie, not the right tool for the job, even if, through > herculean contortions and torturing the editor's functionality, it *can* > be done. Exactly. It can. And it might be done by someone. > I'd, if anything, edit the file as needed, save it, then use 'sed', > 'tr', etc., to post-process it accordingly. No overhead for syntax, > colorschemes, etc. Ie, use the right tool for the job. Yeah, but sed, tr, awk, perl, $language is not always available. And Vim should be able to do it right. What was the reason again to add :vimgrep to vim when grep is available? regards, Christian --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: improving the :join command
>>No disrespect intended, but *why* in B'Harni's Dark Name would you >>want to join >1 lines into 1?!? >There might be usecases. Data is growing rapidly today, and I myself >had to manage automatically generated text-files of several hundred MB >of size. Plus there have occasionally been questions on this list >regarding joining lines. Even so, something which I can understand, eg, a logfile, should be delineated by linebreaks. Raw xml/sgml/etc., should be edited as a sequence of modestly-sized lines, then if necessary, joined to a single line after saving (or before saving, if you have the time :D ). >Well just one simple test: >#v+ >~$ for i in 1 2 4 8 16 32 64 128; do > seq 1 $(($i*1000)) >tempfile > echo "joining $i kilo lines" > time vim -u NONE -N -c ':%join|:q!' tempfile; >done >#v- >and compare the timings yourself. Doesn't this look like a bug to you? I have no idea, as I didn't run it yet. Offhand, an exponential increase wouldn't be out of the question, ie, e^n. Don't forget *physical* limits such as available memory. Once you bang your head on that memory-ceiling and start having to swap to disk, all bets are off, and processing time can increase by order*s* of magnitude, depending how bad it is. Hell, I run into that in *perl*, let alone 'gvim', when intentionally joining huge files to a single line to c&p whole sections of the file! And I'm not even dealing with syntax highlighting, colorschemes, and the like. >>Any 'vi' variant is a *line*-based editor, which presumed a modest >>line-size for each. Juggling lines back and forth is easy, but heaving >>huge MB-sized chunks o' text is just obscene. Add to that syntax-based >>highlighting, multiple colors, etc., and all the processing required for >>just *1* line adds exponentially to the amount of work involved, let >>alone cursor motions, etc. >Well Vim is an editor. Shouldn't it be able to join properly millions >of lines, even if that sounds strange? The power of vim comes from Sure, it should be able to be pushed to its limits and do so, but not necessarily *efficiently*. Ie, it may hit that aforementioned ceiling and then start hitting the disk to do so, and pretty much require you to leave it running overnight to go and join a brazillion lines into 1 Uberline. That's not necessarily a "bug", just an unexpected excursion of its performance envelope. The fact that it can create a huge Uberline without *crashing* is a testament to the robustness of the code. An old version of 'vi' I had would vomit on lines >300chars or so. Point being, *line*-editors are meant to be used with *lines*, and lines of a modest size. The fact that it *can* handle Uberlines is great, but you can't expect it to be handled "efficiently". The kind of advice I might give would be along the lines of the guy who sees his doctor: guy:"Doc, it hurts when I do this." doc:"So don't do that." >the fact, that you can do many different manipulations very >efficiently and does not limit you. Absolutely, but again, recall that it's intended to be a *line*-editor. Not to appear facetious in repeating that again, but that's what 'vim'/'gvim' happens to be, a *line*-editor. You yank and put *lines*. You add *lines*. You delete *lines*. Hell, syntax highlighting becomes downright painful for overly-long lines that people wrote add-ons to stop highlighting after N columns! That should be Clue #1 that overly-long lines are not "natural" to a *line*-editor. >Plus :h limits does not talk about joining only a couple of lines ;) Of course not. I can 'ls' a list of filenames into a file, do a ':%j' to get them into a single line, then prepend a command to run (with the filelist as the list of files to operate on) and make an instant batchfile. Works great. But there's a huge difference between a batch-/shell-command that's 1000chars long, and a 1-line file with a 100Mchar Uberline. >>Dunno, but to me, that seems like using a text editor to edit a .jpg or >>.gif or something, ie, not the right tool for the job, even if, through >>herculean contortions and torturing the editor's functionality, it *can* >>be done. >Exactly. It can. And it might be done by someone. And if he has the luxury of letting it run overnight, great. :D >>I'd, if anything, edit the file as needed, save it, then use 'sed', >>'tr', etc., to post-process it accordingly. No overhead for syntax, >>colorschemes, etc. Ie, use the right tool for the job. >Yeah, but sed, tr, awk, perl, $language is not always available. And >Vim should be able to do it right. >What was the reason again to add :vimgrep to vim when grep is >available? I have no idea, as I don't recall ever using it. To reiterate, I *don't* want to appear to be argumentative, but I'm just saying that handing Uberlines is something that's *possible* in 'vim'/'gvim', but don't expect it to be handled "efficiently", not if it's well outside the usual performance envelope of file-editing. --~
Re: Use terminal colors in GUI Vim?
On Tue, Sep 1, 2009 at 10:31 AM, Nathan Neff wrote:
>
> On Mon, Aug 31, 2009 at 8:19 PM, Patrick Gen-Paul wrote:
>> I used ":hi + copy/paste" to create a color scheme that reflects my
>> xterm's default colors.
>>
>> Pleas find attached the color scheme file I created manually via
>> copy/paste and a few substitutions + the relevant stanza of my
>> .Xdefaults file so all you need to do is replace my terminal color
>> definitions by yours.
>
> Thanks Glen -- I tried your colorscheme, and it looks a lot like mine.
>
> I'll go through the colors 1 by 1 when I have time -- in the meantime, I'll
> use your colorscheme :-)
Well, you can probably tell that I was bored today... but here's a
port of the 16-color-terminal default colorscheme to gvim. Just
change the block of colors (the "let" lines..) to match your
terminal's colors (they're colors 0 through 15, in order, fwiw).
Hopefully gmail doesn't wrap this on me... In fact, just in case it
does, I've attached it as well - so there will be a plain text,
archivable copy in the list archives and a not-horribly-wrapped copy
in subscriber's inboxes. Sorry I can't disable wrapping ATM. :)
~Matt
hi clear
if exists("syntax_on")
syntax reset
endif
let g:colors_name = 'sixteen'
" Change these to match your terminal!
let s:Black = '#00'
let s:DarkBlue= '#AF'
let s:DarkGreen = '#00AF00'
let s:DarkCyan= '#AFAF00'
let s:DarkRed = '#00FF00'
let s:DarkMagenta = '#AF00AF'
let s:Brown = '#00AFAF'
let s:Grey= '#9A9A9A'
let s:DarkGrey= '#5F5F5F'
let s:Blue= '#D7'
let s:Green = '#00D700'
let s:Cyan= '#D7D700'
let s:Red = '#00FF00'
let s:Magenta = '#D700D7'
let s:Yellow = '#00D7D7'
let s:White = '#D7D7D7'
" Both
exe 'hi ErrorMsg term=standout ctermbg=DarkRed guibg=' . s:DarkRed . '
ctermfg=White guifg=' . s:White
exe 'hi IncSearch term=reverse cterm=reverse gui=reverse'
exe 'hi ModeMsg term=bold cterm=bold gui=bold'
exe 'hi NonText term=bold ctermfg=Blue guifg=' . s:Blue
exe 'hi StatusLine term=reverse,bold cterm=reverse,bold gui=reverse,bold'
exe 'hi StatusLineNC term=reverse cterm=reverse gui=reverse'
exe 'hi VertSplit term=reverse cterm=reverse gui=reverse'
exe 'hi VisualNOS term=underline,bold cterm=underline,bold gui=underline,bold'
exe 'hi DiffText term=reverse cterm=bold gui=bold ctermbg=Red guibg=' . s:Red
exe 'hi PmenuThumb cterm=reverse gui=reverse'
exe 'hi PmenuSbar ctermbg=Grey guibg=' . s:Grey
exe 'hi TabLineSel term=bold cterm=bold gui=bold'
exe 'hi TabLineFill term=reverse cterm=reverse gui=reverse'
exe 'hi Cursor guibg=fg guifg=bg'
exe 'hi lCursor guibg=fg guifg=bg'
if &bg == 'light'
exe 'hi Directory term=bold ctermfg=DarkBlue guifg=' . s:DarkBlue
exe 'hi LineNr term=underline ctermfg=Brown guifg=' . s:Brown
exe 'hi MoreMsg term=bold ctermfg=DarkGreen guifg=' . s:DarkGreen
exe 'hi Question term=standout ctermfg=DarkGreen guifg=' . s:DarkGreen
exe 'hi Search term=reverse ctermbg=Yellow guibg=' . s:Yellow . '
ctermfg=NONE guifg=NONE'
exe 'hi SpellBad term=reverse ctermbg=Red guibg=' . s:Red
exe 'hi SpellCap term=reverse ctermbg=Blue guibg=' . s:Blue
exe 'hi SpellRare term=reverse ctermbg=Magenta guibg=' . s:Magenta
exe 'hi SpellLocal term=underline ctermbg=Cyan guibg=' . s:Cyan
exe 'hi Pmenu ctermbg=Magenta guibg=' . s:Magenta
exe 'hi PmenuSel ctermbg=Grey guibg=' . s:Grey
exe 'hi SpecialKey term=bold ctermfg=DarkBlue guifg=' . s:DarkBlue
exe 'hi Title term=bold ctermfg=DarkMagenta guifg=' . s:DarkMagenta
exe 'hi WarningMsg term=standout ctermfg=DarkRed guifg=' . s:DarkRed
exe 'hi WildMenu term=standout ctermbg=Yellow guibg=' . s:Yellow .
' ctermfg=Black guifg=' . s:Black
exe 'hi Folded term=standout ctermbg=Grey guibg=' . s:Grey . '
ctermfg=DarkBlue guifg=' . s:DarkBlue
exe 'hi FoldColumn term=standout ctermbg=Grey guibg=' . s:Grey . '
ctermfg=DarkBlue guifg=' . s:DarkBlue
exe 'hi SignColumn term=standout ctermbg=Grey guibg=' . s:Grey . '
ctermfg=DarkBlue guifg=' . s:DarkBlue
exe 'hi Visual term=reverse'
exe 'hi DiffAdd term=bold ctermbg=Blue guibg=' . s:Blue
exe 'hi DiffChange term=bold ctermbg=Magenta guibg=' . s:Magenta
exe 'hi DiffDelete term=bold ctermfg=Blue guifg=' . s:Blue . '
ctermbg=Cyan guibg=' . s:Cyan
exe 'hi TabLine term=underline cterm=underline gui=underline
ctermfg=Black guifg=' . s:Black . ' ctermbg=Grey guibg=' . s:Grey
exe 'hi CursorColumn term=reverse ctermbg=Grey guibg=' . s:Grey
exe 'hi CursorLine term=underline cterm=underline gui=underline'
exe 'hi MatchParen term=reverse ctermbg=Cyan guibg=' . s:Cyan
exe 'hi Normal gui=NONE'
else
exe 'hi Directory term=bold ctermfg=Cyan guifg=' . s:Cyan
exe 'hi LineNr term=underline ctermfg=Yellow guifg=' . s:Yellow
exe 'hi MoreMsg term=bold ctermfg=Green guifg=' . s:Green
exe 'hi Question term=standout ctermfg=Green guifg=' . s:Green
exe 'hi Search term=reverse ctermbg=Y
Re: improving the :join command
Hi Gene! On Di, 01 Sep 2009, Gene Kwiecinski wrote: > To reiterate, I *don't* want to appear to be argumentative, but I'm just > saying that handing Uberlines is something that's *possible* in > 'vim'/'gvim', but don't expect it to be handled "efficiently", not if > it's well outside the usual performance envelope of file-editing. Well, then don't use it. Nobody forces you to use the plugin. But someone might think it's useful. regards, Christian --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: goto line depending on exit code of filter
On Tue, Sep 1, 2009 at 2:55 AM, Tony Mechelynck wrote: > > Vim can jump to any line that it can count, the problem is having your > external program generate the required number as a return code: IIRC, > return codes are limited to one byte, and those above 127 may have a > special meaning (generated by the OS maybe). Depends on the OS, but on Unix... Return codes are limited to one byte Applications are free to return any number in that range, none of them are "special", but... The operating system often uses return codes between 128 and 255 to indicate death by signal. The solaris machine I'm sitting in front of uses 128 + (signal number) when an app dies of a signal, and Linux uses the same. I could swear that an older version of solaris used 256 - (signal number), but I can't confirm that at the moment, so don't quote me on that. The 127 return code from bash isn't OS-level special, it's just a convenience thing that bash does to make it easier to guess when a script failed because it couldn't find a command. ~Matt --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Suggest a vim task for a college workshop
On Tue, Aug 25, 2009 at 10:08 AM, Erik Falor wrote: > On Tue, Aug 25, 2009 at 09:25:51AM -0700, Ben Fritz wrote: >> 1. Vim is a very powerful tool with plenty of advantages over other >> tools. >> 2. Vim is complex, but there are ways to learn how to use it >> effectively. > > Most of my colleagues who use Vim at work do not use it to its full > potential. For instance, I haven't encountered a single one who was > aware of text objects. Most folks are content to learn only 10% of > Vim's unique functionality. I suspect that's true for most people who > use any software. But it's especially sad in the case of Vim since > they really are missing out on a lot. I have the same observation. Even those who say they are die-hard fans don't really know much of Vim, but I guess they are really die-hard Vi fans, not Vim, they simply switched over to Vim, but don't really want to learn more. What is funny however is there are people who worked for years on Vi on console and still don't know much of Vi. I guess these are the folks who would have been satisfied working in windows notepad like program, but just happened to begin their work in Vi. My recommendation for beginners it to use plain Vi in console (or at least Vim in 'compatible' mode on console) and concentrate on the core Vi features before trying out the newer Vim features. This was my learning path, though mine was natural shift with quite a few years of time to play with Vi before I came across Vim. -- HTH, Hari > > I believe that any approach that emphasizes using Vim's help system > will do them the greatest service in the long-term. And if you teach > them to effectively search and navigate the help system, it should > also have the effect of getting them hooked. You'll be showing them > that: > 1) Vim isn't really *that* hard because it comes with so much good > documentation. > 2) Vim has an overwhelming number of features, but I can learn > about them at my own pace because I know where to look for > help. > 3) Vim's normal-mode and ex-mode commands all adhere to > well-defined conventions with respect to addresses and motions. > Once I master that, it's just a matter of remembering the names > of some commands. Oh, there is tab completion for the ex-mode > commands! That means I really only need to memorize a few > normal mode commands! > >> Start them out with a pre-configured Vim with a lot of "bells and >> whistles" such as syntax highlighting already enabled for them. Maybe >> even install a snippet or skeleton plugin that pre-populates most of a >> C program for them. TagList would not be out of the question. > > I would also show off Vim's insert-mode completion capabilities. That > is something that programmers coming from an IDE very much rely on. > >> 3. Vim's help tells you basically EVERYTHING you need to know about >> the editor. >> >> This step is VERY important. Without knowledge of :help, Vim is >> basically useless, and a new user will never get beyond basic editing. >> If time permits, I would even demonstrate CTRL-D with a :help topic, >> and :helpgrep. > > Please make time to show this aspect of the help system off. I also > encourage you to point out that they can use Ctrl-] and Ctrl-T to > navigate via helptags. > > The :options command along with :mkvimrc would be a good thing to > throw into a hand-out. Vim is very, very configurable. These > commands are a good way to explore all of those settings. > > In addition to the great resources Ben Fritz pointed to, you can also > direct new users to #vim on irc.freenode.net. > > -- > Erik Falor > Registered Linux User #445632 http://counter.li.org > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkqUGpoACgkQpMTu6iYtwselPwCffq28KFLp1vQQLiXmi9du00S4 > xp4An2yfOofSYFo7cMwrVHkBLZPXFDVp > =ri5h > -END PGP SIGNATURE- > > --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: goto line depending on exit code of filter
On 01/09/09 12:18, bill lam wrote: > > On Tue, 01 Sep 2009, Tony Mechelynck wrote: >> external program generate the required number as a return code: IIRC, >> return codes are limited to one byte, and those above 127 may have a >> special meaning (generated by the OS maybe). > > Tony, you are correct. I don't why it seemed to work last time I > tested. > > How can I store content of the current buffer and restore it in case > of error? like the following pseudo code > > let tmp=% > %!filter > if v:xhell_error | set %=tmp | endif > what about (untested) %!filter if v:shell_error undo endif ? If it doesn't work you can always do w! /temp/file %!filter if v:shell_error e! /temp/file saveas # endif but it isn't very elegant. Best regards, Tony. -- President Reagan has noted that there are too many economic pundits and forecasters and has decided on an excess prophets tax. --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ":setlocal spell" shows "SpellLocal" errors
On Aug 30, 1:38 pm, Matt Wozniski wrote: > On Sat, Aug 29, 2009 at 10:01 AM, AndyHancock wrote: > > > I'm using vim 7.1 from the cygwin 1.5.25 installation. I did: > > > :set spelllang=en_us,us_ca > > > I got: > > > Warning: Cannot find word list "us.latin1.spl" or "us.ascii.spl" > > Well, two points here - one, you should probably be using vim in UTF-8 > mode unless you have a really good reason not to, and b) in vim 7.1 > this would fail unless ~/.vim/spell/ already existed, so an mkdir > might help. > > > Before getting the above error, Vim asked for permission to download > > those files, but couldn't find them. After the above error, local > > spellings such as "neighbourhood" and "colour" are highlighted as > > SpellLocal, meaning that it is the /wrong/ spelling for the selected > > region. I thought I was selecting the region with above command? > > If I set spelllang to "en_us", "colour" is highlighted with > SpellLocal. If I set it to "en_ca", "color" is highlighted with > SpellLocal. If I set it to "en_us,en_ca", neither "color" nor > "colour" is highlighted as SpellLocal. Hmm, I'll have to read up a bit more on UTF-8 mode and see if anything I did in the past might have torpedoed that. I already have ~/.vim/ spell. Thanks, Matt --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: changing what counts as a paragraph
Hi Tony,
( I don't know where to write "hi Tony" when bottom-post, jsut do it as
before)
On Sun, Aug 30, 2009 at 5:16 PM, Tony Mechelynck <
antoine.mechely...@gmail.com> wrote:
> ("sic" because
> I would have asked "why people hate bottom posting" or maybe "why people
> hate to bottom-post": "people" is a plural except when "a people" is
> used as an approximate synonym of "a nation".)
>
Sorry for my english, -_-!. And I like your bottom-post indeed.
I posted the "Why" mail for I saw too much top-post mailling lists, almost
all except this one.
The "people" I meant are not all newbies, but they may be not old Usenet
hands.
> The reason most newbies use top-posting is, I believe, that the
> braindead software they use makes top-posting easier. I'm not saying
> that it _enforces_ top-posting, and, indeed, in most cases, when
> composing a reply you can move your edit cursor to below the part to
> which you want to reply, after removing irrelevant quoted text.
>
Many mailing-lists attach a long content of some info, usually the first one
of the subject. And some mail service providers also attach ads at the end
the mail.
So others need to search for where is my post in the middle the mail, if I
bottom post my reply.
Certainly, I should edit quoted part rather than directly bottom-post, but I
don't want to edit
other's post.
When I received a mail with 10 top posted replies, I think, I should do as
what they do.
IMHO, top or bottom, are just a convention, of someone or a list, and there
are not two much
loftiness and sin. But I'll bottom-post here, and need to learn some
confusing things about bottom posting.
> One possible exception has been said to be some "Internet phone" servers
> where the quoted text is added in front of the message by the server
> _after_ you send the reply, where the quoted text is not included. If
> such servers exist, IMO they are worse than braindead.
>
Yeah, when I wrote previous reply on my phone, I could seen none of original
post. Any this one was written on desktop computer.
B.R.
Wayne
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
NERDTree question
Is there a way to have the NERDTree always show up by default for every tab? Thanks, Ernest --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Use terminal colors in GUI Vim?
Matt Wozniski wrote: > Well, you can probably tell that I was bored today... but here's a > port of the 16-color-terminal default colorscheme to gvim. Just > change the block of colors (the "let" lines..) to match your > terminal's colors (they're colors 0 through 15, in order, fwiw). > Hopefully gmail doesn't wrap this on me... In fact, just in case it > does, I've attached it as well - so there will be a plain text, > archivable copy in the list archives and a not-horribly-wrapped copy > in subscriber's inboxes. Sorry I can't disable wrapping ATM. :) [..] Thanks for the feedback. Do not deride such efforts - and yours in particular. Stuff like that is quite valuable in terms of introducing low-level vim users like myself to vim scripting / customization. An obvious limitation is that nobody is going to want to type in their rrggbb's - even 16 of them.. And some folks have 256 colors terminals. I plan to take a closer look at your port, tomorrow I hope. :-) Gen-Paul. --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
