Re: avoiding unneeded buffer scrolling
On 11/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It bothers me how when switching between tabs (gt) or switching between buffers (:bn, :bp), sometimes a buffer will end up being shifted/scrolled up/down within its window. For the occasions that I want to shift the buffer I have keys like zz to do this manually. I don't want this to happen automatically. Is there any way to avoid this automatic shifting that I'm talking about? Yes, Matt, there is. Try http://www.vim.org/tips/tip.php?tip_id=1379 Tip #1375: preserve screen *visual* line when switching buffers Yakov
Re: avoiding unneeded buffer scrolling
Yakov, Your tip is great. It fixed the first problem (with :bn, :bp). However, it does not take care of the second problem, regarding the tabs. In addition, Yakov, I've found some instances where your tip fails to work. It must be a bug in vim, because the tip's code looks fine. --Matt On 11/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It bothers me how when switching between tabs (gt) or switching between buffers (:bn, :bp), sometimes a buffer will end up being shifted/scrolled up/down within its window. For the occasions that I want to shift the buffer I have keys like zz to do this manually. I don't want this to happen automatically. Is there any way to avoid this automatic shifting that I'm talking about? Yes, Matt, there is. Try http://www.vim.org/tips/tip.php?tip_id=1379 Tip #1375: preserve screen *visual* line when switching buffers Yakov
Re: warnings: O_NOFOLLOW redefined.
Maurice Barnum wrote: Bram Moolenaar [EMAIL PROTECTED] writes: : Including fcntl.h was needed in only a few files in the past, that's why : it's included in individual .c files. But we might as well move it to : vim.h now, since it's used by quite few .c files. : Did you try including fcntl.h in vim.h, before the define of O_NOFOLLOW? no. that would work, too. i put it in os_unix.h because it seemed to be the right place to include a unix specific header and it was included by vim.h before the define. it wasn't clear to me when a system specific header is included in vim.h, and when it comes from os_*.h. There is no sharp border between what is system specific and what is generic C. I think most systems have fcntl.h, thus it's better to put it in vim.h. Do you mind if I postpone this change until Vim 7.1? You are the first to complain thus it doesn't appear to be urgent. And it will change many files, it's better to do this in a minor release. -- If you feel lonely, try schizophrenia. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: generate a directory listing file with vim.
On 11/6/06, victor NOAGBODJI [EMAIL PROTECTED] wrote:
How can I use Vim to generate the listing of a directory?
The directory contains images. And a textfile, but I don't
want to textfile. Only the images.
The output would be in the textfile I was talking about.
Each line would represent a path to an image.
Do you think it is possible? How can I do it then?
:help glob()
:let list=glob('*')
Yakov
Re: Expansion of ${!x*} and [EMAIL PROTECTED]
On 11/6/06, Linda W [EMAIL PROTECTED] wrote:
The manpages for my bash's (3.1.11 on Linux and 3.1.17 on cygwin/i686),
under Parameter Expansion, has:
${!prefix*}
[EMAIL PROTECTED]
Expands to the names of variables whose names begin with prefix,
separated by the first character of the IFS special variable.
---
From this, I'd expect both forms to have the same output.
Is this what is intended and what I should expect?
Wrong list ?
Yakov
Re: ':Explore' higlight the results
Hello Chip, I followed your procedure, but unfortunately, the behaviour of netrw surprised me. The installation went fine, no error messages. I tried the following command: :Explore **//STRING to find all the file containing the string STRING. The command just hanged there, not doing anything, like freezing my gvim. I have to type CTRL-C to stop. Before the update, it was giving me the list of the files of the current directory and I could navigate through the results using SHIFTUP or DOWN. When I tried: :Explore */STRING it gave me a lot of error messages that disappeared too fast for me to read it. Is there a way to get that output to be able to debug it with your help? I'm running Vim 7.0 (compiled May 7 2006) on Windows XP (I didn't try it on my Linux box at home). Gregory On 11/3/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hello Vimmers, I've seen recently in the mailing list an interesting post/question about searching for a list of fies containing a pattern. The answer was that we could use :Explore or :vimgrep. For me, the first solution seems the best. I have a friend of mine that is using emacs, which has the same option as :Explore. However, the files matching the pattern are highlighted. Is it possible to do the same with :Explore? I checked the :help :Explore but couldn't find it. I've uploaded v107g of netrw.vim which supports this to my website: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs see Network Oriented Reading, Writing, and Browsing First, remove all previous versions of netrw from both your personal directories and from the system directory where netrw was installed (under Linux, that's often /usr/local/vim/share/vim/vim70/[plugin|autoload|doc]/netrw*). You'll also need to remove all previous versions of vimball. You can get the latest vimball from my website, too (see Vimball Archiver). Install it first: cd /usr/local/vim/share/vim/vim70 mv [wherever]/vimball.tar.gz . gunzip vimball.tar tar xvf vimball.tar Then you may install netrw: vim netrw.vba.gz :so % :q should do it. Regards, Chip Campbell
Re: avoiding unneeded buffer scrolling
On 11/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It bothers me how when switching between tabs (gt) or switching between buffers (:bn, :bp), sometimes a buffer will end up being shifted/scrolled up/down within its window. For the occasions that I want to shift the buffer I have keys like zz to do this manually. I don't want this to happen automatically. Is there any way to avoid this automatic shifting that I'm talking about? Yes, Matt, there is. Try http://www.vim.org/tips/tip.php?tip_id=1379 Tip #1375: preserve screen *visual* line when switching buffers Yakov
click buffer, go to the buffer place
Hi, in my single session, I have many tabs opened, and in one tabs, I often open three windows or more. That means I have many many buffers. Sometimes I want to edit one buffer that I don't know where it is ( in where tab, or in where window ), so I just have to search by iterating from tab to tab. That's annoying. Yeah, I can click buffer from buffer menu item, but that open buffer in my current window which I don't like. I just wonder if I can click the buffer, I redirected to the wherever buffer belongs. Thank you.
Re: ':Explore' higlight the results
Gregory SACRE wrote: Hello Chip, I followed your procedure, but unfortunately, the behaviour of netrw surprised me. The installation went fine, no error messages. I tried the following command: :Explore **//STRING to find all the file containing the string STRING. The command just hanged there, not doing anything, like freezing my gvim. I have to type CTRL-C to stop. Before the update, it was giving me the list of the files of the current directory and I could navigate through the results using SHIFTUP or DOWN. When I tried: :Explore */STRING it gave me a lot of error messages that disappeared too fast for me to read it. Is there a way to get that output to be able to debug it with your help? I'm running Vim 7.0 (compiled May 7 2006) on Windows XP (I didn't try it on my Linux box at home). Gregory see :help :messages :help :redir Best regards, Tony.
How to check spelling in xml files? gentoo gwn as an example.
Hello. I have problem with spell cheking in vim. I'm editing .xml file. Now if I set: :set spell spelllang=en vim starts to check spelling but only inside quotes in link tag (link=here vim checks). And that is all where vim checks spelling. But it does not check text inside p /p tags where the actuall text is. (Fex, pvim does not check here/p) How can I avoid that? And if you wish to try that behavior yourself download the following xml file: $ wget 'http://www.gentoo.org/news/en/gwn/20061030-newsletter.xml?passthru=1' -O 061030-newsletter-en.xml Thank you for your time, Peter. signature.asc Description: This is a digitally signed message part
Re: Lapsus in usr_10.txt?
On Sat, Nov 04, 2006 at 10:01:24PM +0100, Guido Van Hoecke wrote: Fellow Vimmers, Lines 185-186 in usr_10.txt claim ... Other flags include p (print), which causes the :substitute command to print out each line it changes. ... This is not what happens. Line 639 in change.txt correctly describes the actual behaviour: [p] Print the line containing the last substitute. The text in usr_10.txt should be changed into something like: ... Other flags include p (print), which causes the :substitute command to print out the last line it changes. ... Cordially, Guido. Thanks for reporting this. In the future, you can make things a little easier for Bram if you produce a patch, like the one below. For details on patch format, see my tip at http://www.vim.org/tips/tip.php?tip_id=618 HTH --Benji Fisher *** /usr/local/share/vim/vim70/doc/usr_10.txt 2006-05-08 10:42:46.0 -0400 --- /home/benji/temp/usr_10.txt 2006-11-06 08:27:47.358006837 -0500 *** *** 183,190 Teacher Smith criticized Teacher Johnson today. ~ Other flags include p (print), which causes the :substitute command to print ! out each line it changes. The c (confirm) flag tells :substitute to ask you ! for confirmation before it performs each substitution. Enter the following: :%s/Professor/Teacher/c --- 183,191 Teacher Smith criticized Teacher Johnson today. ~ Other flags include p (print), which causes the :substitute command to print ! out the last line it changes. The c (confirm) flag tells :substitute to ask ! you for confirmation before it performs each substitution. Enter the ! following: :%s/Professor/Teacher/c
Re: disappearing echo in ':nmap *'
On Mon, Nov 06, 2006 at 10:55:34AM +0100, Zdenek Sekera wrote: I had many cases of disappearing echo in the past, I was mostly able to solve with some or other tricks. This one is difficult, I cannot solve it whatever I try (echo in the rhs of 'nmap *'): 1. :nnoremap * :exe norm! * bar echomsg bla blacr 2. :help help 3. /forcr 4. press * * * * * * * Message bla bla mostly does not appear (very rarely, it does; :mess shows that mapping was triggered) Why ? I don't know why but I have that problem since a long time (from vim 5 already!). Yes, sometimes tricks (like introducing dummy 'echo ' before the real echo help, but sometimes they don't. I think Bram knows about it. Searching for echo in todo.txt, I did not find any mention of this. Maybe this item? 9 Check handling of overwriting of messages and delays: Very wrong: errors while redrawing cause endless loop. When switching to another file and screen scrolls because of the long message and return must be typed, don't scroll the screen back before redrawing. It seems to me that the message is wiped out when the screen scrolls. If the cursor move on the same screen, or if the screen redraws, then I see the bla bla. Aha: this seems to help: :nnoremap * :execute norm! * Bar redraw Bar echomsg bla blaCR HTH --Benji Fisher
Re: noimd don't works under linux
On Mon, Nov 06, 2006 at 07:28:35PM +0800, Eddy Zhao wrote:
2006/11/6, Benji Fisher [EMAIL PROTECTED]:
[snip]
Part of the problem is that you defined the :map commands with
notation before setting 'nocp'. From another post on this thread, I see
that you want to try this with gvim, not terminal vim. So please try
$ gvim -u NONE
:set nocp
:set laststatus=2 stl=%{imd}
:inoremap ESC ESC:set imdCR
:nnoremap i :set noimdCRi
and *then* try going from Normal mode to Insert mode and back with i and
Esc. The status line should show the current value of the 'imdisable'
option.
This time status line output switch between 0 and 1
What it reveals ?
This means that the 'imdisable' option is being set when you leave
Insert mode with Esc, and it is being reset when you enter Insert mode
with i, both as intended. Thus the source of the problem is not what
you first guessed it was.
Perhaps it would help if you described more precisely what is not
working the way it should (or the way you expect).
HTH --Benji Fisher
Re: noimd don't works under linux
Eddy Zhao wrote: [...] Though status line shows imd is being reset while change from nomal mode to insert mode, but IM is not enabled (in other words, scim input window is not popup when return back to insert mode). That's the problem I encountered. Anything else I can try to debug to nail down the problem? Thanks Eddy I don't use the IM myself, but I have read some of the help about it. IIUC, the 'iminsert' influences whether Vim uses an input method: imi == 2 IM is active imi == 1 keymaps and language-mappings are active if defined imi == 0 neither See :help 'iminsert' for details. If you aren't using Athena or Motif, you should be able to leave either 'imd' constantly off or 'imi' constantly at 2. Best regards, Tony.
Re: File type retention
Thanks. I see where the c.vim plugin sets the browsefilter; I'll have to think about whether I want to adapt my habits or do some script-writing. Maybe some of both! Benji Fisher wrote: On Fri, Nov 03, 2006 at 11:12:19AM -0700, Daryl Lee wrote: This may be a Windows issue, but maybe someone here can help me solve it. Using gVim, when I open a file with .h extension and then try to open another .h file, the FileOpen dialog has the file filter set to *.cpp,*.c++. I have to manually force it back to either All or *.h. Is there some way to override that behavior? I'd prefer All, which is the equivalent of what I get on Linux under KDE, where there is no filter at all in the FileOpen dialog. Have you (or some script) set a (global or buffer-local) browsefilter variable? :echo g:browsefilter :echo b:browsefilter (If both commands generate errors, then the answer is no.) If I read :help browsefilter correctly, then the simplest solution is to add :let g:browsefilter = All Files\t*.*\n to your vimrc file. A more complicated solution is to add something like :let b:browsefilter = C files\t*.c;*.h;*.cpp;*.c++All Files\t*.*\n to an ftplugin for C files. Ask again if you need more details. HTH --Benji Fisher P.S. It seems that b:browsefilter *is* set in the default ftplugin (but only on Windows systems). So see :help ftplugin-overrule -- Daryl Lee Open the Present, it's a Gift.
[OT] Re: Expansion of ${!x*} and [EMAIL PROTECTED]
* Linda W [EMAIL PROTECTED] [061106 00:11]:
The manpages for my bash's (3.1.11 on Linux and 3.1.17 on cygwin/i686),
under Parameter Expansion, has:
${!prefix*}
[EMAIL PROTECTED]
Expands to the names of variables whose names begin with prefix,
separated by the first character of the IFS special variable.
---
From this, I'd expect both forms to have the same output. Is this what is
intended and what I
should expect?
For test purposes, I set:
IFS= OFS= # (also set Output FS to see if it is used
# in the output of 'echo')
---
I used 4 tests, all with prefix=U, 1st pair unquoted, 2nd pair quoted.
input:
echo ' * ' = ${!U*}; \ # (line 1 - * unquoted)
echo ' @ ' = [EMAIL PROTECTED]; \ # (line 2 - @ unquoted)
echo '*' = ${!U*} ; \ # (line 3 - * quoted)
echo '@' = [EMAIL PROTECTED] # (line 4 - @ quoted)
---
output:
* = UID USER # (line 1)
@ = UID USER # (line 2)
* = UIDUSER # (line 3)
@ = UID USER # (line 4)
---
QUESTIONS continued...
- If the two forms are supposed to be identical, why aren't lines
3 4 the same?
- Why do the quotes in line 3 make for different output than in line
Why aren't the 4 lines identical? I see the IFS, in line 3, but
not in lines 1,24. Why isn't it in all 4 lines and, also, even the double
quotes make a
difference when expanding variables, why
aren't lines 34 the same?
As Yakov pointed out, this is the wrong list, but I will answer anyway.
${!prefix*} and [EMAIL PROTECTED] (unquoted) are the same. However, inside
double quotes, ${!prefix*} expands to a single word (and requires IFS
separation between the names that match the prefix), while [EMAIL PROTECTED]
expands to one word for each name that matches, and hence is already
separated by quoting.
I do not see this described in the man page under ${!prefix*}, but if
you look earlier in the man page under Special Parameters, it describes
the difference between $* and [EMAIL PROTECTED] Also, under Arrays (between
Special
Parameters and Parameter Expansion), it says that the difference between
${name[*]} and [EMAIL PROTECTED] is analogous to the difference between $* and
$@, so I imagine that the same applies to !prefix.
...Marvin
Re: avoiding unneeded buffer scrolling
Yakov, Your tip is great. It fixed the first problem (with :bn, :bp). However, it does not take care of the second problem, regarding the tabs. In addition, Yakov, I've found some instances where your tip fails to work. It must be a bug in vim, because the tip's code looks fine. --Matt On 11/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It bothers me how when switching between tabs (gt) or switching between buffers (:bn, :bp), sometimes a buffer will end up being shifted/scrolled up/down within its window. For the occasions that I want to shift the buffer I have keys like zz to do this manually. I don't want this to happen automatically. Is there any way to avoid this automatic shifting that I'm talking about? Yes, Matt, there is. Try http://www.vim.org/tips/tip.php?tip_id=1379 Tip #1375: preserve screen *visual* line when switching buffers Yakov
Re: avoiding unneeded buffer scrolling
Matt Zyzik wrote: It bothers me how when switching between tabs (gt) or switching between buffers (:bn, :bp), sometimes a buffer will end up being shifted/scrolled up/down within its window. For the occasions that I want to shift the buffer I have keys like zz to do this manually. I don't want this to happen automatically. Is there any way to avoid this automatic shifting that I'm talking about? --Matt P.S. There is a shift that frequently happens when closing the second to last tabpage. The last line of the newly active window will scroll to the bottom line of the window. Did you include patch 7.0.149? I just tried up to 7.0.152 and the bug with the second to last tabpage close appears fixed. However, even with this version of Vim, Yakov's script utilizing winsaveview() sometimes doesn't work. The issue with the tabpages and scrolling was my main concern. Thanks for fixing it :) -- hundred-and-one symptoms of being an internet addict: 158. You get a tuner card so you can watch TV while surfing. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org /// \\\help me help AIDS victims -- http://ICCF-Holland.org ///
Re: gvim cut paste selection
On 11/4/06, Ujjal Bose [EMAIL PROTECTED] wrote: I was having problem with cut-paste selections from X - Windows for gvim (6.2) , and this is the reply I got from the RealVNC team . So is there a way to solve this in gvim ? I found the patch someone made for very similar problem: http://permalink.gmane.org/gmane.editors.vim/38505 I wonder whether this patch also fixes your problem with vnc if you replace '#ifdef WIN32UNIX' in the patch to just '#if 1' ? Yakov
let s:F=function('foo#func_in_this_file') ?
Imagine having the files:
-- 8 -- 8 autoload/test.vim - 8 -- 8 -- 8
function test#DoTest(a)
if a == 1
call s:F1()
else
call s:F2()
endif
endfunction
function test#Test()
echo test#Test()
endfunction
let s:F1=function('test#Test')
let s:F2=function('test2#Test')
-- 8 -- 8 -- 8 -- 8 -- 8 -- 8 -- 8
-- 8 -- 8 autoload/test2.vim - 8 -- 8 -- 8
function test2#Test()
echo test2#Test()
endfunction
-- 8 -- 8 -- 8 -- 8 -- 8 -- 8 -- 8
calling test#DoTest(2) doesn't work because vim doesn't know the
function yet. I can solve this using my custom function Function:
function! Function(name)
find autoloadfile containing a:name
exec 'source '.autoloadfile
return function(a:name)
endfunction
calling test#DoTest(1) doesn't work because test#Test isn't known by vim
when sourcing the file. Is the only option moving the function
test#Test() into another file?
Marc
solved - Re: let s:F=function('foo#func_in_this_file') ?
-- 8 -- 8 autoload/test.vim - 8 -- 8 -- 8 function test#DoTest(a) if a == 1 call s:F1() else call s:F2() endif endfunction I'm sorry. It does work. The solution is to use something like let G=s:F1 call G() Marc
Re: let s:F=function('foo#func_in_this_file') ?
Marc Weber wrote:
Imagine having the files:
-- 8 -- 8 autoload/test.vim - 8 -- 8 -- 8
function test#DoTest(a)
if a == 1
call s:F1()
else
call s:F2()
endif
endfunction
function test#Test()
echo test#Test()
endfunction
let s:F1=function('test#Test')
let s:F2=function('test2#Test')
-- 8 -- 8 -- 8 -- 8 -- 8 -- 8 -- 8
-- 8 -- 8 autoload/test2.vim - 8 -- 8 -- 8
function test2#Test()
echo test2#Test()
endfunction
-- 8 -- 8 -- 8 -- 8 -- 8 -- 8 -- 8
calling test#DoTest(2) doesn't work because vim doesn't know the
function yet. I can solve this using my custom function Function:
function! Function(name)
find autoloadfile containing a:name
exec 'source '.autoloadfile
return function(a:name)
endfunction
calling test#DoTest(1) doesn't work because test#Test isn't known by vim
when sourcing the file. Is the only option moving the function
test#Test() into another file?
Marc
If the autoload directory doesn't work, maybe you can use the FuncUndefined
autocommand event? Or else, maybe using function() for an autoload#function()
requires prior sourcing of the appropriate autoload script?
See
:help autoload-functions
:help autoload
:help Funcref
Best regards,
Tony.
Re: BufEnter Oddity After TabEnter
On Sun 5-Nov-06 3:21am -0600, Yakov Lerner wrote: On 11/5/06, Bill McCarthy [EMAIL PROTECTED] wrote: I am having a problem trying to echo a message triggered by an autocmd on BufEnter when entering a tab page. Try this: :au BufEnter foo echom Entered foo First lets try opening a window on the same tab page: :sp foo The message appears in the command line area as expected. Switching between windows, the messages is seen each time foo is entered. Wipe foo with: :bw foo Now try a tab page: :tabe foo The message appears as expected. However leaving and then entering the foo tab page does not display the message! Typing :mes shows that the message was indeed displayed. What is overwriting it? I can see this, too. The message is visible for some time if I add sleep or while getchar(1)|endwh to the rhs of 'au', but disappears right after that. Is it tab switching that causes wipeout of the message ? It shouldn't be, the tab triggers occur before the BufEnter. I modified the autocmd to do a redraw before the echo. That didn't make any difference in this case. As far as I can see, there is nothing happening after the echo - yet something is clearly clearing the line. Running with default settings, ruler is off but showcmd is on. Shutting off showcmd also made no difference. Looking to confirm the order of event triggers, I found the following at :h tabline-menu When switching to another tab page the order is: BufLeave WinLeave TabLeave TabEnter WinEnter BufEnter I decided to test this by writing the following script: Contents of tabtest.vim au BufLeave * se ch=1 au WinLeave * se ch=1 au TabLeave * se ch=1 au TabEnter * se ch=1 au WinEnter * se ch=1 au BufEnter * se ch=1 au BufEnter foo redraw|echo Entered foo tabe foo tabn se vbs=99 vfile=/pad/temp/vfile tabn qa I ran the above with this: gvim -u NONE -i NONE -N +so tabtest.vim and received this: Contents of /pad/temp/vfile line 11: tabn Executing BufLeave Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing WinLeave Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing TabLeave Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing WinEnter Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing TabEnter Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing BufEnter Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing BufEnter Auto commands for foo autocommand redraw|echo Entered foo line 0: redraw|echo Entered foo line 0: echo Entered foo Entered foo line 12: qa Although Entered foo is clearly sent to the command line, it is being wiped out by something - still unknown. Note that the order of triggering specified in the docs (and quoted above) appears to be wrong. As you can see above, TabEnter is triggered after WinEnter (not before it). -- Best regards, Bill
Re: BufEnter Oddity After TabEnter
Bill McCarthy wrote: On Sun 5-Nov-06 3:21am -0600, Yakov Lerner wrote: On 11/5/06, Bill McCarthy [EMAIL PROTECTED] wrote: I am having a problem trying to echo a message triggered by an autocmd on BufEnter when entering a tab page. Try this: :au BufEnter foo echom Entered foo First lets try opening a window on the same tab page: :sp foo The message appears in the command line area as expected. Switching between windows, the messages is seen each time foo is entered. Wipe foo with: :bw foo Now try a tab page: :tabe foo The message appears as expected. However leaving and then entering the foo tab page does not display the message! Typing :mes shows that the message was indeed displayed. What is overwriting it? I can see this, too. The message is visible for some time if I add sleep or while getchar(1)|endwh to the rhs of 'au', but disappears right after that. Is it tab switching that causes wipeout of the message ? It shouldn't be, the tab triggers occur before the BufEnter. I modified the autocmd to do a redraw before the echo. That didn't make any difference in this case. As far as I can see, there is nothing happening after the echo - yet something is clearly clearing the line. Running with default settings, ruler is off but showcmd is on. Shutting off showcmd also made no difference. Looking to confirm the order of event triggers, I found the following at :h tabline-menu When switching to another tab page the order is: BufLeave WinLeave TabLeave TabEnter WinEnter BufEnter I decided to test this by writing the following script: Contents of tabtest.vim au BufLeave * se ch=1 au WinLeave * se ch=1 au TabLeave * se ch=1 au TabEnter * se ch=1 au WinEnter * se ch=1 au BufEnter * se ch=1 au BufEnter foo redraw|echo Entered foo tabe foo tabn se vbs=99 vfile=/pad/temp/vfile tabn qa I ran the above with this: gvim -u NONE -i NONE -N +so tabtest.vim and received this: Contents of /pad/temp/vfile line 11: tabn Executing BufLeave Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing WinLeave Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing TabLeave Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing WinEnter Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing TabEnter Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing BufEnter Auto commands for * autocommand se ch=1 line 0: se ch=1 Executing BufEnter Auto commands for foo autocommand redraw|echo Entered foo line 0: redraw|echo Entered foo line 0: echo Entered foo Entered foo line 12: qa Although Entered foo is clearly sent to the command line, it is being wiped out by something - still unknown. Note that the order of triggering specified in the docs (and quoted above) appears to be wrong. As you can see above, TabEnter is triggered after WinEnter (not before it). Somehow I see neither foo 123L, 2458C nor foo [New File] in your verbosefile; I thought one of them should be issued? Does it make any difference if you set 'cmdheight' to 2 instead? Best regards, Tony.
