Re: Defining new visual-mode motions?
Hi,
On 6/2/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
Joseph Barker schrieb:
>> The following is possible:
>>
>> function VisualMove()
>>normal! gv
>>call search('\u')
>>" visual mode still on
>> endfunction
>>
>> vmap ,w :call VisualMove()
>
> That works perfectly, although I have no idea why. Can you explain? I would
> think that calling `normal! gv` would have no effect, since that should
> reselect the current selection. But for some reason it allows you to call
> search() while staying in visual mode, which makes no sense to me. Perhaps
> I'm not looking at the right place in the documentation.
Entering Cmdline mode with
:call ...
turns Visual mode off, therefore
normal! gv
reselects the visual area.
Within a function (or script or Ex-mode), the visual area is not turned off
between ex commands, because there is no actual mode switching
... IMHO.
I don't know if this is mentioned in the help.
According to ":help mode-switching", it is not possible to enter visual mode
from Ex or command-line mode. Either the table under ":help i_esc" needs
to be updated or this needs to be fixed.
According to that table, you can enter visual mode only from either normal or
select modes.
- Yegappan
Re: Defining new visual-mode motions?
Hi,
On 5/31/07, Joseph Barker <[EMAIL PROTECTED]> wrote:
Hello, all.
I was recently helping someone out with a vim script (camelcasemotion.vim)
which adds additional motion commands (they treat camel-cased words
(WordsLikeThis) as separate words, rather than as a single word). This is
easy enough to do in normal and operator-pending mode. It seems to be very
complicated to do this in visual mode, though -- calling a function (or
anything that lets you move the cursor) seems to force you to leave visual
mode (i.e., doing `vmap ,w :call MoveCursor()` will move the cursor to
the right place, but you're no longer in visual mode).
My approach to this was to call the movement function, set a mark, select
the previous visual block (with gv) and then jump to the mark that was
previously set. The mapping that I created to deal with this is the
following:
vmap ,w @="\33:\25call
CamelCaseMotion('w',1,'v')"m`gvg``
This seems somewhat inelegant, and also clobbers a mark to be able to
accomplish its magic. Is there an easier way to accomplish the same thing?
It seems like there should be, but I was unable to figure one out.
Did you try specifying the attribute to the map command?
Something along the lines of
function! MoveToCursor()
return "/\\u\\|\\<\"
endfunction
vnoremap ,w MoveCursor()
The MoveCursor() function should return a sequence of keys that will
position the cursor at the desired location.
- Yegappan
Re: [PATCH] new ex command :lscscope
Hi, On 4/28/07, Navdeep Parhar <[EMAIL PROTECTED]> wrote: > > > > > Hello, > > > > > > > > Currently :cscope has a variant :lcscope that allows the use of > > > > the location list instead of the quickfix list. However, :scscope > > > > has no equivalent that uses the location list. Please note that > > > > :scs splits only if cscope returns some results, so :scs is not > > > > the same as ":split cs". Due to this reason ":split lcscope" can > > > > not be used to get the same behaviour as the proposed :lscscope. > > > > > > > > I'm confused. I tried exercising this patch and I'm not getting the > > results I expect, but I don't know if it's the patch, the behavior > > of location lists, or me. > > > > This problem is caused by the patch for the ":lscs" command. > > When the ":lcs" command is executed, a new location list is > created for the current window and then the cursor is moved to the > first entry in the location list. > > The ":lscs" command splits the window after the location list is > created. This results in the problem. > > In your case, when you executed the ":lscs" command in the > first window, the new location list is added to the first window > and then the window is split. > > When you invoked the second "lscs" command, a new location > list is added to the second window and then the window is split. > This is correct. The problem both times is that the split takes place after the error list has been constructed. I have reworked the patch a bit. Now it splits the window before constructing the error list. I'd like to point out that with this modification the behaviour if qf_init fails will be different from what it is today. The split will have taken place by the time qf_init gets called. This may not be desirable. This will break backwards compatibility. When the ":lscscope" command fails, the current window should not be split and also the location list for the current window should not be modified. - Yegappan Other than this everything should mostly work as advertised. New patch is attached to this email. Regards, Navdeep > Also, when jumping to the match from the location list, the > location list for the window before the split is used. This results > in the second problem you saw after closing the windows. > > When the location list support was added to Vim7, as the ":lscscope" > command was not supported, this condition was not taken into > account. > > - Yegappan >
Re: [PATCH] new ex command :lscscope
Hi Gary, On 4/27/07, Gary Johnson <[EMAIL PROTECTED]> wrote: On 2007-04-27, Gary Johnson <[EMAIL PROTECTED]> wrote: > On 2007-04-26, Navdeep Parhar <[EMAIL PROTECTED]> wrote: > > Hello, > > > > Currently :cscope has a variant :lcscope that allows the use of > > the location list instead of the quickfix list. However, :scscope > > has no equivalent that uses the location list. Please note that > > :scs splits only if cscope returns some results, so :scs is not > > the same as ":split cs". Due to this reason ":split lcscope" can > > not be used to get the same behaviour as the proposed :lscscope. > > I'm confused. I tried exercising this patch and I'm not getting the results I expect, but I don't know if it's the patch, the behavior of location lists, or me. This problem is caused by the patch for the ":lscs" command. When the ":lcs" command is executed, a new location list is created for the current window and then the cursor is moved to the first entry in the location list. The ":lscs" command splits the window after the location list is created. This results in the problem. In your case, when you executed the ":lscs" command in the first window, the new location list is added to the first window and then the window is split. When you invoked the second "lscs" command, a new location list is added to the second window and then the window is split. Also, when jumping to the match from the location list, the location list for the window before the split is used. This results in the second problem you saw after closing the windows. When the location list support was added to Vim7, as the ":lscscope" command was not supported, this condition was not taken into account. - Yegappan Here's an example. I cd'd to the src directory of my vim installation which is currently at patch level 208. Then I built a cscope database. $ cscope -b Then I opened one of the source files, $ view +3725 buffer.c added the cscope database, :cs add cscope.out moved the cursor to the get_fileformat symbol and opened a new window containing a location list of the places where that function is called. :lscscope find c ^R^W (1 of 10): <> else if (num == CAR && get_fileformat(wp->w_buffer) == EOL_MAC) That happens to be the same line in buffer.c that the cursor had been on. Then I went to the third location in the list, :3ll (3 of 10): <> fileformat = get_fileformat(curbuf); which is line 925 of fileio.c. I moved the cursor to the top of this function, readfile (line 209), and opened a new window containing a location list of the places where this function is called. :lscscope find c ^R^W (1 of 12): <> retval = readfile(curbuf->b_ffname, curbuf->b_fname, This window contains buffer.c, which is also being viewed in the bottom window. The location list is new. We can check the location list stack state as follows: :lold error list 1 of 2; 10 errors :lnew error list 2 of 2; 12 errors Then I went to the 5th location in this list. :5ll (5 of 12): <> if (readfile(otmp, NULL, line2, (linenr_T)0, (linenr_T)MAXLNUM, This is line 1209 of ex_cmds.c. At this point, I wanted to stop following this location list, close this window and return to the place where I executed the :lscscope command, then pick up where I was in the first location list. :q This closed the top window and made the second window "active" with the cursor on the first line of the readline() function. So far so good. When I left this window, I had been at location 3 of 10 in the first location list. Therefore, I expected that executing :ll would put the cursor back on line 925 of this file, fileio.c. :ll (1 of 12): <> retval = readfile(curbuf->b_ffname, curbuf->b_fname, Not only did the :ll command use the "wrong" (i.e., unexpected) location list, but it jumped to the first location in that list instead of the last location used, which was number 5. Checking the location list stack state, :lold error list 1 of 2; 10 errors :lnew error list 2 of 2; 12 errors shows that there are still two location lists. I would have expected that closing that top window would have deleted the newest list. So is this a bug, or am I just not getting it?
Re: problems compiling on solaris
Hi all, On 3/7/07, Paul Stuart <[EMAIL PROTECTED]> wrote: Hi there, I'm having some problems compiling vim 7 on solaris 8, and I'd really appreciate it if someone could point me in the right direction. Here is the error I'm getting : make[1]: Entering directory `/export/home/pstuart/R42014/src/vim70/src' gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -I/usr/dt/include -g -O2 -I/usr/openwin/include-o objects/buffer.o buffer.c In file included from buffer.c:28: vim.h:41: parse error before `:' In file included from /usr/include/stdio.h:22, from os_unix.h:21, from vim.h:233, from buffer.c:28: /usr/include/iso/stdio_iso.h:186: parse error before `__va_list' /usr/include/iso/stdio_iso.h:187: parse error before `__va_list' /usr/include/iso/stdio_iso.h:188: parse error before `__va_list' In file included from os_unix.h:21, from vim.h:233, from buffer.c:28: /usr/include/stdio.h:227: parse error before `__va_list' In file included from /usr/include/wchar.h:11, from /usr/include/wctype.h:20, from vim.h:435, from buffer.c:28: /usr/include/iso/wchar_iso.h:191: parse error before `__va_list' /usr/include/iso/wchar_iso.h:192: parse error before `__va_list' /usr/include/iso/wchar_iso.h:193: parse error before `__va_list' I am also seeing the above build error with the latest Vim7 on Solaris 8. I am able to build successfully on Linux. It looks like some recent changes to the configure script broke this. I was able to compile Vim 7.0.174 successfully on Solaris 8. - Yegappan
Re: [!] missing from :cb and related commands?
Hi, On 3/6/07, Gary Johnson <[EMAIL PROTECTED]> wrote: On 2007-03-07, "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote: > Gary Johnson wrote: > > If I open a new window, read into it the results of a grep command, > > e.g., > > > > :r !grep -nH somepattern somefileset > > > > and then try to use that buffer as a quickfix list or location list > > with either the :cb or :lb commands, respectively, I get > > > > E37: No write since last change (add ! to override) > > > > If I then try to add ! to the :cb or :lb commands, I get > > > > E477: No ! allowed > > > > It seems to me that the :cb and :lb commands are missing the ability > > to handle a !. > > > > The most recent version of vim I had to verify this with was > > 7.0.178. > > > > Regards, > > Gary > > > > If what you want to do with the output of grep is use it as a quickfix > error list, then use ":grep" or ":lgrep" instead of ":r !grep". Or you can > also use ":vimgrep" or ":lvimgrep" for internal grep (with Vim-style > regexps). > > See ":help grep". It seems pretty clear that there has been an oversight in the implementation of the :cb and :lb commands, even pointed to by the text of E37. If there is some reason that the :cb and :lb commands should not be extended to accept !, then the current text of E37 is inappropriate for that error condition. Try using the attached patch which enables the "!" modifier for the ":cbuffer" and ":lbuffer" commands. - Yegappan Index: src/ex_cmds.h === RCS file: /cvsroot/vim/vim7/src/ex_cmds.h,v retrieving revision 1.56 diff -c -p -r1.56 ex_cmds.h *** src/ex_cmds.h 22 Jun 2006 19:15:58 - 1.56 --- src/ex_cmds.h 7 Mar 2007 02:21:53 - *** EX(CMD_call, "call", ex_call, *** 198,204 EX(CMD_catch, "catch", ex_catch, EXTRA|SBOXOK|CMDWIN), EX(CMD_cbuffer, "cbuffer", ex_cbuffer, ! RANGE|NOTADR|WORD1|TRLBAR), EX(CMD_cc, "cc", ex_cc, RANGE|NOTADR|COUNT|TRLBAR|BANG), EX(CMD_cclose, "cclose", ex_cclose, --- 198,204 EX(CMD_catch, "catch", ex_catch, EXTRA|SBOXOK|CMDWIN), EX(CMD_cbuffer, "cbuffer", ex_cbuffer, ! BANG|RANGE|NOTADR|WORD1|TRLBAR), EX(CMD_cc, "cc", ex_cc, RANGE|NOTADR|COUNT|TRLBAR|BANG), EX(CMD_cclose, "cclose", ex_cclose, *** EX(CMD_laddfile, "laddfile", ex_cfile, *** 498,504 EX(CMD_later, "later", ex_later, TRLBAR|EXTRA|NOSPC|CMDWIN), EX(CMD_lbuffer, "lbuffer", ex_cbuffer, ! RANGE|NOTADR|WORD1|TRLBAR), EX(CMD_lcd, "lcd", ex_cd, BANG|FILE1|TRLBAR|CMDWIN), EX(CMD_lchdir, "lchdir", ex_cd, --- 498,504 EX(CMD_later, "later", ex_later, TRLBAR|EXTRA|NOSPC|CMDWIN), EX(CMD_lbuffer, "lbuffer", ex_cbuffer, ! BANG|RANGE|NOTADR|WORD1|TRLBAR), EX(CMD_lcd, "lcd", ex_cd, BANG|FILE1|TRLBAR|CMDWIN), EX(CMD_lchdir, "lchdir", ex_cd,
Re: [!] missing from :cb and related commands?
Hi Gary, On 3/6/07, Gary Johnson <[EMAIL PROTECTED]> wrote: If I open a new window, read into it the results of a grep command, e.g., :r !grep -nH somepattern somefileset and then try to use that buffer as a quickfix list or location list with either the :cb or :lb commands, respectively, I get E37: No write since last change (add ! to override) If I then try to add ! to the :cb or :lb commands, I get E477: No ! allowed It seems to me that the :cb and :lb commands are missing the ability to handle a !. The most recent version of vim I had to verify this with was 7.0.178. You can try using the ":cgetbuffer" and ":lgetbuffer" commands. These commands will not automatically jump to the first error. - Yegappan
Re: Jump to tag in a file opened in another session
Hi, On 3/6/07, Corinna Vinschen <[EMAIL PROTECTED]> wrote: Hi, I've searched for this for some time now but it's either not available or I have to hone my search skills a lot. Most of the time I have multiple xterms opened, running vim sessions within the same project. The files are tagged and I'm using :ta and :tj a lot. It happens often that I'm about to jump to a tagged function in a file which I have opened in another xterm. What happens is that the swap file is found and the "Swap file [...] already exists" message is printed, giving the usual choice which has to be confirmed. The more often this happens, the more annoying it is. What I usually want is to open the file readonly, because I just want to have a look into that function. The actual editing of this file is done in the other vim window. I can't find a way to accomplish this. I know there's the shortmess=A option, but it avoids the attention message in a dangerous way: It doesn't print *any* warning and it allows to edit the file. If I really edit the file at this point, because I miss the fact that this is the same file as in the other xterm session, the first warning appears in the second session only when trying to write back the changes made there. So, the bottom line is, I'm looking for is a way to open a file automatically in r/o mode if I'm going to jump to a tag in that file and the file is opened in another session. Is that possible already? If not, would it make sense to add a setting which enables this behaviour? You can use the following autocmd (only in Vim7) to open a file in read-only mode (if the file is already opened in another Vim instance) while jumping to a tag in that file. In all other cases, you will be prompted if the swap file already exists for that file. autocmd SwapExists * if v:swapcommand =~ '^:ta\%[g] ' | let v:swapchoice='o' | endif - Yegappan
Re: Quickfix window not working anymore
Hi, On 2/19/07, Bill McCarthy <[EMAIL PROTECTED]> wrote: On Mon 19-Feb-07 7:21am -0600, A.J.Mechelynck wrote: > Works for me. For me too. BTW, Tony, I've never used :copen before - I use :cw . There look the same but the documentation doesn't seem to indicate that they are the same. What's the difference between :copen and :cwindow ? The ":cwindow" command opens the quickfix window only if there are valid errors in the quickfix list. If the quickfix window is already opened and there are no valid errors in the quickfix list, then the window is closed. The ":copen" command always opens the quickfix window even if there are no valid errors in the quickfix list or the list is empty. - Yegappan
Re: Apparent Vim 7.0 bug (re comments)
Hello, On 1/10/07, Robert Lee <[EMAIL PROTECTED]> wrote: I discovered that the problem was caused by the lines: au BufWinLeave * mkview au BufWinEnter * silent loadview Apparently the view file that is created contains a copy of the vimrc settings. This prevents changes to the vimrc to be honored once a file has been opened. The temporary fix was to clean up the "vimfiles/view" directory. I think the right fix is to move these files to the very top of the vimrc file, but I am skeptical that this will help at all. I wish mkview only saved folds/marks/cursor position information instead of a full vimrc copy. You can change the 'viewoptions' option to control the type of information that gets saved in the view file. :help 'viewoptions' :help 'sessionoptions' - Yegappan
Re: problem with taglist plugin
Hi, On 1/3/07, flyfish <[EMAIL PROTECTED]> wrote: hi, i have used vim for some days and i would like to use the taglist plugin which is very hot in internet, my os is ubuntu 6 and the version of vim is 7, i downloaded the taglist package and unziped it, then i put the two files taglist.vim and the doc file in corresponding places separately, then i open vim both in console and gvim, and use :Tlist command, but any of them failed and gived me the following message: You should use the taglist mailing list for the taglist plugin related questions. http://groups.yahoo.com/group/taglist/ The vim-dev mailing list is used for discussing Vim development. Failed to generate tags for /home/myusername/.vim/plugin/taglist.vim ctags: unrecognized option `--format=2'[EMAIL PROTECTED] `ctags --help' for a complete list of options.^@ The taglist plugin requires exuberant ctags. You cannot use GNU ctags with the taglist plugin. Refer to the following FAQ page: http://vim-taglist.sourceforge.net/faq.html You can download exuberant ctags from: http://ctags.sourceforge.net - Yegappan i have searched from google and i also found that i had the file ctags in .vim directory, i do not know what to do next, could you give me a favor,
Re: VIM window restores incorrectly
Hi Liu, On 11/23/06, Liu Yubao <[EMAIL PROTECTED]> wrote: Bram Moolenaar wrote: > Yegappan Lakshmanan wrote: > >> On 11/22/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: >>> It does happen for me: >>> >>> "gvim somefile" >>> maximize gvim window >>> minimize gvim window >>> "gvim --remote-tab otherfile" >>> >>> Now I only see the tab label for "otherfile". I can click on the gap >>> before it to go to "somefile", and then only that label is shown. >>> >> Which version of MS-Windows (Win98/WinME/Win2K/WinXP/Vista) >> are you using? I am not able to reproduce this problem using the >> above steps on WinXP and Win2K. >> >> I am using the following version of Vim: >> >> VIM - Vi IMproved 7.0 (2006 May 7, compiled May 7 2006 16:21:39) >> MS-Windows 32 bit GUI version >> Compiled by [EMAIL PROTECTED] >> Big version with GUI. Features included (+) or not (-): >> >> Anybody else seeing this problem on MS-Windows? > > It apparently only happens when 'encoding' is set to "utf-8". Can you > reproduce it then? > I think I got it. In gui_w48.c:gui_mch_update_tabline(), SendMessage(...TCM_INSERTITEMW...) is called at line 2408 but TabCtrl_SetItem(...) at line 2416. I'm a little confused why it sends an INSERT message but not a SET one too. Index: gui_w48.c === --- gui_w48.c (revision 184) +++ gui_w48.c (working copy) @@ -2405,7 +2405,7 @@ tiw.mask = TCIF_TEXT; tiw.iImage = -1; tiw.pszText = wstr; - SendMessage(s_tabhwnd, TCM_INSERTITEMW, (WPARAM)nr, + SendMessage(s_tabhwnd, TCM_SETITEMW, (WPARAM)nr, (LPARAM)&tiw); vim_free(wstr); } This looks like the correct fix. The TCM_SETITEMW message should be used instead of the TCM_INSERTITEMW message to modify the attributes of an existing item in the tab control. - Yegappan
Re: VIM window restores incorrectly
Hi Bram, On 11/22/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > > VIM 7.0, MS-Windows 32 bit GUI version with OLE support > > > Included patches: 1-162 > > > > > > run "gvim a.txt"; > > > maximize the VIM window, then minimize it to task bar; > > > run "gvim --remote-tab b.txt"; > > > VIM window is brought to foreground, then double click > > > the title bar of VIM window to restore its size, it's > > > restored incorrectly with maximum dimension. > > > > There appears to be something wrong with the GUI tab pages line. I only > > see the label for the current tab, not the others. That looks like a > > bug. > > > > I am not able to reproduce this problem with the tab page line. When the > GVIM window is restored, the tab page line is properly updated with > the tab names. > > I do see the problem reported by OP with the size of the restored Vim > window. It does happen for me: "gvim somefile" maximize gvim window minimize gvim window "gvim --remote-tab otherfile" Now I only see the tab label for "otherfile". I can click on the gap before it to go to "somefile", and then only that label is shown. Which version of MS-Windows (Win98/WinME/Win2K/WinXP/Vista) are you using? I am not able to reproduce this problem using the above steps on WinXP and Win2K. I am using the following version of Vim: VIM - Vi IMproved 7.0 (2006 May 7, compiled May 7 2006 16:21:39) MS-Windows 32 bit GUI version Compiled by [EMAIL PROTECTED] Big version with GUI. Features included (+) or not (-): Anybody else seeing this problem on MS-Windows? - Yegappan
Re: VIM window restores incorrectly
Hi Bram, On 11/22/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > > > > > > VIM 7.0, MS-Windows 32 bit GUI version with OLE support > > > > > Included patches: 1-162 > > > > > > > > > > run "gvim a.txt"; > > > > > maximize the VIM window, then minimize it to task bar; > > > > > run "gvim --remote-tab b.txt"; > > > > > VIM window is brought to foreground, then double click > > > > > the title bar of VIM window to restore its size, it's > > > > > restored incorrectly with maximum dimension. > > > > > > > > There appears to be something wrong with the GUI tab pages line. I only > > > > see the label for the current tab, not the others. That looks like a > > > > bug. > > > > > > > > > > I am not able to reproduce this problem with the tab page line. When the > > > GVIM window is restored, the tab page line is properly updated with > > > the tab names. > > > > > > I do see the problem reported by OP with the size of the restored Vim > > > window. > > > > It does happen for me: > > > > "gvim somefile" > > maximize gvim window > > minimize gvim window > > "gvim --remote-tab otherfile" > > > > Now I only see the tab label for "otherfile". I can click on the gap > > before it to go to "somefile", and then only that label is shown. > > > > Which version of MS-Windows (Win98/WinME/Win2K/WinXP/Vista) > are you using? I am not able to reproduce this problem using the > above steps on WinXP and Win2K. > > I am using the following version of Vim: > > VIM - Vi IMproved 7.0 (2006 May 7, compiled May 7 2006 16:21:39) > MS-Windows 32 bit GUI version > Compiled by [EMAIL PROTECTED] > Big version with GUI. Features included (+) or not (-): > > Anybody else seeing this problem on MS-Windows? It apparently only happens when 'encoding' is set to "utf-8". Can you reproduce it then? Yes. When 'encoding' is set to 'utf-8', I am able to reproduce the problem now. - Yegappan
Calling a non-existing dictionary function doesn't result in an error
Hi all,
When a non-existing dictionary function is invoked using the ":call"
command, there is no error. But when it is used in an expression,
an error message is displayed. Is this the expected behavior?
let a = {}
call a.xyz()
The ":call" command silently returns without any errors. But
the following commands result in error:
:let x = a.xyz()
E716: Key not present in Dictionary: xyz()
E15: Invalid expression: a.xyz()
:echo a.xyz()
E716: Key not present in Dictionary: xyz()
E15: Invalid expression: a.xyz()
- Yegappan
Re: missing setbufline()?
Hi Bram,
On 10/23/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> You can try the attached patch against the latest Vim7 sources.
> The syntax of the new function is:
>
> setbufline({expr}, {lnum}, {line})
>
> where, {expr} specifies the loaded buffer name/number, {lnum} specifies
> a valid line number in that buffer and {line} is either a single line
> or a List of lines.
>
> Note. The patch also includes the new gettabvar() and settabvar()
> functions.
It looks like after this patch, if you change lines in another buffer
some marks in the current window will be moved. Especially the
jumplist, perhaps setting cmdmod.lockmarks would help.
I tried to reproduce this problem using the new setbufline()
function. The jumplist for the current buffer is not affected
while changing the contents of another loaded buffer using
the setbufline() function. Is there any specific sequence that
needs to be followed to see this problem?
The '< and '> marks are probably moved. Manual folds might be moved.
I couldn't reproduce the above problems also. The manual folds
and the visual area marks for the current buffer are not changed
by setbufline().
There may also be redrawing problems.
I didn't see any redraw problems. Are you referring to redraw
problems in the current buffer or in the buffer that is being
changed using setbufline()?
- Yegappan
This needs a test in src/testdir. And documentation, of course.
I'm very careful with including something like this. Currently there is
no code that changes another buffer. It could break more than you
expect.
Re: missing setbufline()?
Hi Bram,
On 10/23/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
Yegappan Lakshmanan wrote:
> On 10/22/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
> > > On 10/22/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I see functions for creating new unlisted buffers (bufnr() with {create}
> > > > option), and for reading the lines from the buffer using getbufline(),
> > > > all without having to change the current buffer, but I don't see a
> > > > setbufline() so there is no way to set the lines without having to
> > > > switch to it. Is there a reason to leave this circle incomplete?
> > > >
> > >
> > > Yes. I had a patch for the setbufline() function last year. There were
> > > several problems with it. So it was not included in Vim7 and only
> > > the getbufline() function was included.
> > >
> > > The setbufline() function worked only for loaded buffers. The undo
> > > history was not updated correctly.
> > >
> > > But I agree that it will be good to have the setbufline() function.
> > >
> > > - Yegappan
> >
> > Nice, so it will be included at some point after resolving these issues.
> >
>
> You can try the attached patch against the latest Vim7 sources.
> The syntax of the new function is:
>
> setbufline({expr}, {lnum}, {line})
>
> where, {expr} specifies the loaded buffer name/number, {lnum} specifies
> a valid line number in that buffer and {line} is either a single line
> or a List of lines.
>
> Note. The patch also includes the new gettabvar() and settabvar()
> functions.
It looks like after this patch, if you change lines in another buffer
some marks in the current window will be moved. Especially the
jumplist, perhaps setting cmdmod.lockmarks would help. The '< and '>
marks are probably moved. Manual folds might be moved. There may also
be redrawing problems.
The setbufline() implementation is similar to the one used in
if_perl.xs (Set) , if_python.c (SetBufferLine), if_ruby.c (set_buffer_line)
if_mzsch.c (set_buffer_line_list) and if_tcl.c (BUF_SET) interface
files. These problems should also be seen with those
interfaces also.
This needs a test in src/testdir. And documentation, of course.
Will add the doc updates.
I'm very careful with including something like this. Currently there is
no code that changes another buffer. It could break more than you
expect.
You can't change the buffer contents with the Perl/Python/Tcl/Ruby
interfaces?
- Yegappan
Re: Autocommand-Event for Clipboard-Changed
Hi Charles,
On 10/3/06, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:
Bram Moolenaar wrote:
>Suresh Govindachar wrote:
>
>
>>Is it possible to add an autocommand-event for "Clipboard Changed"?
>>
>>
>
>Not really. This is not something that happens inside Vim. Polling for
>changes in the system is not really something I would like to add to Vim.
>
>
Bram -- would you be willing to give out a bit of code that will send a
remote message to vim?
Some function, perhaps SendCmd2Vim("string"). That way it'll be simple
for folks to make their
own external programs to send a command to vim via the already available
remote vim stuff.
Presumably the code snippet wouldn't be a Part of Vim itself; maybe
something for vim.sf.net?
Just an idea...
Chip Campbell
Are you referring to a sample code similar to the xcmdsrv_client.c file under
the $VIM/tools directory? This sample code shows how to send commands
to a remote Vim from a C program in Unix systems running X-Windows.
A similar sample code for MS-Windows is needed.
- Yegappan
Re: no winclose event
Hi Charles, On 9/25/06, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: Hello! Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave would almost do, but if two or more windows are open on the same buffer, then no event. WinLeave fires whenever one changes windows, which isn't what I want, either. Unless I'm misunderstanding the help for these two events. Yes. It would be good to have this autocmd. I needed this autocmd for the taglist plugin. - Yegappan
BufWinEnter autocmd is not invoked when splitting a window
Hi all,
The BufWinEnter autocmd is not invoked when splitting a window.
According to the help for the BufWinEnter autocmd, this autocmd
is invoked when a buffer is displayed in a window.
For example, use the following autocmd:
au BufWinEnter * echomsg "Entering buffer " . expand("")
With the above autocmd, if you execute the following commands:
:e
:split
The BufWinEnter autocmd is not invoked for the new window.
But if you use the following commands, then the BufWinEnter autocmd
is invoked:
:e
:split
- Yegappan
Re: Proposal: New command/feature for quickfix
Hi, On 6/28/06, Yegappan Lakshmanan <[EMAIL PROTECTED]> wrote: Hi, On 6/28/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote: > On 6/28/06, Jochen Baier <[EMAIL PROTECTED]> wrote: > > On Wed, Jun 28, 2006 at 11:21:00PM +0200, Mikolaj Machowski wrote: > > > Dnia ?roda, 28 czerwca 2006 22:07, Jochen Baier napisa?: > > > > i think a command like "cbefore" or "croot" could be > > > > usefull. using this command after a quickfix trip (vimgrep, > > > > > > Doesn't fulfill your request? > > > > > > m. > > > > no > > Good answer ;-). Short and to the point. > > However, further explanation may be necessary. > > just gets you back to the previous position in the jump list (or > [count]), but this would be a complete reset to the point where you > were before beginning to use the change list commands. > You can try using the attached qf.vim plugin. Save the file to the $HOME/.vim/plugin or $HOME/vimfiles/plugin directory. This plugin saves the current location in the file before executing a quickfix command like grep, vimgrep, make, etc. The locations are maintained in a stack. You can display the stack using the ":QfShow" command. You can pop an entry from the stack and jump to that file location using the ":QfPop" command. This command also accepts a count and allows you to pop multiple entries. I have updated the quickfix stack plugin with the new Vim7 data types and fixed a few problems. The updated version is attached. If there are no problems, I will upload it to the Vim online website. - Yegappan qf.vim Description: Binary data
Re: Proposal: New command/feature for quickfix
Hi, On 6/28/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote: On 6/28/06, Jochen Baier <[EMAIL PROTECTED]> wrote: > On Wed, Jun 28, 2006 at 11:21:00PM +0200, Mikolaj Machowski wrote: > > Dnia ?roda, 28 czerwca 2006 22:07, Jochen Baier napisa?: > > > i think a command like "cbefore" or "croot" could be > > > usefull. using this command after a quickfix trip (vimgrep, > > > > Doesn't fulfill your request? > > > > m. > > no Good answer ;-). Short and to the point. However, further explanation may be necessary. just gets you back to the previous position in the jump list (or [count]), but this would be a complete reset to the point where you were before beginning to use the change list commands. You can try using the attached qf.vim plugin. Save the file to the $HOME/.vim/plugin or $HOME/vimfiles/plugin directory. This plugin saves the current location in the file before executing a quickfix command like grep, vimgrep, make, etc. The locations are maintained in a stack. You can display the stack using the ":QfShow" command. You can pop an entry from the stack and jump to that file location using the ":QfPop" command. This command also accepts a count and allows you to pop multiple entries. - Yegappan qf.vim Description: application/octetstream
Re: Proposal: New command/feature for quickfix
Hi Jochen, On 6/28/06, Jochen Baier <[EMAIL PROTECTED]> wrote: hi, i think a command like "cbefore" or "croot" could be usefull. using this command after a quickfix trip (vimgrep, make etc) will jump to the buffer and line the user used before. with this command it will be easy to go back to buffer it was used before and the user do not need to remember it. what you think ? What about using the per window jump list? After using the quickfix commands, you can use the CTRL-O command to go back to the previous buffer/file location. :help jumplist - Yegappan
Re: VS2005 linking errors with FEATURES=TINY GUI=yes OLE=yes
Hi Mathias, On 6/4/06, Mathias Michaelis <[EMAIL PROTECTED]> wrote: Hi developers If I compile vim on Windows XP with Microsoft Visual Studio 2005 Express Edition on the command line with nmake -f Make_mvc.mak DEBUG=yes FEATURES=TINY GUI=yes OLE=yes I get the errors: ex_cmds2.obj : error LNK2019: unresolved external symbol _get_locale_val referenced in function _get_mess_env os_mswin.obj : error LNK2019: unresolved external symbol _gui_mch_dialog referenced in function _display_errors Is this a bug or isn't this configuration supported for certain reasons? You should be able to compile Vim with the tiny feature set. I guess some more checks needs to be added to the feature.h file. - Yegappan
Re: [Bug] On Unix-like systems, cannot redir to register +
Hi Antoine, On 6/2/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Bug: Cannot redir to @+ Redirecting the Ex command output and messages to the + register is not (yet?) supported and is not mentioned in the help for the ":redir" command. - Yegappan - Symptom: Trying to :redir to register + (seen by other apps as the clipboard) gives E475: Invalid argument: @+ - Vim version: 7.0.017 for GTK2 GUI - Workaround: :redir to register * then (after :redir END) do manually :let @+ = @* Just redirecting to @* is not enough, the other app (e.g., Thunderbird) will paste from whatever was previously in the "clipboard" (actually, the "primary selection" @+). - Additional comments: On non-Unix versions (where @* and @+ are synonymous) this is of course not a problem. Best regards, Tony.
Re: commandline window
Hi, On 6/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: All, Is there an elegant way of checking if the current window is a "command line" window other than seeing if the buffer name is "command-line" ? You can use the CmdwinEnter and CmdwinLeave autocmds and set buffer-local variables. - Yegappan
Re: VIM 7.0 on WinXP - Strange garbage during editing.
On 5/16/06, Yegappan Lakshmanan <[EMAIL PROTECTED]> wrote: Hello, On 5/16/06, Ali Akcaagac <[EMAIL PROTECTED]> wrote: > Hello, > > At work I am using VIM 7.0 on WindowsXP and detected some garbage during > editing process. Say I am loading a normal Textfile. I edit it, move > around with the arrows, press ESC move around even more, scroll around a > bit.. And quite often I find stuff that I previously yanked into the > buffers spread all over the file. > Are you scrolling with the mouse and are you using the mouse scroll wheel? Also, refer to the following FAQ question: http://vimdoc.sourceforge.net/vimfaq.html#31.14 - Yegappan > > With other words, it looks like someone has pressed 'p' for pasting > what's in the buffer all over the file. I get this quite often when > editing code at work and I wonder why I run into errors and reloading > the files show me that somehow the content of the buffers got pasted > somewhere. The paste somehow happens when scrolling or cursor moving > happens. It's quite strange to explain. > > I also add the vimrc file that I keep using at work (it's basicly the > same as I use under my home Linux machine - I never had that problem at > home with Linux.) > > Any ideas are welcome. > > mfg, > > Ali Akcaagac
Re: VIM 7.0 on WinXP - Strange garbage during editing.
Hello, On 5/16/06, Ali Akcaagac <[EMAIL PROTECTED]> wrote: Hello, At work I am using VIM 7.0 on WindowsXP and detected some garbage during editing process. Say I am loading a normal Textfile. I edit it, move around with the arrows, press ESC move around even more, scroll around a bit.. And quite often I find stuff that I previously yanked into the buffers spread all over the file. Are you scrolling with the mouse and are you using the mouse scroll wheel? - Yegappan With other words, it looks like someone has pressed 'p' for pasting what's in the buffer all over the file. I get this quite often when editing code at work and I wonder why I run into errors and reloading the files show me that somehow the content of the buffers got pasted somewhere. The paste somehow happens when scrolling or cursor moving happens. It's quite strange to explain. I also add the vimrc file that I keep using at work (it's basicly the same as I use under my home Linux machine - I never had that problem at home with Linux.) Any ideas are welcome. mfg, Ali Akcaagac
Re: :cw messes with _ =
Hi Benji, On 5/15/06, Benji Fisher <[EMAIL PROTECTED]> wrote: After opening the quickfix window and using _ to make it larger, I find that = no longer works until I close the quickfix window. This is because the quickfix window has the 'winfixheight' option set. So when you try to make the height of all the windows equal, the windows with the 'winfixwidth' option set are skipped. If you reset the 'winfixheight' option for the quickfix window then CTRL-W_= will work. - Yegappan Details: vim 7.0 (no patches) on Linux + GTK2 (so 'encoding' is set to utf-8) + Normal features (compiled OOTB). $ vim -u NONE :helpgrep guifont=\* :cw :wincmd _ :wincmd = --Benji Fisher
Re: How to convert a string into a "file"
Hi Zdenek,
On 5/5/06, Zdenek Sekera <[EMAIL PROTECTED]> wrote:
I have this problem (trivially simplified a real case):
let a="a\nb\nc"
When echo'ing it, it displays lines:
:echo a
a
b
c
Now I need to call system() and have the contents of 'a'
as the file, without actually writing the 'a' into a temp file,
something like this:
execute "system(". editor . " " . file .")"
where 'editor' is a variable containing the editor name,
could be
let editor=gvim
and 'file' is *the something* containing the lines from
the variable 'a'.
Can that be done or do I have to go via a temp file?
The system() function in Vim7 takes an additional optional argument that
specifies the input to a command:
--
system({expr} [, {input}]) *system()* *E677*
Get the output of the shell command {expr}.
When {input} is given, this string is written to a file and
passed as stdin to the command. The string is written as-is,
you need to take care of using the correct line separators
yourself. Pipes are not used.
--
In your example, you can do:
call system(editor, a)
This will write the contents of the variable 'a' to a temporary file and
supply it to the command mentioned in the variable 'editor'.
- Yegappan
Re: Tab menu?
Hi Robert, On 5/1/06, Robert Webb <[EMAIL PROTECTED]> wrote: From the help: "In the GUI tab pages line you can use the right mouse button to open menu." This doesn't seem to work on Windows2000. Which beta version of Vim7 are you using? The tabline menu should work in the GUI version on Windows 2000. - Yegappan
Re: Comments about 7.0g
Hello, On 5/1/06, Robert Webb <[EMAIL PROTECTED]> wrote: > This is the last chance to report problems. This is my first look at the version 7 line. Here's a few things I noticed: - I was excited about tabs, but a bit disappointed to see that they're only implemented using text in the Windows GUI version. Can't an actual tab control be used for this? In the MS-Windows version, the Win32 tab control is used to support the tab pages. Which beta version of Vim7 are you using? Currently the GUI tab control in supported in the Win32, Motif and GTK+ versions. The text based tab control works in all the versions. - With 'mousefocus' set, moving the mouse onto the tab bar makes the top window active. Putting the mouse on the tab bar shouldn't change which window is currently active. For one thing it means that when you put the mouse on the tab bar, the bar names may change, causing the tab you put the mouse on to move and possibly no longer be under the mouse. I am not able to reproduce this problem. With the 'mousefocus' option set and with two horizontally split windows, when the mouse pointer is on the tab bar, the current window is not changed. If the cursor was in the bottom window, it remains in that window. - When the tabs don't all fit, the tab names are truncated at the start. Wouldn't it make more sense to truncate them from the end? The extension of the file is probably the least relevant part of the file name, but it is the last thing to go when the names are truncated. In fact the same goes for the file names shown on lines between split windows. I notice each part of a leading path is truncated from the end, so why not the filename? Also, the path in the tab is ALWAYS truncated, unlike what appears on the split lines, even when there is plenty of room for the full path. Why not show any leading path untruncated if it will fit? Bram should comment on the above. But I just want to mention that when you place the mouse pointer over a tab, the complete tab label should be displayed in a tooltip. You can also set the 'guitablabel' option to control the text displayed in the tab labels. - Shouldn't there be some menu items for using tabs? So far I only see "Open Tab" under the file menu. Some others should probably go in the Window menu, eg creating a new empty tab, or splitting the current window into a new tab. - Dragging tabs to rearrange their order would be nice. - Just noticed that after Ctrl+F on the :-line a menu appears when doing completion. This is nice, but I immediately went to select an option with the mouse, but it seems that doesn't work. Would be useful if it did. When you press CTRL-F on the : prompt, you should get the cmdline window where all the previous commands are displayed. This is a normal Vim window, so you can use the normal Vim commands to edit the contents displayed in the window and select a command to execute. The cmdline window is supported in Vim6 also. - Yegappan
Re: functions that take much time in load_dummy_buffer() [vimgrep]
Hi Yakov, On 4/28/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: I identified which functions are slow and which are fast out of functions called (load_dummy_buffer() + wipe_dummy_buffer()) pair. As I wrote earlier this pair of functions is what slows down vimgrep, not the search. The loop of 1000x (load_dummy_buffer() + wipe_dummy_buffer()) takes 30 seconds per 1000 pairs on my machine (800 MHZ). These tests are on empty files, so data size is not a problem. No regexp searching is performed. Results: check_need_swap() - 50% major contributor to slowdown Maybe the 'noswapfile' option should be set for buffers opened during the ":vimgrep" operation? - Yegappan ml_open()- 30% 2nd contributor setfname() - 19% surprise, surprise The rest of functions are blazingly fast, take <1% of time. Fast functions (negligible overhead) include: - wipe_dummy_buffer() - buf_copy_options() - buflist_new() - aucmd_prepbuf() - aucmd_restbuf() I don't have real results for readfile() because I tested on empty files. But on empty file readfile() works fast. Yakov
Re: Now that we have feedkeys()...
Hi Nikolai, On 4/26/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote: > a readkeys() can't be far behind. Having a readkey() - singular > probably makes more sense - function would allow us (i.e., me) to do > something like this: > What will be difference between the existing getchar() function and this new readkey() function? - Yegappan > > function! s:DeleteComment(inclusive) > " Delete a language-specific comment > : > : > endfunction > > function! s:Delete() > let key = readkey() > let object = '' > if key == 'a' || key == 'i' > let object = readkey() > if object == 'c' > return s:DeleteComment(key == 'a') > endif > endif > call feedkeys(key . object) > endfunction > > map d :call Delete() > > That is, the input sequence "dac" would delete a comment. Entering > something else would just be fed to Vim as always. > > It would also be nice if the keys read by readkey() came up in the > 'showcmd' buffer. > > And for anyone suggesting I map "dac" directly, consider the fact that > "dd" will be delayed, which is, to me, unacceptable. > > One could map 'd' to map 'ac' once pressed, but it would be hard to > make sure that 'ac' was unbound if the user cancelled the command in > any way. > > nikolai >
Re: changing cursor position from search prompt doesn't work
Hi Hari, On 4/19/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote: > > If you execute a function that changes the cursor position from the > search prompt, vim completely ignores it, but the same works fine from > the command prompt. Say, you have something like this: > > function! TT() > call cursor(1,1) > return "" > endfunction > > and you execute it as: > > :=TT() > > the cursor position gets changed to the start of the file, but the same > doesn't work if you do the below: > > /=TT() > > Is this a bug or intended behavior? I can't find a way to get this to > work without coming out of the search prompt, go into the command > prompt to execute the function, and return back to the search prompt. > Any help is apprecaited. > This is the intended behavior. After you hit enter at the search prompt, the cursor is repositioned to the original cursor location and the pattern is searched again. So you cannot change the cursor location from the search prompt. - Yegappan
Re: Vim 70 and multibyte printing
Hello, On 4/13/06, Valery Kondakoff <[EMAIL PROTECTED]> wrote: > Hello, vim-developers! > > Please, bring some lite on this topic: is this true, that it is > still impossible to print mutibyte textes using (g)Vim 7.0 when you > set 'encoding' to 'utf-8'? > > At least all my experiments were unsuccsessfull. I'm using gVim 7.0d > under WinXP SP2. > > > As far as I understand the Vim 7.0d beta available from ftp.vim.org > is compiled without postscript support. Is this the reason why > multibyte printing is impossible? > > I just can't believe such an advanced editor like (g)Vim just > can not provide such an obvious feature like multibyte printing - so > you should reopen the textes in Notepad just to print them! > According to version7.txt, multi-byte printing is now supported: Printing multi-byte text*new-print-multi-byte* -- The |:hardcopy| command now supports printing multi-byte characters. The 'printmbcharset' and 'printmbfont' options are used for this. Also see |postscript-cjk-printing|. (Mike Williams) - Yegappan
Re: :!gvim does not work
Hi Bram, On 4/13/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > Benji Fisher wrote: > > > I just tried > > > > :!gvim > > > > and all I got was > > > > Vim: Caught deadly signal SEGV > > Vim: Finished. > > > > Command terminated > > > > Press ENTER or type command to continue > > > > I am using vim 7.0d on Linux (FC2). I get the same result running vim > > (in a gnome-terminal) or gvim. > > Works fine for me... Check what program is actually executed, perhaps > in a ":!" shell $PATH is different. > I am able to reproduce this crash only in the GTK version of gvim. In the Motif and Win32 versions, it works fine. - Yegappan
Re: vim split buffer bug
Hi, On 4/10/06, Yegappan Lakshmanan <[EMAIL PROTECTED]> wrote: > Hello, > > On 4/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > ...this also reminds me of another related issue: > > > > 1. press in the top window repeatedly until you get to the last > > > > line of this three line buffer > > > > 2. do a :tab split > > > > 3. do a :tabclose > > > > > > > > Notice that the top window scrolled back to the top of the buffer. This > > > > is annoying because the idea of using the tab split is if you want to > > > > look at some file in a full window view, and then return to the preview > > > > tab page, with its view unhindered. > > > > > > Doesn't happen for me, I only see the third line. Do you have > > > 'scrolloff' set perhaps? Then the window scrolls when you enter it. > > > > I turned scrolloff off; and it still happens. Even in gvim. Again, with > > several lines in the buffer, all the way down so that only the > > last line is showing, :tab split, :tabclose... and it scrolled back to > > the top. Annoying. > > > > Anyone else see this? > > > > I am not able to reproduce this problem. Did you running Vim with > "vim -N -u NONE -U NONE"? > I am able to reproduce this problem only when using the non-GUI tabline. I am also not able to reproduce the problem when the new tab is closed using a command other than ":tabclose". You can also see this issue when you switch between the tabs. - Yegappan
Re: vim split buffer bug
Hello, On 4/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > ...this also reminds me of another related issue: > > > 1. press in the top window repeatedly until you get to the last > > > line of this three line buffer > > > 2. do a :tab split > > > 3. do a :tabclose > > > > > > Notice that the top window scrolled back to the top of the buffer. This > > > is annoying because the idea of using the tab split is if you want to > > > look at some file in a full window view, and then return to the preview > > > tab page, with its view unhindered. > > > > Doesn't happen for me, I only see the third line. Do you have > > 'scrolloff' set perhaps? Then the window scrolls when you enter it. > > I turned scrolloff off; and it still happens. Even in gvim. Again, with > several lines in the buffer, all the way down so that only the > last line is showing, :tab split, :tabclose... and it scrolled back to > the top. Annoying. > > Anyone else see this? > I am not able to reproduce this problem. Did you running Vim with "vim -N -u NONE -U NONE"? - Yegappan
