Re: Suggestion for :syn-nextgroup enhancement
On 2/27/07, Nikolai Weibull [EMAIL PROTECTED] wrote: Anyway, what I'm actually suggesting is a way to get around this issue by adding a new directive to the :syntax command that can be used alongside nextgroup to skip certain syntax groups before trying the groups defined by nextgroup. This is much like skipwhite, skipnl, and skipempty, but for arbitrary syntax groups. Actually, what makes even more sense would be to add a skippable directive, which could then be set on tocComment. This may be harder to implement, though. nikolai
todo? (setting eol/noeol after :r !cmd ? )
Hello Bram, Maybe vim would better set eol/noel after ':r !cmd' also, no only after reading the file into buffer ? (that is, the condition whether input had final \n or not). As I can see currently, this piece of info is lost after ': !cmd' ? Yakov
Re: Fwd: mac gui tabline v5
On Sunday, February 11 at 09:34 PM, quoth Nicolas Weber: Hi, vim-mac stripped the attachment again. I hope it comes through on this list. I like it! But it has a weird problem for me... if the focus is on some other application (say, Mail.app), and I click on the vim window's tab list edge, the window will resize itself to be extremely thin. Any ideas? ~Kyle -- America will never be destroyed from the outside. If we falter and lose our freedoms, it will be because we destroyed ourselves. -- Abraham Lincoln pgpdfiFueHY2V.pgp Description: PGP signature
Re: todo? (setting eol/noeol after :r !cmd ? )
Yakov Lerner wrote: Hello Bram, Maybe vim would better set eol/noel after ':r !cmd' also, no only after reading the file into buffer ? (that is, the condition whether input had final \n or not). As I can see currently, this piece of info is lost after ': !cmd' ? Yakov Maybe after :$r !cmd (appending at end-of-file), but not in other cases since the last line of the file isn't touched. Best regards, Tony. -- Hard work may not kill you, but why take chances?
Re: Bug: :confirm w only works once
Michael Schaap wrote: When editing a read-only file, :confirm w only works the first time you use it in a session. The second time you try to use it, you simply get an error message, as if you didn't use :confirm. The same problem occurs when using :set confirm. To recreate: $ echo Hello hello.txt $ chmod 400 hello.txt $ vim -u NONE hello.txt :set nocompatible or you won't be able to overwrite at all A, WorldEsc :confirm w 'readonly' option is set for qq. Do you wish to write anyway? (Y)es, [N]o: y A!Esc :confirm w E505: qq is read-only (add ! to override) This is using 7.0.203, but it has been happening for quite a while. An old 6.3 does the same thing. Michael What happens when 'readonly' is set is that the :confirm asks you if you want to override it. If you select yes then it will behave as if you did :w!. If you do the same with 'readonly' off you don't get the prompt, but writing fails for :w, only :w! works. Note that when 'readonly' is set then :w results in E45, while a read-only file gives E505. They are two different things, but both are overruled with :w!. We don't have a separate ! for each situation. Perhaps the E505 should also trigger :confirm w to ask for writing anyway. That's more difficult, but would be what you expect. -- hundred-and-one symptoms of being an internet addict: 222. You send more than 20 personal e-mails a day. /// 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: todo? (setting eol/noeol after :r !cmd ? )
Yakov Lerner wrote: Maybe vim would better set eol/noel after ':r !cmd' also, no only after reading the file into buffer ? (that is, the condition whether input had final \n or not). As I can see currently, this piece of info is lost after ': !cmd' ? It completely depends on what you are doing. If you have 'binary' set and do :r !cmd on the last line, then you actually insert a line break already, no matter if 'endofline' is set or not. And whether the value of 'endofline' should be adjusted to the output of cmd again depends on what you are doing. If you are concatenating binary files it does make sense to adjust 'endofline'. But you still need to fix that line break if 'endofline' wasn't set before. Perhaps it's a lot simpler if we just leave it to the user. It's a very uncommon issue anyway. -- hundred-and-one symptoms of being an internet addict: 229. You spend so much time thinking what to add on this list. /// 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: Suggestion for :syn-nextgroup enhancement
On 2/28/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: [Add a skip directive to the :syn command to allow arbitrary skipping.] Sounds like a good idea. I'll add it to the todo list. Great! If you really want this added you would have to send a patch... Yeah :-(. I'm taking the easy way out and adding the group to everythings nextgroup instead for this syntax definition. We'll see if that slows things down unbearably. nikolai
Re: Subject: Re: vim on cygwin using win32 clipboard
On 2007-02-28, Frodak Baksik [EMAIL PROTECTED] wrote: On 2/27/07, Gary Johnson wrote: On 2007-02-15, Frodak Baksik wrote: Here are all the changes in a single patch. I'm also posting this to the cygwin-apps mailing list, so if anyone over there could try it out would be nice. I just applied this patch to the latest Cygwin vim source package, vim-7.0.122-1, and configured it with ./configure --prefix=/usr/local --without-x --enable-gui=no However, after successfully building a number of .o files, make fails as follows: $ make Starting make in the src directory. If there are problems, cd to the src directory and run make there cd src make first make[1]: Entering directory `/usr/src/vim-7.0.122-1/src' make[1]: *** No rule to make target `proto/winclip.pro', needed by `objects/winclip.o'. Stop. make[1]: Leaving directory `/usr/src/vim-7.0.122-1/src' make: *** [first] Error 2 I'm sorry I don't have time to look into it further before I leave for the day. I hope it's obvious to someone what I've done wrong. Regards, Gary The problem appears to be with applying the patch. The file proto/winclip.pro should have been created by the patch command. I've just reinstalled fresh cygwin sources vim-7.0.122-1. Here is the command and output I get when applying the patch. The patch appeared to apply correctly except for auto/configure, which I was able to resolve, but not the way I should have. The way I applied the patch, which was to execute patch vim_cygwin_clip_patch_2007-02-13.diff in the /usr/src/vim-7.0.122-1/src directory, resulted in winclip.pro being created in that directory instead of in the proto subdirectory. $ pwd /usr/src/vim-7.0.122-1/src $ patch -p0 /usr/src/vim_cygwin_clip_patch_2007-02-13.diff patching file term.c [...] Hunk #1 succeeded at 759 (offset -5 lines). Using -p0 worked _much_ better, with the same results as yours. I thought it was probably something stupid like that. Thank you very much. I used the same configuration in your email and didn't have any issues. BTW, This is the configuration I normally use for compiling vim on cygwin. This is based upon the configuration options on the cygwin website and the feature set that vim is normally compiled with. ./configure \ --prefix=/usr \ --sysconfdir=/etc \ --libexecdir=/usr/sbin \ --localstatedir=/var \ --datadir=/usr/share \ --mandir=/usr/share/man \ --infodir=/usr/share/info \ --with-features=huge \ --without-x --enable-gui=no I wanted to keep the patched version separate from the official Cygwin version for comparison and backup in case I encountered any problems with the patched version. 'make' and 'make install' worked fine, but the resulting vim didn't use color in an rxvt. I ran configure again, this time including --with-features=huge: ./configure \ --prefix=/usr/local \ --with-features=huge \ --without-x --enable-gui=no However, I still don't see any color and there are still differences in :version between the original Cygwin vim and this patched version: $ diff vim_version_cygwin vim_version_patched_huge 1c1 VIM - Vi IMproved 7.0 (2006 May 7, compiled Oct 10 2006 10:07:11) --- VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 28 2007 15:32:26) 3c3 Compiled by [EMAIL PROTECTED] --- Compiled by [EMAIL PROTECTED] 13c13 -clipboard --- +clipboard 36c36 +gettext --- -gettext 84c84 +terminfo --- -terminfo 109c109 fall-back for $VIM: /usr/share/vim --- fall-back for $VIM: /usr/local/share/vim 111c111 Linking: gcc -L/usr/local/lib -o vim.exe -lncurses -liconv -lintl --- Linking: gcc -L/usr/local/lib -o vim.exe -ltermcap -liconv (I edited the outputs of :version to put each feature on a separate line.) :set termcap shows t_Co=8 in the original Cygwin vim and t_Co= in the patched version. It appears that I may need to install the ncurses package and reconfigure vim in order to get color. I don't know how to account for the other differences. (I wish there was a /usr/share/doc/vim-7.0.122-1/README or a /usr/src/vim-7.0.122-1/README_cygwin.txt that explained how the official Cygwin vim was built and a list of other packages needed.) Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Subject: Re: vim on cygwin using win32 clipboard
Gary Johnson wrote: It appears that I may need to install the ncurses package and reconfigure vim in order to get color. That would be likely; ncurses is (AFAIK) *much* better than termcap. -- Matthew Obscurity: +5
