Re: Color scheme
On Sep 19, Bruce Korb wrote: > Hi, > I go to the trouble of wrapping my vim invocation inside > of a function that adds "-i NONE" to the command line. I assume you mean -u? > I do this because somebody thinks it's really cool to > have dark purple or blue letters on a black background. > [...] Vim thinks your terminal has colour capability, and is guessing a light background. It can't guess reliably, so to ensure it thinks you have a dark background you can tell it with ":set background=dark". You should see the legibility of the colours improve after this. > I'd go back to plain vi, but it is not supported anymore. I mean, if you like bugs that will never be fixed ... :-) > SO, how can I force vim to never, ever try to colorize my > text ever again? Thank you. To tell Vim that no colours are available: set t_Co=0 You can add this to your command to invoke Vim: vim -u NONE -c 'set t_Co=0' --Antony -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200920024026.GA821758%40naga.
Re: Typo/mistake in insert.txt?
Hi! On May 30, Ethan Hereth wrote: > I am pretty sure there is a mistake in insert.txt at line > 639 (at least it's there on the version I just checked on > github) where it explains the insert mode completion > commands. It says "All these (except 2) are done in > CTRL-X mode." I think that this should say "except 13"? > Or, am I misunderstanding something? I think it means 'all except two of them,' i.e. CTRL-N and CTRL-P. --Antony -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug in ftdetect?
On May 25, Christian Brabandt wrote: > [...] > > I am not sure, if this behaviour is a bug. However after > thinking some more about it, I am wondering, whether the > fact that the BufNew autocommand triggers a FileType > autocommand is a bug itself, since autocommands shouldn't > nest (see :h autocmd-nested). But I haven't looked into > the detail, why the FileType autocommand is triggered. > (And I have a feeling, that when this behaviour is > changed, it might actually break a lot of ftdetect > scripts.) I was under the impression that nesting only applied to :e and :w. The documentation at `:h setfiletype` implies to me that it does nest, hence the inclusion of that command. You can even set 'ft' within a FileType autocommand and then trigger a different FileType autocommand. --Antony -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug in ftdetect?
On May 24, Christian Brabandt wrote: > [...] > > However, I think you might have found a bug here. Your > ftdetect script does this: I don't know that I'd characterise it as a bug, since this: > autocmd BufNew,BufNewFile,BufRead *.md :set filetype=markdown > > The :args command does fill the argument list, calls > ex_next() which calls eventually alist_set() and then > iterates over the argument list [... firing off > autocommands ...]. So in the end, we are iterating over > the whole list of arguments and call autocommands, for > buffers that are not even going to be displayed next. ... is what I'd expect from reading :h bufnew. > [... patch to prevent filetype autocmd firing during > loading the args list ...] Bug or not, this seems like it could be helpful. --Antony -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug in ftdetect?
On May 24, Frew Schmidt wrote: > [...] > > Maybe a dumb question, but why would BufNew be more expensive > than BufRead? Shouldn't the filetype stuff get run either way? > I wouldn't expect BufRead to take 500ms and BufNew to take > multiple seconds, would you? The bufnew autocommands happen all at once. Change your autocommand to this instead: au bufnew *.md echo 'markdown bufnew' au bufread *.md echo 'markdown bufread' Then :args * and see what happens. I think you should still remove the 'BufNew' from your autocommand (Christian's helpful-looking patch notwithstanding). I can't see what purpose it serves other than to detect name changes. If that's a real requirement, there's buffilepost. --Antony -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim startup profiling
Your colorscheme or vimrc or both appears to be causing
syncolor.vim to go bananas. I'd take a look at the code
there to find out what's going on. filetype.vim and menu.vim
are just big. You can disable loading menu.vim with `set
guioptions+=M` if you don't need it. --Antony
2017-05-24 9:39 GMT+01:00 Ni Va :
> Le mardi 23 mai 2017 21:46:01 UTC+2, Ni Va a écrit :
>> Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit :
>> > > Thank you
>> > Sped up by using a plugin manager supporting lazy loading or as needed
>> > (vim-addon-manager/Neobundle maybe more).
>> >
>> > Typically sourcing twice is not a problem, often guard [1] like guard
>> > has been setup which is a quick workraound which immediately saves most
>> > time.
>> >
>> > Marc Weber
>> >
>> > [1]
>> >
>> > if exists("loaded_")
>> > finish
>> > endif
>> > let loaded_ = 1
>> >
>> >
>>
>> Ok this one seems better than vundle and save me 100ms at startup but I dig.
>> https://github.com/junegunn/vim-plug
>>
>> Thank you Marc !
>
> Ok I save 100ms using the plugin manager vim-plug but not enough for me.
> Is anyone can advise me or explain to me why some files are loaded twice and
> take twice or more times N msec:
> - vim80/menu.vim
> - vim80\filetype.vim
>
>
> Thank you
> _
>
> times in msec
> clock self+sourced self: sourced script
> clock elapsed: other lines
>
> 000.000 000.000: --- VIM STARTING ---
> 000.000 000.000: Allocated generic buffers
> 002.000 002.000: locale set
> 004.000 002.000: GUI prepared
> 004.000 000.000: clipboard setup
> 004.000 000.000: window checked
> 004.000 000.000: inits 1
> 006.000 002.000: parsing arguments
> 006.000 000.000: expanding arguments
> 007.000 001.000: shell init
> 007.000 000.000: inits 2
> 008.000 001.000: init highlight
> 018.000 003.000 003.000: sourcing
> D:\Logiciels\Vim/awesomeplugins/vim/vim-plug-master/plug.vim
> 043.000 000.000 000.000: sourcing
> D:\Logiciels\Vim\awesomeplugins\vim\awl\ftdetect\awl.vim
> 044.000 000.000 000.000: sourcing
> D:\Logiciels\Vim\awesomeplugins\vim\sonictemplate-vim\ftdetect\stpl.vim
> 045.000 000.000 000.000: sourcing
> D:\Logiciels\Vim\awesomeplugins\vim\vim-ps1\ftdetect\ps1.vim
> 046.000 000.000 000.000: sourcing
> D:\Logiciels\Vim\awesomeplugins\vim\vim-ps1\ftdetect\ps1xml.vim
> 047.000 000.000 000.000: sourcing
> D:\Logiciels\Vim\awesomeplugins\vim\vim-ps1\ftdetect\xml.vim
> 052.000 001.000 001.000: sourcing
> D:\Logiciels\Vim\vim80\lang/menu_fr_fr.latin1.vim
> 052.000 002.000 001.000: sourcing
> D:\Logiciels\Vim\vim80\lang\menu_fr.latin1.vim
> 054.000 001.000 001.000: sourcing D:\Logiciels\Vim\vim80\autoload\paste.vim
> 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> 097.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\ftplugin.vim
> 099.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\indent.vim
> 104.000 002.000 002.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 104.000 003.000 001.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
> 104.000 004.000 001.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
> 119.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\syntax/nosyntax.vim
> 122.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 122.000 001.000 001.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
> 122.000 004.000 003.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
> 124.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\syntax/nosyntax.vim
> 127.000 001.000 001.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 127.000 002.000 001.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
> 127.000 004.000 002.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
> 128.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> 129.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\ftplugin.vim
> 130.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\indent.vim
> 132.000 001.000 001.000: sourcing D:\Logiciels\Vim\vim80\syntax/nosyntax.vim
> 134.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 135.000 002.000 002.000: sourcing D:\Logiciels\Vim\vim80\syntax\synload.vim
> 135.000 004.000 001.000: sourcing D:\Logiciels\Vim\vim80\syntax\syntax.vim
> 138.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 140.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 142.000 000.000 000.000: sourcing D:\Logiciels\Vim\vim80\syntax\syncolor.vim
> 142.000 005.000 005.000: sourcing
> D:\Logiciels\Vim\vimfiles\colors\nivacolors.vim
> 143.000 134.000 038.000: sourcing $VIM\_vimrc
> 143.000 001.000: sourcing vimrc file(s)
> 144.000 000.000 000.000: sourcing
> D:\Logiciels\Vim\awesomeplugins\vim\awl\plugin\awl.vim
> 145.000 000.000 000.000: sourcing
> D:\Logi
Re: Bug in ftdetect?
P.S. If you want to detect name changes, there's BufFilePost. --Antony
On 24 May 2017 at 08:17, Antony Scriven wrote:
> Try taking out the BufNew autocmd. That'll get triggered for every
> file in the args list, whereas BufRead is only triggered for the first
> one that's actually edited. FWIW 'BufNew' is not in the template
> ftdetect file in the docs. --Antony
>
> On 23 May 2017 at 22:28, Frew Schmidt wrote:
>> On Tuesday, May 23, 2017 at 12:58:16 PM UTC-7, Bram Moolenaar wrote:
>>> I'm afraid this doesnt make any sense. I would suggest to reinstall
>>> Vim, making sure you first delete all Vim related files (make a backup
>>> of your preferences somewhere).
>>
>> Well I have already repro'd this on a fresh 7.3, 7.4, 8.0, and system 8.0.
>> Here's a reproduction using docker, with no dotfiles or even system vim
>> installed:
>>
>> $ docker run -it --rm library/buildpack-deps bash -l
>> $ git clone git://github.com/vim/vim
>> $ make
>> $ make install
>> $ mkdir -p ~/.vim/ftdetect
>> $ echo 'autocmd BufNew,BufNewFile,BufRead *.md :set filetype=markdown'
>> > ~/.vim/ftdetect/markdown.vim
>> $ mkdir testing
>> $ cd testing
>> $ touch {1..500}.md
>> $ vim
>> :args *
>>
>> It still happens, and this is from master, today.
>>
>> If you don't have time to check this yourself I get it. I have multiple
>> workarounds at this point.
>>
>> Thanks,
>> fREW Schmidt
>>
>> --
>> --
>> You received this message from the "vim_use" maillist.
>> Do not top-post! Type your reply below the text you are replying to.
>> For more information, visit http://www.vim.org/maillist.php
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "vim_use" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to vim_use+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Bug in ftdetect?
Try taking out the BufNew autocmd. That'll get triggered for every
file in the args list, whereas BufRead is only triggered for the first
one that's actually edited. FWIW 'BufNew' is not in the template
ftdetect file in the docs. --Antony
On 23 May 2017 at 22:28, Frew Schmidt wrote:
> On Tuesday, May 23, 2017 at 12:58:16 PM UTC-7, Bram Moolenaar wrote:
>> I'm afraid this doesnt make any sense. I would suggest to reinstall
>> Vim, making sure you first delete all Vim related files (make a backup
>> of your preferences somewhere).
>
> Well I have already repro'd this on a fresh 7.3, 7.4, 8.0, and system 8.0.
> Here's a reproduction using docker, with no dotfiles or even system vim
> installed:
>
> $ docker run -it --rm library/buildpack-deps bash -l
> $ git clone git://github.com/vim/vim
> $ make
> $ make install
> $ mkdir -p ~/.vim/ftdetect
> $ echo 'autocmd BufNew,BufNewFile,BufRead *.md :set filetype=markdown' >
> ~/.vim/ftdetect/markdown.vim
> $ mkdir testing
> $ cd testing
> $ touch {1..500}.md
> $ vim
> :args *
>
> It still happens, and this is from master, today.
>
> If you don't have time to check this yourself I get it. I have multiple
> workarounds at this point.
>
> Thanks,
> fREW Schmidt
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_use+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Spell checking a word straddling @Spell and @NoSpell
Hi folks If a word straddles two syntax items, and the first allows spell checking but the second does not, then spell checking still occurs on the word as a whole. So it looks like the spell clusters define where spell checking can start, but not where it stops. Is this intentional? If so, is it in the documentation? Nothing leapt out at me, so maybe the documentation at `:help spell-syntax` could do with additional details in that case. Example: :new :set spell :put='xxxwordxxx' :syn match search 'xxx' contains=@NoSpell 'wordxxx' is highlighted as a bad word. Version 8.0.046 --Antony -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim wiki editable by git
On 24 February 2013 23:34, Marc Weber wrote: > As you all know I wrote VAM to solve a problem: Vim plugins > distribution. > > The Vim community suffers from a second problem: There > are many plugins - some are outdated - and its sometimes > hard to find the "jewels" - because they may be hosted on > github only. There is a wiki, but its not integrated in > the main site - neither is it easy for external people to > hack on it just using what they know best: "Vim" (right?) > > For this reason I'd like to start a wiki like text file > based git repository which summarizes the most useful > tools (and maybe alternatives) so that people who want to > find answers about: "How to I most efficiently code xy" > or do "z". > > [...] I agree there's a problem. I think vim.org could do with some modernising. > Also would you be interested in joining and helping > maintain such a git based wiki? A wiki is a great idea. And they maintain themselves, courtesy of those who give a shit. I think it should be on vim.org though (I realise this is your ultimate intent too). > Its not about writing comprehensive documentation, rather > about creating an index about which tools are known to > solve a problem. This can be completion, configuration, > running a compiler and more. Agreed. These questions come up *a lot*, and finding the answers with Google is surprisingly difficult. What you get are blog posts saying 'you can hack foo integration into Vim with these custom mappings which happen to rely on custom program x which is in my environment but you'll have to compile it from source ...,' etc. This isn't a criticism: because Vim is so customisable, people can easily whip up their own systems which solve the problem at hand but aren't always helpful for the beginner (or seasoned professional!) trying to learn Python, for example. The current state of affairs is quite fragmented. There's vim.org, the mailing list, the Vim tips wiki, scripts on vim.org, other scripts on Github, discussion on #vim, many questions on Stack Overflow Where to look? Certainly I think the scripts section on vim.org needs a thorough revamp. > Feedback about this idea and ideas are welcome. Well, I also think that vim.org would benefit from a chatroom, Stack Overflow style. I've no doubt it would be popular among new users of Vim. #vim has loads of new users asking questions, and who uses IRC these days? :-) I think, given the enduring popularity of Vim, it needs a centralised resource. --Antony -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ruler / statusline
On 7 November 2012 01:03, John Little wrote:
> On Tuesday, November 6, 2012 6:42:57 AM UTC+13, shawn wilson wrote:
> > rulerformat almost does what i want but it
> > seems to only allow 18 characters in that space.
>
> A bit of experimentation, and 40 characters seems to be
> allowed. I tried
>
> :set ls=1
> :let &ruf = '%40(' . &stl . '%)'
>
> and there was my status line, without the colours,
> sitting on the bottom right. Using 50 gave the same
> result.
Yeah, last I checked, the maximum allowed by the
%{width}{item} notation was 50-or-so chars. To get round
this I wrote a function to manually pad out the status line
with spaces. (Cos I liked the nvi way of having the line and
col in the centre of the statusline.) --Antony
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: ruler / statusline
On 5 November 2012 17:42, shawn wilson wrote: > [...] > > i want a status bar that doesn't take up an extra line. > so, basically something that takes up the line where > i enter commands and goes away when i enter commands. > rulerformat almost does what i want but it seems to only > allow 18 characters in that space. it's not that big of > a deal, i just like the information statusline gives but > want the extra line of real estate. Well, this is one of the few things that nvi gets right. If this is more important to you than anything else, use nvi. Otherwise `:set ls=2` and suck it up. You might be bikeshedding a little! :-) --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Two search patterns
On 23 January 2011 21:17, Tim Chase wrote: > [...] > > Case #2: > > Start Vim (-u NONE) on a document > Perform a replacement (either a null-op, or just the > first-in-a-line with further matches later in the line, > or a replacement that allows for the pattern to be found > again) > > :%s/pattern/& > > Hit "n" to find the next instance of the pattern or use > "/" with an empty pattern. I get > > E35: No previous regular expression > > [...] It does indeed seem odd. Interestingly you can prevent this from happening by starting vim with $ vim -u NONE --cmd "set vi='0" --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Context aware syntax?
On 20 April 2010 11:46, Ovid wrote: > I'm using a simple syntax file to highlight the TAP > protocol > (http://en.wikipedia.org/wiki/Test_Anything_Protocol). > The syntax can be found here: > http://github.com/threebytesfull/perltest/blob/master/syntax/TAPVerboseOutput.vim > > There are two problems I would like to address. First, > TAP is essentially a series of "ok/not ok" lines followed > by an optional sequential number: > > 1..5 > ok 1 - this is a test > not ok 2 > ok - another test # number optional, assumed as 3 > ok > ok 5 # number MUST be 5 because this is fifth result > > Is there anyway to highlight a syntax error if the fifth > "ok/not ok" line should have the number 5, but actually > has a different number? Shouldn't you write a unit test for this? :-) --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_use/subscribe?hl=en
Re: Is there a variable containing all tokens that matched a regex search term?
On 10 April 2010 12:29, Christian Brabandt wrote: > Hi tomPorter! > > On Fr, 09 Apr 2010, tomPorter wrote: > > Is there a way to create a new window and populate it > > with only the found items? You snipped the rest of the specification. > I would do it like this, which means > :redir => a " redirect output into variable a > :g/&&/ " print all lines matching the pattern && > :redir end " end redirection > :vert new " open a new window > :put =a " put the result into that window That's not what the OP asked for. --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php To unsubscribe, reply using "remove me" as the subject.
Re: Is there a variable containing all tokens that matched a regex search term?
On 9 April 2010 22:25, tomPorter wrote: > If I enter a regex search term, all occurrences of the > matched items in a window will be highlighted. > > Is there a way to create a new window and populate it > with only the found items? > > OR is there a variable that contains all items matching > the regex search term? > > Example: > > A colleague is working on a some large files where we use > substitution variables than start with '&&'. Assume > these are terminated by white space, so are 'words' to > vim. > > [...] For a quick a quick hack, try this. :let tokens=[] :%s/&&\S\+/\=add(tokens,submatch(0))/g :undo :new :put=tokens --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php To unsubscribe, reply using "remove me" as the subject.
Re: How powerful is language build in vim compare with the language build in emacs?
On 28 March 2010 09:25, Teemu Likonen wrote: > [...] > > GCC 0.47 seconds (the hand-optimized version) > SBCL 0.67 seconds (with DECLARE and THE expressions) > GForth 3.8 seconds (the hand-optimized version) > SBCL 9.5 seconds (without DECLARE and THE expressions) > Python 35 seconds > > (Common Lisp has dynamic typing by default but programmer > can use DECLARE and THE expressions to give hints to the > compiler about variables' type. They help optimizing the > compiled code.) > > DISCLAIMER: My tests may suck so I suggest everyone do > better ones. :-) :-). Well I think I should mention that GForth is VM based, or it was last I looked. A fast commercial Forth is probably pretty close to the optimised SBCL. --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: No more 8-character limit?
On 29 March 2010 19:30, Yakov wrote: > On Mar 29, 5:46 pm, Tony Mechelynck > wrote: > > > Even on later Windows systems, 8.3 names still exist > > because they are > > Are we going to rename vim to something like > visualeditorcompatiblewithvi now ? Why? Not everything warrants a catchy name. > I think the argument confuses two different things, > (a) 8.3 limit of APIs or of filesystem, and > (b) tendency of [unix] people to abbreviate filenames and > variables *really short*. > > Beleive it or not, some people will abbreviate really > short, no matter what's filename limit. You've never needed more than eight letters? --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: 'w' command to actually move to the next word
On 26 March 2010 02:38, AK wrote: > Antony Scriven wrote: > > [...] > > > Well, if you're doing it properly you should perhaps map > > w to a function. Maybe something along the lines of: > > > > nno :silent call MyWFunction(v:count1, > > ...) > > ono ... maybe something slightly different ... > > > > Because you just know that there will be corner cases > > that require special handling. > > Indeed, I'm also thinking about that because I find > :hlsearch very useful and doing /\i\+ necessitates > mapping :nohl after it, but this leads to some ugly > flicker in gvim. So, if someone more experienced than me > makes a function that'd be awesome; if not, I will > eventually make one myself I guess. No, make one yourself now. It will be instructive. And if it doesn't work send what you do have to the list and we'll help. And that way it will not be instructive just for you but also for other readers of this list. > My thinking on this issue is that w/b would be much > easier to move around than f/F in most cases if, well, > w/b worked sensibly. The trouble with w/b is that my > brain just doesn't parse a few punctuation chars together > as a word [...] Well that's why I use / and ? almost exclusively for moving about: it's consistent, works for small and large distances, and if you can touch-type is about as instantaneous as you can get. But I probably would make use of a `w' that worked as you've described. Things such as `dw' will require careful thought however. I might be inclined to leave them as they are. --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: 'w' command to actually move to the next word
On 26 March 2010 01:56, Tim Chase wrote: > Sven Guckes wrote: > > > > * AK [2010-03-26 02:11]: > > > > > > Is there any way to get vim's 'w' command > > > (and similar) to move from word to word? > > [...] Well a complete definition of what the OP meant by `word' was not given, but I assumed it to be /\i\+/ which at least matched the example give.. Let's go with that for the sake of argument. > A nice thought, but given the OP's original condition, it > does seem weird that "w" stops where "\<" wouldn't match, > and where 'iskeyword' isn't a match. [...] These days it sounds a bit odd saying this but I guess this is vi-compatible behaviour. > [...] Even more confusing, if you issue > > :match Error /\w/ > > it doesn't highlight the "<" or "=" characters as "word" > characters, despite the same usage of "word" in the > descriptor (per ":help word", a "word" includes sequences > of non-whitespace non-keyword characters surrounded by > whitespace). Yes, the help for "\w" explicitly gives the > character-class, but that seems in conflict with the > definition of "word". Sigh :-/ Fun fun fun! > I agree with the Antony's response that, to get the > "intuitive" behavior of jumping between 'isk'-defined > "word"s, one would have to do a mapping. I'd likely use > > :nnoremap w /\ > :nnoremap e /\>/e- > :nnoremap b ?\ > > (and their kin for visual-mode). The only oddity is that > "w" now respects 'wrapscan'. Ha! Yes, once you start doing w then you are compelled to do others as well. Well, if you're doing it properly you should perhaps map w to a function. Maybe something along the lines of: nno :silent call MyWFunction(v:count1, ...) ono ... maybe something slightly different ... Because you just know that there will be corner cases that require special handling. > I originally thought the OP was jesting or had some odd > setting; but tried it (with my default vimrc and with "-u > NONE") just to make sure, and indeed it doesn't behave as > I would have expected. I can't say I hit it (the "w" or > the issue at hand) often because I usually use > t/T/f/F/;/, for my horizontal jumping, or use the "iw" > text-object for deleting/changing/visualizing the current > word. Well I mostly use / and ? for moving about, but the OP's question makes a lot of sense to me too. --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: 'w' command to actually move to the next word
On 26 March 2010 00:42, AK wrote: > Is there any way to get vim's 'w' command (and similar) > to move from word to word? > > E.g.: tar > > I want vim to see this as 4 words separated by non-words > (i.e. whitespace and punctuation). After all, tar, foo, > bar and jar are words and =" is certainly not a word! And > that's how I want vim to behave. I want to be on 't' and > hitting '3w' should take me to 'j'. Hmm, that's a good question; I wouldn't mind knowing that myself. The following will work for your example. :nmap w /\i\+ But it will need refinement to work well. Let me know if there's an elegant solution! --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: How powerful is language build in vim compare with the language build in emacs?
On 25 March 2010 23:17, Tony Mechelynck wrote: > On 15/02/10 23:33, Ben Schmidt wrote: > [...] > > > > Vim is essentially an imperative procedural language. > > Lisp is essentially a functional language. Most people > > find imperative languages easier to understand because > > they're a bit more like recipes and a bit less like > > Mathematics! Some people find the reverse, though. > > > > Lisp is certainly more elegant than Vimscript, which is > > just a mess, with as many exceptions as rules, and > > different escaping mechanisms needed every few lines. > > If you want to do serious programming, Lisp is the way > > to go. If you want a quick hack, Vimscript is probably > > easier. Depends on the hack. Vimscript is a domain-specific language, so for quick hacks on text files, yeah. > [...] (also how to compute a square root, but that wasn't > a required subject; I learnt it from the arithmetics book > without even telling the teacher, because it was my kind > of fun). [...] > > Lisp looks like Volapük to me; Then check out the SICP lectures. The videos are online for free. The first one teaches you the basics of Lisp (well, Scheme) in a few minutes, and it (or maybe the second one, I can't remember) shows you how to compute a square root :-). It really is a wonderful language. > Vimscript I can (more or less) understand. Of course, the > Blob argument invalidates this line of reasoning, letting > it even appear that "therefore" (which I challenge as > "the argument of obscurity") Lisp would be "more > powerful" than vimscript. What is "serious" programming > anyway? Not having to prefix function parameters with `a:'! :-) > AFAICT, the collection of Vim plugins run the whole gamut > from the most serious to the most fun; but of course, for > heavy number-crunching, vimscript has the same > performance liabilities as most interpreted languages -- > maybe not really all of them: so perhaps I could say that > for serious programming, FORTH is the way to go? ;-) Not sure what you're saying here. > And BTW, (in answer to another post) how to compute an > arbitrary sum (of zero or more terms)? IIRC (it was > several decades ago): > > 0 > 1 + 2 + 3 + 4 + > PRINT > > 10 > > Simple isn't it? (And the 0 can be left out if you also > omit the first +) By the time you've finished entering > the data, you have the result. :-P Now put your HP calculator away. :-) --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Jump to Javascript function prototype
On 23 March 2010 07:20, Gareth Oakes wrote: > [... on omnicompletion of ECMAScript ...] > > It now references my tags file (yay!). The only problem > now is that some tags can't be resolved. For example, > I have an object A and object B. Each object is of > a different "class". Each object has a "doSomething()" > method available, but the parameters are different > depending on whether I'm looking at object A or B - how > to identify which doSomething() tag to lookup?? You can't: it can change at runtime. > In this regard, I'm starting to think that Vim is not > well-prepared for the explosion of object-orientated, > loosely typed, scripting languages. The omnicompletion > and tags functions would need to implement an interpreter > for each language in order to figure out what the correct > completion/tag lookup is meant to be... sounds tricky! Not good enough: it can change unpredictably at runtime. Also, please try not to top-post. Thanks! --Antony -- Mailing list guidelines: http://groups.google.com/group/vim_use/web/vim-information -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: best C++ plugin for vim?
On 12 March 2010 00:58, Aman Jain wrote: > I would like to know what plugins are most useful while > writing C++ code. I am currently using trinity which is > a combination of Taglist, Source Explorer, NerdTree. > > I can see the definitions and all that simple stuff. > > But what seems to be lacking here is the understanding > of C++ inheritance structure. > > For example, if I am about to declare an object for a C++ > class, I want to know what is the class hierarchy, i.e. > which class was the base class, how many classes have > been derived from this particular class, and stuff like > that. Maybe a documentor would help. E.g. doxygen: http://www.stack.nl/~dimitri/doxygen/index.html And an example: http://xerces.apache.org/xerces-c/apiDocs-3/hierarchy.html --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Unexpected behaviour of File browser in multi-windows environment
On 4 March 2010 17:01, Patrick Texier wrote: > Le Thu, 04 Mar 2010 10:58:18 -0500, Charles Campbell a écrit dans le > message <4b8fd89a.7080...@nasa.gov> : > > > Unfortunately Content-Type: text/plain would not have > > guaranteed fixed width. Necessary for proper viewing. > > text/plain should be read only using a fixed font. It's > not the sender's problem. > > If you want send HTML, use multipart with text *and* html. It might be worth mentioning that in google groups and gmail at least, there is an option to display a message in a fixed width font. --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Please, suggest a font!
Dotan Cohen wrote: > I have been trying to move to GVIM from Kate, but as > I prefer proportional fonts I find the GVIM look to be to > hard on my eyes. I have been looking up and down for > a decent font that does not look outdated in GVIM yet has > good differention betweel 0/O, I/l/1, and other common > confusions. Could someone please recommend a font! Try Consolas or Inconsolata. --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: math, utf-8, and windows
Charles Campbell wrote: > I've written a math keymap and menu plugin > (http://www.vim.org/scripts/script.php?script_id=2723) which generates > various math-related glyphs with utf-8 encoding. > > As a sampling... (which may or may not show up properly > in some browsers, so this is something of an experiment > in itself) > > abcdefghijklmnoprstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ > αβψδϵφγηιξκλμνοπρστθvωχυζ ΑΒΨΔΕΦΓΗΙΞΚΛΜΝΟΠQΡΣΤΘΩWΧΥΖ > > 0123456789 > ⁰¹²³⁴⁵⁶⁷⁸⁹ > ₀₁₂₃₄₅₆₇₈₉ > > ⌠ ⎡⎤ > ⎮ ⎢⎥ > ⌡ ⎣⎦ > > (and there's many more) > > Now for my question -- I use Luxi Mono under Linux, but > is there a font that will display these utf-8 characters > under Windows (and, if so: how to install it)? It's not very well hinted, needing 12pt or above, but the FreeMono font displays all your sample glyphs correctly in Windows. --Antony -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: How powerful is language build in vim compare with the language build in emacs?
On 20 February 2010 00:38, bill lam wrote: > ven, 19 Feb 2010, Antony Scriven skribis: > > Not 100% sure what you mean here, but writing HOFs > > shouldn't be complex. I hope you don't mind me > > switching to what is a more familiar language for me. > > > > zipWith = function(fn,list1,list2) > > map(function(val) fn(val[0],val[1]), zip(list1,list2)); > > the list1 and list2 are arguments that I meant to > eliminite, that is, write a zipwith without explicit > appearance of list1 and list2. > > something like this, > http://en.wikipedia.org/wiki/SKI_combinator_calculus Why you'd want to do that is anybody's guess! But if ECMAScript properly supported currying you could write: zipWith2 = function(fn) compose(map(function(val) fn(val[0],val[1])), zip); I wrote a curry function and faked compose and the above does work, but you have to invoke it as zipWith2(fn)(list1,list2), which is ugly but amounts to the same thing. And now we're wy off-topic. --Antony -- You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php
Re: How powerful is language build in vim compare with the language build in emacs?
On 19 February 2010 07:34, bill lam wrote: > ven, 19 Feb 2010, Teemu Likonen skribis: > > > [...] > > > > Good. Then perhaps (reduce ) is > > also in the category of easy-to-read. I thought I had > > found an area in Lisp code which is difficult to > > understand quickly but it seems I was at least > > partially wrong. Well it's going to depend on an individual's background of course, but I think this style of programming is quite prevalent now. It's available in many mainstream languages and, don't forget, VimL has map() and filter(). > It is fairly easy to understand when the function apply > to an argument, try another example to define a higher > order function in terms of purely other functions without > explicit appearance of argument. Not 100% sure what you mean here, but writing HOFs shouldn't be complex. I hope you don't mind me switching to what is a more familiar language for me. zipWith = function(fn,list1,list2) map(function(val) fn(val[0],val[1]), zip(list1,list2)); I'm assuming that map and zip have been defined and that you know how they work, of course :-). --Antony -- You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php
Re: How powerful is language build in vim compare with the language build in emacs?
On 18 February 2010 12:14, Teemu Likonen wrote: > [...] > > Higher-order functions are standard stuff in Lisp but > probably weird for many people because the the concept is > not common and the feature of first-class functions is > not available in many languages. Nevertheless they are > powerful. [...] Most comp sci degrees teach functional programming in the first year now. And don't forget that the world's most popular programming language includes reduce and other HOFs as standard. --Antony -- You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php
Re: How powerful is language build in vim compare with the language build in emacs?
On 18 February 2010 12:53, Tom Link wrote:
> > But really Common-Lispers would write the same functionality with this:
> >
> > (reduce #'+ '(1 2 3 4))
Well that's just (+ 1 2 3 4) :-)
> So cl with its vast standard library provides a function
> for that. That's cool of course but nothing stops you
> from implementing such a function in vimscript, perl or
> whatever.
>
>
> function! Reduce(ffn, list) "{{{3
> if empty(a:list)
> return ''
> else
> let list = copy(a:list)
> let s:acc = remove(list, 0)
> let ffn = substitute(a:ffn, '\', "s:acc", 'g')
> for val in list
> let s:acc = eval(substitute(ffn, '\', val, 'g'))
> endfor
> return s:acc
> endif
> endf
>
>
> echom Reduce("v:val + v:acc", [1, 2, 3, 4])
> echom Reduce("v:val> v:acc ? v:val : v:acc", [1, 2, 3, 4])
> echom Reduce("'v:val' < v:acc ? 'v:val' : v:acc", split("characters",
> '\zs'))
Don't do this with string processing! Much better with funcrefs.
fun Reduce(funcname, list)
let F = function(a:funcname)
let acc = a:list[0]
for value in a:list[1:]
let acc = F(acc, value)
endfor
return acc
endfun
fun Add(a,b)
return a:a + a:b
endfun
fun Max(a,b)
return a:a > a:b ? a:a : a:b
endfun
fun Min(a,b)
return a:a < a:b ? a:a : a:b
endfun
let list = [1,2,3,4,5]
echo Reduce('Add', list)
echo Reduce('Max', list)
echo Reduce('Min', list)
--Antony
--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
Re: How powerful is language build in vim compare with the language build in emacs?
2010/2/18 Mikołaj Machowski : > Dnia 18-02-2010 o godz. 13:14 Teemu Likonen napisał(a): > > > > > (reduce #'+ '(1 2 3 4)) > > > > To get sum of table elements you can use this in Vim: > > exe 'echo ' join([1,2,3,4], '+') > > I know this is not what are you really talking about but I really, > really like this trick :) Actually, they're the same (give or take). :-) --Antony -- You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php
Re: how to fix (how did I break it?) my language syntax indentation
On 13 February 2010 09:09, Linda A W wrote: > Linda W wrote: > > > [... perl indent script not working; closing brace in > > wrong place ... ] > > [...] just found out "we" didn't have "ai" set)... > [...] Perl indenting works without 'ai' set. Maybe 'indentkeys' is at fault. --Antony -- You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php
Re: Programming With Proportional Fonts?
On 10 February 2010 20:45, Spencer Collyer wrote: > On Fri, 05 Feb 2010 00:20:44 -0800, Linda A W wrote: > > [...] > > Personally I'd rather the time and effort that would be > wasted adapting Vim to support proportional fonts was > instead directed towards making it even more featureful > for what it is designed to do - edit text. You mean features like making text readable? :help design-not > Spencer > > ps Are you the same Linda who got into a strop last year > when being asked not to send out messages in HTML text? Miaow! -- You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php
Re: Programming With Proportional Fonts?
On 5 February 2010 08:20, Linda A W wrote: > Paul wrote: > > > > On Sat, Jan 23, 2010 at 12:21:57PM +0200, Nicolas Aggelidis wrote: > > > > > > whats your opinion? Repeat the question in the body of your mail. > > I prefer monospaced. Proportional looks untidy when you > > have a list of similar lines together and the only > > difference is between then are a few characters, which > > happen to change the length of those lines. That's a very specific situation. I think both have their place. > > > is there anyway to use some proportional fonts ,like > > > Lucida Sans, in gvim (windows/linux)? > > > > Edit -> Select Font... > > > Sure...ok, let's see...I have that font... > > Edit -> Select Font... > > Hmmm...seems like it isn't on my list of allowed fonts. > > Wonder why that is? You'd think Lucida Sans unicode > would work on MS Windows where it's a native > font...hmmm... Hands up who hasn't tried that before. > Lets fire up linux...(*sound of 747 revving up...*)...and > check my flaps,er check my Cygwin > X-server...yup...*check*and gvim!... Blink...there's > the window...now try "Select font...". Ahhh. Now there's > the font I want... I really, really don't want to type `lol' in a technical mailing list but I just can't help myself! You do realise you are posting humour to the vim mailing list? Have you done your pre-flight sanity checks? > Um...slight problem...it's double spaced and its > NOT proportionally space, but it is > displayable...hmmm...not very useful at double spaced > height. > > Maybe a better question would be something along > the lines of do you think it would be possible for vim to > function as well as a 10 year old copy of MS-Word when > using a proportional font and allow one to edit a text > document with such? Now you're talking! > *bristling* at rocks being prepared for inevitably > stoning...again...so old. Long live proportional fonts!!! > So sad favorite editor doesn't have option to allow...(I > know, it would be nontrivial to support, as a move > 'down' would mean what? down to position on screen most > likely, but it wouldn't mean you'd end up on the same > column on the line below as you were on the line > above > > [...] Sam and acme use proportional fonts, as does much Plan9 stuff. But neither are quite like vim. Worth checking out though. Sentences getting shorter. And shorter. Proportional fonts are nice, but I'm not sure that they're nice enough to be worth the effort, such as the problems which you mention above. And longer again. --Antony -- You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php
Re: [CURIOUSITY] am i using
On 1 February 2010 03:26, pansz wrote: > [...] > > IMO most serious vim users should compile their own vim. > Only casual users should rely on distribution-specific > version. I'm busy enough that I don't even know what the latest version of Vim is, never mind compile my own. --Antony -- You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php
Re: How long is too long for .vimrc?
2009/2/8 R. Hicks : > I am not running into problems at all. I was just > curious. I am a basic user of Vim and my .vimrc is 305 > lines long (including comments and blank lines). Is there > a point where you modularize it? I am not sure I see the > point there. Is there a "best practive" for maintaining > a .vimrc? 2000+ and no probs. I modularise it using folds. I find lots of small files more of a hassle. --Antony --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: case insensitive iabbrev
2009/1/25 Szymon Guz : > is there any way to have some kind of case insensitive > iabbrev to have it like this: > > iabbrev integer INTEGER > > so all words like these: > > integER > Integer > INTeger > > will be changed into INTEGER? Try this as a starting point. imap guiwdiwa"; --Antony --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Visual feedback on yank?
On Sat, Jan 17, 2009 at 10:11 PM, Gary Johnson wrote: > On 2009-01-17, Wincent Colaiuta wrote: > > Is there any way to get Vim to highlight a range of > > text when I yank so that I can get some visual > > feedback? > > > > [...] > > The solution to that is to visually select the region > first, then yank it. For example, instead of "ytp", do > "vtpy". See Alternatively, try :set incsearch and y/ --Antony --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: scripting: split into seperate files based on line contents
On Wed, Jan 14, 2009 at 5:45 PM, Linus Neumann wrote: > [...] > > What is the script supposed to do? (relevant) The .dat or > .csv file needs to be split up into seperate .txt-Files, > based on certain variables, that are contained in the > .dat/.csv-file. > > Here for a (shortened) example: > > .dat-file might look like this: > > [multiple spaces compressed into one] > 1 1 6,83 5,67 5,916667 > 1 1 4,75 6,33 5,25 6 6,33 > 1 1 4,916667 4,67 6,08 > 1 2 6,08 5,33 5 > 1 2 4,58 4,916667 5,416667 > 1 2 4,33 3,5 5 5,17 > 2 1 > 2 2 > 3 1 > 3 2 > > [...] > > To sum it up: > - Var 1 [field 1] is the file number: fl_grVAR1 > - Var 2 determines mw/wm: fl_grVAR1VAR1.txt > - File should only contain data for the corresponding VAR1/VAR2- > combination, yet not VAR1 & VAR2 > - Attention: >- lines are much longer (not only five, but > ranges of 13 to 18 variables per line - script should > adjust to that) > - script needs to be run on a total of 1800 > lines in 6 seperate files, each having different numbers > of variables - so it should be fairly adjustable. By the > way: Now you see why I need a script to do this) >- if possible, tabs (.dat) or semicolons (CSV) > should be converted to simple single space ( ) (Probably > I can find a way for SPSS to do this in the first place) >- if possible, commas (,) should be converted > to dots (.) (Probably I can find a way for SPSS to do > this in the first place) > > [...] Summat like this? :g/^/s/,/./g|s/\t/ /g|s/^/.w!>>fl_gr/|s/ 1/mw/|s/ 2/wm/|s/ /.txt\r/|-d x|@x How maintainable did you want it? :-) --Antony --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Navigating complicated file hierarchies
On Tue, Jan 13, 2009 at 11:50 PM, Antony Scriven
wrote:
> On Tue, Jan 13, 2009 at 3:22 PM, Per Thulin
> wrote:
>
> > [...]
> >
> > One simple little integration thing that would fix it all
> > would be if could do this:
> >
> > 1. From vim, run :shell
> > 2. Find the files I'm after
> > 3. Open these in the vim session I ran :shell from.
> >
> > [...]
>
> $>~/.x pwd
> $ vim
> :cd readfile(expand('~/.x'))[0] | e.
Oops, I meant :exe 'cd' readfile(expand('~/.x'))[0] | e.
> You don't even need to script this last one: the shell
> command is easy enough to type and you can get the vim
> command from your history, e.g. :cd r --Antony
And, similarly, :exe --Antony
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Navigating complicated file hierarchies
On Tue, Jan 13, 2009 at 3:22 PM, Per Thulin
wrote:
> [...]
>
> One simple little integration thing that would fix it all
> would be if could do this:
>
> 1. From vim, run :shell
> 2. Find the files I'm after
> 3. Open these in the vim session I ran :shell from.
>
> Hold your hats now, but Emacs users can do this. From
> Emacs they do the equivalent of running :shell, then
> navigate to another directory which becomes Emacs working
> directory. Now they can do the equivalent of :e file in that directory>.
If you have a client-server enabled vim:
$ vim --servername VIM1
:shell " or
$ cd ~/tmp
$ vim --servername VIM1 --remote *.txt; exit # or fg
Or, from any shell to any vim:
$ >~/.x; for f in *.txt ; do >>~/.x readlink -f $f; done
$ vim
:for f in readfile(expand('~/.x')) | exe 'argadd' f | endfor
This is essentially what Itai Fiat does elsethread, but you can
do this in any shell and read the files into any vim instance.
Or, like your emacs example:
$ >~/.x pwd
$ vim
:cd readfile(expand('~/.x'))[0] | e.
You don't even need to script this last one: the shell
command is easy enough to type and you can get the vim
command from your history, e.g. :cd r --Antony
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Easiest way to insert a blank line?
On Fri, Jan 9, 2009 at 11:08 PM, Tony Mechelynck wrote: > On 09/01/09 15:52, Ben Fritz wrote: > > > > > > On Fri, 09 Jan 2009 16:41:45 +0800, Tony Mechelynck wrote: > > > > > Have you tried the about:config page (or opera:config > > > or whatever Opera calls it, I'm no Opera guru)? > > > > It would be opera:config. [...] > > If filtering on "address" leads nothing useful, [...] Wtf has any of this got to do with the `Easiest way to insert a blank line?'? C'mon dudes, with the collective IQ of this list I'm sure we can manage a relevant subject line if we try hard enough. --Antony P.S. the above was taken from my book `Embroidery and Horsemanship' in the chapter on Fourier transforms. --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: top/bottom posting [Re: an independent Chinese IME is available]
On Thu, Jan 8, 2009 at 10:09 PM, Sean wrote: > > > [...] > > [...] > > Well, data file in binary is not an option. [...] Which is nothing to do with the subject line. C'mon people, get it together! --Antony --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: new to VIM
On Wed, Dec 31, 2008 at 12:27 PM, Tony Mechelynck wrote: > On 31/12/08 11:14, Antony Scriven wrote: > > [...] > > > > Mappings are short key sequences. What happens when you have > > lots of :abbrevs? You need longer names so that you can > > remember them easily. Long key sequences for mappings are > > unwieldy: you can't see what you are typing and they time > > out. You can backspace and correct a typo in an :abbrev and > > it will still work. --Antony > > With 'showcmd' on, you see what you are typing for > a multikey mapping at the bottom right of the screen. ... until you make a typo or the mapping times out. --Antony --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: new to VIM
2008/12/31 pansz :
> 程梁 写道:
> > Thanks a lot for your help. What I want to get is that,
> > turn off space or enter for expanding abbreviations and
> > make other keys such as Ctrl+B do the same thing.
> > Because I maybe define a lot abbreviations and I cannot
> > map so much keys to an abbreviation. But thank you all
> > the same.
> >
> > [...]
> > What you need is a mapping, not abbr, see :help map for
> > that.
> >
> > for example:
> >
> > :imap for (i=0; i<; i++) {7hi
> >
> > Would map something you like to Ctrl+B, Try and see.
>
> I wonder whether you have tried my example or not, does
> it work for you? Why you insist doing an abbreviation
> while mapping suits your need a lot better? [...]
Mappings are short key sequences. What happens when you have
lots of :abbrevs? You need longer names so that you can
remember them easily. Long key sequences for mappings are
unwieldy: you can't see what you are typing and they time
out. You can backspace and correct a typo in an :abbrev and
it will still work. --Antony
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: new to VIM
2008/12/29 Ben Schmidt : > I don't know of any way to turn off abbreviation > expansion when you use space or enter, though. That's quite easy: imap and define your abbrevs like so: ab foo foobarbaraann() Then foo will expand to foobarbaraann() but foo will not. Obviously foo will also expand to foobarbaraann(), but you're not going type that. Are you? --Antony --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Indent with tabs, align with spaces
2008/12/24 Matt Wozniski : > On Tue, Dec 23, 2008 at 11:26 PM, Tony Mechelynck wrote: > > > > On 24/12/08 01:04, Oliver Zheng wrote: > > > > > > So it seems like there is no feature available. > > > I guess I'll request this feature on vim.org. > > > > It's hard for Vim to guess that in > > > >if (a == b && > >c == d && > >e == f) > > > > you want c aligned with a (and not, let's say, one > > level of indent further than the "if"). > > Unless you're using, say, cindent, or an indentexpr, > which give you absolute control over that sort of thing. > > > However, as others have repeatedly said, with ":set > > autoindent copyindent" (and maybe 'preserveindent' but > > I'm less sure what it does), when you hit Enter after > > "c == d &&", the third line will get the exact same > > mixture of tabs and spaces as the second one. > > Which is still a far cry away from properly using tabs > for indenting blocks and spaces for aligning code > automatically. Like I said before, vim just isn't > capable of doing the right thing here, and changing that > would require making a way for indentexpr's to specify > "number of spaces of indent" and "number of spaces for > alignment" independently. This is verging on the autistic. The main problem with complicated indentation schemes is getting all programmers in a group to follow them. Complicated suggestion: write a (simple) map to insert the correct number of spaces for you. Simple suggestion: just use two extra levels of indentation for continuation lines, like many people. --Antony --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "vim_use" group. To post to this group, send email to vim_use@googlegroups.com To unsubscribe from this group, send email to vim_use+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/vim_use?hl=en -~--~~~~--~~--~--~---
