How to generate auto increased number lines
Hello, Everybody, How to generate auto increased number lines in vim? For example， a[0] a[1] a[2] a[3] .. Thanks! -- 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 to generate auto increased number lines
Harvey Li [11-09-18 09:28]: > Hello, Everybody, > How to generate auto increased number lines in vim? > For example， > a[0] > a[1] > a[2] > a[3] > .. > Thanks! > > -- > 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 Hi Harvey, you can do this conveniently with a macro definition. First type the first line by hand: a[0] then start defining a macro by entering ESC q q then do the editing work yyp end your macro definition by entering q Now position your cursor where the '*' (dont type this) is: a[0] a[1] * To execute the macro type . The result is a[0] a[1] a[2] . If you want to execute it n times preceed AltGr-q by the number n of executions you want to be executed. HTH! Best regards and have a nice weekend! mcc -- Unix,vim and a IBM model M - what does it need more? -- 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: Using :let to view a wildcard of variables
In reply to ``Using :let to view a wildcard of variables''
sent 17 September 2011, Saturday by David Fishburn
> Will display all variables currently defined in Vim.
>
> One thing I have always wanted to do is:
> :let my_prefix.*
let d={}
for [var, d.val] in filter(items(g:), 'v:val[0]=~#"\\v^my_prefix"')
echo var."\t" d.val
endfor
. You can also use t:, w:, b:, v: dictionaries, or even create a command:
let s:scopes=split('g b v w t')
let s:types={type(''): 's',
\type(0) : 'n',
\type({}): 'd',
\type([]): 'l',
\ 2: 'r',}
if has('float')
let s:types[type(0.0)]='f'
endif
function s:FindVars(regex)
let vars=[]
for scope in s:scopes
let vars+=map(filter(keys({scope}:), 'v:val =~# a:regex'),
\ 'scope.":".v:val')
endfor
let maxvarlen=max(map(copy(vars), 'len(v:val)'))
for var in vars
echo printf('%-*s', maxvarlen, var) s:types[type({var})] {var}
endfor
endfunction
command -nargs=1 FindVars :call s:FindVars()
The regex will be used to search for variable name without a scope. If you
want to search for variable name with scope, exchange `map(' and `filter(' in
`let vars+=' line (and their second arguments, of course).
Original text:
> Vim 7.3.315
>
> My plugins all use naming conventions for variables.
>
> :let
>
> Will display all variables currently defined in Vim.
>
> One thing I have always wanted to do is:
> :let my_prefix.*
>
> Or something like that to show all variables beginning with my_prefix.
>
> The only way I have come up with a way to do this is:
> :new
> :redir @a
> :let
> :redir end
>
> "ap
>
> :v/^my_prefix/d
>
> Which essentially does want I want, but is a real pushup.
>
> Can any Vimmers suggest a more streamlined approach?
>
> Thanks,
> Dave
signature.asc
Description: This is a digitally signed message part.
Re: How to generate auto increased number lines
vim script,i happened to ask such a question not long before and someone had solve it for me. let i =0 g/^$s//\="a[".i."]"/g | let i+=1 you can check my post here if you could read chinese, http://www.zfanw.com/blog/vim-substitute-script-function.html 2011/09/18 15:25 "Harvey Li" : -- 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 to generate auto increased number lines
there should be a / before the s,sorry. 2011/09/18 17:56 "Chen San" : > vim script,i happened to ask such a question not long before and someone had > solve it for me. > let i =0 > g/^$s//\="a[".i."]"/g | let i+=1 > you can check my post here if you could read chinese, > http://www.zfanw.com/blog/vim-substitute-script-function.html > 2011/09/18 15:25 "Harvey Li" : -- 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: LaTeX syntax misery
On Sun, Sep 18, 2011 at 3:19 AM, William E. Skeith III wrote: > > > - Original Message - > From: Moshe Kamensky > To: "v...@vim.org" > Cc: > Sent: Saturday, September 17, 2011 8:03 PM > Subject: Re: LaTeX syntax misery > > In my experience, the problem is the folding. When I set > foldmethod=manual, the problem (mostly) disappears. > > Moshe > > > > After following your suggestion, the situation is much improved! > Thanks Moshe! > > -WES > > p.s.- 90% of the work I do with the computer is writing LaTeX, so this was > pretty critical. Many thanks! > > > How do you make this problem happen? Does it only happen with very large files? (I'm interested because it sounds like it shows some kind of bug in the syntax code that could show up in other kinds of files.) -- 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 to generate auto increased number lines
On 09/18/2011 08:47 AM, Harvey Li wrote: Hello, Everybody, How to generate auto increased number lines in vim? For example， a[0] a[1] a[2] a[3] .. One method of doing so would be: ia[0]qqyypq@q@q@q That is: i: go to insert mode a[0]: type the first line : go to normal mode qq: start recording a macro into register q yy: yank the current line p: paste the yanked line : increase the number q: stop recording @q: replay the macro, adding the second line @q: replay the macro again, adding the third line As an alternative to repeating @q a few times, you could also use 5@q to repeat it 5 times for example Hope this helps, Jeroen -- website: http://budts.be/ - twitter: @teranex ___ Registered Linux User #482240 - GetFirefox.com - ubuntu.com -- 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 to generate auto increased number lines
On 09/18/2011 08:47 AM, Harvey Li wrote: How to generate auto increased number lines in vim? For example， a[0] a[1] a[2] a[3] You might be interested in this common tip: http://vim.wikia.com/wiki/Generating_a_column_of_increasing_numbers -tim -- 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: Remembering syntax when moving in and out of buffers
On Sep 17, 10:25 pm, "Benjamin R. Haskell" wrote:
> On Sat, 17 Sep 2011, Spiros Bousbouras wrote:
> > If you define a syntax for a buffer , move away and then return is the
> > syntax remembered or do all the syntax commands have to be executed
> > again? Some tests I did indicate it's the latter.
>
> It should be the former.
>
> > Specifically (with simplifications) my .vimrc (on Linux) has
>
> > autocmd BufReadPost,BufNewFile *.myfile source ~/myfile.vim
>
> > and file ~/myfile.vim has
>
> > if exists("b:myfile")
> >finish
> > endif
>
> > let b:myfile = 1
> > syntax match special /special/
> > highlight special term=bold cterm=bold
>
> Either the simplifications have eliminated something important (though I
> don't know what) or something else on your system is interfering. The
> way you've set it up isn't the way a typical filetype-related plugin
> should be laid out (see: :help new-filetype ). The way you've coded it
> will work, but it will get messy, quickly, if you want to add multiple
> filetypes.
I did read :help new-filetype and I thought that the method
mentioned there is too complicated that's why I didn't follow it. It
seems much simpler to me to have different file types be recognised
by extension and then load syntax and anything else I want by
sourcing an appropriate script. Works well enough up to now but I
only have 3-4 different file types.
> > When I edit file.myfile the highlighting works correctly but if I
> > move away and return then there's no highlighting.
>
> Does some plugin from your system set up some kind of autocmd on the
> WinEnter, WinLeave, BufEnter, or BufLeave event(s)?
>
> :au WinEnter,WinLeave,BufEnter,BufLeave
The above command returns
--- Auto-Commands ---
and nothing else. Apart from that , I have
let &loadplugins=0
in /etc/vim/vimrc so I don't think that any plugin is causing the
behaviour.
> On my system, I see about a dozen BufEnter entries, but none that would
> affect a *.myfile buffer. Two in the filetypedetect augroup, one in
> FileExplorer, and the ones in no group are vimball-related. WinEnter
> only lists an autocmd in the matchparen group.
Here's a version of the problem with no simplifications:
File a contains
This is a special line
File b is empty. I do
vim -u NONE a b
:let &verbose=20
:syntax match special /special/
:highlight special term=bold cterm=bold
The word "special" gets highlighted.
2Ctrl-^
"b" 0 lines, 0 characters
Ctrl-^
"a" 1 line, 23 characters
Now "special" is no longer highlighted.
:syntax
No Syntax items defined for this buffer
:syntax match special /special/
The word "special" gets highlighted again. Note that this time I
didn't have to enter the highlight command to get the highlighting.
I would be especially interested if anyone who runs Debian Lenny
would try the above test.
--
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: LaTeX syntax misery
Hi Efraim! On So, 18 Sep 2011, Efraim Yawitz wrote: > How do you make this problem happen? Does it only happen with very large > files? (I'm interested because it sounds like it shows some kind of bug in > the syntax code that could show up in other kinds of files.) This is a well-known problem, that seems to have been caused by patch 7.2.274. https://vimhelp.appspot.com/vim_faq.txt.html#faq-29.7 regards, Christian -- Manche Pferde machen "Muh", aber die nennt man auch Kühe. -- 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
Setting the bold attribute for "Normal" text"
I start a buffer not belonging to any specific filetype. I type some random stuff and then do :highlight Normal ctermfg=green I get green letters. But if instead I do :highlight Normal cterm=bold term=bold I don't get bold text. What am I doing wrong ? -- 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
when Ctrl-Q and Ctrl-V conflict with other short keyword on MS windows xp
hi, On windows xp, Ctrl-V is mapped into paste. so Ctrl-Q is commonly used for visual block select. At sometimes Ctrl-Q is mapped into other functions, such as Ctrl-Q is mapped as exit from MATLAB. In this case, the visual block selection appears to be unavailable. If I want to cancel the mapping of other applications (such as MATLAB), and force Ctrl-Q to be mapped into Vim, what should I do? thank you for your help. ---yakex -- 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: when Ctrl-Q and Ctrl-V conflict with other short keyword on MS windows xp
On Sep 18, 8:12 am, yanzhisheng wrote: > hi, > On windows xp, Ctrl-V is mapped into paste. so Ctrl-Q is commonly used for > visual block select. At sometimes Ctrl-Q is mapped into other functions, such > as Ctrl-Q is mapped as exit from MATLAB. In this case, the visual block > selection appears to be unavailable. > If I want to cancel the mapping of other applications (such as MATLAB), and > force Ctrl-Q to be mapped into Vim, what should I do? > thank you for your help. First, I'm not entirely clear on your problem. Vim and MATLAB are two separate applications. Pressing a key in one should not affect the other, unless you have installed some fancy plugin which makes Vim control MATLAB. Second, it is very easy to map keys in Vim. Since there are so few keys available, the best would be something like: nnoremap The "nnoremap" says "make this mapping apply in normal mode, and don't expanding other mappings while evaluating this one" is the key you will press to trigger the mapping. In general the function keys F2-F12 are not used by Vim and are therefore good candidates for mappings. F1 is just a synonym for :help so that could probably be remapped too. obviously enters visual block mode as normal (since the nnoremap command ignores other mappings). -- 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: Setting the bold attribute for "Normal" text"
On Sep 18, 9:40 am, Spiros Bousbouras wrote: > I start a buffer not belonging to any specific filetype. I type some > random stuff and then do > :highlight Normal ctermfg=green > I get green letters. But if instead I do > :highlight Normal cterm=bold term=bold > I don't get bold text. What am I doing wrong ? See :help highlight-cterm Many terminals are unable to mix fg colors and attributes like bold. You do not specify what term you are using but possibly it does not support this. Have you considered using the GUI (gvim)? -- 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
case-dependent replace
Hi, I would like to know if it is possible to replace 'foo' by 'bar', 'FOO' by 'BAR' and 'Foo' by 'Bar' (or at least the first two), with a single command. Any link or the right :help command would be enough. Thanks a lot in advance, Jose -- 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: case-dependent replace
On Sun, 18 Sep 2011, Jose Caballero wrote: Hi, I would like to know if it is possible to replace 'foo' by 'bar', 'FOO' by 'BAR' and 'Foo' by 'Bar' (or at least the first two), with a single command. Any link or the right :help command would be enough. From: http://vim.wikia.com/wiki/Search_and_replace """ For substituting patterns with a corresponding case-sensitive text, Michael Geddes's keepcase¹ plugin can be used, e.g.: :%SubstituteCase/\cHello/goodBye/g Substitute 'Hello hello helLo HELLO' by 'Goodbye goodbye goodBye GOODBYE' """ ¹: http://www.vim.org/scripts/script.php?script_id=6 -- Best, Ben -- 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: case-dependent replace
Abolish.vim adds this functionality: http://www.vim.org/scripts/script.php?script_id=1545 With this installed, you can run: :S/foo/bar/g Note: that's an uppercase 'S' (for Subvert), not a lowercase 's' (for substitute). Drew On Sun, Sep 18, 2011 at 4:02 PM, Jose Caballero wrote: > Hi, > > > I would like to know if it is possible to replace 'foo' by 'bar', 'FOO' by > 'BAR' and 'Foo' by 'Bar' (or at least the first two), with a single command. > > Any link or the right :help command would be enough. > > > Thanks a lot in advance, > Jose > > -- > 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 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: Remembering syntax when moving in and out of buffers
On Sun, 18 Sep 2011, Spiros Bousbouras wrote:
On Sep 17, 10:25 pm, "Benjamin R. Haskell" wrote:
On Sat, 17 Sep 2011, Spiros Bousbouras wrote:
If you define a syntax for a buffer , move away and then return is
the syntax remembered or do all the syntax commands have to be
executed again? Some tests I did indicate it's the latter.
It should be the former.
Specifically (with simplifications) my .vimrc (on Linux) has
autocmd BufReadPost,BufNewFile *.myfile source ~/myfile.vim
and file ~/myfile.vim has
if exists("b:myfile")
finish
endif
let b:myfile = 1
syntax match special /special/
highlight special term=bold cterm=bold
Either the simplifications have eliminated something important
(though I don't know what) or something else on your system is
interfering. The way you've set it up isn't the way a typical
filetype-related plugin should be laid out (see: :help new-filetype
). The way you've coded it will work, but it will get messy,
quickly, if you want to add multiple filetypes.
I did read :help new-filetype and I thought that the method
mentioned there is too complicated that's why I didn't follow it. It
seems much simpler to me to have different file types be recognised by
extension and then load syntax and anything else I want by sourcing an
appropriate script. Works well enough up to now but I only have 3-4
different file types.
The problem is that the filetype is being detected again every time you
switch buffers. Apparently Debian (like most distros) has a bunch of
auto-detection on filetypes. With your:
:let &verbose=20
You can see there's an autocmd on BufRead that gets triggered every
time. It's conditioned on:
if !did_filetype()
And, since your filetype isn't set up the way Debian expects it (which
may or may not be the way Vim normally does it), did_filetype() returns
0.
When I edit file.myfile the highlighting works correctly but if I
move away and return then there's no highlighting.
Does some plugin from your system set up some kind of autocmd on the
WinEnter, WinLeave, BufEnter, or BufLeave event(s)?
:au WinEnter,WinLeave,BufEnter,BufLeave
The above command returns
--- Auto-Commands ---
and nothing else. Apart from that , I have
let &loadplugins=0
in /etc/vim/vimrc so I don't think that any plugin is causing the
behaviour.
I missed the guilty autocmd (BufRead), because I always set the 'hidden'
option. So, files aren't re-read everytime I unhide them -- they're
only read when they're first loaded. And I was testing by switching
between two windows, with both visible.
On my system, I see about a dozen BufEnter entries, but none that
would affect a *.myfile buffer. Two in the filetypedetect augroup,
one in FileExplorer, and the ones in no group are vimball-related.
WinEnter only lists an autocmd in the matchparen group.
Here's a version of the problem with no simplifications:
File a contains
This is a special line
File b is empty. I do
vim -u NONE a b
:let &verbose=20
:syntax match special /special/
:highlight special term=bold cterm=bold
The word "special" gets highlighted.
2Ctrl-^
"b" 0 lines, 0 characters
Ctrl-^
"a" 1 line, 23 characters
Now "special" is no longer highlighted.
:syntax
No Syntax items defined for this buffer
:syntax match special /special/
The word "special" gets highlighted again. Note that this time I
didn't have to enter the highlight command to get the highlighting.
I would be especially interested if anyone who runs Debian Lenny would
try the above test.
Is Debian Lenny the same as Debian 6? I don't use Debian, but I have
VM's of Debian 5 and 6 for testing things. Under 6 is where I observed
the BufRead problem.
I'm not sure which parts of this are necessary, but the following works
for me. Using your example with the 'a' and 'b' files, but moving 'a'
to 'a.myfile' (so it can be detected by extension):
1. Change your autocmd for detection from:
(old:) autocmd BufReadPost,BufNewFile *.myfile source ~/myfile.vim
to, either:
i. if you *really* want to keep it in vimrc (for some reason -- not
recommended, but it worked fine in testing):
aug filetypedetect
autocmd BufReadPost,BufNewFile *.myfile setf myfile
aug END
ii. or just put it in ~/.vim/ftdetect/myfile.vim (where you don't need
the augroup wrapper):
au BufReadPost,BufNewFile *.myfile setf myfile
" au is short for :autocmd
" setf is short for :setfiletype
2. And create a file ~/.vim/syntax/myfile.vim containing just the
following two lines:
syn match special /special/
hi special term=bold cterm=bold
Then it's properly detected for me under Debian 6.
--
Best,
Ben
--
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: Setting the bold attribute for "Normal" text"
On Sep 18, 3:59 pm, Ben Fritz wrote: > On Sep 18, 9:40 am, Spiros Bousbouras wrote: > > > I start a buffer not belonging to any specific filetype. I type some > > random stuff and then do > > :highlight Normal ctermfg=green > > I get green letters. But if instead I do > > :highlight Normal cterm=bold term=bold > > I don't get bold text. What am I doing wrong ? > > See :help highlight-cterm > > Many terminals are unable to mix fg colors and attributes like bold. > You do not specify what term you are using but possibly it does not > support this. I wasn't trying to mix foreground colours and bold , I only want bold. I guess my last post wasn't clear enough but what I meant was that I start vim with an unnamed buffer not belonging to any specific filetype , I type some random stuff and then do :highlight Normal cterm=bold term=bold and I don't get bold. I tried it with eterm , xterm and Linux console and I don't get bold in any of them. But if I don't do :highlight Normal cterm=bold term=bold and instead I do :highlight Normal ctermfg=green then it works on all 3 of them. I also tried :syntax match boldtext /.*/ :highlight boldtext term=bold cterm=bold and I get bold on all 3. > Have you considered using the GUI (gvim)? I prefer console vim and it's only there that I want bold (on some occasions). -- 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: Remembering syntax when moving in and out of buffers
On Sep 18, 5:45 pm, "Benjamin R. Haskell" wrote: > On Sun, 18 Sep 2011, Spiros Bousbouras wrote: > > The problem is that the filetype is being detected again every time you > switch buffers. Apparently Debian (like most distros) has a bunch of > auto-detection on filetypes. With your: > > :let &verbose=20 > > You can see there's an autocmd on BufRead that gets triggered every > time. It's conditioned on: > > if !did_filetype() > > And, since your filetype isn't set up the way Debian expects it (which > may or may not be the way Vim normally does it), did_filetype() returns > 0. I'm afraid I don't follow your explanation. Don't the Debian specific stuff become irrelevant when I do vim -u NONE ? Or do you mean that Debian have modified the source of vim before compiling so that even when I start vim with -u NONE some filetype detection stuff still happens ? In the experiment with vim -u NONE a b I described why is it that when I return to a then issuing only the syntax command (but not the highlight command) turns on highlighting ? And I didn't see any autocommands being executed either , the output was exactly as I described it. > > Here's a version of the problem with no simplifications: > > File a contains > > This is a special line > > > File b is empty. I do > > vim -u NONE a b > > :let &verbose=20 > > :syntax match special /special/ > > :highlight special term=bold cterm=bold > > > The word "special" gets highlighted. > > 2Ctrl-^ > > "b" 0 lines, 0 characters > > Ctrl-^ > > "a" 1 line, 23 characters > > > Now "special" is no longer highlighted. > > :syntax > > No Syntax items defined for this buffer > > :syntax match special /special/ > > > The word "special" gets highlighted again. Note that this time I > > didn't have to enter the highlight command to get the highlighting. > > > I would be especially interested if anyone who runs Debian Lenny would > > try the above test. > > Is Debian Lenny the same as Debian 6? I don't use Debian, but I have > VM's of Debian 5 and 6 for testing things. Under 6 is where I observed > the BufRead problem. Debian 6 is squeeze , Debian 5 is lenny. > I'm not sure which parts of this are necessary, but the following works > for me. Using your example with the 'a' and 'b' files, but moving 'a' > to 'a.myfile' (so it can be detected by extension): > > 1. Change your autocmd for detection from: > > (old:) autocmd BufReadPost,BufNewFile *.myfile source ~/myfile.vim > > to, either: > > i. if you *really* want to keep it in vimrc (for some reason -- not > recommended, but it worked fine in testing): > > aug filetypedetect > autocmd BufReadPost,BufNewFile *.myfile setf myfile > aug END > > ii. or just put it in ~/.vim/ftdetect/myfile.vim (where you don't need > the augroup wrapper): > > au BufReadPost,BufNewFile *.myfile setf myfile > > " au is short for :autocmd > " setf is short for :setfiletype > > 2. And create a file ~/.vim/syntax/myfile.vim containing just the > following two lines: > > syn match special /special/ > hi special term=bold cterm=bold > > Then it's properly detected for me under Debian 6. Thanks but if these are the alternatives then it's simpler just to reexecute the syntax commands every time the buffer is loaded. -- 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: Setting the bold attribute for "Normal" text"
On 18/09/11 16:40, Spiros Bousbouras wrote: I start a buffer not belonging to any specific filetype. I type some random stuff and then do :highlight Normal ctermfg=green I get green letters. But if instead I do :highlight Normal cterm=bold term=bold I don't get bold text. What am I doing wrong ? After setting the Normal highlight as above, does hitting Ctrl-L change anything? (If it does, there's a missing redraw somewhere). Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 173. You keep tracking down the email addresses of all your friends (even childhood friends). -- 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: Using :let to view a wildcard of variables
On Sep 18, 10:25 am, ZyX wrote:
> In reply to ``Using :let to view a wildcard of variables''
> sent 17 September 2011, Saturday by David Fishburn
>
> > Will display all variables currently defined in Vim.
>
> > One thing I have always wanted to do is:
> > :let my_prefix.*
>
> let d={}
> for [var, d.val] in filter(items(g:), 'v:val[0]=~#"\\v^my_prefix"')
> echo var."\t" d.val
> endfor
Why are you using a dictionary ? Why not simply write
for [var, var2] in filter(items(g:), 'v:val[0]=~#"\\v^my_prefix"')
echo var."\t" var2
unlet var2
endfor
Is it because you want to avoid unlet ? But with the dictionary
I get some error message that it can't be displayed because the
nesting is too deep.
--
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: Setting the bold attribute for "Normal" text"
On Sep 18, 8:44 pm, Tony Mechelynck wrote: > On 18/09/11 16:40, Spiros Bousbouras wrote: > > > I start a buffer not belonging to any specific filetype. I type some > > random stuff and then do > > :highlight Normal ctermfg=green > > I get green letters. But if instead I do > > :highlight Normal cterm=bold term=bold > > I don't get bold text. What am I doing wrong ? > > After setting the Normal highlight as above, does hitting Ctrl-L change > anything? No it doesn't. -- 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
Perl Support - Turn off perl header block creation for new files
I just downloaded Perl Support and find it very useful. However I would like to disable the header block creation for new perl files. I have looked in perl-support.vim in vimfiles\plugin but I cannot find where this header block is generated for new perl files. Does anyone know how I can locate and disable this feature? TIA. -- 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: Using :let to view a wildcard of variables
In reply to ``Re: Using :let to view a wildcard of variables''
sent 18 September 2011, Sunday by Spiros Bousbouras
> Why are you using a dictionary ? Why not simply write
> ...
1. let val=function('tr')
2. let val=0
let val=[]
3. function Val()
endfunction
let Val=function('tr')
There is no way to safely handle function references without putting it into a
dictionary. You have a point though: I should have used `s:d', not `d' here.
> Is it because you want to avoid unlet ? But with the dictionary
> I get some error message that it can't be displayed because the
> nesting is too deep.
It should not happen unless you wrote `string()'.
Original text:
> On Sep 18, 10:25 am, ZyX wrote:
> > In reply to ``Using :let to view a wildcard of variables''
> > sent 17 September 2011, Saturday by David Fishburn
> >
> > > Will display all variables currently defined in Vim.
> > >
> > > One thing I have always wanted to do is:
> > > :let my_prefix.*
> > > :
> > let d={}
> > for [var, d.val] in filter(items(g:),
> > 'v:val[0]=~#"\\v^my_prefix"')
> >
> > echo var."\t" d.val
> >
> > endfor
>
> Why are you using a dictionary ? Why not simply write
>
> for [var, var2] in filter(items(g:), 'v:val[0]=~#"\\v^my_prefix"')
> echo var."\t" var2
> unlet var2
> endfor
>
> Is it because you want to avoid unlet ? But with the dictionary
> I get some error message that it can't be displayed because the
> nesting is too deep.
signature.asc
Description: This is a digitally signed message part.
Re: Perl Support - Turn off perl header block creation for new files
On Sun, Sep 18, 2011 at 04:17:01PM -0400, Roy Fulbright wrote: > I just downloaded Perl Support and find it very useful. However I would like > to disable the header block creation for new perl files. I have looked in > perl-support.vim in vimfiles\plugin but I cannot find where this header block > is generated for new perl files. Does anyone know how I can locate and > disable this feature? TIA. You can edit template in ~/.vim/perl-support/templates/Templates file. -- 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: Using :let to view a wildcard of variables
Am 18.09.2011 05:57, schrieb David Fishburn: Vim 7.3.315 My plugins all use naming conventions for variables. :let Will display all variables currently defined in Vim. One thing I have always wanted to do is: :let my_prefix.* Or something like that to show all variables beginning with my_prefix. The following is builtin, and I use it all the time: :let my_prefix :h c_CTRL-A -- Andy -- 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: Remembering syntax when moving in and out of buffers
On Sun, 18 Sep 2011, Spiros Bousbouras wrote:
On Sep 18, 5:45 pm, "Benjamin R. Haskell" wrote:
On Sun, 18 Sep 2011, Spiros Bousbouras wrote:
The problem is that the filetype is being detected again every time
you switch buffers. Apparently Debian (like most distros) has a
bunch of auto-detection on filetypes. With your:
:let &verbose=20
You can see there's an autocmd on BufRead that gets triggered every
time. It's conditioned on:
if !did_filetype()
And, since your filetype isn't set up the way Debian expects it
(which may or may not be the way Vim normally does it),
did_filetype() returns 0.
I'm afraid I don't follow your explanation. Don't the Debian specific
stuff become irrelevant when I do vim -u NONE ? Or do you mean that
Debian have modified the source of vim before compiling so that even
when I start vim with -u NONE some filetype detection stuff still
happens ? In the experiment with vim -u NONE a b I described why
is it that when I return to a then issuing only the syntax command
(but not the highlight command) turns on highlighting ? And I didn't
see any autocommands being executed either , the output was exactly as
I described it.
I wasn't using -u NONE, sorry. I was explaining what goes wrong without
it. In the -u NONE case that you present, it gets cleared because
syntax starts fresh prior to loading each new buffer, so that filetype
detection can detect the file and load the proper syntax without having
to worry about clearing out the syntax of whatever other file or files
are open.
There are a few ways to avoid having Vim load the buffer from scratch
each time you switch to it. One way is to set the 'hidden' option.
Another is to set bufhidden=hide. Both of those alter how buffer
management works slightly. (You can switch away from a buffer that
contains unsaved changes, for example, though Vim will prompt you about
that if you try to exit.)
Here's a version of the problem with no simplifications:
File a contains
This is a special line
File b is empty. I do
vim -u NONE a b
:let &verbose=20
:syntax match special /special/
:highlight special term=bold cterm=bold
The word "special" gets highlighted.
2Ctrl-^
"b" 0 lines, 0 characters
Ctrl-^
"a" 1 line, 23 characters
Now "special" is no longer highlighted.
:syntax
No Syntax items defined for this buffer
:syntax match special /special/
The word "special" gets highlighted again. Note that this time I
didn't have to enter the highlight command to get the highlighting.
I would be especially interested if anyone who runs Debian Lenny would
try the above test.
Is Debian Lenny the same as Debian 6? I don't use Debian, but I have
VM's of Debian 5 and 6 for testing things. Under 6 is where I observed
the BufRead problem.
Debian 6 is squeeze , Debian 5 is lenny.
Works the same on Lenny for me as it did on Squeeze.
I'm not sure which parts of this are necessary, but the following
works for me. Using your example with the 'a' and 'b' files, but
moving 'a' to 'a.myfile' (so it can be detected by extension):
1. Change your autocmd for detection from:
(old:) autocmd BufReadPost,BufNewFile *.myfile source ~/myfile.vim
to, either:
i. if you *really* want to keep it in vimrc (for some reason -- not
recommended, but it worked fine in testing):
aug filetypedetect
autocmd BufReadPost,BufNewFile *.myfile setf myfile
aug END
ii. or just put it in ~/.vim/ftdetect/myfile.vim (where you don't
need the augroup wrapper):
au BufReadPost,BufNewFile *.myfile setf myfile
" au is short for :autocmd
" setf is short for :setfiletype
2. And create a file ~/.vim/syntax/myfile.vim containing just the
following two lines:
syn match special /special/
hi special term=bold cterm=bold
Then it's properly detected for me under Debian 6.
Thanks but if these are the alternatives then it's simpler just to
reexecute the syntax commands every time the buffer is loaded.
Maybe I'm missing something, but my suggestion is simpler than (or at
worst "as simple as") what you're already doing. And it has the benefit
of being better-contained: All your Vim-related settings are in your
~/.vimrc file and ~/.vim directory (and its subdirs).
= What you said you were doing: =
1. in your .vimrc (1 line):
autocmd BufReadPost,BufNewFile *.myfile source ~/myfile.vim
2. in ~/myfile.vim (6 lines of code):
if exists("b:myfile")
finish
endif
let b:myfile = 1
syntax match special /special/
highlight special term=bold cterm=bold
= What you could be doing (one version): =
1. in your .vimrc (3 lines):
aug filetypedetect
au BufReadPost,BufNewFile *.myfile setf myfile
aug END
" The aug[roup] might not be necessary, but it makes management easier
2. put ~/myfile.vim into a different directory ( ~/.vim/syntax/ ) and
remove all but the last two lines (2 lines):
syntax match special /special/
highlight special term=bold cterm=bold
= What you could be doing (the other version): =
1
Re: Remembering syntax when moving in and out of buffers
On 19/09/11 00:14, Benjamin R. Haskell wrote:
On Sun, 18 Sep 2011, Spiros Bousbouras wrote:
On Sep 18, 5:45 pm, "Benjamin R. Haskell" wrote:
On Sun, 18 Sep 2011, Spiros Bousbouras wrote:
The problem is that the filetype is being detected again every time
you switch buffers. Apparently Debian (like most distros) has a bunch
of auto-detection on filetypes. With your:
:let &verbose=20
You can see there's an autocmd on BufRead that gets triggered every
time. It's conditioned on:
if !did_filetype()
And, since your filetype isn't set up the way Debian expects it
(which may or may not be the way Vim normally does it),
did_filetype() returns 0.
I'm afraid I don't follow your explanation. Don't the Debian specific
stuff become irrelevant when I do vim -u NONE ? Or do you mean that
Debian have modified the source of vim before compiling so that even
when I start vim with -u NONE some filetype detection stuff still
happens ? In the experiment with vim -u NONE a b I described why is it
that when I return to a then issuing only the syntax command (but not
the highlight command) turns on highlighting ? And I didn't see any
autocommands being executed either , the output was exactly as I
described it.
I wasn't using -u NONE, sorry. I was explaining what goes wrong without
it. In the -u NONE case that you present, it gets cleared because syntax
starts fresh prior to loading each new buffer, so that filetype
detection can detect the file and load the proper syntax without having
to worry about clearing out the syntax of whatever other file or files
are open.
There are a few ways to avoid having Vim load the buffer from scratch
each time you switch to it. One way is to set the 'hidden' option.
Another is to set bufhidden=hide. Both of those alter how buffer
management works slightly. (You can switch away from a buffer that
contains unsaved changes, for example, though Vim will prompt you about
that if you try to exit.)
Here's a version of the problem with no simplifications:
File a contains
This is a special line
File b is empty. I do
vim -u NONE a b
:let &verbose=20
:syntax match special /special/
:highlight special term=bold cterm=bold
The word "special" gets highlighted.
2Ctrl-^
"b" 0 lines, 0 characters
Ctrl-^
"a" 1 line, 23 characters
Now "special" is no longer highlighted.
:syntax
No Syntax items defined for this buffer
:syntax match special /special/
The word "special" gets highlighted again. Note that this time I
didn't have to enter the highlight command to get the highlighting.
I would be especially interested if anyone who runs Debian Lenny would
try the above test.
Is Debian Lenny the same as Debian 6? I don't use Debian, but I have
VM's of Debian 5 and 6 for testing things. Under 6 is where I observed
the BufRead problem.
Debian 6 is squeeze , Debian 5 is lenny.
Works the same on Lenny for me as it did on Squeeze.
I'm not sure which parts of this are necessary, but the following
works for me. Using your example with the 'a' and 'b' files, but
moving 'a' to 'a.myfile' (so it can be detected by extension):
1. Change your autocmd for detection from:
(old:) autocmd BufReadPost,BufNewFile *.myfile source ~/myfile.vim
to, either:
i. if you *really* want to keep it in vimrc (for some reason -- not
recommended, but it worked fine in testing):
aug filetypedetect
autocmd BufReadPost,BufNewFile *.myfile setf myfile
aug END
ii. or just put it in ~/.vim/ftdetect/myfile.vim (where you don't
need the augroup wrapper):
au BufReadPost,BufNewFile *.myfile setf myfile
" au is short for :autocmd
" setf is short for :setfiletype
2. And create a file ~/.vim/syntax/myfile.vim containing just the
following two lines:
syn match special /special/
hi special term=bold cterm=bold
Then it's properly detected for me under Debian 6.
Thanks but if these are the alternatives then it's simpler just to
reexecute the syntax commands every time the buffer is loaded.
Maybe I'm missing something, but my suggestion is simpler than (or at
worst "as simple as") what you're already doing. And it has the benefit
of being better-contained: All your Vim-related settings are in your
~/.vimrc file and ~/.vim directory (and its subdirs).
= What you said you were doing: =
1. in your .vimrc (1 line):
autocmd BufReadPost,BufNewFile *.myfile source ~/myfile.vim
2. in ~/myfile.vim (6 lines of code):
if exists("b:myfile")
finish
endif
let b:myfile = 1
syntax match special /special/
highlight special term=bold cterm=bold
= What you could be doing (one version): =
1. in your .vimrc (3 lines):
these 3 lines actually belong in ~/.vim/filetype.vim (for Unix) or in
~/vimfiles/filetype.vim (for Windows) or in $VIM/vimfiles/filetype.vim
(for access by any user, on any OS) — in all cases, create missing
directories as you go along. The "other version" below (replacing
filetype.vim by ftdetect/myfile.vim and doing away with the augroup,
which Vim sets before sourcing everything in the ftdetect director
Re: Remembering syntax when moving in and out of buffers
On Mon, 19 Sep 2011, Tony Mechelynck wrote:
On 19/09/11 00:14, Benjamin R. Haskell wrote:
= What [the OP was] doing: =
1. in your .vimrc (1 line):
autocmd BufReadPost,BufNewFile *.myfile source ~/myfile.vim
2. in ~/myfile.vim (6 lines of code):
if exists("b:myfile")
finish
endif
let b:myfile = 1
syntax match special /special/
highlight special term=bold cterm=bold
= What [the OP] could be doing (one version): =
1. in your .vimrc (3 lines):
these 3 lines actually belong in ~/.vim/filetype.vim (for Unix) or in
~/vimfiles/filetype.vim (for Windows) or in $VIM/vimfiles/filetype.vim
(for access by any user, on any OS) — in all cases, create missing
directories as you go along. The "other version" below (replacing
filetype.vim by ftdetect/myfile.vim and doing away with the augroup,
which Vim sets before sourcing everything in the ftdetect directory)
would also work.
Interesting. I didn't know about ~/.vim/filetype.vim.
This way this autocommand will be correctly forgotten and remembered
back if ever you do ":filetype off" and later ":filetype on".
See ":help new-filetype".
This wasn't the version I was advocating. But, since the OP implied
that creating the proper directories was more complex ("Thanks but if
these are the alternatives then it's simpler to just [keep things as
before]"), I was providing a way that would work without having to
create more directories.
For the record, my suggested "= What you could be doing (the other
version): =" is the one I actually recommend (and is what new-filetype
seems to advocate):
= What you could be doing (the other version): =
1. in ~/.vim/ftdetect/myfile.vim (1 line):
au BufReadPost,BufNewFile *.myfile setf myfile
2. put the last two lines of ~/myfile.vim into ~/.vim/syntax/myfile.vim
(2 lines):
syn match special /special/
hi special term=bold cterm=bold
--
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
keyboard question - was Re: How to generate auto increased number lines
On Sunday, September 18, 2011 02:42:28 meino.cra...@gmx.de wrote: > To execute the macro type > AltGr? my keyboard doesn't have one of those -- wikipedia says Windows started allowing the Alt-Ctrl combination to emulate AltGr -- anybody know a way to map that for vim on linux? it looks useful... sc -- 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: keyboard question - was Re: How to generate auto increased number lines
sc [11-09-19 04:52]: > On Sunday, September 18, 2011 02:42:28 meino.cra...@gmx.de wrote: > > > To execute the macro type > > > > > AltGr? my keyboard doesn't have one of those -- wikipedia > says Windows started allowing the Alt-Ctrl combination to > emulate AltGr -- anybody know a way to map that for vim on > linux? it looks useful... > > sc > > -- > 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 > AltGr is "Alternate graphics" is normally the right Alt key. But I was wrong here. It depends what keyboard layout you use. Mine is a QWERTZ layout and the ALTGR-q produces a '@'-sign. So what you really need is the @-sign Please read :h q this explains it better than my keyboard-layout-dependant blabla ;) (which does NOT mean, that I dont want to help you -- mail me and I will try to answer :) Best regards, mcc -- Unix,vim and a IBM model M - what does it need more? -- 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
