todo suggestion: remote feature for console vim
Hello Bram, Would you consider to include into"todo list'" the remote feature for console vim, that'd rely on basic kernel-provided IPC (maybe pipes or sokets) without dependency on large packages (like X1 and dbus) not packaged with vim and not present on console systems ? Yakov -- You received this message from the "vim_dev" 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_dev+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Patch 7.2.025 and periodic execution
Hello Bram,
Patch 7.2.025 broke periodic execution idiom [1], it seems.
[1] http://vim.wikia.com/wiki/Timer_to_execute_commands_periodically
Can the ability to do perioc execution via CursorHold be restored ?
Periodic execution is possible in GUI-enabled vim via spawning
expernal subprocess that sends remote events to the vim.
In console vim, the idiom [1] is was the only possible means to
do periodic execution. 'updatetime' value served as a guarantee
to not get 100%cpu, so it seemed clean, no ? It was used in several
plugin, notably in "timetable" plugin that highlighted time-based lines of
file based on current time.
Thanks
Yakov
Patch 7.2.025
Problem:When a CursorHold event invokes system() it is retriggered over
and over again.
Solution: Don't reset did_cursorhold when getting K_IGNORE.
Files: src/normal.c
*** ../vim-7.2.024/src/normal.c Sat Sep 6 16:44:06 2008
--- src/normal.cSat Sep 27 13:03:34 2008
***
*** 1132,1138
out_flush();
#endif
#ifdef FEAT_AUTOCMD
! did_cursorhold = FALSE;
#endif
State = NORMAL;
--- 1132,1139
out_flush();
#endif
#ifdef FEAT_AUTOCMD
! if (ca.cmdchar != K_IGNORE)
! did_cursorhold = FALSE;
#endif
State = NORMAL;
*** ../vim-7.2.024/src/version.cThu Oct 2 22:48:01 2008
--- src/version.c Thu Oct 2 22:54:41 2008
***
*** 678,679
--- 678,681
{ /* Add new patch number below this line */
+ /**/
+ 25,
/**/
--
--
You received this message from the "vim_dev" 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_dev+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
Re: Vim creates files named "4913", why?
On Wed, Oct 28, 2009 at 00:52, Yakov Lerner wrote:
> On Wed, Oct 21, 2009 at 17:13, James Vega wrote:
>
>>
>> On Wed, Oct 21, 2009 at 10:52 AM, Arve Knudsen
>> wrote:
>> >
>> > On 21 Okt, 13:58, James Vega wrote:
>> >> On Wed, Oct 21, 2009 at 02:33:46AM -0700, Arve Knudsen wrote:
>> >> > I have a very annoying problem with the x64 build of Vim 7.2 on
>> >> > Windows 7, for some reason it creates files named "4913" during
>> >> > editing. Is this a bug, or maybe triggered by a problem with my
>> >> > system?
>> >>
>> >> As a quick Google would tell you, Vim creates this file in an attempt
>> to
>> >> verify it can create a file in the directory in which you see the file
>> >> and set the uid/gid. It's just a temporary file used during the
>> process
>> >> of creating a backup file.
>> >
>> > I did Google it, and found that it could be a problem on network-
>> > filesystems? The problem is that it *isn't* temporary, it persists.
>>
>> Here's the code:
>>
>> 3486 for (i = 4913; ; i += 123)
>> 3487 {
>> 3488 sprintf((char *)gettail(IObuff), "%d", i);
>> 3489 if (mch_lstat((char *)IObuff, &st) < 0)
>> 3490 break;
>> 3491 }
>> 3492 fd = mch_open((char *)IObuff,
>> 3493
>> O_CREAT|O_WRONLY|O_EXCL|O_NOFOLLOW, perm);
>> 3494 if (fd < 0) /* can't write in directory */
>> 3495 backup_copy = TRUE;
>> 3496 else
>> 3497 {
>> 3498 # ifdef UNIX
>> 3499 # ifdef HAVE_FCHOWN
>> 3500 ignored = fchown(fd, st_old.st_uid,
>> st_old.st_gid);
>> 3501 # endif
>> 3502 if (mch_stat((char *)IObuff, &st) < 0
>> 3503 || st.st_uid != st_old.st_uid
>> 3504 || st.st_gid != st_old.st_gid
>> 3505 || (long)st.st_mode != perm)
>> 3506 backup_copy = TRUE;
>> 3507 # endif
>> 3508 /* Close the file before removing it, on
>> MS-Windows we
>> 3509 * can't delete an open file. */
>> 3510 close(fd);
>> 3511 mch_remove(IObuff);
>> 3512 }
>>
>> If mch_open (line 3492) returns a file descriptor, then we get into
>> the following else which always calls mch_remove on the file (line
>> 3511).
>
>
> Arve, I wonder if changing line 3494 'if( fd < 0 )' to 'if( fd == -1)'
> fixes the problem ?
> Can you make the change on line 3494, rebuild vim, and see if there is
> change ?
>
> Yakov
>
> PS
> I learned once that on win32, you *must* write
> if(sock == -1) and never if(sock < 0).
> Win32 sockets can be negative. Yes they really can be.
> msdn specs _open() as returning -1 on error, not "negative number".
>
>
I was wrong. _open can't return negative fd.
Maybe moving mch_remove()
after brace 3512 fixed it ?
Maybe win32 _open() has
some race where it creates the file but then returns -1 ?
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Vim creates files named "4913", why?
On Wed, Oct 21, 2009 at 17:13, James Vega wrote:
>
> On Wed, Oct 21, 2009 at 10:52 AM, Arve Knudsen
> wrote:
> >
> > On 21 Okt, 13:58, James Vega wrote:
> >> On Wed, Oct 21, 2009 at 02:33:46AM -0700, Arve Knudsen wrote:
> >> > I have a very annoying problem with the x64 build of Vim 7.2 on
> >> > Windows 7, for some reason it creates files named "4913" during
> >> > editing. Is this a bug, or maybe triggered by a problem with my
> >> > system?
> >>
> >> As a quick Google would tell you, Vim creates this file in an attempt to
> >> verify it can create a file in the directory in which you see the file
> >> and set the uid/gid. It's just a temporary file used during the process
> >> of creating a backup file.
> >
> > I did Google it, and found that it could be a problem on network-
> > filesystems? The problem is that it *isn't* temporary, it persists.
>
> Here's the code:
>
> 3486 for (i = 4913; ; i += 123)
> 3487 {
> 3488 sprintf((char *)gettail(IObuff), "%d", i);
> 3489 if (mch_lstat((char *)IObuff, &st) < 0)
> 3490 break;
> 3491 }
> 3492 fd = mch_open((char *)IObuff,
> 3493
> O_CREAT|O_WRONLY|O_EXCL|O_NOFOLLOW, perm);
> 3494 if (fd < 0) /* can't write in directory */
> 3495 backup_copy = TRUE;
> 3496 else
> 3497 {
> 3498 # ifdef UNIX
> 3499 # ifdef HAVE_FCHOWN
> 3500 ignored = fchown(fd, st_old.st_uid,
> st_old.st_gid);
> 3501 # endif
> 3502 if (mch_stat((char *)IObuff, &st) < 0
> 3503 || st.st_uid != st_old.st_uid
> 3504 || st.st_gid != st_old.st_gid
> 3505 || (long)st.st_mode != perm)
> 3506 backup_copy = TRUE;
> 3507 # endif
> 3508 /* Close the file before removing it, on
> MS-Windows we
> 3509 * can't delete an open file. */
> 3510 close(fd);
> 3511 mch_remove(IObuff);
> 3512 }
>
> If mch_open (line 3492) returns a file descriptor, then we get into
> the following else which always calls mch_remove on the file (line
> 3511).
Arve, I wonder if changing line 3494 'if( fd < 0 )' to 'if( fd == -1)'
fixes the problem ?
Can you make the change on line 3494, rebuild vim, and see if there is
change ?
Yakov
PS
I learned once that on win32, you *must* write
if(sock == -1) and never if(sock < 0).
Win32 sockets can be negative. Yes they really can be.
msdn specs _open() as returning -1 on error, not "negative number".
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: "./vimXX/src/syntax.c" as an external utility?
On Sun, Oct 11, 2009 at 00:46, Guido van Steen wrote:
>
> Dear VIM developers,
>
> I would like to use VIM's syntax/lexical highlighting/coloring in order to
> color the command line in zsh - and if possible highlight it as well. (For
> zsh: see "www.zsh.org"). I would actually hope that this can be done using
> VIM's zsh' syntax file ("./vimXX/syntax/zsh.vim")
>
> It seems to me that within VIM the actual VIM syntax/lexical
> highlighting/coloring has been programmed in the file "./vimXX/src/syntax.c".
>
> Unfortunately, however, I am not any good at C programming. Therefore most of
> this "syntax.c" file seems like magic to me.
>
> My question is: Could someone give me some idea on how this "syntax.c" file
> could be turned into into an external program, which takes a "zsh file" as
> its input, and which provides the information on the syntax/lexical
> highlighting/coloring of this "zsh file" as its output??
>
> Does someone know if such an external program has ever been made?
Yes. Probably you'll want to use vim in batch mode, along the lines of
vim -c 'set ft=zsh|syntax on' -c 'TOhtml' -c 'w!
/path/to/output.html' -c 'qall!' input_file
This line seems to actually work :-) Ask on "vim_use" forum for
further details (*1).
And see :help convert-to-HTML
If you wrap this line into shell script, you get the "external utility".
Yakov
(1) http://groups.google.com/group/vim_use
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
doc micro-patch, autocmd.txt line 62
--- autocmd.txt.000 2009-10-04 22:52:45.0 +0200
+++ autocmd.txt 2009-10-04 22:53:30.0 +0200
@@ -59,7 +59,7 @@
:au[tocmd] [group] {event} {pat} [nested] {cmd}
Add {cmd} to the list of commands that Vim will
execute automatically on {event} for a file matching
- {pat}. Vim always adds the {cmd} after existing
+ {pat}|autocmd-patterns|. Vim always adds the {cmd}
after existing
autocommands, so that the autocommands execute in the
order in which they were given. See |autocmd-nested|
for [nested].
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: copy a map (in order to restore it later)
On Sun, Sep 27, 2009 at 08:58, Hari Krishna Dara wrote: > > I need to be able to create an imap for when my plugin is > toggled on, and unmap it when it is toggled off. What I would prefer > is to restore the previous map of rather than simply unmap it, > but there is no straight-forward way to capture the existing map such > that it can be restored later. I first ventured into capturing the > output of :imap command and extract the , but this won't work for > many scenarios (including the case of
Re: Memory is used up when I replace "\t0\n" to "\n"
On Fri, Sep 11, 2009 at 06:57, Matt Wozniski wrote: > > On Thu, Sep 10, 2009 at 4:13 AM, John Beckett wrote: > > > > Aleafs wrote: > >> :1,$ s/\t0\n/\n/g > > Note that :% is a shortcut for :1,$ > > > In a substitute, \n means two different things: > > - In the pattern, it refers to a newline. > > - In the replacement, it refers to a null byte (8 zero bits). > > > > You can see this at ':help :s' by following the first two links. > > > > In a replacement, '\r' inserts a newline. Yes, it's strange, and > > no, I didn't try to work out why this issue caused the problem > > you report. > > My guess: Vim is really, really bad at handling extremely long lines, > and if the goal was to delete "the last column of a text file" (I'm > assuming every line ended with "\t0") then this command told vim to > turn the file into one 700kb long line. > 1. I don't understand why vim grows here (800MB and up)without giving memory overallocation error based on 'maxmem' and 'maxmemtot'. 'maxmem' and 'maxmemtot' have values of of 150524 (that's KB, or 150MB). It's undo memory causes memory overuse here. 2. This problem of memory use here (and speed)is is with 'noswapfile' and 'undolevels', and it's solved by: :set noswapfile undolevel=-1, Then vim finishes the replacement (wait 1/2 minutes). And vim opens 700k-long file consisting of single line and many 0-bytes, in the first place, without problem. Testcase: 1) 700k file consisting of single line and many 0-bytes perl -e 'printf "%8d %8d %8d %8d\n", $_,$_,$_,$_ for(1..2)' >/tmp/1 tr '\n' '\000' /tmp/2 vim /tmp/2 # no problem 2) vim repalces newlines to 0-bytes without growing in memory, 700k file 20k lines: perl -e 'printf "%8d %8d %8d %8d\n", $_,$_,$_,$_ for(1..2)' >/tmp/1 vim /tmp/1 :set noswapfile undolevel=-1 :%s/\n/\n/ " finished in 30 sec, resul tis single 700k-long line 3) without 'et noswapfile undolevel=-1', blows up vim to pieces: perl -e 'printf "%8d %8d %8d %8d\n", $_,$_,$_,$_ for(1..2)' >/tmp/1 vim /tmp/1 :%s/\n/\n/ " grows beyond 1G in size and killed by OS, if you have patience Killed In scenario #3, I thought vim would report error based on 'maxmem' and 'maxmemtot', but it did not. My values of 'maxmem' and 'maxmemtot' are 150254 (=150MB), but why vim grew over 800MB in vm size without giving memory size error ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] when 'autochdir' is set, let mksession always use full pathname independently on curdir,sesdir
On Thu, Apr 30, 2009 at 22:11, _sc_ wrote: > > On Thursday 30 April 2009 11:19 am, Yakov Lerner wrote: > > When 'acd' is set, mksession uses short pathname in the typical usage > which > > leads to wrong result (the testcase below). This is biting me every time > I > > use mksession (I always have acd on). > > The interaction of 'curdir' in sessionoptions and 'set acd' leads to > > apparently wrong result. > > This patch adds additional check in ses_fname, the logic is similar to > the > > check for 'did_lcd' which already exists for the same reason. > >Note: When this option is on some plugins may not work. > > or maybe it's time we examined the question of whether 'autochdir' > is buggy I think the problem is when code tests for did_lcd flag but does not test for p_acd flag. Looks like p_acd should have same effect as did_lcd. When code tests for did_lcd but not for p_acd, it's problematic for acd. So I fixed one case of it, very pinpointed. Maybe setting did_lcd=TRUE should be automatic whenever p_acd is, set will solve more problems ? Maybe. I don't know. So far, I am using acd for many years, I am satified. Before I discovered acd, I used lcd+au as yours, and I had side-effects, too. I switched from lcd to acd. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Fwd: [wish] different statusline format for noncurrent statusline
On Sat, Mar 21, 2009 at 11:22, Dominique Pelle wrote:
>
> Tony Mechelynck wrote:
>
> > On 19/03/09 13:08, Yakov Lerner wrote:
> >>
> >> On Tue, Mar 17, 2009 at 12:41, Yakov Lerner wrote:
> >>> We have separae highlighting, StatusLineNC, for non-current.
> >>> I wish I had different *format*, too, for noncurrent statusline. I do
> not
> >>> think differnt format for non-current statusline is supported.
> >>> Is it possible to put this request in todo. Thanks.
> >>
> >> Found how to make it in current vim.
> >> Sorry for the noise. Took me time to figure it, works fine.
> >>
> >> let&statusline="Your favourite statusline"
> >> let g:Active_statusline=&g:statusline
> >> let g:NCstatusline = "%<%F"" non-current statusline
> >> au WinEnter * let&l:statusline = g:Active_statusline
> >> au WinLeave * let&l:statusline = g:NCstatusline
> >>
> >> Yakov
> >
> > Wow! Hadn't realized it was global-local. :thumbsup:
> >
> > Best regards,
> > Tony.
>
> Agreed, that's quite a nice tip.
>
> I ended up using it to change the colors of the active vs inactive
> statusline in my already fancy statusline settings:
>
> " Colors of active statusline
> hi User1 guifg=#66ff66 guibg=#008000 gui=bold term=standout
> cterm=bold ctermfg=lightgreen ctermbg=lightgreen
> hi User2 guifg=#60 guibg=#008000 gui=bold term=none cterm=bold
> ctermfg=yellow ctermbg=lightgreen
>
> " Colors or inactive statusline
> hi User3 guifg=#66ff66 guibg=#008000 gui=bold term=standout
> cterm=bold ctermfg=lightgreen ctermbg=lightgreen
> hi User4 guifg=#66ff66 guibg=#008000 gui=bold term=none cterm=bold
> ctermfg=lightgreen ctermbg=lightgreen
>
> " Function used to display syntax group.
> function! SyntaxItem()
> return synIDattr(synID(line("."),col("."),1),"name")
> endfunction
>
> " Function used to display utf-8 sequence.
> function! ShowUtf8Sequence()
> let p = getpos('.')
> redir => utfseq
> sil normal! g8
> redir End
> call setpos('.', p)
> return substitute(matchstr(utfseq, '\x\+ .*\x'), '\<\x', '0x&', 'g')
> endfunction
>
> if has('statusline')
> if version >= 700
>" Fancy status line.
>set statusline =
>set statusline+=%#User1# " highlighting
>set statusline+=%-2.2n\" buffer number
>set statusline+=%#User2# " highlighting
>set statusline+=%f\" file name
>set statusline+=%#User1# " highlighting
>set statusline+=%h%m%r%w\ " flags
>set statusline+=%{(&key==\"\"?\"\":\"encr,\")} " encrypted?
>set statusline+=%{strlen(&ft)?&ft:'none'}, " file type
>set statusline+=%{(&fenc==\"\"?&enc:&fenc)}, " encoding
>set statusline+=%{((exists(\"+bomb\")\ &&\ &bomb)?\"B,\":\"\")} " BOM
>set statusline+=%{&fileformat}," file format
>set statusline+=%{&spelllang}, " spell language
>set statusline+=%{SyntaxItem()}" syntax group under
> cursor
>set statusline+=%= " indent right
>set statusline+=%#User2# " highlighting
>set statusline+=%{ShowUtf8Sequence()}\ " utf-8 sequence
>set statusline+=%#User1# " highlighting
>set statusline+=0x%B\ " char under cursor
>set statusline+=%-6.(%l,%c%V%)\ %<%P " position
>
>" Use different colors for statusline in current and non-current window.
> let g:Active_statusline=&g:statusline
> let g:NCstatusline=substitute(
> \substitute(g:Active_statusline,
> \'User1', 'User3', 'g'),
> \'User2', 'User4', 'g')
> au WinEnter * let&l:statusline = g:Active_statusline
>au WinLeave * let&l:statusline = g:NCstatusline
> endif
> endif
Different highlighting for non-active statusline is trivial due to
'hi StatusLineNC', as opposed to different contents/format of statusline.
But I've got to try out your statusline code. It's hideousest statusline
I've seen.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
[patch] when 'autochdir' is set, let mksession always use full pathname independently on curdir,sesdir
When 'acd' is set, mksession uses short pathname in the typical usage which leads to wrong result (the testcase below). This is biting me every time I use mksession (I always have acd on). The interaction of 'curdir' in sessionoptions and 'set acd' leads to apparently wrong result. This patch adds additional check in ses_fname, the logic is similar to the check for 'did_lcd' which already exists for the same reason. Testcase: echo abc >/tmp/xxx vim -u NONE -U NONE /tmp/xxx :set acd :he help :mksession! ~/xxx :qall! vim -u NONE -U NONE -S ~/xxx ^^^ bug: upper window is empty ^^^ Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- patch-mksession-acd Description: Binary data
doc suggestion
If vimscript functions had remark "Added in vim7.1.129", it would be useful. For example, if you want to know how portable the script is. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Fwd: [wish] different statusline format for noncurrent statusline
On Tue, Mar 17, 2009 at 12:41, Yakov Lerner wrote: > We have separae highlighting, StatusLineNC, for non-current. > I wish I had different *format*, too, for noncurrent statusline. I do not > think differnt format for non-current statusline is supported. > Is it possible to put this request in todo. Thanks. Found how to make it in current vim. Sorry for the noise. Took me time to figure it, works fine. let &statusline="Your favourite statusline" let g:Active_statusline=&g:statusline let g:NCstatusline = "%<%F" " non-current statusline au WinEnter * let &l:statusline = g:Active_statusline au WinLeave * let &l:statusline = g:NCstatusline Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
doc suggestion
[eval.txt] option *expr-option* *E112* *E113* Suggest to add '&' character to tags here. If I want to jump to help topic about 'let &option=...', and I look at all tags containing &, it's not there. Example: option *expr-option* *&option* *&g:option* *&l:option: *E112* *E113* (2) Suggest to add "See also |expr-options|" to :help setl and :help :setg. Suggest to add example with "let &..." to examples under *expr-option*. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: {bug report] redir in functions
On Wed, Mar 18, 2009 at 16:27, Ben Fritz wrote: > > > > On Mar 18, 8:25 am, Yakov Lerner wrote: >> redir => var | let var = 0 " (in a function) refers to >> local local var, >> " it's reserved >> name like 'count' >> Everything is consistent. Where do you see a problem ? >> > > StarWing is saying that he does, in a function, > "redir => var" and the > global var gets changed. Not for me. If I do 'redir => var' in a function, local virable gets changed. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: {bug report] redir in functions
2009/3/16 StarWing
>
>
>
> On 3月16日, 下午6时15分, Tony Mechelynck
> wrote:
> > On 15/03/09 04:18, StarWing wrote:
> >
> >
> >
> >
> >
> > > use redir in functions, e.g.
> > > func! Func1()
> > > redir => funclist
> > > silent func
> > > redir END
> > > " other sentence ...
> >
> > > endfunc
> >
> > > funclist maybe a local-variable, but it is globle variable here, must
> > > write
> > > redir => l:funclist
> > > to make funclist a local variable.
> >
> > > the doc only said:
> > > :redi[r] => {var} Redirect messages to a variable. If the variable
> > >doesn't exist, then it is created. If the variable
> > >exists, then it is initialized to an empty string.
> > >The variable will remain empty until redirection ends.
> > >Only string variables can be used. After the
> > >redirection starts, if the variable is removed or
> > >locked or the variable type is changed, then further
> > >command output messages will cause errors. {not in Vi}
> >
> > Here's the relavant info, from elsewhere in the docs:
> >
> > >*global-variable* *g:var*
> > > Inside functions global variables are accessed with "g:". Omitting this
> > > will
> > > access a variable local to a function. But "g:" can also be used in any
> > > other
> > > place if you like.
> >
> > >*local-variable* *l:var*
> > > Inside functions local variables are accessed without prepending anything.
> > > But you can also prepend "l:" if you like. However, without prepending
> > > "l:"
> > > you may run into reserved variable names. For example "count". By
> > > itself it
> > > refers to "v:count". Using "l:count" you can have a local variable with
> > > the
> > > same name.
> >
> > So, _inside_ a function, funclist (with no explicit namespace) is
> > equivalent to l:funclist. _Outside_ all functions it is equivalent to
> > g:funclist.
>
> So, is it a bug?
No
It is consistent with other use of g:var, l:var, var inside the function.
redir => g:var | let g:var = 0 " (in a function) refers to global var
redir => l:var | let l:var = 0" (in a function) refers
to local var
redir => var | let var = 0 " (in a function) refers to
local local var,
" it's reserved
name like 'count'
Everything is consistent. Where do you see a problem ?
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
[wish] different statusline format for noncurrent statusline
We have separae highlighting, StatusLineNC, for non-current. I wish I had different *format*, too, for noncurrent statusline. I do not think differnt format for non-current statusline is supported. Is it possible to put this request in todo. Thanks. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: CR-used-for-NL
On Thu, Jul 17, 2008 at 2:08 AM, John Beckett <[EMAIL PROTECTED]> wrote: > The command :dig has output including: > NU ^@ 10 > Inserting Ctrl-K N U, then ga on it says <^@> 0, Hex 00, Octal 000 Shouldn't :dig say NU ^@ 0 rather than NU ^@ 10 ? --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Five (5) new features request
On Wed, Jul 16, 2008 at 1:57 AM, smu johnson <[EMAIL PROTECTED]> wrote: > > 5. Ever used Vim in a putty window, and pasted a giant section of code > after hitting insert when you accidently left "auto-indent" on? > You can find "autopatch" patch on this mailing list about several years ago. It was not accepted into core vim, though. But you can try it out, maybe improve it. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: syntax highlighting of embedded scripts
On Tue, Jul 8, 2008 at 8:14 PM, Ben Fritz <[EMAIL PROTECTED]> wrote:
>
> Consider the following:
>
> perl << EOF
> some code that contains Vim keywords
> EOF
>
> If has("perl") is true, no problem! A syntax region is defined that
> does not include any Vim groups, and the perl syntax is included
> within the region.
>
> If has("perl") is false, however, the code within perl << EOF to EOF
> will be (incorrectly?) highlighted as if it were Vim code.
>
> If has("perl") is false, Vim still tries to run the code as Perl code,
> but will raise an error.
>
Therefore, I think that a containing region should be defined even if
> has("perl") is false. However, if has("perl") is false, either the
> entire region or at least the "perl << EOF" and the "EOF" should be
> highlighted as errors.
I agree
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Gvim issue: slow scrolling of terminal output
On Wed, Jul 2, 2008 at 11:57 PM, Amy Williams <[EMAIL PROTECTED]> wrote: > Gvim appears to have very slow scrolling for output from external > commands. This is an issue for me, particularly with :make and with spell > checking. To see the issue, run gvim, type a word, and then with the cursor > over that word, type z= (for suggested spell corrections). The issue is > worse for me when I do :make, especially for a LaTeX document, since LaTeX > spews all kinds of information to its output. > > I understand that the terminal emulator for Gvim is rudimentary. I guess I > thought I'd put in a plug for either improving it, or, to make at least my > life easier, plug in something like xterm or gnome-terminal to it instead > (not sure how much work this would entail). Is there a chance this will > happen anytime soon? This is platform-depended issue. You need to mention your OS and graphic libraries of your gvim (that is, :version output). In gtk gvim (Linux), there is no slowness. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Terminal-specific query sequences
On Thu, Jul 3, 2008 at 10:34 AM, Yakov Lerner <[EMAIL PROTECTED]> wrote: > On Tue, Jul 1, 2008 at 7:34 PM, Marc Haisenko <[EMAIL PROTECTED]> > wrote: > >> >> As you can see, the UNIX way of handling output is severely broken and >> always >> has been because there's just no way that the terminal can tell the system >> and/or application what it CAN support. > > > Wrong. > Vt* terminals, xterm, konsole, uterm all have ESC Z query. > Vim makes use of ESC Z query. But there's more to it. > > konsole and uterm have more query sequences. You can query colors > and current codepage.But Vim does not implement terminal-specific quering > currently. > > Maybe somebody can make plugin or patch to define and use terminal-specific > queries, especially for konsole and uterm. > > If vim had support for terminal-specific queries (even if by vimscript), > vim would > automatically run better in those terminals. > > It is pity that vim does not make use of terminal-specific queries. That > would > give terminal developers incentive to standardize and expand, queries. > > Yakov > > [1] And even switch codepages. Thst makes it possible to > automatically synchronize vim's encoding and terminals > codepage. Or at least detect and report inconsistency to the user. > Hello Bram, Would you add to the Wishlist support for open-ended terminal-specific quering (konsole, uterm, probably others) for quering terminal's colors and codepage for exampple, and ability to configure into vim new query strings and response processing logic ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Terminal-specific query sequences
On Tue, Jul 1, 2008 at 7:34 PM, Marc Haisenko <[EMAIL PROTECTED]> wrote: > > As you can see, the UNIX way of handling output is severely broken and > always > has been because there's just no way that the terminal can tell the system > and/or application what it CAN support. Wrong. Vt* terminals, xterm, konsole, uterm all have ESC Z query. Vim makes use of ESC Z query. But there's more to it. konsole and uterm have more query sequences. You can query colors and current codepage.But Vim does not implement terminal-specific quering currently. Maybe somebody can make plugin or patch to define and use terminal-specific queries, especially for konsole and uterm. If vim had support for terminal-specific queries (even if by vimscript), vim would automatically run better in those terminals. It is pity that vim does not make use of terminal-specific queries. That would give terminal developers incentive to standardize and expand, queries. Yakov [1] And even switch codepages. Thst makes it possible to automatically synchronize vim's encoding and terminals codepage. Or at least detect and report inconsistency to the user. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: No explicitly positive numbers!
On Mon, Jun 23, 2008 at 8:28 PM, Ben Schmidt <[EMAIL PROTECTED]> wrote: > Hi, Bram, > > Another oddity I've recently discovered is that str2nr won't accept an > explicitly > positive number, such as '+3'. > > This is unexpected. Would you be willing to adjust the behaviour? I can't > think of > any negative/compatibility-breaking side effects this would have, but I > also don't > know where the vim_str2nr function is used. C functions atoi() and strtol() both do accept + in front of the number, if it matters. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: autocommand when changing/setting option ?
On Tue, Jun 17, 2008 at 6:43 PM, Tony Mechelynck < [EMAIL PROTECTED]> wrote: > > On 17/06/08 16:40, Yakov Lerner wrote: > > We do not have autocommand that fires when option is set/changed, right ? > > vim 8 maybe ? Can this be added to do todo ? > > > > For example, when I do 'set tw=70' I want automatically > > execute "match Error /\%>70v/". > > > > I realize I can make a custom command or function to > > change two things together. But if this was a good method, then vim > > never had autocommands in the first place. > > > > Yakov > > You can define an autocommand on some other event(s) (CursorMoved and > CursorMovedI, maybe) to highlight whatever gets after the 'textwidth'. > Here's an example: > >:au CursorMoved * exe 'match Error /\%>' . &tw . 'v/' >:au CursorMovedI * exe 'match Error /\%>' . &tw . 'v/' > > These events are already used by the matchparen.vim plugin, so you're in > good company. > > I am thinking about making use of CursorHold/CursorHoldI event. Remeber old option value, compare it to the current value, detect option change, handle. I have very low 'updatetime' value anyway (200 milli). Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
autocommand when changing/setting option ?
We do not have autocommand that fires when option is set/changed, right ? vim 8 maybe ? Can this be added to do todo ? For example, when I do 'set tw=70' I want automatically execute "match Error /\%>70v/". I realize I can make a custom command or function to change two things together. But if this was a good method, then vim never had autocommands in the first place. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: opening huge files, a little slow
On Sun, Jun 15, 2008 at 3:36 PM, misi <[EMAIL PROTECTED]> wrote: > > Hello, > > would like to use vim to edit large files (600mb). Unfortunatelly, it > looks like opening such large files even on a Pentium 3.4Ghz with PATA > disk takes quite some time (ubuntu, kernel 2.6.22-14). I know that vim > creates some internal tree representation of the file, but I wonder if > something could be tuned, so that such loading times decrease, even if > memory usage would increase. > > I tried to open a 767.187.800 bytes file (I created this file by cat- > ing all vim src files 100 times ) : > > time vim -u ./.vimrc --noplugin -c":q" ../all3.c > > the result is: > > real0m17.670s > user0m15.457s > sys 0m1.428s Hmm you are lucky. Same command takes me 43 sec on 700mb file, E2180 processor with 2GB RAM, ubuntu feisty, kernel 2.6.26-rc5, and ul=-1 added to ./vimrc. > > the .vimrc contains only > > set noswapfile > > I profiled vim, and opening the same file I got the file below > > So the question would be, is it possible to tune sthg. to open faster > these files?? > > Regards > Misi > > below the gprof head > > X$ head -40 no_swap > > Flat profile: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds secondscalls s/call s/call name > 46.12 1.96 1.961 1.96 4.22 readfile > 23.53 2.96 1.00 31025600 0.00 0.00 ml_append_int > 12.94 3.51 0.55 31025601 0.00 0.00 ml_updatechunk > 8.24 3.86 0.35 31361959 0.00 0.00 ml_find_line > 4.94 4.07 0.21 31025600 0.00 0.00 ml_append > 0.47 4.09 0.02 1876672 0.00 0.00 mf_put > 0.47 4.11 0.02 1655954 0.00 0.00 mf_find_hash > 0.47 4.13 0.02 1655954 0.00 0.00 mf_get > 0.47 4.15 0.021 0.02 0.02 ml_delete > 0.47 4.17 0.02 ml_setmarked > 0.24 4.18 0.01 1876675 0.00 0.00 mf_ins_hash > 0.24 4.19 0.01 1655955 0.00 0.00 mf_rem_hash > 0.24 4.20 0.01 1655954 0.00 0.00 mf_rem_used > 0.24 4.21 0.01 698266 0.00 0.00 ml_add_stack > 0.24 4.22 0.01 441920 0.00 0.00 alloc > 0.24 4.23 0.01 258689 0.00 0.00 mf_trans_del > 0.24 4.24 0.01 258600 0.00 0.00 ml_lineadd > 0.24 4.25 0.01 vim_chdirfile > 0.00 4.25 0.00 1876674 0.00 0.00 mf_ins_used > 0.00 4.25 0.00 453656 0.00 0.00 lalloc > 0.00 4.25 0.00 453591 0.00 0.00 vim_free > 0.00 4.25 0.00 220720 0.00 0.00 mf_alloc_bhdr > 0.00 4.25 0.00 220720 0.00 0.00 mf_free_bhdr > 0.00 4.25 0.00 220720 0.00 0.00 mf_new > 0.00 4.25 0.00 220720 0.00 0.00 mf_release > 0.00 4.25 0.00 219851 0.00 0.00 ml_new_data > 0.00 4.25 0.0011709 0.00 0.00 RealWaitForChar > 0.00 4.25 0.0011709 0.00 0.00 mch_breakcheck > --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request For Feedback: "timeout per-mapping" wish, like :nnoremap lhs rhs
On Fri, Jun 6, 2008 at 10:03 PM, Tony Mechelynck < [EMAIL PROTECTED]> wrote: > > On 06/06/08 20:52, Yakov Lerner wrote: > > I'd lile to hear people feedback about "timeout per-mapping" wish, like: > > > >:noremapXYZ .. > > > > I have certain mappings for which wish to define > > smaller timeout that my usual keyboard timeout. > > Does anybody have feedback ? > > > > Yakov > > not me, and I had already seen your post the first time. I got mailer bounce to the 1st message that it was rejected. Strange that you saw it given the bounce. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Request For Feedback: "timeout per-mapping" wish, like :nnoremap lhs rhs
I'd lile to hear people feedback about "timeout per-mapping" wish, like: :noremap XYZ .. I have certain mappings for which wish to define smaller timeout that my usual keyboard timeout. Does anybody have feedback ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Request For Feedback: "timeout per-mapping" wish, like :nnoremap lhs rhs
I'd lile to hear people feedback about "timeout per-mapping" wish, like: :noremap XYZ .. I have certain mappings for which wish to define smaller timeout that my usual keyboard timeout. Does anybody have feedback ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
vimdiff with one non-existent and one existent file does not show contents ?
cd /tmp rm -f nosuchfile # make sure there is no such file man 1 ls >ls.txt # get some text vimdiff -U NONE -u NONE ls.txt nosuchfile # as expected vimdiff -U NONE -u NONE nosuchfile ls.txt # ??? where is contents of right pane ??? Thanks Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: clientserver --remote-send and map
On Fri, May 23, 2008 at 7:54 PM, Philippe Fremy <[EMAIL PROTECTED]>
wrote:
>
> Tony Mechelynck wrote:
> > On 22/05/08 15:52, Philippe Fremy wrote:
> > [...]
> >> The conclusion seems pretty clear: mapping code is not executed when
> >> sending keys through --remote-send. Is that a bug ?
> > [...]
> >
> > I believe it is not a bug, by analogy to the following:
> >
> >> *remote_send()*
> *E241*
> >> remote_send({server}, {string} [, {idvar}])
> >> Send the {string} to {server}. The string is sent as input
> >> keys and the function returns immediately. At the Vim
> server
> >> the keys are not mapped |:map|.
> > etc.
> >
>
> I see.
>
Philippe,
Try this:
vim --remote-expr 'feedkeys("\")'
:help feedkeys()
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: clientserver --remote-send and map
On Wed, May 21, 2008 at 6:49 PM, Philippe Fremy <[EMAIL PROTECTED]> wrote: > > >Hi, > > I am playing with --remote-send. I have the following problem: > > d:\work\vimWrapper\vimWrapper1\pyvimwrapper\tests>gvim --servername HOP > --remote -send ":map icoucouCR>ESC>j" > > This sets the function key to do "icoucouj", i.e. insert > coucou + end of line, return to normal mode and go one line down. After > it has been executed, it works if I press the function key. > > However: > > d:\work\vimWrapper\vimWrapper1\pyvimwrapper\tests>gvim --servername HOP > --remote -send "" > > does strictly nothing. Use are sending 4 characters here, '<', 'F', '4', '>'. Ask on vim_use forums for the solution. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: UTF-8 bomb showing up after :%!sort
On Mon, May 19, 2008 at 11:01 PM, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > :se fileencoding=utf8 bomb > > :%!sort > > > > The problem is with using an encoding that the sort command doesn't > understand [utf8] Maybe sort does understand utf8 (gnu sort definitely does), but vim does not set $LANG,$LC_ALL env.vars to reflect new &fenc ? Maybe vim could auto-set env.vars. $LANG,$LC_ALL to reflect new &fenc? to help subprocesses know encoding of files they handle ... Maybe vim already does this .. but I do not see it. That won't help BOM-in-the-middle-of-file issue, of course. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: D-Bus in vim, and collaborative editing
On Sat, May 17, 2008 at 4:45 PM, Alban Crequy <[EMAIL PROTECTED]> wrote: > > The D-Bus connection is an Unix socket. When vim fires a signal from the > Does it require a daemon or something ? That is a burden of additional dependency that I would not like, personally. Why not use vim-remote mechanism ? It is event-driven and already built into vim. If you want to artificially limit your mechanism it to be host-local and then there are more portable solutions than d-bus (windows has no d-bus). Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: authoritative source repository
On Thu, May 15, 2008 at 8:59 PM, John Calixto <[EMAIL PROTECTED]> wrote: > > Hi folks, > > Could somebody please explain the Vim source repos to me? > > There seems to be activity in both the CVS and SVN repos - which one is > The Authoritative Vim Repository? > > How do merges occur? Who is responsible for merging them? > > Are there specific purposes for each repo? There are no merges. CVS and SVN stay in sync. CVS being updated first, and CVN follows CVS updates in short time. Originally, only CVS repo existed. Sourceforge, where CVS is hosted, had big problems with stability and slowness of CVS in the past, I do not know if SVN is better now, I switched to SVN mirror. SVN repo was created by a volunteer to mirror the CVS repo. SVN mirrors CVS. SVN server is more stable than CVS, but SVN gets updates several minutes or hours later than CVS. Patches and vim sources originate from Bram Moolenaar, author and maintainer of vim. Bram calls himself "vim dictator". Development model has "star structure:" People contribute matches/emails to Bram, but all checkins originate from Bram. Bram issues patches in 3 forms simultaneously: 1) he emails patches to vim-dev mailing list 2) he uploads patchfiles to http://ftp.home.vim.org/vim/patches/VERSION, new versions as tarballs to http://ftp.home.vim.org/vim 3) he checks in CVS SVN gets same checkins as CVS, except that SVN is managed and fed by Edward L.Fox, not by Bram directly. Patches are sequentially numbered, and SVN stays in sync with CVS. >From time to time, Bram uploads full tarballs to http://ftp.home.vim.org/vim . Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
On Mon, Apr 14, 2008 at 7:14 AM, Yakov Lerner <[EMAIL PROTECTED]> wrote: >123. 456 " floating number 123. concatenated with "456" Correction: 123. 456 " floating number 123. , space, integer 456 --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
On Sat, Apr 12, 2008 at 4:58 PM, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > Here is an update for the floating point patch. The 'g' argument for > printf() was implemented and a few bug fixes. > > This is to be applied to the original source code, without the older > floating point patch. > > I would still like feedback on the format of floating point numbers: > >&123.456 >&1.23e-3 When left operand is number, can you require space around '.' concatenation operator, otherwise '.' is floating point ? Who needs concatenation of two constants anyway ? 123.456 " floating number 123 . 456 " concatenation of "123" and "456" 123. 456 " floating number 123. concatenated with "456" 123 .456 " integer 123, space, floating .456 123.e2 " floating number 123 . e2 "concatenation of number and variable 123. e2 "floating number, space, variable e2 123 .e2 "concatenation ? Maybe backward-compatibility option for that ? (treat 123.456 as concat vs floating ?) Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: upgrading vim on linux
You can try the scriptvim7-install.sh (attached) which downloads, builds and installs latest vim7 in one command without arguments. Description and download link ia at: http://www.vim.org/scripts/script.php?script_id=1473 Invocation: sh ./vim7-install.sh Or save the script directly from this link: http://ilerner.3b1.org/vim7-install.sh Attached. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- vim7-install.sh Description: Bourne shell script
Re: shell highlighting problem, after command name 'locale'
On Thu, Mar 6, 2008 at 12:11 PM, Vladimir Marek <[EMAIL PROTECTED]> wrote:
>
> On Thu, Mar 06, 2008 at 10:13:16AM +0200, Yakov Lerner wrote:
> >
> > I see problem with shell highlighting with the following piece,
> > apparently caused by the command named 'locale'.
> > I am using latest runtime files. from rsync.
> > Does anybody see incorrect highlighting, too ?
> > --
> > #!/bin/bash
> >
> > utf-off() {
> > echo "export LANG=C; unset LC_ALL LANGUAGE"
> > unset `locale | awk -F= '{print$1}' `
> > export LANG=C; unset LC_ALL LANGUAGE;
> > env|egrep '^(LANG|LC_)';
> > }
> > --
>
> > The problem seem to begin with the word 'locale'.
> >
> > If I remove space after 'locale' (so it becomes locale|),
> > there is another strange highlighting in the word 'locale'.
>
> It seems to work fine for me.
>
> !cat $VIMRUNTIME/syntax/sh.vim | grep Version
> " Version: 89
Version 95 here.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
shell highlighting problem, after command name 'locale'
I see problem with shell highlighting with the following piece,
apparently caused by the command named 'locale'.
I am using latest runtime files. from rsync.
Does anybody see incorrect highlighting, too ?
--
#!/bin/bash
utf-off() {
echo "export LANG=C; unset LC_ALL LANGUAGE"
unset `locale | awk -F= '{print$1}' `
export LANG=C; unset LC_ALL LANGUAGE;
env|egrep '^(LANG|LC_)';
}
--
The problem seem to begin with the word 'locale'.
If I remove space after 'locale' (so it becomes locale|),
there is another strange highlighting in the word 'locale'.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: feature request: help users count lines - display relative line numbers
Nick Gravgaard <[EMAIL PROTECTED]> escrit: > if Vim could display relative line numbers > in the left hand margin (with the current > line being 1, the next being 2, and so on) Yes, this is easy, vim can. This is easy implementable in vimscript using the *SIGNS* (:help signs). Plus, use the CursorMoved autocommand. Learn vim scripting yourself, or ask someone who has vimscript experience to write such script. Couple of hours if you already have experience with vimscript, or several days if it's your first nontrivial vim script. Good luck Yakov -- [1] Not related to http://imdb.com/title/tt0286106/ :-) --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
"collaborative editing" clarification Was: New features to vote on and sponsoring
Hello Bram, You wrote: > add collaborative editing: changes made to a buffer show up in another Vim in a second I'd like to ask for some clarifications. Clarification about perceived behaviour, not about implementation: 1. "two-way collaboration" or "one-way collaboration" ? Vim instance B attaches to instance A for collaboration on file F. Then B absorbs (and shows) changes to F made by A, right ? Does it automatically work the opposite way ? That is, when B's user makes changes, will A also show these changes so that they always stay in sync ? Which operation mode will be the basic mode ? The two-way or the one-way ? Do we allow both modes of operation ? In two-way collab, two swapfiles file will coexist for the same edited file, right ? 2. Relation of "collaborative editing" to "client-server" Does "collaborative editing" *require* client-server ? Can "collaborative editing" work *without* client-server ? I see this item as matter of requirements, not nevessarily as matter of implementation. 3. We want to allow more than two Vims atached to the collaboration group, correct ? (N-way collaboration). Is the collaboration group "symmetric" (every instance plays identical role; absorbs changes of all others, can make changes which all others absorb) ? Or it has one "central" instance which has special role in the group ? (say, only "central" instance makes changes; all other instances cannot make their own changes; peripheral instances absorb only changes of the "central" instance). 4. You see the simple implementation of collaboration as vim-B reading swapfile of vim-A, correct ? Does it lend itself to two-way collaboration ? To the N-way collaboration ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Charles E Campbell wrote: > Any good way to get > the vim process's pid? How about under Windows? Maybe a patch to add getpid() function to vimscript is not bad idea ? Even without relation to Charles ciphering troubles. Can this be added to the todo ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
> to make it work > for may unixes for many unixes --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On Nov 29, 2007 12:23 AM, Charles E Campbell Jr
<[EMAIL PROTECTED]> wrote:
>
> Hello!
>
> I don't see any way to encrypt/decrypt strings in the vim function
> library, but there is a way to encrypt a file buffer. Netrw tries to
> make use of ftp, etc and its associated passwords simpler by retaining
> the password in a variable (which is not normally saved). Thus one
> reads a file via ftp, say, provides the password to do so, and writing
> is done without requiring another entry of the password. I thought
> about making a temporary "password" automatically using localtime() at
> first invocation of netrw and the process's pid. Any good way to get
> the vim process's pid? How about under Windows?
On unixes that have /proc, you can get pid of vim examining
/proc/self.
On another note, if all you need is some pseudorandom number,
you can try extract all digits from tempname(). Supposed to
be relatively unique.
In my linux, :echo libcallnr("libc.so.6", "getpid", "")
prints pid of vim. Surprisingly, libcallnr("libc.so", "getpid", "")
doesn't. On some older linux, that would be libc.so.5 etc.
Doing small loop for N and checking existance of
/usr/lib/libc.so.N might help. On some other unixes,
libcallnr("libc.so", "getpid", "") would actually work; to make it work
for may unixes, you could trap the error and resort /usr/lib/libc.so.N.
On windows, somebody should know name of the library and
name of the function for correct libcallnr() call.
However, if you need several unique/random bytes, the best
way on unix is to read /dev/urandom if it exists.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: vim scrolling painfully slow
On Nov 18, 2007 9:26 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I connect from windows xp to solaris using telnet. I was scrolling > using vim editor and saw something strange. If I do a Ctrl-F twice > in succession, the first screen gets updated quickly (almost in > no time) but the second screen takes very long time (about 8 > seconds). > > To eliminate problems in network, keyboard, memory on windows > side, I tried the vi editor. It scrolls so fast, I barely see the > refresh > happening. I think that in order to really eliminate problems in network & telnet client, you need to run the same editing session locally. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: anchoring filename completion to the end of filename
On 10/22/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > Yakov Lerner wrote: > > > Would you add to the todo list some way to lock the > > filename completion to the end of the filename ? Currently, the > > :e *a > > automatically adds the * at the end. This shows not > > files endnig with 'a', but all files *containing* 'a' . This > > is by design. The consequence is that user cannot make the > > completion show files the ending with 'a', no ? > > > > Maybe some character can be defined that anchors the to the > > end of name and tells the completion mechanism not to add > > the trailing * ? For example, > > :e *a$ > > ? > > > > This affects usefulness of filename completion when > > directory contains very large number of files. > > You can at least match with the end of a word: > :e *a\> > > Somehow using a dollar doesn't work here, probably because of expanding > environment vars. We might not be able to change this without breaking > backwards compatiblity. $$ maybe ? some sequence never used before ? This is completion-specific issue. In glob, the problem does not exist. Strangely, :e $ completes names of env.vars, but :e *a$ does not complete anything. Since completions are not scriptable, backward-compatibility here is different maybe ? There are human habits of course. \> in filenames is weird. It works depending on current syntax which does not make much sense for filenames (For example, In ft=c, it matches before '.' and before '-' . In 'help' mode, it does not). Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Possibility of a console server through a socket?
On 10/22/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote: > > > How difficult would it be to implement a console server using sockets? > if_xsrvcmd.c looks quite complicated, but I get the felling that a > simple socket interface wouldn't require quite as much code. > > Anyone have any thoughts on this? > > The reason I would like to see a socket-powered server is that the X11 > interface will only work when an actual X11 server is also running. You might have better luck running some "pseudo-X11 server" like vnc server which can run on Linux/Unix machine without any graphics hardware (but *not* x11vnc). Besides vnc, other "pseudo-X11 servers" exist which run without actual graphics hardware, for different kinds of weirdness. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
anchoring filename completion to the end of filename
Bram, Would you add to the todo list some way to lock the filename completion to the end of the filename ? Currently, the :e *a automatically adds the * at the end. This shows not files endnig with 'a', but all files *containing* 'a' . This is by design. The consequence is that user cannot make the completion show files the ending with 'a', no ? Maybe some character can be defined that anchors the to the end of name and tells the completion mechanism not to add the trailing * ? For example, :e *a$ ? This affects usefulness of filename completion when directory contains very large number of files. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Fwd: doc nitpicking
On 10/12/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
>
> Yakov Lerner wrote:
>
> > On 10/11/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Yakov Lerner wrote:
> > >
> > > > :help :! says:
> > > > :silent !{cmd}
> > > > The screen is not redrawn then, thus you have to use
> > > > CTRL-L or ":redraw!" if the command did display something.
> > > >
> > > > The last part ("if the command did display something") is not true.
> > > > In console vim, screen is always grabled after ':silent !CMD"
> > > > even if CMD did not print anything. (try ':silent !true' after
> ':help
> > > > help').
> > > > The correct wording would be:
> > > >
> > > > :silent !{cmd}
> > > > The screen is not redrawn then, thus you have to use
> > > > CTRL-L or ":redraw!" even if the command did not display
> anything.
> > >
> > > The docs are correct, ":silent !true" doesn't mess up the display for
> > > me.
> > >
> > > Check your shell init scripts for something that produces output.
> >
> >
> > To make sure that shell init script are not even invoked, I set
> > :set shell=/bin/true
> > Still, screen is cleared after :silent !/bin/true.
> > In gdb, I caught the place and the string that clears the screen.
> > The string is "\033[?1049h\033[?1h\033=" (length=15).
> > It is printed after fork+execve("/bin/true"), at this place:
> >
> > mch_write ( s=0x820b040 "\033[?1049h\033[?1h\033="..., len=15) at
> > os_unix.c:307
> > 307 write(1, (char *)s, len);
> > (gdb) n
> >
> > [Yakov] the vim screen is cleared at after the write() above
> >
> > 308 if (p_wd) /* Unix is too fast, slow down a bit
> more */
> > (gdb) where
> > #0 mch_write (
> > s=0x820b040 "\033[?1049h\033[?1h\033="..., len=15) at os_unix.c:308
> > #1 0x081a2b74 in ui_write (
> > s=0x820b040 "\033[?1049h\033[?1h\033="..., len=15) at ui.c:51
> > #2 0x0819ed96 in out_flush () at term.c:2545
> > #3 0x0819fa6a in starttermcap () at term.c:3233
> > #4 0x08090393 in do_shell (cmd=0x82155d8 "/bin/true", flags=0) at
> > ex_cmds.c:1471
>
> Apparently your termcap settings are causing this. Try this:
> :set t_ti= t_ks=
Didn't help.
The issue is related to terminal emulator somehow.
Under minicom, ':silent !' works as documented (minicom emulation set to
"ANSI").
Under xterm and konsole, ':silent !true' clears the screen.
Bram, which terminal emulator are you using ?
It might have something to do with the colorscheme you are using, esp.
> if you are using a non-default background color.
This is 'vim -u NONE', i.e. default everything.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: doc nitpicking
On 10/11/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
>
> Yakov Lerner wrote:
>
> > :help :! says:
> > :silent !{cmd}
> > The screen is not redrawn then, thus you have to use
> > CTRL-L or ":redraw!" if the command did display something.
> >
> > The last part ("if the command did display something") is not true.
> > In console vim, screen is always grabled after ':silent !CMD"
> > even if CMD did not print anything. (try ':silent !true' after ':help
> > help').
> > The correct wording would be:
> >
> > :silent !{cmd}
> > The screen is not redrawn then, thus you have to use
> > CTRL-L or ":redraw!" even if the command did not display anything.
>
> The docs are correct, ":silent !true" doesn't mess up the display for
> me.
>
> Check your shell init scripts for something that produces output.
To make sure that shell init script are not even invoked, I set
:set shell=/bin/true
Still, screen is cleared after :silent !/bin/true.
In gdb, I caught the place and the string that clears the screen.
The string is "\033[?1049h\033[?1h\033=" (length=15).
It is printed after fork+execve("/bin/true"), at this place:
mch_write ( s=0x820b040 "\033[?1049h\033[?1h\033="..., len=15) at
os_unix.c:307
307 write(1, (char *)s, len);
(gdb) n
[Yakov] the vim screen is cleared at after the write() above
308 if (p_wd) /* Unix is too fast, slow down a bit more */
(gdb) where
#0 mch_write (
s=0x820b040 "\033[?1049h\033[?1h\033="..., len=15) at os_unix.c:308
#1 0x081a2b74 in ui_write (
s=0x820b040 "\033[?1049h\033[?1h\033="..., len=15) at ui.c:51
#2 0x0819ed96 in out_flush () at term.c:2545
#3 0x0819fa6a in starttermcap () at term.c:3233
#4 0x08090393 in do_shell (cmd=0x82155d8 "/bin/true", flags=0) at
ex_cmds.c:1471
#5 0x0808fac8 in do_bang (addr_count=0, eap=0xbf96b110, forceit=0, do_in=1,
do_out=1) at ex_cmds.c:1021
#6 0x080a99de in ex_bang (eap=0xbf96b110) at ex_docmd.c:8305
#7 0x080a0e58 in do_one_cmd (cmdlinep=0xbf96b278, sourcing=0,
cstack=0xbf96b2d4, fgetline=0x80b4454 ,
cookie=0x0) at ex_docmd.c:2622
#8 0x0809e718 in do_cmdline (cmdline=0x0, getline=0x80b4454 ,
cookie=0x0, flags=0) at ex_docmd.c:1100
#9 0x0811b3f5 in nv_colon (cap=0xbf96b658) at normal.c:5168
#10 0x08114a32 in normal_cmd (oap=0xbf96b6f8, toplevel=1) at normal.c:1141
#11 0x080dc833 in main_loop (cmdwin=0, noexmode=0) at main.c:1180
#12 0x080dc383 in main (argc=3, argv=0xbf96b8f4) at main.c:939
After that, there is only one mch_write(), "\033[1;25H" (len=7),
and screen remains empty, and vim waits for input.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: doc nitpicking
On 10/11/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
>
> On 10/11/07, ap <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > On Oct 10, 10:22 pm, "Yakov Lerner" <[EMAIL PROTECTED]> wrote:
> > > :help :! says:
> > > :silent !{cmd}
> > > The screen is not redrawn then, thus you have to use
> > > CTRL-L or ":redraw!" if the command did display something.
> > >
> > > The last part ("if the command did display something") is not true.
> > > In console vim, screen is always grabled after ':silent !CMD"
> > > even if CMD did not print anything. (try ':silent !true' after ':help
> > > help').
> > > The correct wording would be:
> > >
> > > :silent !{cmd}
> > > The screen is not redrawn then, thus you have to use
> > > CTRL-L or ":redraw!" even if the command did not display anything.
> > >
> > > Yakov
> >
> > logic nitpicking:
>
>
>
> I forgot to include the testcase that demonstrates
> the discrepancy between the doc and the reality. Here it is:
>
> vim -u NONE
> :help help " get some text on screen, and statuslines
> :silent :true " The screen is garbled. Now you need Ctrl-L.
>
Oops. This sould have veen
:silent !true " The screen is garbled. Now you need Ctrl-L.
console vim, Linux, v 7.1.2.
This is noting new. I had always have this behavour since 6.3 times.
In GUI vim, the sceen seems to be not garbled in such scenario.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: doc nitpicking
On 10/11/07, ap <[EMAIL PROTECTED]> wrote:
>
>
>
>
> On Oct 10, 10:22 pm, "Yakov Lerner" <[EMAIL PROTECTED]> wrote:
> > :help :! says:
> > :silent !{cmd}
> > The screen is not redrawn then, thus you have to use
> > CTRL-L or ":redraw!" if the command did display something.
> >
> > The last part ("if the command did display something") is not true.
> > In console vim, screen is always grabled after ':silent !CMD"
> > even if CMD did not print anything. (try ':silent !true' after ':help
> > help').
> > The correct wording would be:
> >
> > :silent !{cmd}
> > The screen is not redrawn then, thus you have to use
> > CTRL-L or ":redraw!" even if the command did not display anything.
> >
> > Yakov
>
> logic nitpicking:
I forgot to include the testcase that demonstrates
the discrepancy between the doc and the reality. Here it is:
vim -u NONE
:help help " get some text on screen, and statuslines
:silent :true " The screen is garbled. Now you need Ctrl-L.
" But command did not output anything.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: doc nitpicking
The screen is not redrawn then, thus you have to use CTRL-L or ":redraw!" if the command did display something. I do not think this paragraph can be interpreted ambiguously. The first part - "The screen is not redrawn then" - I see it as information not operational, it does not contradict the second part. The second part is operational. It instructs the user when to use Ctrl-L and when not to use Ctrl-L: You have to use Ctrl-L(or :redraw!) *IF* the command did display something. Do you interpret the above phrase differently than me ? The problem with this instruction, it is incorrect. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
doc nitpicking
:help :! says:
:silent !{cmd}
The screen is not redrawn then, thus you have to use
CTRL-L or ":redraw!" if the command did display something.
The last part ("if the command did display something") is not true.
In console vim, screen is always grabled after ':silent !CMD"
even if CMD did not print anything. (try ':silent !true' after ':help
help').
The correct wording would be:
:silent !{cmd}
The screen is not redrawn then, thus you have to use
CTRL-L or ":redraw!" even if the command did not display anything.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Trial patch for variable tabstops
On 10/6/07, Matthew Winn <[EMAIL PROTECTED]> wrote: > > On Sat, 6 Oct 2007 10:22:53 +0200, "Yakov Lerner" <[EMAIL PROTECTED]> > wrote: > > > On 10/5/07, Matthew Winn <[EMAIL PROTECTED]> wrote: > > > > > > I've been working on an implementation of the non-uniform tabstops > > > that were discussed about a month ago, and I have a patch ready for > > > trying out. I've done some testing on Linux and Windows XP; the parts > > > I'm able to test seem to be OK and on Linux it survives "make test" > > > cleanly, but I need people to try it out on other systems and test > > > the parts I can't reach. > > > > > > With this patch the set tabstop, set softtabstop and retab commands > > > take a comma-separated list of tab widths (as in ":set ts=4,20,8" or > > > ":retab 20,4"). > > > > You changed the option type from numeric to string, right ? > > > > I believe this breaks some backward-compatibility: > > 1) The old code rightly expected &ts to be proper number and did > > arithmetics on it; this gets broken. > > 2) Also, if old code had things like 'set ts+=3', 'set ts-=3', it gets > > broken, too. > > :set ts=5,7 ts+=3 ts? > tabstop=5,73 > > Not a very useful ability. Wrong. On a comma-separated string option, += normally adds the implied/needed comma. Try this: :set ve= ve+=block ve+=insert ve? virtualedit=block,insert Notice how += adds the comma ? Your example above is not how += usually behaves on the comma-separated string options. On the comma-separated string option, your example should look like this: :set option=5,7 option+=3 option? option=5,3,7 , not 5,37. Then it sort of starts making sense, no ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Trial patch for variable tabstops
On 10/6/07, Matthew Winn <[EMAIL PROTECTED]> wrote: > > > On Sat, 6 Oct 2007 10:22:53 +0200, "Yakov Lerner" <[EMAIL PROTECTED]> > wrote: > > > On 10/5/07, Matthew Winn <[EMAIL PROTECTED]> wrote: > > > > > > I've been working on an implementation of the non-uniform tabstops > > > that were discussed about a month ago, and I have a patch ready for > > > trying out. I've done some testing on Linux and Windows XP; the parts > > > I'm able to test seem to be OK and on Linux it survives "make test" > > > cleanly, but I need people to try it out on other systems and test > > > the parts I can't reach. > > > > > > With this patch the set tabstop, set softtabstop and retab commands > > > take a comma-separated list of tab widths (as in ":set ts=4,20,8" or > > > ":retab 20,4"). > > > > You changed the option type from numeric to string, right ? > > > > I believe this breaks some backward-compatibility: > > 1) The old code rightly expected &ts to be proper number and did > > arithmetics on it; this gets broken. > > 2) Also, if old code had things like 'set ts+=3', 'set ts-=3', it gets > > broken, too. > > Does anyone actually do that? It's easy to find out. Just check every vim script in existance ;-) Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Trial patch for variable tabstops
On 10/5/07, Matthew Winn <[EMAIL PROTECTED]> wrote: > > I've been working on an implementation of the non-uniform tabstops > that were discussed about a month ago, and I have a patch ready for > trying out. I've done some testing on Linux and Windows XP; the parts > I'm able to test seem to be OK and on Linux it survives "make test" > cleanly, but I need people to try it out on other systems and test > the parts I can't reach. > > With this patch the set tabstop, set softtabstop and retab commands > take a comma-separated list of tab widths (as in ":set ts=4,20,8" or > ":retab 20,4"). You changed the option type from numeric to string, right ? I believe this breaks some backward-compatibility: 1) The old code rightly expected &ts to be proper number and did arithmetics on it; this gets broken. 2) Also, if old code had things like 'set ts+=3', 'set ts-=3', it gets broken, too. For preserving backward compatibility, I believe it's better to introduce new option name (some 'vst' for variable tabstop, or suchlike) than to change the type of existing option. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vim : process.c ?
On 9/30/07, A.Politz <[EMAIL PROTECTED]> wrote: > > > I am student of computer science. In the next semester I'll > have to do some practical work supervised by a professor. > Now what I really would like to do in this project, is > giving vim the ability to start and manage subprocesses. > > What I have in mind is : > > - Obviously writing the code, that handles the processes > (sockets ? ,portability ? ). > I would at least want to implement this for *nix. > - vim functions to interface with this code. > > - associate process output with a buffer > - add a buffer option, which automatically scrolls a > buffer to the end > > or/and > > - make its output available via functions and autocommand. Are you going to use pseudo-tty (between parent and child) ? If no, then be aware you are going to have some problems. If yes, then how much %% of code overlap with /usr/bin/screen you are going to have ? Are you going to have detach/attach functionality a-la screen ? Are you aware of the existing trick of redirecting output of the process to the log-file and having vim constantly reread and show the bottom of the logile ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: :catch value of a variable
On 9/21/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
>
> On 9/21/07, Ben Schmidt <[EMAIL PROTECTED]> wrote:
>
> > Most commands do not take
> > variables/expressions as input directly but need to be constructed using the
> > :exe command. I don't see any good reason why :catch should differ.
>
> For one thing, :catch can't be :execute'd.
Yes, separate catch can't.
But you can 'exe'cute the whole try...endtry block -- as a workaround for you:
exe "try | echo nosuchvar | catch // | echo 'Caught' | endtry"
There in such a construct, you can use variable in place of catch regex.
Regarding your pursuit of the modification of catch -- my opinion is
that vimscript would gain if it had general mechanism to
substitute vars and expressions in any part of command.
Like $VAR workd in shell or [...] in tcl or Ctrl-R= in vim's own
commandline mode.
Such extension would cover any command not only catch.
Maybe existing {...} can be extended to expand in any part of the
command and contain any expression ?
At the very least, Ctrl-R= could be made to work for script lines, too.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
No use of 'el' (clear to end of line) ?
I work on 60 lines x 120 columns miniterm over 9600 baud. The speed is satisfactory except one case: when vim draws '~' in every line on the init screen. This drawing is very slow, takes several seconds to fill the screen. I took the vim output log and noticed that vim fills every line with spaces and does not make use of 'el' escape sequence (clear to end of line). 'infocmp xterm|grep el' shows that 'el' is defined. (TERM is xterm). I think the speed can be improved here, the more that the whole screen was cleared just prior to this ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [BUG] autocmd effect cancelled by :bdelete
On 9/16/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote: > > % vim > :new > :autocmd BufWinLeave :2wincmd w | quit > :wincmd p > :q > > Guess what, buffer 1 is still loaded and displayed. Like, WTF? > > The reason I want to do this is that I have opened a window that I > want to be dependent on the first window being visible. This is for > doing diffs.I've tried basically every combination of autocmds I > could think of, but nothing works. This works: autocmd BufWinLeave :qall! and looks to me much better than your example if you indend to quit vim from autocommand. Your example btw works same way with buffer-local autocommands, or with buffer-name-based autocommands, same way. If, instead of quitting vim, you want to close the other window, you can use :bd 2 or :bw 2 in the autocommand. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Searching for Vim scripts
On 9/4/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > Hello Vim users, > > So far we only had the possibility to search for scripts on the Vim > website. Of course you could use your favorite search engine, but then > you would find any type of file, not just Vim scripts. > > I have now added a search box to the search page on www.vim.org where > you can specifically search for Vim scripts, anywhere on the internet. > This uses Google Code Search. It not only finds individual "*.vim" > files but also scripts inside archives. E.g., in the Vim distribution. > > There is one extra special thing: You search with a regexp pattern. > Thus what you type in the search box are not keywords, it is different > from a normal Google search. For example, you can search for > "python.*indent" and find matches in "Python indent", "GetPythonIndent" > and "python_highlight_indent_errors". The regexp synax used is Posix, > it's different from Vim regexp. > > Try it out on the Vim search page (second box from the top): >http://www.vim.org/search.php Wow, regexes in in google codesearch. Is it what you added ? Do they plan to regex-search anywhere :-) ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Feature request... non-uniform tabstops
On 8/27/07, Mark Waggoner <[EMAIL PROTECTED]> wrote: > > > I've asked Bram in the past whether he would add this to the voting list. > The best I've been able to get is "I'll think about it" :) Perhaps if I > throw the idea out to the mailing lists I can garner a little support. > > When editing or viewing text files that contain data with fields separated > by tab characters, I would like to be able to set non-uniform tabstops. > This would allow the text to be viewed and edited in a much more > readable/understandable format than fixed tabstops can provide. The usage > model I envision is: > > set tabstop=8,10,4,20,8 You can make this in vimscript, as "userlevel" plugin. By remapping the tab in i-mode an using to expand it to your function. Get example of simple plugin, learn vimscript, make plugin, post to www.vim.org/scripts. Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: weird up/down arrows behaviour on braces 7.1.87
On 8/28/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
>
>
> Yakov Lerner wrote:
>
> > > > I get weird up/down behaviour when cursor traverses the braces. vim
> > > 7.1.87,
> > > > no custom plugins. This is apparently somehow related to matchparen.
> > > >
> > > > The testfile is x.c below.
> > > > Here is what happens if I press down starting from the beginning of
> > > file,
> > > > position 1:
> > > >
> > > > 1. Down. instead of going to line 2, cursor shows at line 4 !!!
> > > > 2. Down. cursor is at line 3
> > > > 3. Down. cursor is at line 2 !!!
> > > > 4. Down. cursor is at line 5
> > > > 6. Up. Cursor is at line 2!!!
> > > > 7. Up. Cursor is at line 3.
> > > > 8. Up. Cursor is '}' line 4!!!
> > > > 9. Up. Cursor is at line 1.
> > > >
> > > > --- x.c
> > > > int foo()
> > > > {
> > > > return 0;
> > > > }
> > > > /* */
> > >
> > > I don't have a vt220 so I can't try it out. I wonder if you are
> > > actually using a vt220 anyway, these are quite rare these days...
> >
> >
> > I observe same results when setting XTERM to xterm-mono.
> > The terminal was actually xterm.
> > You can change vt220 to xterm-mono and see the same results.
> >
> > > How can you tell where the cursor is and it's not the highlighting
> that
> > > makes you think the cursor is somewhere else?
> >
> > I can do :echo line('.') col('.'). This shows me that cursor is not
> > where vim shows the white block on the screen.
> >
> > > Try using a different color scheme.
> >
> > I normally work in color xterm. There is no problem there.
> > I do not normally work in B/W term. What we were doing, we were checking
> how
> > some console software (not vim) behaves under the black-and-white TERM.
> >
> > As a side effect, I noticed that matchparen behaves weirdly on
> B/W term. In
> > the mentioned B/W setup, the colorscheme was default because .vimrc is
> > empty.
> >
> > Anyway, if you want to see the matchparen problem on BW term (with
> default
> > colorscheme), you can set TERM to xterm-mono and see for yousrself.
>
> After I do ":set term=xterm-mono" I get no syntax HL and no matchparen
> highlighting. The cursor shows up in the expected position.
>
> I suspect there is something wrong with your termcap/terminfo entry for
> xterm-mono. Check the output of ":set termcap".
Output of :set termcap is below. More details about reproducing this:
This happens to me on the konsole with (1) white-on-black konsole
schema and (2) no blinking cursor. Maybe this is konsole problem.
I get matchparen display wrong in the following scenario:
1. In konsole, disable blinking cursor. Set 'White on Black' konsole schema.
2. cp /dev/null /tmp/.vimrc# simulate empty .vimrc
3. HOME=/tmp TERM=xterm-mono vim
a
{
}
-
:set termcap
--- Terminal codes ---
t_AB= t_CV= t_ks=^[[?1h^[=
t_RV=^[[>c t_us=^[[4m
t_AF= t_ut=y t_le=^H
t_Sb= t_vi=^[[?25l
t_AL=^[[%p1%dL t_da= t_mb=^[[5m
t_Sf= t_vs=^[[?12;25h
t_al=^[[L t_db= t_md=^[[1m
t_se=^[[27m t_SI=
t_bc= t_DL=^[[%p1%dM t_me=^[[m
t_so=^[[7m t_EI=
t_cd=^[[J t_dl=^[[M t_mr=^[[7m
t_sr=^[Mt_xs=
t_ce=^[[K t_fs=^G t_ms=y
t_ts=^[]2; t_ZH=^[[7m
t_cl=^[[H^[[2J t_IE=^G t_nd=^[[C
t_te=^[[?1049l t_ZR=^[[m
t_Co= t_IS=^[]1; t_op= t_ti=^[[?1049h
t_CS= t_ke=^[[?1l^[> t_RI=^[[%p1%dC t_ue=^[[m
t_cm=^[[%i%p1%d;%p2%dH
t_cs=^[[%i%p1%d;%p2%dr
t_vb=^[[?5h$<100/>^[[?5l
t_ve=^[[?12l^[[?25h
t_WP=^[[3;%p1%d;%p2%dt
t_WS=^[[8;%p1%d;%p2%dt
--- Terminal keys ---
t_#2 ^[[1;2H t_K8^[O*o t_k;
^[[21;*~ ^[O*P
t_#4 ^[[1;2D t_K9 ^[O*j t_kB
^[[Z ^[O*Q
t_%1 ^[[28;*~ t_KA ^[O*M t_kD
^[[3~ ^[O*R
t_%i^[[1;2C t_KB ^[O*n t_kI
^[[2;*~ ^[O*S
t_&8 ^[[26;*~ t_k1 ^[[11;*~ t_kN
^[[6;*~ ^[O*F
t_*7 ^[[1;2F t_k2 ^[[12;*~ t_kP
^[[5;*~ ^[[8;*~
[EMAIL PROTECTED]^[[1;*F t_k3 ^[[13;*~ t_kb
^?
Re: weird up/down arrows behaviour on braces 7.1.87
On 8/28/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
>
> On 8/27/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> >
> >
> > Yakov Lerner wrote:
> >
> > > I get weird up/down behaviour when cursor traverses the braces. vim
> > 7.1.87,
> > > no custom plugins. This is apparently somehow related to matchparen.
> > >
> > > The testfile is x.c below.
> > > Here is what happens if I press down starting from the beginning of
> > file,
> > > position 1:
> > >
> > > 1. Down. instead of going to line 2, cursor shows at line 4 !!!
> > > 2. Down. cursor is at line 3
> > > 3. Down. cursor is at line 2 !!!
> > > 4. Down. cursor is at line 5
> > > 6. Up. Cursor is at line 2!!!
> > > 7. Up. Cursor is at line 3.
> > > 8. Up. Cursor is '}' line 4!!!
> > > 9. Up. Cursor is at line 1.
> > >
> > > --- x.c
> > > int foo()
> > > {
> > > return 0;
> > > }
> > > /* */
> >
> > I don't have a vt220 so I can't try it out. I wonder if you are
> > actually using a vt220 anyway, these are quite rare these days...
>
>
> I observe same results when setting XTERM to xterm-mono.
> The terminal was actually xterm.
> You can change vt220 to xterm-mono and see the same results.
>
> > How can you tell where the cursor is and it's not the highlighting that
> > makes you think the cursor is somewhere else?
>
> I can do :echo line('.') col('.'). This shows me that cursor is not
> where vim shows the white block on the screen.
>
> > Try using a different color scheme.
>
> I normally work in color xterm. There is no problem there.
> I do not normally work in B/W term. What we were doing, we were checking
> how some console software (not vim) behaves under the black-and-white TERM.
>
>
> As a side effect, I noticed that matchparen behaves weirdly on B/W term.
> In the mentioned B/W setup, the colorscheme was default because .vimrc is
> empty.
>
> Anyway, if you want to see the matchparen problem on BW term (with default
> colorscheme), you can set TERM to xterm-mono and see for yousrself.
>
Maybe the solution is that patchparen would turn itself off when the
terminal is black and white.
Even if matchparen gets fixed and shows exactly same blocks at two places --
at the cursor point and and at the matching parent point -- this looks
confusing.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: weird up/down arrows behaviour on braces 7.1.87
On 8/27/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
>
> Yakov Lerner wrote:
>
> > I get weird up/down behaviour when cursor traverses the braces. vim
> 7.1.87,
> > no custom plugins. This is apparently somehow related to matchparen.
> >
> > The testfile is x.c below.
> > Here is what happens if I press down starting from the beginning of
> file,
> > position 1:
> >
> > 1. Down. instead of going to line 2, cursor shows at line 4 !!!
> > 2. Down. cursor is at line 3
> > 3. Down. cursor is at line 2 !!!
> > 4. Down. cursor is at line 5
> > 6. Up. Cursor is at line 2!!!
> > 7. Up. Cursor is at line 3.
> > 8. Up. Cursor is '}' line 4!!!
> > 9. Up. Cursor is at line 1.
> >
> > --- x.c
> > int foo()
> > {
> > return 0;
> > }
> > /* */
>
> I don't have a vt220 so I can't try it out. I wonder if you are
> actually using a vt220 anyway, these are quite rare these days...
I observe same results when setting XTERM to xterm-mono.
The terminal was actually xterm.
You can change vt220 to xterm-mono and see the same results.
> How can you tell where the cursor is and it's not the highlighting that
> makes you think the cursor is somewhere else?
I can do :echo line('.') col('.'). This shows me that cursor is not
where vim shows the white block on the screen.
> Try using a different color scheme.
I normally work in color xterm. There is no problem there.
I do not normally work in B/W term. What we were doing, we were checking how
some console software (not vim) behaves under the black-and-white TERM.
As a side effect, I noticed that matchparen behaves weirdly on B/W term. In
the mentioned B/W setup, the colorscheme was default because .vimrc is
empty.
Anyway, if you want to see the matchparen problem on BW term (with default
colorscheme), you can set TERM to xterm-mono and see for yousrself.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: weird up/down arrows behaviour on braces 7.1.87
On 8/27/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
>
> On 8/27/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> >
> > I get weird up/down behaviour when cursor traverses the braces. vim
> > 7.1.87,
> > no custom plugins. This is apparently somehow related to matchparen.
> >
> > The testfile is x.c below.
> > Here is what happens if I press down starting from the beginning of
> > file, position 1:
> >
> > 1. Down. instead of going to line 2, cursor shows at line 4 !!!
> > 2. Down. cursor is at line 3
> > 3. Down. cursor is at line 2 !!!
> > 4. Down. cursor is at line 5
> > 6. Up. Cursor is at line 2!!!
> > 7. Up. Cursor is at line 3.
> > 8. Up. Cursor is '}' line 4!!!
> > 9. Up. Cursor is at line 1.
> >
> > --- x.c
> > int foo()
> > {
> > return 0;
> > }
> > /* */
> >
> >
> > Yakov
>
>
>
> The problem is related to TERM set to vt200 and it being black-and-white,
> and syntax off.
> When TERM is xterm and color, everything is fine, problem does not appear.
I played with .vimrc to find out what is needed to reproduce it.
The combination of conditions is:
- .vimrc is present but empty
- TERM set to vt220 ( black-and-white )
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: weird up/down arrows behaviour on braces 7.1.87
On 8/27/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
>
> I get weird up/down behaviour when cursor traverses the braces. vim 7.1.87
> ,
> no custom plugins. This is apparently somehow related to matchparen.
>
> The testfile is x.c below.
> Here is what happens if I press down starting from the beginning of file,
> position 1:
>
> 1. Down. instead of going to line 2, cursor shows at line 4 !!!
> 2. Down. cursor is at line 3
> 3. Down. cursor is at line 2 !!!
> 4. Down. cursor is at line 5
> 6. Up. Cursor is at line 2!!!
> 7. Up. Cursor is at line 3.
> 8. Up. Cursor is '}' line 4!!!
> 9. Up. Cursor is at line 1.
>
> --- x.c
> int foo()
> {
> return 0;
> }
> /* */
>
>
> Yakov
The problem is related to TERM set to vt200 and it being black-and-white,
and syntax off.
When TERM is xterm and color, everything is fine, problem does not appear.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
weird up/down arrows behaviour on braces 7.1.87
I get weird up/down behaviour when cursor traverses the braces. vim 7.1.87,
no custom plugins. This is apparently somehow related to matchparen.
The testfile is x.c below.
Here is what happens if I press down starting from the beginning of file,
position 1:
1. Down. instead of going to line 2, cursor shows at line 4 !!!
2. Down. cursor is at line 3
3. Down. cursor is at line 2 !!!
4. Down. cursor is at line 5
6. Up. Cursor is at line 2!!!
7. Up. Cursor is at line 3.
8. Up. Cursor is '}' line 4!!!
9. Up. Cursor is at line 1.
--- x.c
int foo()
{
return 0;
}
/* */
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
undo after :retab
Undo after retab modifies 'tabstop' in a way that doesn't look consistent or correct. Test case: - vim -u NONE -U NONE iabc :set ts=4 :retab 8 u -- After the last u, tabstop changes to 8. But we expect the screen to return to the state before :retab where tabstop was 4, not 8. THanks Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: he Vim maillists have moved
On 7/20/07, Gautam Iyer <[EMAIL PROTECTED]> wrote: > > > On Fri, Jul 20, 2007 at 04:43:00PM -, BartlebyScrivener wrote: > > > > To subscribe, send a message to the [EMAIL PROTECTED] list. > > > > If you just want to subscribe without getting emails > > and just browse the site with the ability to post, you can join up at: > > > > http://groups.google.com/group/vim_use?hl=en > > Erm. Sorry to sound paranoid, but doesn't this make life a lot easier > for Spammers? I guess we've got no spam yet... (fingers crossed) gmail has exceptional spam filtering. by the way, do you possibly want to buy v1agra ? --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
