Re: text is gone
scott wrote: ok, so help me out here i've looked at filetype vim, and i see nothing that associates _.txt modules with ft=txt whether i enter my 'ai' modules with the script or by navigating to where they are and, with my bloody fingers typing 'gvim ai_200609.txt', still, inside the module, filetype is undefined are we only supposed to use vim for exotic languages? is 'text' deprecated? i thought it used to suffice to have an extension of .txt now the ground is shifting under my feet... sc As far as I rember checking, *.txt was associated with nothing so it was edited as, basically, free text with just a single BW set of fg/bg colors, no auto-linebreak etc. There is an autocommand in the vimrc_example.vim which sets 'textwidth' to 78 (causing auto-linebreak at column 78) for any files with text filetypes. If you want to detect *.txt, you can: 8 ~/.vimrc ... runtime vimrc_example.vim au! vimrcEx FileType ...etc. 8 8 ~/.vim/filetype.vim augroup filetypedetect ... etc ... au BufRead,BufNewFile *.txt setf text ... etc ... augroup END 8 then write your own scripts: ~/.vim/ftplugin/text.vim (for local options using :setlocal and/or mappings/abbreviations using :map buffer, :abbr buffer etc.), ~/.vim/syntax/text.vim (for syntax colouring if any: :syntax and :hi default commands) ~/.vim/indent/text.vim (for special indenting if any: probably :setlocal indentexpr to a function defined there). (on Windows, replace /.vim/ by /vimfiles/ and .vimrc by _vimrc) Best regards, Tony.
Re: Help non-functional in 7.0.90
scott wrote: On Thu, 2006-09-07 at 06:55 +0200, A.J.Mechelynck wrote: scott wrote: On Thu, 2006-09-07 at 05:58 +0200, A.J.Mechelynck wrote: scott wrote: On Thu, 2006-09-07 at 01:57 +0200, A.J.Mechelynck wrote: A.J.Mechelynck wrote: In (g)vim 7.0.90, when I try to invoke the help, let's say :help :help the program hangs; and when I finally hit Ctrl-C I get: E426: tag not found: :[EMAIL PROTECTED] Similarly for F1 E426: tag not found: [EMAIL PROTECTED] Running :helptags in the doc/ subdirectories of all 'rtp' directories doesn't help. Best regards, Tony. Cleaned my ~/.vim and $VIM/vimfiles from a few obsolete and dubious files, compiled 7.0.091 (with make reconfig), it works again (as src/vim). More fear than harm. Next thing is make install. Best regards, Tony. tony -- all this weirdness with your help -- as dependant as we are on whatever is insalled for 'ctags', i'd say you might spend some time looking at whatever shows up for 'which ctags' with a thought towards maybe fixing something there scott IIUC it's the version of ctags that came with SuSE 9.3 rpm -qa |grep ctags ctags-2004.11.15-3 which -a ctags /usr/bin/ctags ls -l `which ctags` -rwxr-xr-x 1 root root 128852 Mar 19 2005 /usr/bin/ctags ctags --version Exuberant Ctags 5.5.4, Copyright (C) 1996-2003 Darren Hiebert Compiled: Mar 19 2005, 19:18:40 Addresses: [EMAIL PROTECTED], http://ctags.sourceforge.net Optional compiled features: +wildcards, +regex The wierdness appeared after installing the manpageview plugin from vim-online, and disappeared after removing it as well as versions of the netrw and vimball plugins which had become older than the default ones due to a runtime rsync. Don't know what _any_ of those had to do with not finding the help; and (I checked) my doc/tags files were OK -- anyway, regenerating them all using (internal) helptags changed nothing. Best regards, Tony. hmmm what jumped out at me in your error messages was the '@en' -- makes me think whatever happened to you relates to something to do with the english language -- did manpageview have a lot of klunky language weirdness? sc I didn't check (and now it's gone thanks to rm -vf); but after recompiling (make reconfig but not make install) with (a) a define commented-out: /* # define FEAT_MULTI_LANG */ (b) an additional configure setting: export CONF_OPT_NLS='--disable-nls', and (c) renaming $VIMRUNTIME/lang to lanx (probably overkill but you never know...), I got the same error without the @en IIUC that @xx postfix is characteristic of multi-language help. My vimrc sets :language messages to C (on Unix) or en (on Windows) before sourcing the vimrc_example, to avoid French or Dutch menus and error messages regardless of the locale. Now I have undone all those changes, removed, as I said, the dubious plugins, re-made reconfig, and my 7.0.091 again shows any help with no noticeable lag. The only global plugins which I still have outside $VIMRUNTIME/plugin are matchit (runtime macros/matchit.vim) and a small plugin I wrote myself to display the splash screen (:intro) at the VimEnter event, even when Vim is started with one or more editfiles named on the command-line. Best regards, Tony. IIUC, your problem has been solved? no more goofy :help errors? Yes, as I mentioned earlier in this thread (at 01:57 +0200) removing doubtful plugins and making (reconfig) 7.0.091 made the problem disappear. (FYI, it is now 08:17 in the same time zone). Best regards, Tony.
Re: text is gone
On Thu, 2006-09-07 at 08:13 +0200, A.J.Mechelynck wrote: scott wrote: ok, so help me out here i've looked at filetype vim, and i see nothing that associates _.txt modules with ft=txt whether i enter my 'ai' modules with the script or by navigating to where they are and, with my bloody fingers typing 'gvim ai_200609.txt', still, inside the module, filetype is undefined are we only supposed to use vim for exotic languages? is 'text' deprecated? i thought it used to suffice to have an extension of .txt now the ground is shifting under my feet... sc As far as I rember checking, *.txt was associated with nothing so it was edited as, basically, free text with just a single BW set of fg/bg colors, no auto-linebreak etc. There is an autocommand in the vimrc_example.vim which sets 'textwidth' to 78 (causing auto-linebreak at column 78) for any files with text filetypes. If you want to detect *.txt, you can: 8 ~/.vimrc ... runtime vimrc_example.vim au! vimrcEx FileType ...etc. 8 8 ~/.vim/filetype.vim augroup filetypedetect ... etc ... au BufRead,BufNewFile *.txt setf text ... etc ... augroup END 8 then write your own scripts: ~/.vim/ftplugin/text.vim (for local options using :setlocal and/or mappings/abbreviations using :map buffer, :abbr buffer etc.), ~/.vim/syntax/text.vim (for syntax colouring if any: :syntax and :hi default commands) ~/.vim/indent/text.vim (for special indenting if any: probably :setlocal indentexpr to a function defined there). (on Windows, replace /.vim/ by /vimfiles/ and .vimrc by _vimrc) Best regards, Tony. excuse me this transcends ridiculous i am editing text, and i have gone around the bend to tell vim that i am doing so to have to create an entire text syntax, where NOTHING HAPPENS, seems against every premise that vim was built on why do i have to be surprised by 'cindent' when i am editing text? it is, after all, text, and i went out of my way to define these modules with the .txt extension, even here in linux -- specifically so he'd know why would cindent kick in if i'm not editing c? now you say *.txt is associated with nothing -- that goes far to explain why my search in filetype.vim for 'txt' was so fruitless, thank you i don't remember having this problem before -- before what exactly i'm not sure -- but i've been surprised with indenting behavior enough to go out of my way to turn every indenting feature off i can find, but still i get surprises now cindent is off, maybe i can still work...tab is easy to hit... forgive me, i have no bottom line -- no idea what i'm saying -- i'll shutup now sc
Re: text is gone
scott wrote: On Thu, 2006-09-07 at 08:13 +0200, A.J.Mechelynck wrote: scott wrote: ok, so help me out here i've looked at filetype vim, and i see nothing that associates _.txt modules with ft=txt whether i enter my 'ai' modules with the script or by navigating to where they are and, with my bloody fingers typing 'gvim ai_200609.txt', still, inside the module, filetype is undefined are we only supposed to use vim for exotic languages? is 'text' deprecated? i thought it used to suffice to have an extension of .txt now the ground is shifting under my feet... sc As far as I rember checking, *.txt was associated with nothing so it was edited as, basically, free text with just a single BW set of fg/bg colors, no auto-linebreak etc. There is an autocommand in the vimrc_example.vim which sets 'textwidth' to 78 (causing auto-linebreak at column 78) for any files with text filetypes. If you want to detect *.txt, you can: 8 ~/.vimrc ... runtime vimrc_example.vim au! vimrcEx FileType ...etc. 8 8 ~/.vim/filetype.vim augroup filetypedetect ... etc ... au BufRead,BufNewFile *.txt setf text ... etc ... augroup END 8 then write your own scripts: ~/.vim/ftplugin/text.vim (for local options using :setlocal and/or mappings/abbreviations using :map buffer, :abbr buffer etc.), ~/.vim/syntax/text.vim (for syntax colouring if any: :syntax and :hi default commands) ~/.vim/indent/text.vim (for special indenting if any: probably :setlocal indentexpr to a function defined there). (on Windows, replace /.vim/ by /vimfiles/ and .vimrc by _vimrc) Best regards, Tony. excuse me this transcends ridiculous i am editing text, and i have gone around the bend to tell vim that i am doing so to have to create an entire text syntax, where NOTHING HAPPENS, seems against every premise that vim was built on No, no, no! You don't have to; you don't have to do _anything_ if freeform single-color display is OK to you for that kind of file. If you want fancy colors (e.g., odd lines with light pink background and even lines with light yellow background), fancy indenting (such as 4 kinds of bulleted lists: * - o and ยค, and 5 kinds of numbered lists: 1., 2., 3.; A., B., C.; a), b), c); I., II., III and i. ii., iii), or special mappings and options, _then_ you have to tell Vim. why do i have to be surprised by 'cindent' when i am editing text? it is, after all, text, and i went out of my way to define these modules with the .txt extension, even here in linux -- specifically so he'd know You shouldn't, because the 'cindent' default is FALSE. The C indent plugin sets it, but since it is well-behaved it uses :setlocal, not :set, and the indenting of your other files won't be affected. why would cindent kick in if i'm not editing c? It shouldn't. The indent/c.vim plugin (which, BTW, is not sourced unless you have :filetype indent on) uses setlocal cindent which should not propagate to other files. Now if you set 'cindent' manually you should also use :setlocal rather than :set, because the latter modifies not only the local setting but also the global default. And if you want to know whether 'cindent' is set, you should use :set cindent? (or its variants with :setlocal or :setglobal) _with_ a question mark, because without one it means set 'cindent' to TRUE, not display its current value. now you say *.txt is associated with nothing -- that goes far to explain why my search in filetype.vim for 'txt' was so fruitless, thank you My pleasure. i don't remember having this problem before -- before what exactly i'm not sure -- but i've been surprised with indenting behavior enough to go out of my way to turn every indenting feature off i can find, but still i get surprises now cindent is off, maybe i can still work...tab is easy to hit... forgive me, i have no bottom line -- no idea what i'm saying -- i'll shutup now sc I use (in this order) runtime vimrc_example.vim (which contains filetype plugin indent on) filetype indent off set autoindent smartindent (and 'cindent' is off by default). I may turn 'smartindent' off someday of it proves obnoxious. 'autoindent' indents each line to the same indent as the one it was broken off from (the following one for O, otherwise usually the previous one). That's good enough for vim script or HTML (which are what I code), where there may be long blocks of code with a common indent. Best regards, Tony.
Re: text is gone
scott wrote: [...] why would cindent kick in if i'm not editing c? [...] Maybe you set it yourself or some plugin set it for you. A.J.Mechelynck proposed you really good thing. Remove code that turns cindent off, restart vim and type :verbose set cindent? and you will see where this option was set last. If this would not make it clear for you who is setting cindent, then, I believe, you can post result of this command here and somebody could help you understand vim a bit better.
Re: Help non-functional in 7.0.90
A.J.Mechelynck wrote: The wierdness appeared after installing the manpageview plugin from vim-online, and disappeared after removing it as well as versions of the netrw and vimball plugins which had become older than the default ones due to a runtime rsync. Don't know what _any_ of those had to do with not finding the help; and (I checked) my doc/tags files were OK -- anyway, regenerating them all using (internal) helptags changed nothing. Well, as I've mentioned, I have no problem with the :help command, and I certainly use manpageview all the time. Manpageview doesn't have any autocmds, so its not being invoked behind your back. The latest one defines five commands: Man [HORV]Man and a map for K. Regards, Chip Campbell
Re: Help non-functional in 7.0.90
Charles E Campbell Jr wrote: A.J.Mechelynck wrote: The wierdness appeared after installing the manpageview plugin from vim-online, and disappeared after removing it as well as versions of the netrw and vimball plugins which had become older than the default ones due to a runtime rsync. Don't know what _any_ of those had to do with not finding the help; and (I checked) my doc/tags files were OK -- anyway, regenerating them all using (internal) helptags changed nothing. Well, as I've mentioned, I have no problem with the :help command, and I certainly use manpageview all the time. Manpageview doesn't have any autocmds, so its not being invoked behind your back. The latest one defines five commands: Man [HORV]Man and a map for K. Regards, Chip Campbell All I can say is I'm puzzled. Bset regards, Tony.
Re: text is gone
scott wrote: ok, so help me out here i've looked at filetype vim, and i see nothing that associates _.txt modules with ft=txt whether i enter my 'ai' modules with the script or by navigating to where they are and, with my bloody fingers typing 'gvim ai_200609.txt', still, inside the module, filetype is undefined are we only supposed to use vim for exotic languages? is 'text' deprecated? i thought it used to suffice to have an extension of .txt now the ground is shifting under my feet... - scott wrote again: excuse me this transcends ridiculous i am editing text, and i have gone around the bend to tell vim that i am doing so to have to create an entire text syntax, where NOTHING HAPPENS, seems against every premise that vim was built on why do i have to be surprised by 'cindent' when i am editing text? it is, after all, text, and i went out of my way to define these modules with the .txt extension, even here in linux -- specifically so he'd know why would cindent kick in if i'm not editing c? now you say *.txt is associated with nothing -- that goes far to explain why my search in filetype.vim for 'txt' was so fruitless, thank you i don't remember having this problem before -- before what exactly i'm not sure -- but i've been surprised with indenting behavior enough to go out of my way to turn every indenting feature off i can find, but still i get surprises now cindent is off, maybe i can still work...tab is easy to hit... forgive me, i have no bottom line -- no idea what i'm saying -- i'll shutup now Yep, nothing associates *.txt modules with ft=txt. That's because there is no syntax/txt.vim highlighting, at least as distributed. What highlighting should be done for a non-specific, arbitrary language? Keywords? Regions? Or did you intend to mean that you used a .txt suffix to avoid syntax highlighting, filetype plugins, etc? To answer your question about cindent -- are you sure you're not setting it yourself in your .vimrc? To find out where it was last set: :verbose set cin? There's also autoindent (short form: ai). If that's on, to find out where it was last set: :verbose set ai? Perhaps you can either remove these settings from your .vimrc if that's where they're set or remove any plugins that are setting them. What do you mean by entering your ai modules with the script? Chip Campbell
Re: text is gone
On Thu, 2006-09-07 at 10:19 -0400, Charles E Campbell Jr wrote: scott wrote: ok, so help me out here i've looked at filetype vim, and i see nothing that associates _.txt modules with ft=txt whether i enter my 'ai' modules with the script or by navigating to where they are and, with my bloody fingers typing 'gvim ai_200609.txt', still, inside the module, filetype is undefined are we only supposed to use vim for exotic languages? is 'text' deprecated? i thought it used to suffice to have an extension of .txt now the ground is shifting under my feet... - scott wrote again: excuse me this transcends ridiculous i am editing text, and i have gone around the bend to tell vim that i am doing so to have to create an entire text syntax, where NOTHING HAPPENS, seems against every premise that vim was built on why do i have to be surprised by 'cindent' when i am editing text? it is, after all, text, and i went out of my way to define these modules with the .txt extension, even here in linux -- specifically so he'd know why would cindent kick in if i'm not editing c? now you say *.txt is associated with nothing -- that goes far to explain why my search in filetype.vim for 'txt' was so fruitless, thank you i don't remember having this problem before -- before what exactly i'm not sure -- but i've been surprised with indenting behavior enough to go out of my way to turn every indenting feature off i can find, but still i get surprises now cindent is off, maybe i can still work...tab is easy to hit... forgive me, i have no bottom line -- no idea what i'm saying -- i'll shutup now Yep, nothing associates *.txt modules with ft=txt. That's because there is no syntax/txt.vim highlighting, at least as distributed. What highlighting should be done for a non-specific, arbitrary language? Keywords? Regions? Or did you intend to mean that you used a .txt suffix to avoid syntax highlighting, filetype plugins, etc? To answer your question about cindent -- are you sure you're not setting it yourself in your .vimrc? To find out where it was last set: :verbose set cin? There's also autoindent (short form: ai). If that's on, to find out where it was last set: :verbose set ai? Perhaps you can either remove these settings from your .vimrc if that's where they're set or remove any plugins that are setting them. What do you mean by entering your ai modules with the script? Chip Campbell it is irrelevant to my rant, but i'm glad to share -- it's a simple one line bash executable on my bin path that gets me into the current 'ai' module (think action items): #!/bin/bash gvim -S ~/bin/ai.vim and then ai.vim sets up the name: let s:name = '~/documents/txt/ai_' . strftime(%Y%m) . '.txt' execute e + s:name since i was editing ai_200609.txt having used this process, i felt obliged, in the interest of full disclosure, to mention it in the context of why filetype might not be set my 'ai' modules and vim's autoindent feature are related only in that they share a name for homework i am assigning myself the research of as many flavors of indenting as i can find -- my first objective will be to find out exactly how many options are being set with the command :set filtype plugin indent
Vimdiff Oddity
Hello Vim Developers, To better understand what vimdiff is doing (and why it is so slow), I had my shell (4NT under WinXP) keep a log showing me just what was requested. [Note: I use '!' instead of '' for redirection because my 4NT is set to not overwrite existing files unless explicitly told to do so.] Invoking vimdiff with: gvim -d file1 file2 I can see that the following 3 shell requests are made: diff -a VIo2A3F.tmp VIn2A40.tmp !VId2A41.tmp diff -a --binary VIo2A3F.tmp VIn2A40.tmp !VId2A41.tmp diff -a --binary VIo2A3F.tmp VIn2A40.tmp !VId2A41.tmp The log shows about 4 seconds between commands. I would have thought that the first diff would provide enough information. What is the purpose of the other two? -- Best regards, Bill
Re: screen update problem during periodic file refresh
Yakov Lerner wrote: I see several problems (that I can't explain) in the vim refresh-loop watching the growing file (a-la 'tail -f'). Vim commands are below. Problem #1: There is unexpected output on the bottom line (lines of the file is echoed on the bottom line). Why ? Problem #2: When you vertically resize the xterm window, vim screen is corrupted and never repainted properly. Problem #3: Sometimes, when I press Ctrl-C to quit the loop, vim is in ex mode and responds 'Type :quitEnter to exit Vim' Why ? Problem #4: Since vim repaints properly when waiting for chars, I'd like to put getchartimeout(1000) in place of sleep 1. Do we have getchar() with timeout ? To see the demonstration: 1. In one window, create growing file using these shell command: % while :; do date 1; sleep 1; done 2. In another window: vim -u NONE ~/xxx :set nolz | while 1 | e | redraw | $ | sleep 1 | endw notice unexpected output on the bottom line try to resize screen. It is not restored properly. Press Ctrl-C to quit. Sometimes, vim quits the loop properly. Sometime, vim does not quit the loop, stays in ex mode. (Type :quitEnter to exit Vim) (This command sequence must be not perfect but it demonstrates the problem). I can see the extra output on the bottom line. I'll look into this later. How do you see the problem with the screen resize? -- Vim is like Emacs without all the typing. (John Johann Spetz) /// 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: using hidden unlisted buffer as transparently as possible
Marvin Renich wrote: * Bram Moolenaar [EMAIL PROTECTED] [060906 17:07]: After you do :set nohidden there still is one hidden buffer. Thus the first TestBuf() after that will work a bit different from the next ones. I do see a problem: The info about the current buffer is displayed even though you edited another buffer. Thus the message should be given for the un-hidden file but it's given for the other file, for which a message was already given. I'll fix that. Okay, I did not get all of the steps to reproduce the problem, though I thought I had followed my own steps carefully to verify them after writing them down. :-( Note that somefile.txt already exists and has some text before starting. In my testing since my last message, testbuf.vim already existed except in the very first test, in which I pasted the text and did :w at the step designated in my last message. It seems that after :set hidden, you must :call TestBuf() twice to see what I believe is wrong (or switch to the second buffer and back, followed by :call TestBuf()). The first time, I see two lines of output, followed by the Press ENTER prompt: testbuf.vim 9 lines, 208 characters Done with TestBuf (found = 3) Press ENTER or type command to continue I understand this behavior, and it is TTBOMK correct. The second time, I only see one line (and no Press ENTER prompt): somefile.txt line 1 of 28 --3%-- col 1 The behavior that I believe is incorrect is that I see the output from the exec b curbuf command, but not the output from my echomsg command. The :buffer N command doesn't display the name of the target buffer right away, it's postponed until later (after a possible redraw). You can see the message with :messages. Check the 'shortmess' option, it probably allows overwriting a message. Thus the message for the newly edited buffer overwrites your message. The other behavior that I believe is incorrect is that adding silent in front of _both_ exec b commands still produces the output from the silent exec b curbuf even though it is supposed to be silent; I also do not see the output from my echomsg. I'll fix that. Further note, in this last case using silent, that :messages shows the output from my echomsg _before_ the output from silent exec b curbuf. That's because the file message is postponed until after redrawing. -- WOMAN: King of the who? ARTHUR: The Britons. WOMAN: Who are the Britons? ARTHUR: Well, we all are. we're all Britons and I am your king. The Quest for the Holy Grail (Monty Python) /// 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: screen update problem during periodic file refresh
On 9/7/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Yakov Lerner wrote: I see several problems (that I can't explain) in the vim refresh-loop watching the growing file (a-la 'tail -f'). Vim commands are below. Problem #1: There is unexpected output on the bottom line (lines of the file is echoed on the bottom line). Why ? Problem #2: When you vertically resize the xterm window, vim screen is corrupted and never repainted properly. Problem #3: Sometimes, when I press Ctrl-C to quit the loop, vim is in ex mode and responds 'Type :quitEnter to exit Vim' Why ? Problem #4: Since vim repaints properly when waiting for chars, I'd like to put getchartimeout(1000) in place of sleep 1. Do we have getchar() with timeout ? To see the demonstration: 1. In one window, create growing file using these shell command: % while :; do date 1; sleep 1; done 2. In another window: vim -u NONE ~/xxx :set nolz | while 1 | e | redraw | $ | sleep 1 | endw notice unexpected output on the bottom line try to resize screen. It is not restored properly. Press Ctrl-C to quit. Sometimes, vim quits the loop properly. Sometime, vim does not quit the loop, stays in ex mode. (Type :quitEnter to exit Vim) (This command sequence must be not perfect but it demonstrates the problem). I can see the extra output on the bottom line. I'll look into this later. How do you see the problem with the screen resize? Originally, lines is around 50. Screenshot before resize is http://www.wikiupload.com/download_page.php?id=16428 (before-resize.gif). This is normal screen. Here is how I resize: I resize screen height down to 10. Then I resize height back to approximately original height. Here is screenshot after resize (I also give it several seconds of time, but it never really recovers): http://www.wikiupload.com/download_page.php?id=16429 (after-resize.gif). It's different every time, but always screwed. Yakov
Re: screen update problem during periodic file refresh
On 9/7/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 9/7/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Yakov Lerner wrote: I see several problems (that I can't explain) in the vim refresh-loop watching the growing file (a-la 'tail -f'). Vim commands are below. Problem #1: There is unexpected output on the bottom line (lines of the file is echoed on the bottom line). Why ? Problem #2: When you vertically resize the xterm window, vim screen is corrupted and never repainted properly. Problem #3: Sometimes, when I press Ctrl-C to quit the loop, vim is in ex mode and responds 'Type :quitEnter to exit Vim' Why ? Problem #4: Since vim repaints properly when waiting for chars, I'd like to put getchartimeout(1000) in place of sleep 1. Do we have getchar() with timeout ? To see the demonstration: 1. In one window, create growing file using these shell command: % while :; do date 1; sleep 1; done 2. In another window: vim -u NONE ~/xxx :set nolz | while 1 | e | redraw | $ | sleep 1 | endw notice unexpected output on the bottom line try to resize screen. It is not restored properly. Press Ctrl-C to quit. Sometimes, vim quits the loop properly. Sometime, vim does not quit the loop, stays in ex mode. (Type :quitEnter to exit Vim) (This command sequence must be not perfect but it demonstrates the problem). I can see the extra output on the bottom line. I'll look into this later. How do you see the problem with the screen resize? I am trying now to ':call getchar(0)' near 'sleep 1', and with this addition, screen resizes properly. Like this: :set nolz | while 1 | e | redraw | $ | call getchar(0) | sleep 1 | endw Correction, this should have been getchar(1) not getchar(0). Addition of getchar(1) also handles resizes properly. Yakov
Re: text is gone
scott wrote: [...] for homework i am assigning myself the research of as many flavors of indenting as i can find -- my first objective will be to find out exactly how many options are being set with the command :set filtype plugin indent :filetype plugin indent on (note the difference in command-name and spelling) does the following: 1. Filetype detection is ON: whenever you open an existing file for editing, create a new file, or change a file's name (using e.g. :saveas), Vim sources any filetype.vim scripts in any of the directories mentioned in the 'runtimepath' option to determine the filetype. These scripts always include $VIMRUNTIME/filetype.vim from the distribution; they may include ~/.vim/filetype.vim if you have created it. Near the end of $VIMRUNTIME/filetype.vim there is a line runtime! ftdetect/*.vim to source additional (optional) scripts in e.g. ~/.vim/ftdetect/ 2. Filetype plugins are ON: whenever the 'filetype' is set for a file (usually as a result of step 1), the ftplugin/ subdirectory of 'runtimepath' directories are searched (in the order of the 'runtimepath' option) for a .vim script whose name (before .vim) matches the filetype. All such scripts, if any, are sourced in the order they are found. These scripts are supposed to define buffer-local options and/or buffer-local mappings and abbreviations for files of the given filetype. 3. Filetype indenting is ON: additionally, indent/ subdirectories are searched the same way ftplugin/ subdirectories were searched at step 2. These scripts are supposed to define how text in files of the given filetype must be auto-indented. In addition, if you have used :syntax on, the 'syntax' option is set to (usually) the same value as the filetype; and syntax/ subdirectories of 'runtimepath' directories are searched for .vim scripts matching the syntax name. These scripts are supposed to define the syntax groups for files of the given syntax, and, if they create new syntax group names (which is usually the case), to define default highlight links or default highlight colors for use (if no colorscheme is already saying how these new groups must be displayed) in three kinds of terminal, namely BW text, color text, and GUI. Depending on the filetype and on what the corresponding scripts do, all the above can be very simple (e.g. the c.vim indent plugin merely sets 'cindent' on) or very complex, including invocation of scripts for different filetypes or syntaxes in order to handle special regions of the file: for instance, the vim.vim syntax script (used for vim scripts) invokes perl, ruby, python, tcl and (in Vim 7) scheme syntaxes to handle here-documents; HTML syntax invokes CSS, javascript and VB syntaxes; C++ scripts invoke C scripts (both syntax and ftplugin); and so on. Options can also be set on a file-by-file basis if 'modeline' is TRUE and 'modelines' is nonzero, which are the 'nocompatible' default in Vim. Not every option can be set by modelines, for security reasons. Best regards, Tony.
Re: Vimdiff Oddity
Bill McCarthy wrote: Hello Vim Developers, To better understand what vimdiff is doing (and why it is so slow), I had my shell (4NT under WinXP) keep a log showing me just what was requested. [Note: I use '!' instead of '' for redirection because my 4NT is set to not overwrite existing files unless explicitly told to do so.] Invoking vimdiff with: gvim -d file1 file2 I can see that the following 3 shell requests are made: diff -a VIo2A3F.tmp VIn2A40.tmp !VId2A41.tmp diff -a --binary VIo2A3F.tmp VIn2A40.tmp !VId2A41.tmp diff -a --binary VIo2A3F.tmp VIn2A40.tmp !VId2A41.tmp The log shows about 4 seconds between commands. I would have thought that the first diff would provide enough information. What is the purpose of the other two? Just guessing. As noted in the help (e.g. under :help 'diffexpr'), vimdiff uses ed-style diffs, which (unlike context or unified diffs) are not reversible. It may need those three calls to properly highlight both windows of the vimdiff. The fact that the temporary files' _names_ are the same between calls doesn't prove that their _contents_ are the same. Or you may have a nonstandard diff.exe: the --help for my GNU diff (version 2.8.7) makes no mention of a --binary argument. Best regards, Tony.
