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
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: 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: Suggestion for :syn-nextgroup enhancement
Nikolai Weibull wrote:
> I'm a firm believer in the nextgroup directive for defining syntaxes.
> It allows you to define grammars, which I really enjoy doing.
> However, one problem is that many languages allow things to appear in
> their input that's not part of the language's grammar. For example,
> many languages allow comments to appear almost anywhere in the input,
> which are stripped out of the input while lexing the input into tokens
> that are then fed to the actual parser. Now comments could be a part
> of the grammar, simply being thrown away at that point in the process,
> but it forces you to provide for the possibility of a comment
> appearing basically anywhere between terminals/non-terminals.
>
> 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.
>
> Here's an example of what I intend for it to do:
>
> syn keyword tocTodo
> \ contained
> \ TODO
> \ FIXME
> \ XXX
> \ NOTE
>
> syn match tocComment
> \ contains=tocTodo,@Spell
> \ '//.*$'
>
> syn keyword tocHeaderKeyword
> \ nextgroup=tocCatalogNumber
> \ skip=tocComment
> \ skipwhite
> \ skipempty
> \ CATALOG
>
> syn match tocCatalogNumber
> \ contained
> \ '"\d\{13\}"'
>
> This is a partial grammar that matches comments and the CATALOG
> keyword in the header part of a cdrdao(1) TOC file (yes, I'm writing a
> grammar for such files). Comments begin with a set of slashes and can
> appear anywhere in the file. The CATALOG keyword is followed by a
> (optional, but let's keep it simple for this example) catalog number.
> The idea here is that the skip=tocComment directive to
> tocHeaderKeyword will tell the syntax highlighting engine that it
> should skip any matches to tocComment that follow tocHeaderKeyword,
> just as the skipwhite and skipempty pair tells it to skip whitespace
> and empty lines (before and after any tocComments) before it tries to
> match a tocCatalogNumber.
>
> I have no idea how hard this would be to implement, but I'm thinking
> that it can't be too difficult. It should "only" be to add some
> handling around the code that handles skipwhite/skipnl/skipempty to go
> through a list of syntax groups and try to match them, highlighting
> them, and then trying to highlight whatever is in nextgroup
> afterwards.
>
> I'm sure there are edge cases to consider, but I can't think that it
> should be impossible. I sadly don't have any understanding of the Vim
> syntax highlighter, so someone with more knowledge will have to help
> me out.
>
> Comments? Patches? Complaints?
Sounds like a good idea. I'll add it to the todo list.
If you really want this added you would have to send a patch...
--
hundred-and-one symptoms of being an internet addict:
227. You sleep next to your monitor. Or on top of it.
/// 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: 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, World > :confirm w > 'readonly' option is set for "qq". > Do you wish to write anyway? > (Y)es, [N]o: y > A! > :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: 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: 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
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: Subject: Re: vim on cygwin using win32 clipboard
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. $ 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 patching file Make_cyg.mak patching file configure.in Hunk #1 succeeded at 1957 (offset -1 lines). patching file Make_ming.mak patching file proto/winclip.pro patching file proto/os_mswin.pro patching file vim.h Hunk #1 succeeded at 1726 (offset -4 lines). patching file Make_w16.mak patching file Make_bc5.mak patching file feature.h patching file proto.h patching file Makefile patching file config.h.in patching file mbyte.c Hunk #2 succeeded at 3122 (offset -6 lines). Hunk #3 succeeded at 4409 (offset -6 lines). patching file os_unix.c patching file os_mswin.c patching file os_win32.c patching file Make_ivc.mak patching file Make_mvc.mak patching file auto/configure patching file winclip.c patching file globals.h Hunk #1 succeeded at 759 (offset -5 lines). 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 :-) Frodak
Re: Subject: Re: vim on cygwin using win32 clipboard
I just applied this patch to the latest Cygwin vim source package, vim-7.0.122-1, and configured it with Using the latest official vim sources (via CVS) I was able to apply the patch and execute configure && make && make install with no issues. Do you know if the patch applied successfully? Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org
Re: Bug: ":confirm w" only works once
On 2/28/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 2/27/07, Michael Schaap <[EMAIL PROTECTED]> wrote: >> Hi, >> >> 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, World >> :confirm w >> 'readonly' option is set for "qq". >> Do you wish to write anyway? >> (Y)es, [N]o: y >> A! >> :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. > > You see this behaviour because the first :confirm w(or ':w!', > for this matter) resets the 'ro' option. This is the reason the 2nd > ':confirm w' doesn't ask anything. You can see yourself if you do > 'set ro?' before and after first ':confirm w'. >:set ro? > readonly >:confirm w > ... (Y)es, [N]o: y >:set ro? > noreadonly > > As you see, the 'ro' option has been reset. This is > the reason the following ':confirm w' does not ask for > the confirmation. > > AFAIK, vim always behaved this way -- that is, > the ':w!' would reset the ro flag. > > But notice that inserting text into 'ro' file does not reset the 'ro' > flag by itself. > It warns (modifying the readonly file). but the 'ro' flag remains. After > :w!, 'ro' flag is reset. > > Yakov > Why then does the second ":confirm w" give 'E505: "qq" is read-only (add ! to override)' ? Because file-on-disk has read-only permissions. But the 'set readonly?' option is off. Yakov
Re: Bug: ":confirm w" only works once
Yakov Lerner wrote: On 2/27/07, Michael Schaap <[EMAIL PROTECTED]> wrote: Hi, 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, World :confirm w 'readonly' option is set for "qq". Do you wish to write anyway? (Y)es, [N]o: y A! :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. You see this behaviour because the first :confirm w(or ':w!', for this matter) resets the 'ro' option. This is the reason the 2nd ':confirm w' doesn't ask anything. You can see yourself if you do 'set ro?' before and after first ':confirm w'. :set ro? readonly :confirm w ... (Y)es, [N]o: y :set ro? noreadonly As you see, the 'ro' option has been reset. This is the reason the following ':confirm w' does not ask for the confirmation. AFAIK, vim always behaved this way -- that is, the ':w!' would reset the ro flag. But notice that inserting text into 'ro' file does not reset the 'ro' flag by itself. It warns (modifying the readonly file). but the 'ro' flag remains. After :w!, 'ro' flag is reset. Yakov Why then does the second ":confirm w" give 'E505: "qq" is read-only (add ! to override)' ? Best regards, Tony. -- Your fault: core dumped
Re: Bug: ":confirm w" only works once
On 2/27/07, Michael Schaap <[EMAIL PROTECTED]> wrote: Hi, 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, World :confirm w 'readonly' option is set for "qq". Do you wish to write anyway? (Y)es, [N]o: y A! :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. You see this behaviour because the first :confirm w(or ':w!', for this matter) resets the 'ro' option. This is the reason the 2nd ':confirm w' doesn't ask anything. You can see yourself if you do 'set ro?' before and after first ':confirm w'. :set ro? readonly :confirm w ... (Y)es, [N]o: y :set ro? noreadonly As you see, the 'ro' option has been reset. This is the reason the following ':confirm w' does not ask for the confirmation. AFAIK, vim always behaved this way -- that is, the ':w!' would reset the ro flag. But notice that inserting text into 'ro' file does not reset the 'ro' flag by itself. It warns (modifying the readonly file). but the 'ro' flag remains. After :w!, 'ro' flag is reset. Yakov
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
