Re: Stable Vim version 7.1 has been released
On Sun 13-May-07 6:01am -0600, Edward L. Fox wrote: I finally committed the two missing files from the sf.net's shell server. Let's blame the Great Fire Wall built by the P.R.C. government. SVN now appears to be working nicely and appears to have the full 7.1 code. Thanks! -- Best regards, Bill
Re: Quickfix window not working anymore
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 ? -- Best regards, Bill
Modelines: First Form
Hello Vim Developers,
The help files specifies (see :help modeline):
-
There are two forms of modelines. The first form:
[text]{white}{vi:|vim:|ex:}[white]{options}
[text] any text or empty
{white} at least one blank character (Space or Tab)
{vi:|vim:|ex:} the string vi:, vim: or ex:
[white] optional white space
{options} a list of option settings, separated with white space or ':',
where each part between ':' is the argument for a :set
command
-
Yet most of the distributed help files fail to follow this
format (and are note second form).
Most end with a ':' which does not appear to be permitted
above.
Others start with 'vim:' without the mandatory white space
preceding it.
Perhaps the docs should mention that {white} is optional if
[text] is empty - if that is true. And a trailing ':' is
permitted.
Also, for the second form, the same comment applies to its
{white}. It should also be mentioned that the mandatory ':'
is preceded by [white] (optional white space).
--
Best regards,
Bill
Re: Modelines: First Form
On Wed 14-Feb-07 1:30am -0600, A.J.Mechelynck wrote: Bill McCarthy wrote: Most end with a ':' which does not appear to be permitted above. It is. It just adds an empty do-nothing setting at the end. Thanks, Tony, I didn't consider the do-nothing setting and didn't read the exception at the bottom for vim: and vi: appearing at the start of the line. -- Best regards, Bill
Re: 7.0.188 - problem with directory browser?
On Fri 26-Jan-07 10:46pm -0600, Denis Perelyubskiy wrote: in version 7.0.188 (I am on windows xp, us) nothing works when I select '..' when browsing a directory. has anyone seen this? is this something peculiar to my installation, a bug, or a feature? I reported this problem to Chip on 1/9. He responded with a fixed version (108c) on 1/10. It works fine here. Do you have an older version? You will need to go to Dr Chip's Vim Page for the current one: http://mysite.verizon.net/astronaut/vim/index.html -- Best regards, Bill
Re: 7.0.188 - problem with directory browser?
Denis, On Sat 27-Jan-07 1:26am -0600, Bill McCarthy wrote: On Fri 26-Jan-07 10:46pm -0600, Denis Perelyubskiy wrote: in version 7.0.188 (I am on windows xp, us) nothing works when I select '..' when browsing a directory. has anyone seen this? is this something peculiar to my installation, a bug, or a feature? I reported this problem to Chip on 1/9. He responded with a fixed version (108c) on 1/10. It works fine here. Do you have an older version? You will need to go to Dr Chip's Vim Page for the current one: http://mysite.verizon.net/astronaut/vim/index.html That site contains an older version. I've copied Chip on this note. Hopefully he will update his site (unless other problems were discovered with that fix). -- Best regards, Bill
GNUPG.VIM
Hello Markus, Thanks for updating your plugin. It's working fine here on Windows XP, except for one cosmetic problem. Most of my text files have DOS EOLs (CR/LF). When the file is decrypted, all lines end with ^M. If I save the file, all lines end with CR/CR/LF - the only difference from simply decrypting with GNUPG. This can easily be fixed by the user with :%s/^M where all references ^M are the graphic representation of a CR. Another minor cosmetic, perhaps beyond your control, is that the shell window - that asks for the passphrase - comes up behind Gvim. -- Best regards, Bill
^ vs 0 vs Home vs |
Hello Vim Developers,
Here's what the docs say:
===
*^*
^ To the first non-blank character of the line.
|exclusive| motion.
*0*
0 To the first character of the line. |exclusive|
motion. When moving up or down, stay in same screen
column (if possible).
*Home* *kHome*
Home To the first character of the line. |exclusive|
motion. When moving up or down, stay in same text
column (if possible). Works like 1|, which differs
from 0 when the line starts with a Tab. {not in
Vi}
*bar*
| To screen column [count] in the current line.
|exclusive| motion.
===
(1) The sentence starting with When moving (in the help
for both '0' and 'Home' appears to also belong with
the help for '^'.
(2) The sentence starting with Works like (in the help for
'Home') does not appear to be correct. 'Home'
appears to work like '0'. The movement is just like
'1|' (which is equivalent to '|') except for the
behavior of moving up or down.
(3) '0' and 'Home' appear to be identical. Does anyone
see a difference?
--
Best regards,
Bill
Re: ^ vs 0 vs Home vs |
On Wed 6-Dec-06 6:24pm -0600, A.J.Mechelynck wrote: Bill McCarthy wrote: (3) '0' and 'Home' appear to be identical. Does anyone see a difference? (3) Yes I do. Notice the one mentions the same _text_ column and the other the same _screen_ column. Hit 0 on a line starting with a hard tab, then j : Vim will try to keep the cursor in column 8 (except, of course, on lines shorter than 1 tab or 8 other characters). After Home or 1| it would try to keep the cursor in column 1 (if possible: when the first character on a line is a hard tab the cursor will move temporarily to column 8). Thanks Tony, that clears it up nicely. Somehow I just wasn't seeing the difference - I certainly see it now! -- Best regards, Bill
Re: Patching Issue
On Tue 21-Nov-06 7:38pm -0600, Liu Yubao wrote: == pad pv 168 patching file src/memline.c Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 339 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. I suggest you use CVS or SVN. I actually run both. The shell command 'cv sv' write their results to separate output files and open (or remote to) a vim session in separate tabs. This is handy if one of them is down for a while and a patch doesn't work - generally that happens only when patches include runtime files which are automatically updated from the vim FTP site. I like the email updates. A keystroke from my email client remotes a tab to vim with the patch almost ready to go (I have to verify changes at times, with it executes: :%s#runtime/#//gc But this lets my read Bram's notes in Gvim with syntax highlighting of the diff. You don't get that in CVS (although you do get a very nice summary of Bram's notes in the SVN log (for any sequential set of patches you want - very nice). The purpose of my email was simply warn Windows uses that the GnuWin32 patch program chokes on UNIX patches to DOS source code. The solution is trivial. My alias to patch the next version looks like this: pv 169 Inside the script is: u2d 7.0.169 patch -b -p 0 -i 7.0.169 where u2d translates UNIX to DOS in place and does no harm to DOS files. -- Best regards, Bill
Re: buffer list count
On Mon 13-Nov-06 7:54pm -0600, Eggum, DavidX S wrote:
Okay, try this, Matt (it is, again, lightly tested). Granted, it
recalculates from scratch every time, but it only does it when it needs
to and it should still be pretty fast. It also doesn't rely on the
events to be called once every time a buffer is added or deleted. HTH.
set rulerformat=%60(%=%{GetBufCount()}%)
autocmd VimEnter,BufAdd,BufDelete * call UpdateBufCount()
let s:prev_last = 0
let s:prev_count = 0
function! UpdateBufCount()
let lst = range(1, bufnr('$'))
call filter(lst, 'buflisted(v:val)')
let s:prev_count = len(lst)
endfunction
function! GetBufCount()
return s:prev_count
endfunction
Using filter() speeds things up quite a bit - very nice.
Testing with 78 buffers and running 1,000 times (and
dividing the resulting time by 1,000):
Using for loop: 3.5 ms
Using filter(): .55 ms
On one line: .50 ms
Using a global variable, instead of global functions, and
using a one liner:
let bcnt = 0
function! s:CntBufListed()
let g:bcnt = len(filter(range(1, bufnr('$')), 'buflisted(v:val)'))
endfunction
autocmd VimEnter,BufAdd,BufDelete * call SIDCntBufListed()
Then the %{GetBufCount()} can be replaced by %{bcnt}
Although the function works fine, it still doesn't get
triggered when it should. For example, given two files foo
and bar in the current directory (listed buffer counts are
from my statusline):
gvim foo 1 listed buffer
:sp bar 2 listed buffers
:bd 2 listed buffers :-(
:doau BufDelete 1 listed buffer
--
Best regards,
Bill
Re: buffer list count
On Sun 12-Nov-06 7:54pm -0600, [EMAIL PROTECTED] wrote: Well I'm reporting the above g:zbuflistcount in my 'rulerformat'. Don't you think you should have mentioned that? I really don't think I can afford the baggage of calling your function from within my 'rulerformat'. No, for 100 buffers, my function would take nearly 4 ms on a 800 Mhz PC. You could upgrade the function to capture, for example, the number of existing, loaded, listed and wiped buffers. Then write is simple map to give yourself a little report whenever you want it. Or your map could also set a global variable to update your ruler or statusline. -- Best regards, Bill
Re: gVim 7 Win32 Maximize bug report
On Thu 2-Nov-06 5:11am -0600, [EMAIL PROTECTED] wrote: I'm pretty new to this mailing list and I hope I'm posting at the right place. I just want to report a simple bug, easy to reproduce. I have only tested it on Windows. Open vim, write a single 1 characters line (filled with blanks for example), and just maximize the window. On my PC, I get the following error: Vi Improved - A Text Editor has encountered a problem and needs to close. We are sorry blabla... The details are: AppName: gvim.exe AppVer: 7.0.262.0 ModName: gvim.exe ModVer: 7.0.262.0 Offset: 0012c053 Is the problem reproducible on your configurations? Running Gvim 7.0.158 on Win XP, I get no crash for 10,000+ character lines. I do get some unusual behavior. With set fileformats=dos,unix,mac I see a ^J as the first character of lines 2 through n+1 (for an n-line file) and my 'fileformat' is set to mac. [That would be expected behavior for reading a dos file as a mac file, since the CR of dos's CR/LF would end the line and LF (0x0A) would render as ^J.] It rendered OK when I changes 'ffs' to dos,unix - IIRC, Bram once mentioned that file format detection was a bit weak on long lines. BTW, I also see that Windows Explorer reports Gvim is at version 7.0.262.0. Its copyright is for 1996-2005, its trademark is Vim and the original file name is VIM.EXE? -- Best regards, Bill
Re: svn updates
On Wed 18-Oct-06 4:13pm -0600, Mark Guzman wrote: I hate to report problems w/o having solutions, but the svn repos is currently only up to patch 132. I'm wondering if whatever update script was maintaining it is broken... Hopefully someone with access can take a look at it. That's updated by Edward Fox. The last update was Friday (13-Oct). He's probably away. You can also use CVS or get the patches here or at: ftp.vim.org/pub/vim/patches/7.0 Also, simple one-line shell scripts have been posted to update your runtime files from 'nix or Windows (4nt). -- Best regards, Bill
Re: svn vs rsync vs ftp
On Tue 17-Oct-06 4:04pm -0600, Yakov Lerner wrote: Of different current methods to access vim sources (svn, ftp, rsync, etc) which one is fastest to be updated when new patch is issued, and also has most reliable/fast server ? I wasn't aware that sources were on FTP. Where are they? Patches are available on FTP and patched sources are available on CVS, frequently before the emailed patches are received. SVN patched files appear a little later. FTP and CVS are currently at patch level 145. SVN is at 132. Speed is more important getting updates to the runtime. It currently takes about a minute to check the runtime/dos tree for updates (and not download anything). I get them at ftp.home.vim.org - if you know of a faster site, I would like to know. -- Best regards, Bill
Re: Vim 7.0 (1-109 patches) completion bug.
This was a response to a personal mail from Igor, but I am unable to reach his address by mail. I got my message back with: [EMAIL PROTECTED]: 80.91.16.141 does not like recipient. Remote host said: 553 5.7.1 smtp106.sbc.mail.mud.yahoo.com[68.142.198.205]: Client host rejected: Big domain level Giving up on 80.91.16.141. This continues the conversion with the same subject. There does appear to be a bug. Please read on. On Sun 8-Oct-06 10:42pm -0600, Igor Prischepoff wrote: Hello, Bill. Can you try _one more last time_ please ? gvim - whatever you prefer for clean vim without preferences set cot+=longest set cot-=menuone set complete-=t After starting with: gvim -u NONE -i NONE -N I typed: :se cot+=longest cpt-=t cot cpt Gvim outputs: completeopt=menu,preview,longest complete=w,b,u,i which is hopefully the same state you get. i one : word two : word oC-N:tC-N On the first C-N, 'o' is expanded to 'one', however I get a message Back at original. That is wrong. The original is 'o' not 'one'. Gvim appears confused. Typing any non- whitespace printable characters continues its confusion and another C-N, after typing one or more of these characters, does nothing. After the 'one' is completed from the first C-N, a second C-N changes the message to The only match. Now you can continue typing - the completion text in the command area will be cleared and C-N will work on 't' (but you'll be in the same wrong state of completion with the incorrect message of Back at original. BTW, a C-Y is supposed to tell Gvim you are done with completion. It behaves strangely here. After the C-N completes the 'o' to 'one', a C-Y indeed ends the completion but I am not left with 'one', I am left with 'ow'! what I've got is one : word two : word one:t and message Back at original Please note that when you type C-N first time (after 'o') you should get 'one' expanded automatically because it's only match in this case. And when type C-N after 't' you should get nothing (that's a bug I think). In both cases you should get NO MENU. (because of longest and no menuone in completeoption) I get no menu because there is no menuone, not because of longest. Don't you also see the problem begins with the first C-N after the 'o'? If you got other result's can you please send you :ver output? mine is : vi Improved 7.0 Included patches:1-118 Here the output of :version VIM - Vi IMproved 7.0 (2006 May 7, compiled Oct 8 2006 13:02:44) MS-Windows 32 bit GUI version with OLE support Included patches: 1-121 Compiled by Bill McCarthy [EMAIL PROTECTED] Big version with GUI. Features included (+) or not (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang +mzscheme/dyn +netbeans_intg +ole -osfiletype +path_extra -perl -postscript +printer -profile +python/dyn +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl -tgetent -termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim -xterm_save -xpm_w32 system vimrc file: $VIM\vimrc user vimrc file: $HOME\_vimrc 2nd user vimrc file: $VIM\_vimrc user exrc file: $HOME\_exrc 2nd user exrc file: $VIM\_exrc system gvimrc file: $VIM\gvimrc user gvimrc file: $HOME\_gvimrc 2nd user gvimrc file: $VIM\_gvimrc system menu file: $VIMRUNTIME\menu.vim Compilation: gcc -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=pentium3 -Wall -Ic:/util/MzScheme/include -DFEAT_MZSCHEME -DMZSCHEME_COLLECTS=c:/util/MzScheme/collects -DDYNAMIC_MZSCHEME -DDYNAMIC_MZSCH_DLL=libmzsch209_000.dll -DDYNAMIC_MZGC_DLL=libmzgc209_000.dll -DFEAT_PYTHON -I c:/util/python24/include -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=python24.dll -O3 -fomit-frame-pointer -freg-struct-return -s Linking: gcc -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=pentium3 -Wall -Ic:/util/MzScheme/include -DFEAT_MZSCHEME -DMZSCHEME_COLLECTS=c:/util/MzScheme/collects -DDYNAMIC_MZSCHEME -DDYNAMIC_MZSCH_DLL
Re: New Versions of 4nt and tcmd
On Sun 8-Oct-06 7:29pm -0600, Bill McCarthy wrote: New versions of 4nt and tcmd were recently loaded to the FTP site. These are still called 8.00.49. What is the difference? Sorry, I sent that to the wrong email address. -- Best regards, Bill
Re: Q: rsync://ftp.vim.org/Vim/runtime/ - when?
On Sun 8-Oct-06 7:39pm -0600, A.J.Mechelynck wrote:
Bill McCarthy wrote:
On Sun 8-Oct-06 5:42pm -0600, Alexey I. Froloff wrote:
When current version of vim runtime will be updated for latest
patches? Patch 111 modifies autoload/gzip.vim and doc/eval.txt
which are still outdated on ftp...
The gzip.vim is clearly old, but comparing (vimdiff) the
eval.txt on the FTP site to the patch version on CVS, they
both share the same internal date of 22-Sep-2006 yet the one
on the FTP site looks newer.
I generally find it easier to ignore the patches to runtime
files and, instead, rely on the FTP site for those. They
are usually updated fairly quickly.
After checking, the new versions of the files mentioned in patch 111 agree
with the latest versions I downloaded from the rsync server, except that the
gzip.vim lacks the new datestamp (the rest of the file is OK though.)
After deleting gzip.vim and performing a copy update from
the ftp site, the gzip.vim downloaded is older. It will not
use the new shellescape function. It has this logic:
if v:version 700 || (v:version == 700 has('patch999'))
return shellescape(a:name)
endif
The patched version on the CVS, has the same code but the
has() has:
has('patch111'))
so it will use the new function.
--
Best regards,
Bill
Re: Vim 7.0 (1-109 patches) completion bug.
On Fri 6-Oct-06 12:25am -0600, Igor Prischepoff wrote: Well, i still don't understand vim logic behind that process. Let's see more realistic example. gvim -U NONE -u NONE Only last time, although I don't think it matters in this example, you are working in 'cp' mode. Many of vim/gvim features will not work in that mode. (Also, the -U NONE is redundant. See ':h -u' second paragraph for why you don't need -U and the side effect of setting 'cp') Let's suppose that I am a poor pascal programmer and typing code like this: :set completeopt+=longest :set complete-=t i var one : byte; two : byte; two_and_three : byte; three : byte; // may be this is a word? one:=three; // or next one is a a word? one:=two_and_three; oC-N:=tC-n // completion in second C-N still not working here... // so there is no word? not 'one:=t*' or 't*' words in buffer? // I still thinks it should be considered as a bug. What action did you take on the first C-N? Since 'o' is the longest common, no addition completion is done. If you just want the 'o' type C-Y, if you want 'one' type C-N, or if you want 'or' type C-P. Why C-Y? See ':h complete_CTRL-Y' Now type ':=tC-N'. What do you mean by still not working? I see (since I picked 'one' for the first completion): one:=t two two_and_three three this Nothing was added to the 't' because it's the longest common. If I now want 'this;' I would type 'C-P;'. My complete keystrokes from insert mode at the beginning of that line are: oC-NC-N:=tC-NC-P;Esc and my line reads: one:=this; and my cursor would be on the ';'. -- Best regards, Bill
Re: vim -u NONE
On Fri 6-Oct-06 12:15am -0600, Gary Johnson wrote: I also found this under :help gui-init: To skip loading the system menu include 'M' in 'guioptions'. So to avoid loading _anything_, at the expense of not having any menus, one could start gvim as gvim -N -u NONE -i NONE --cmd 'set go+=M' Since I use Gvim with no menu - much better syntax highlighting than Vim - my vimrc has set guioptions=M which speeds up loading a bit. I also have a toggle in gvimrc which, upon being toggled for the first time, includes: source $vimruntime\menu.vim However, when I'm running Gvim to be as virgin as possible, I keep the menu. My actual aliases do the following (revised after wading through all the existing startup docs and experimenting with -V a few weekends ago): gvim.exe -u NONE -i NONE -N --cmd se rtp=$VIMRUNTIME +so $vim\_minrc and vim.exe -u NONE -i NONE -N +so $vim\_minrc where _minrc does some simple things like shut off bells and screen flashing, gives me my normal 'rtp' and 'stl', and sets 'gfn' (if has(GUI)) for normal and vimdiff. -- Best regards, Bill
Re: vim -u NONE
On Fri 6-Oct-06 12:38pm -0600, Yakov Lerner wrote: On 10/6/06, Bill McCarthy [EMAIL PROTECTED] wrote: On Thu 5-Oct-06 8:54pm -0600, Gary Johnson wrote: gvim -u NONE -i NONE -N Setting -u NONE -i NONE -N is all that's needed. See :help -u. I never noticed that 'vim -u NONE' ever read the .viminfo ? It doesn't, you're in 'cp' mode and 'viminfo' is empty. For example, if I set 'set nocp' in 'vim -u NONE' then I don't see any command history that I'd see had .viminfo been read in. That's the problem. As soon as you change to 'nocp' mode, 'viminfo' is populated. When you close, the viminfo file is overwritten. Do you see any difference between 'vim -u NONE' and 'vi -u NONE -i' ? (Assuming the second is 'vim -u NONE -i NONE'.) Both come up in compatibility mode. If that is changed to 'nocp' during the session, the chance of overwriting an existing viminfo file is greatly reduced by the second approach. -- Best regards, Bill
Re: Vim 7.0 (1-109 patches) completion bug.
On Wed 4-Oct-06 10:16pm -0600, Igor Prischepoff wrote: Hi, i think i have found a bug in vim 7.0 Patch level 1-109. Windows version +perl +python (i don't think this matters in this case) here is how to reproduce: gvim -u NONE -U NONE :set complete-=tdon't want complete from tags file - it's not important, just to switch off message :set complete+=longest that's important i now we in insert mode one two oC-N:tC-Nnow trying to complete second time - no completion, nothing i.e. i've got resulting text in buffer like this: one two one:t and no 'two' on second C-N when trying to complete 'two' and message Back at original (First completion works as expected, but second didn't shown and not complete at all) if remove 'longest' from 'complete' then everything works as expected. Can you reproduce that bug? Or it's intended behaviour? I see two issues. The first is independent of adding longest to 'completeopt'. Whenever you get Back at original in the command window, typing additional non-whitespace characters keeps you in a complete mode until you either use whitespace or backspace to the original. I don't see this behavior documented. The second, using :se cot+=longest causes Vim to complete to the longest common text among the matches (starting from the beginning) and completes the typing to that point. Yet it calls this partial completion Back at original even though it clearly is not the original - so you are back to the first issue. BTW, using gvim -u NONE -U NONE is both redundant (in the case of -U NONE), dangerous (since default settings may truncate your viminfo on exit), and put you in vi compatible mode. Better is: gvim -u NONE -i NONE -N An even better approach to getting a more virgin Vim is: gvim.exe -u NONE -i NONE -N --cmd se rtp=$VIMRUNTIME +se rtp That stops making access to personal rtp paths for starting up, and restores the default rtp at the end of startup. -- Best regards, Bill
Re: vim -u NONE
On Thu 5-Oct-06 8:54pm -0600, Gary Johnson wrote:
On 2006-10-06, Peter Hodge [EMAIL PROTECTED] wrote:
BTW, using
gvim -u NONE -U NONE
is both redundant (in the case of -U NONE), dangerous (since
default settings may truncate your viminfo on exit), and put
you in vi compatible mode. Better is:
gvim -u NONE -i NONE -N
I wouldn't think the -i option is necessary, because 'viminfo' is
empty by default anyway. Perhaps there should be a shell script
distributed with vim so that anyone can start up vim cleanly.
cleanvim.sh:
vim -u NONE -i NONE -N --noplugin --cmd 'set rtp=$VIMRUNTIME' '+set rtp'
cleanvim.bat:
gvim.exe -u NONE -i NONE -N --noplugin --cmd set rtp=$VIMRUNTIME +set
rtp
Setting -u NONE -i NONE -N is all that's needed. See :help -u.
When {vimrc} is equal to NONE (all uppercase), all
initializations from files and environment variables are
skipped, including reading the |gvimrc| file when the GUI
starts. Loading plugins is also skipped.
The viminfo file may be empty initially, but it probably is not once
vim has been run.
Gary, the reason I use and suggested
--cmd se rtp=$VIMRUNTIME
is to prevent customizations such as adding all of your
colorschemes, compilers, etc. in the Gvim menus, custom
icons, etc. --cmd happens before menu.vim is sourced.
The reason I use:
+se rtp
is to have 'rtp' set as by default but without the side
effects mentioned above.
:h startup
For fun start with the above but without the --cmd above
but add -V99nocmd. Then include the --cmd above and with
-V99wcmd. Finally do a vimdiff on nocmd and wcmd.
--
Best regards,
Bill
Re: Patch 7.0.106
On Thu 14-Sep-06 6:35am -0600, Bram Moolenaar wrote: Patch 7.0.106 I encountered a problem that has appeared before patching files in runtime. I received the following from my patch invocation: patching file `menu.vim' Hunk #1 FAILED at 2. Hunk #2 FAILED at 885. Hunk #3 succeeded at 912 (offset 2 lines). Hunk #4 FAILED at 942. Hunk #5 FAILED at 1019. 4 out of 5 hunks FAILED -- saving rejects to menu.vim.rej patching file `src/version.c' I regularly update my local copy of vim with the following copy update command (4nt under WinXP): copy /u /s ftp://ftp.home.vim.org/pub/vim/runtime/dos/*; c:\vim\vim70\ I suspect your patches assume that users do not update their runtime files. Is this what's happening? -- Best regards, Bill
Re: Binary, Octal, Decimal, Hex!
On Mon 11-Sep-06 3:02am -0600, Nikolai Weibull wrote: This stream of thought mode you're using is more suited for IRC, see http://www.vim.org/community.php. Alternately, the vim list is a good choice. And never add return receipt requests in posts to a mailing list. -- Best regards, Bill
Re: Vimdiff Oddity
On Fri 8-Sep-06 4:11pm -0600, Bram Moolenaar wrote: Bill McCarthy wrote: 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? Vim first tests to see if executing diff works, with the -a and --binary arguments. Finally it does the actual diff. This should take a fraction of a second. 4 seconds indicates that there is something wrong in your setup. Perhaps caused by 4NT. Try using another shell. Thank you for your comments. I had added using Windows volatile environment variables supported by 4nt. The author (Rex Conn of JPSoft) simply uses an API call to implement these. They are deadly slow and account for nearly all of the time delay. 4nt, without that baggage, is still a fraction of a second slower that cmd (which itself is about the same startup speed of sh or zsh). I am curious about the necessity of those 3 shell calls to do a diff - maybe I'll spend a little time with diff.c next weekend :-) -- Best regards, Bill
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: Help non-functional in 7.0.90
On Wed 6-Sep-06 8:01am -0600, 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] Both work fine for (g)vim on WinXP from both my normal starting or from a pristine start (see below): vim -u NONE -i NONE -N --cmd se rtp=$VIMRUNTIME -- Best regards, Bill
Re: Unwanted leading spaces in reltimestr()
On Sat 19-Aug-06 3:13pm -0600, Yegappan Lakshmanan wrote:
On 8/10/06, Bill McCarthy [EMAIL PROTECTED] wrote:
The function reltimestr() return a string which may have
leading spaces. Is that a bug or a feature?
The string returned by reltimestr() has leading spaces, because
the following code is internally used to generate this string (on
non MS-Windows systems):
sprintf(buf, %3ld.%06ld, (long)tm-tv_sec, (long)tm-tv_usec);
On MS-Windows, the following code is used:
sprintf(buf, %10.6lf, (double)tm-QuadPart / (double)fr.QuadPart);
A workaround for this is:
function Reltimestr(t)
return matchstr(reltimestr(a:t),'[0-9.]\+')
endfunction
That code, from profile_msg() in ex_cmds2.c is also used in
several other functions to produce formatted text. However,
the function f_reltimestr() is only used to perform for the
end user.
IMO the docs should disclose that the string returned has a
minimum field width of 10 characters padded on the left with
blanks OR any leading blanks should be stripped by the
function.
I prefer the latter. A patch is attached.
(However, since I don't think this list accepts attachments,
I have included this small patch as text below my sig and
copying the vim-dev list - beware of email client tab
handling.)
--
Best regards,
Bill
*** eval.7.0.063.c Wed Aug 16 15:21:55 2006
--- eval.c Sat Aug 19 20:10:45 2006
***
*** 13001,13007
--- 13001,13011
rettv-vval.v_string = NULL;
#ifdef FEAT_RELTIME
if (list2proftime(argvars[0], tm) == OK)
+ {
rettv-vval.v_string = vim_strsave((char_u *)profile_msg(tm));
+ while (rettv-vval.v_string[0] == ' ')
+ rettv-vval.v_string++;
+ }
#endif
}
eval.c.diff
Description: Binary data
Re: Vim updates
On Sun 13-Aug-06 7:41pm -0600, Steve Hall wrote: A normal full install should have all or nearly all these (at least my install here on Fedora Core 5 does): vim70/autoload/ colors/ compiler/ doc/ ftplugin/ icons/ indent/ keymap/ lang/ macros/ plugin/ print/ spell/ syntax/ tools/ tutor/ This is fairly close to what installs on a Win system. We don't have icon/ but do have nsis/ and src/. Also the print/ directory isn't standard with a Win installation - it tagged along when I updated my runtime files with runtime/dos on the FTP site. I see bitmaps/ is not included there also. Gvim, at startup, checks for 20 separate .bmp files for each directory in 'rtp'. Not a startup speed enhancement. Is there a way to shut this bitmaps searching off? -- Best regards, Bill
Re: Bug in :runtime ?
On Wed 26-Jul-06 1:20pm -0600, A.J.Mechelynck wrote: Morality: Whenever possible, use / as path separator in Vim, even on Windows. There are a few exceptions (where they don't work). IMHO too many. One common example is passing a file to a program within Vim - the '/' appears to be treated like a switch in many windows programs. -- Best regards, Bill
Bug in :runtime ?
Hello Vim Developers, I was timing the startup process by stepping though what I think Gvim does (on Win XP Pro with 7.0.42). gvim -u NONE -N That starts up without _vimrc or _gvimrc or plugins and sets nocp. :so $vim\_vimrc worked fine. :so $vim\_gvimrc also worked fine. :ru! plugin\**\*.vim didn't seem to do anything. Repeating the above as :verb ru! plugin\**\*.vim reports: not found in 'runtimepath': plugin\**\*.vim Hmm, when I tried again with the unixy :ru! plugin/**/*.vim the plugins were finally sourced. Bug? -- Best regards, Bill
Re: using hidden unlisted buffer as transparently as possible
On Sun 23-Jul-06 7:09pm -0600, Marvin Renich wrote: At this point, I see the output from exec b curbuf but using :messages I can see that the echomsg did indeed display (before the output from :b). I also tried redraw between the :b and the :echomsg. I don't have an answer for you but I can commiserate :-) I was working on the same kind of problem using a temp buffer (bt=nofile) for a work area. The script worked fine except that the output was getting overwritten as if Vim had issued :file at the end. A work around was to echo an extra blank line and let Vim overwrite it. I tried all the things you mentioned - I was quite surprised that :redraw didn't solve it. I finally changed my method slightly by switching windows instead of switching buffers directly. The echo problem went away. I will be following this thread for solutions. -- Best regards, Bill
Re: SVN and svn:eol-style
On Thu 11-May-06 2:03am -0600, you wrote: Bill McCarthy wrote: When I checkout vim7 with svn under WinXP Pro, my text files are all coming out as UNIX files (using LF instead of CR/LF). The svn program is designed to handle proper EOL for an operating system when a property called svn:eol-stype is set to native. Am I supposed to do anything special to cause svn to give my text files to be stored as standard CR/LF files? Why do you want CR-LF files? A single LF should work just fine. The svn docs explain this quite well. Some programs fail to properly deal with LF only. A good example is Microsoft notepad.exe. In the context of Vim I don't think we should worry about notepad users. Probably not, but there are other utility programs that also fail on LF files. As Mike wrote, the diff utility was one of these - I haven't checked the new diff.exe that was distributed with Windows Vim. Automatic LF to CR-LF translation always causes trouble somewhere. I have never had a problem with CVS doing this. I believe the trick is to only mark 'native' those files which are indeed text files. Right. So what if files aren't properly marked as text or binary? And there always is a mistake somewhere (I recall there was an icon file that was broken for a year before someone discovered it should be marked binary). I've seen too many files with mixed line endings, this can be a real mess. Especially Unix files that were edited in Visual studio. Also remember that files on a USB stick will never adjust to the computer you plug it into. Systems must be able to deal with both LF and CR-LF. There is only one solution eventually: Drop those CR-LF line separators. It just takes a bit of time before all MS-Windows programs can deal with them. One big step forward is to (1) use the LF format in the Window distribution and (2) use the same file structure for Windows and UNIX. -- Best regards, Bill
Re: Patch 7.0.006
On Wed 10-May-06 10:27am -0600, Bram Moolenaar wrote: Patch 7.0.006 Problem:Mac: make shadow doesn't make a link for infplist.xml. (Axel Kielhorn) Solution: Make the link. Files: src/Makefile From WinXP, I installed with the big exe file and unzipped the src and lang files. There is no src\Makefile. What did I miss? -- Best regards, Bill
Re: SVN and svn:eol-style
On Wed 10-May-06 9:43pm -0600, Anduin Withers wrote: Why do you want CR-LF files? A single LF should work just fine. The only place where I know it doesn't work is when you read Make_ivc.mak into Visual Studio. Automatic LF to CR-LF translation always causes trouble somewhere. CVS did it automatically, as long as binaries are properly tagged there shouldn't be (and wasn't, at least for me) a problem. One reason is consistency: This is the behavior CVS had, it is the format the releases are in on the ftp site, it also makes things look better when I edit my .vim files with notepad. Just another request for native line endings. Some days it is better for me to read my mail from newest to oldest - or at least read through everything before replying. Well stated. I now wish I used a different example that notepad - although that is indeed a good one, since every Windows user has it and it is frequently a default in Explorer. Hopefully, the gentleman maintaining the svn repository (Edward L Fox) will talk to the gentleman who properly marked the files in CVS. I have also had no problems with the CVS distribution -- Best regards, Bill
Re: Vim 7 pre-announcement
On Sun 7-May-06 10:58am -0600, Bram Moolenaar wrote: Vim 7 is out! Congratulations! I looked at the release area and noticed that the vim70 tree for Windows is still different from what is available by CVS or SVN. This remains a minor inconvenience for Windows users - either we use CVS (or SVN with its unix text files) and copy over to a separate Windows tree OR we use patch files that we need to modify to get rid of the runtime/ stuff where appropriate. Please consider putting these trees in sync in some future release. -- Best regards, Bill
Re: Install Fails on Windows
On Sat 29-Apr-06 3:49pm -0600, Bram Moolenaar wrote: There are two setups, the Unix one and the MS-Windows one. If you use the Unix setup you need to do make install. Thus uses the files in the ../runtime directory that were unpacked from the Unix tar archive. If you use the MS-Windows setup you should unpack the vim70xxrt.zip file, which puts the runtime files below the src directory, without a runtime directory. Then you can use the install.exe. The problem with this is that there is only one current beta and that is the the unix form of the Vim tree. Even if I copy my executables to runtime\, install complains with: [c:\vim\vim70f\runtime]install This program sets up the installation of Vim 7.0f BETA ERROR: Install program not in directory vim70f This program can only work when it is located in its original directory The solutions provided by Suresh Govindachar and Georg Dahn both appear to work, but involve copying the contents of runtime\ on top of vim70.f\ (which should produce some pretty ugly results when CVS is back again :-) I was hoping there was a simple way of enabling dosinst.c to work with the unix tree. Since Alpha and Beta versions have worked just fine without installing, and there are no patches to apply to the older vim7 files that are are available, I'll just not install until the release and subsequent patch releases. Thanks to Suresh, Georg and you for your comments. -- Best regards, Bill
Install Fails on Windows
Hello Vim Developers, Compiling with MVC or Ming, the exe files are copied from c:\vim\vim70f\src to c:\vim\vim70f (the usual place). But running install produces the following: [c:\vim\vim70f]install This program sets up the installation of Vim 7.0f04 BETA ERROR: Cannot find filetype.vim in C:\vim\vim70f It looks like you did not unpack the runtime archive. You must unpack the runtime archive vim70frt.zip before installing. The problem is that unzipping the archive places filetype.vim in c:\vim\vim70f\runtime (it would have been placed in the same directory as the exe files in all release versions of Vim - in this case in c:\vim\vim70f\). Doesn't dosinst.c need to reflect this new placement? -- Best regards, Bill
