Documentation bug about matchparen
*pi_paren.txt* For Vim version 7.0. Last change: 2006 Apr 24 line 46 (i.e. 5th from bottom) there is 'synmaxcolumn' there should be 'synmaxcol' Best regards, Tony.
Re: incorrect behavior of gzip.vim plugin?
Charles E Campbell Jr wrote: [...] The problem here is :so % doesn't source the buffer, it sources the underlying file. Thus the file must needs be gunzip'ed first. Vimball could be set up not to gunzip the file, but then sourcing it would fail. Regards, Chip Campbell Looking at the vimball plugin, I notice it always unpacks into directories of the first (existing) directory in 'runtimepath'. That is, into ~/.vim/something or ~/vimfiles/something if they exist. The description (at vim-online) of the netrw plugin also recommends to remove the version under $VIMRUNTIME. This has two consequences: - It is not possible to install a vimball (such as a new version of the netrw plugin) system-wide under $VIM/vimfiles unless ~/.vim or ~/vimfiles does not exist. - If the recommendations at vim-online are followed, the netrw functionality (including local directory browsing) will be made unavailable to all users except the one who installed the new version. The above may be intentional but I believe it is a severe drawback. It is admittedly documented under ":help :Mkvimball" but not under "install details" at http://vim.sourceforge.net/scripts/script.php?script_id=1075 (where "your .vim/ or vimfiles\ directory" can be construed as including $VIM/vimfiles); and searching that HTML page for "vimball" gives a null result so anyone not already knowing about vimballs won't be drawn to the pi_vimball.txt helpfile. Suggestion 1: I suggest to add optional additional parameters to the vimball commands: :MkVimball filename [path] :UseVimball [filename] [path] Maybe even (but perhaps less iimportant) :MkVimball filename [path] [EMAIL PROTECTED] where "filelist" is a file containing one filename per line, relative to [path] or, by default, to the first existing directory in 'runtimepath'. As a further refinement (I'm "thinking aloud" here) maybe the result of applying :redir to UseVimball/VimballList could be acceptable too. This would allow: 1) creating a vimball from files located elsewhere than in "the first existing directory in 'runtimepath'". The following possible locations come to mind: $VIM/vimfiles (the system-wide non-distribution tree in 'vimruntime') ~/.build/vim/vim70 (a directory tree used to build vim but not necessarily for execution on this machine) /home/myusername/.vim (a Vim directory tree for a different user, e.g. when done from an admin account having implicit +rw permissions everywhere) 2) unpacking a vimball other than the current file and/or to some non-default location. The same locations as above come to mind, and in addition a not-yet-existing ~/.vim or ~/vimfiles 3) by making then unpacking a vimball, copying a series of related vim scripts from one location to another (for instance, from /root/.vim and its subdirectories to the corresponding locations in and under /home/user1/.vim but not to /home/user2/.vim). 4) optionally, keeping a disk record of which files belong to a given project, in a format acceptable to :MkVimball, to streamline the creation of the relevant vimball. A cursory glance at plugin/vimball.vim and autoload/vimball.vim seems to indicate that this suggestion (which, IIUC, wouldn't break existing functionality) wouldn't be too hard to implement, but of course you know those plugins much better than I do. If you want me to suggest a patch, ay so, and I will try. Suggestion 2: I also suggest to explicitly mention vimballs in the vim-online blurbs for vimballed scripts. Best regards, Tony
Re: incorrect behavior of gzip.vim plugin?
On 2006-06-13, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: > Gary Johnson wrote: > > > I was following Chip Campbell's advice in the vim list to download > > v100 of the netrw plugin when I discovered the following > > undesirable behavior of the gzip.vim plugin. I downloaded > > netrw.vba.gz, then opened it with > > > >view netrw.vba.gz > > > > and saw the following messages at the bottom of the screen: > > > >"netrw.vba.gz" [readonly][noeol] 260L, 67511C > >"~/.vim/netrw.vba" [readonly] 7156L, 274745C > >Source this file to extract it! (:so %) > >Press ENTER or type command to continue > > > > I took a brief look at the file, then closed vim with > > > >:q > > > > When I did an 'ls' of the directory, I discovered that netrw.vba.gz > > had been replaced by netrw.vba! I didn't want to unzip the file, > > only look at it. I believe this is an error in the behavior of the > > gzip.vim script. > > > > > The problem here is :so % doesn't source the buffer, it sources the > underlying file. Thus the > file must needs be gunzip'ed first. > > Vimball could be set up not to gunzip the file, but then sourcing it > would fail. Oh, so you're saying that the unzipping of the file was a consequence of it being a vimball, not of being a gzip archive. I thought that vim-7.0 was now unzipping any .gz file that it opened. I just now used vim to read a gzipped text file and a gzipped tar file and verified that vim did not alter either of them. That's better. Thanks for the explanation. Considering the purpose of a vimball the and operations you want to perform on it, the current behavior seems fine. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: incorrect behavior of gzip.vim plugin?
Gary Johnson wrote: I was following Chip Campbell's advice in the vim list to download v100 of the netrw plugin when I discovered the following undesirable behavior of the gzip.vim plugin. I downloaded netrw.vba.gz, then opened it with view netrw.vba.gz and saw the following messages at the bottom of the screen: "netrw.vba.gz" [readonly][noeol] 260L, 67511C "~/.vim/netrw.vba" [readonly] 7156L, 274745C Source this file to extract it! (:so %) Press ENTER or type command to continue I took a brief look at the file, then closed vim with :q When I did an 'ls' of the directory, I discovered that netrw.vba.gz had been replaced by netrw.vba! I didn't want to unzip the file, only look at it. I believe this is an error in the behavior of the gzip.vim script. The problem here is :so % doesn't source the buffer, it sources the underlying file. Thus the file must needs be gunzip'ed first. Vimball could be set up not to gunzip the file, but then sourcing it would fail. Regards, Chip Campbell
incorrect behavior of gzip.vim plugin?
I was following Chip Campbell's advice in the vim list to download v100 of the netrw plugin when I discovered the following undesirable behavior of the gzip.vim plugin. I downloaded netrw.vba.gz, then opened it with view netrw.vba.gz and saw the following messages at the bottom of the screen: "netrw.vba.gz" [readonly][noeol] 260L, 67511C "~/.vim/netrw.vba" [readonly] 7156L, 274745C Source this file to extract it! (:so %) Press ENTER or type command to continue I took a brief look at the file, then closed vim with :q When I did an 'ls' of the directory, I discovered that netrw.vba.gz had been replaced by netrw.vba! I didn't want to unzip the file, only look at it. I believe this is an error in the behavior of the gzip.vim script. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Bug: Gvim window resizes during save with ":w"
On Tue, Jun 13, 2006 at 08:07:48PM +0200, Jochen Baier wrote: > On Tue, Jun 13, 2006 at 07:37:53PM +0200, A.J.Mechelynck wrote: > > Jochen Baier wrote: > > >hi, > > > > > >i have weird behavior here (latest svn gvim, linux, Gnome or Wmii) > > > > > >if i save with ":w" the window change the size to larger > > >size (5 pixel) for moment then it size back to the orginal size. > > >The left scrollbar is visible during this. no problems with > > >normal konsole vim. > > > > > >is this bug known ? > > > > > > > > >regards jochen > > > > > > > > > > > Strange. > > > > 1. What are the first lines (until and including "Features included (+) or > > not (-)") output by > > the ":version" command? > > > > To copy them to the clipboard, use the following (on gvim for X11): > > > > :redir @* > > :version > > :redir END > > :let @+ = @* > > > > Then paste the clipboard into your mailer, and remove the part starting > > with either +arabic or > > -arabic. > > > > > > 2. Immediately after experiencing the strange behaviour, without waiting, > > try > > > > :verbose set guioptions? > > > > What is the output? If a script name is mentioned, maybe that script > > temporarily sets the left > > scrollbar on (that's the l flag in 'guioptions', q.v.). > > > > > > Best regards, > > Tony. hi, thanks for the answer. after reading your email i was intelligent for 5 minutes and renamed. .vimrc, .gvimrc . vim etc... and found the bad guy: the MRU script. i will Cc the author. regards jochen
[Fwd: Re: I just updated my Vim site]
Hi Steve, I got the attached email privately. I believe it is meant for you. Best regards, Tony. --- Begin Message --- A.J.Mechelynck wrote: > And even if someday you do understand RPM (used by RedHat and SuSE), > you'll still have to figure out dpkg (for Debian) and what-not... I have > compiled gvim on my SuSE system and found the process remarkably easy. But it'd be much easier to make a deb as someone in Debian already maintains one: http://packages.qa.debian.org/c/cream.html The package description (from Ubuntu, but it's the same for Debian essentially): Package: cream Priority: optional Section: universe/editors Installed-Size: 2904 Maintainer: Christoph Haas <[EMAIL PROTECTED]> Architecture: all Version: 0.33.1-1 Depends: vim (>= 1:6.2), gvim | kvim, ucf Filename: pool/universe/c/cream/cream_0.33.1-1_all.deb Size: 844946 MD5sum: d848a0b33614f63eb838793924c8d96e Description: VIM macros that make the VIM easier to use for beginners Cream's motto is "Cream makes the powerful Vim text editor easy!". It brings a completely different look and feel to the VIM for those who are used to more intuitive editors while still preservering the more powerful features of VIM. It features pull-down menus, color themes, bookmarking, auto spellcheck and more. It leaves the default VIM untouched and is started by running 'cream'. See also: http://cream.sf.net Bugs: mailto:[EMAIL PROTECTED] Origin: Ubuntu So, talk to <[EMAIL PROTECTED]> if you need help packaging it. You might not even need to package it as he'll happily continue doing it along with whatever else he packages. signature.asc Description: OpenPGP digital signature --- End Message ---
Re: Bug: Gvim window resizes during save with ":w"
Jochen Baier wrote: hi, i have weird behavior here (latest svn gvim, linux, Gnome or Wmii) if i save with ":w" the window change the size to larger size (5 pixel) for moment then it size back to the orginal size. The left scrollbar is visible during this. no problems with normal konsole vim. is this bug known ? regards jochen Strange. 1. What are the first lines (until and including "Features included (+) or not (-)") output by the ":version" command? To copy them to the clipboard, use the following (on gvim for X11): :redir @* :version :redir END :let @+ = @* Then paste the clipboard into your mailer, and remove the part starting with either +arabic or -arabic. 2. Immediately after experiencing the strange behaviour, without waiting, try :verbose set guioptions? What is the output? If a script name is mentioned, maybe that script temporarily sets the left scrollbar on (that's the l flag in 'guioptions', q.v.). Best regards, Tony.
Bug: Gvim window resizes during save with ":w"
hi, i have weird behavior here (latest svn gvim, linux, Gnome or Wmii) if i save with ":w" the window change the size to larger size (5 pixel) for moment then it size back to the orginal size. The left scrollbar is visible during this. no problems with normal konsole vim. is this bug known ? regards jochen
Re: gui tabline for mac vim; general direction for mac vim
Nicolas Weber wrote: > I've written a gui tabline implementation for mac vim. I've been > using it for three weeks for now, it seems to work quite good, even > the required context menu is included ;-). The patch against vim7 svn > is attached, apply it with -p1. You can find some notes I wrote when > I implemented it here (there's a screenshot as well): > http://www.amnoid.de/vim/vimmacnotes.html > The attached patch contains the drawer implementation. > > This is the first time I'm submitting a patch (and the first time I > played with vim's code), so I'm thankful for all comments... Thanks for making this patch. Before including it I'll await comments from others. > Another question: I'm playing with the thought of porting the mac vim > port to carbon events (currently it uses a seriously deprecated event > handling method). Furthermore, I'd like to use HIView for the gui > stuff (the latter change would make vim dependent on OS X 10.2, > currently it requires 10.0). Are there any chances a patch for these > things would be accepted? I would think hardly anyone uses 10.0 or 10.1. Using 10.2 as the minimum version should be OK. We dropped OS 9 support a while ago. Before changing code for new features, I hope the current problems with ATSUI can be fixed. And a few other known bugs. -- If Microsoft would build a car... ... The airbag system would ask "are you SURE?" before deploying. /// 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///
