Re: [Cygwin] Configure Detects Incorrect Ruby Version
On 2007-06-03, Taylor Venable <[EMAIL PROTECTED]> wrote: > Hello, > > When I compile Vim 7.1.2 under Cygwin (on Windows XP), the configure > script incorrectly identifies the version of my Ruby interpreter. The > output from the configure script is as follows: > > checking --enable-rubyinterp argument... yes > checking for ruby... /usr/bin/ruby > checking Ruby version... too old; need Ruby version 1.6.0 or later > > But running `ruby --version` yields: > > ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-cygwin] > > Any ideas? Thanks. I don't know anything about Ruby and not much about the inner workings of configure, but it appears that the ruby version is being checked at line 881 of vim71/src/configure.in: if $vi_cv_path_ruby -e '(VERSION rescue RUBY_VERSION) >= "1.6.0" or exit 1' >/dev/null 2>/dev/null; then where I think $vi_cv_path_ruby is "/usr/bin/ruby". That doesn't tell me anything other than that the version is not being determined by executing "ruby --version", but maybe it tells you something useful. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Wish: col("^")
On 2007-05-21, Andy Wokula <[EMAIL PROTECTED]> wrote:
> ... get position of first non-blank character in the line.
>
> If there is col("$"), there should also be col("^").
> In some situations (e.g. :imap )
>:normal ^
> is not allowed.
indent(".")?
HTH,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
| Spokane, Washington, USA
Re: Subject: Re: vim on cygwin using win32 clipboard
On 2007-05-17, Gary Johnson <[EMAIL PROTECTED]> wrote: > On 2007-02-15, Frodak Baksik <[EMAIL PROTECTED]> wrote: > > On 2/15/07, Chris Sutcliffe wrote: > > > > > Also, is there anything I can do to help get the original > > > > > patch accepted? > > > > > > > > Ask a few people to try it out and report their results here. > > > > > > I'll give it a shot. Is there somewhere I can grab the patch from, or > > > should I go through the list archives to find it? > > > 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 7.1 source. The patch to > proto/os_mswin.pro failed, but it was easy to fix manually. The > problem was that the extern prefix has been removed from the 7.1 > declarations. Hunk #2 of the patch to os_win32.c failed, apparently > because that change was already made to the 7.1 source, so I left > that file with only hunk #1 applied. It looks like I goofed when applying the patch that way. I just applied the patch to another system, but edited the patch first to get rid of the failures instead of trying to edit the files afterwards. All I had to do to the proto/winclip.pro section was to remove "extern " from the start of all the lines. While editing the os_win32.c section, I discovered that 'patch' was missing the first hunk in the target and applying the first hunk of the patch to the second hunk in the target, causing the application of the second hunk of the patch to fail. This was cause by the reformatting of a comment from 7.0 to 7.1. I changed the comment in the patch to match the comment in the 7.1 source and the entire patch applied successfully. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Subject: Re: vim on cygwin using win32 clipboard
On 2007-02-15, Frodak Baksik <[EMAIL PROTECTED]> wrote: > On 2/15/07, Chris Sutcliffe wrote: > > > > Also, is there anything I can do to help get the original > > > > patch accepted? > > > > > > Ask a few people to try it out and report their results here. > > > > I'll give it a shot. Is there somewhere I can grab the patch from, or > > should I go through the list archives to find it? > 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 7.1 source. The patch to proto/os_mswin.pro failed, but it was easy to fix manually. The problem was that the extern prefix has been removed from the 7.1 declarations. Hunk #2 of the patch to os_win32.c failed, apparently because that change was already made to the 7.1 source, so I left that file with only hunk #1 applied. The code compiled without problem and seems to work fine. The patch seemed to work fine with 7.0, too, but I wasn't able to test it very much since I haven't had to do much work on Windows recently. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: [PATCH] vim_is_xterm() and "screen"
On 2007-05-09, Micah Cowan <[EMAIL PROTECTED]> wrote: > Towards a better solution: how straightforward do you think it'll be to > talk the ncurses guys into adding support for some of screen's > extensions? AFAIK, the only one I care about is the xterm mouse support; > another interesting one is a boolean "supports ansi > setforeground/setbackground codes"; but I usually infer this (if > necessary) from the presence of setaf/setbf (not a given, but...). "The ncurses guys" is Thomas Dickey, who frequents a number of lists and newsgroups, and who would probably be willing to discuss it with you. Contact information is here: http://www.gnu.org/software/ncurses/ Look for "Who's Who and What's What". You might also consider joining the bug-ncurses-request mailing list, which is "open to anyone interested in helping with the development and testing of this package." I would imagine the process would be more a matter of convincing Thomas to accept the concept, the design, and any patches you would submit, rather than "the ncurses guys" adding this support themselves. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: VimWiki - again - but with a brand new option
On 2007-05-08, Ian Tegebo <[EMAIL PROTECTED]> wrote: > On 5/8/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > Ian Tegebo wrote: > > > I would like to make another implementation independent suggestion; > > > one could make a VimWiki more valuable by importing the _extremely_ > > > valuable vim helpfiles into it. > > > > Please don't do this. It might sound like a nice idea, but it means > > making a branch that will be very hard to merge back into the help files > > of the distribution. > I feel misunderstood but it serves me right for not saying what I mean... > > Synchronizing data is no fun, I agree. While I was up in the clouds I > was imaging that the wiki would be the authoritative source for the > helpfiles after doing an initial _import_. Then the text version > would be exported as needed, e.g. end user runtime update or for a new > release. This seems like a bad idea. The vim help files are an authoritative source because their content is under the control of an authority: Bram. Others are encouraged to submit patches that correct errors or clarify wording, but before any of those patches are applied, Bram looks at them to be sure they are correct and consistent with the help files' style. A wiki allows every Tom, Dick and Harry to make changes to it, whether they know what they're talking about or not. Wikis are useful, but it's difficult to ensure their correctness. Requiring Bram to vet every page before it is included in vim's help files would be an undue burden on him as well as a poor use of his time. A wiki is a good idea, but the content should be separate from the help files. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim version 7.1a BETA has been released
On 2007-05-06, Gary Johnson <[EMAIL PROTECTED]> wrote: > On 2007-05-05, "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote: > > Compiles as a breeze :-). > > Yes indeed. I've compiled it so far on SunOS 5.8 and HP-UX 10.20. > I may try Cygwin if I'm feeling adventurous enough. I've never done > that except from Cygwin sources. Well, that was really easy. I built just the console version for Cygwin and it seems to work fine in PuTTY over an ssh connection. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim version 7.1a BETA has been released
On 2007-05-06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > Gary Johnson wrote: > > > I noticed that filetype.vim does not include the patch that I > > submitted to this list 2006-07-25 to fix the recognition of mutt > > temporary files on SunOS. Is there something else I can do to have > > this patch accepted? > > It was still in the todo list. There are many items I still didn't have > time for, unfortunately. I assume you have properly tested this change. > I'll include this one now. Thank you. I was concerned that it hadn't made it onto the list. I didn't realize you had such a backlog of changes. I've been using it in my $VIMRUNTIME/filetype.vim since July without any problems or errors that I know of. Best regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim version 7.1a BETA has been released
On 2007-05-05, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > Announcing: Vim (Vi IMproved) version 7.1a BETA > > > This is a BETA release of Vim 7.1. It consists of Vim 7.0 plus all > patches and updated runtime files. > > I expect this to be stable, since the patches have been used by many > people already. This BETA is mainly to check that the files has been > setup properly. It's been almost a year since the last one! > > Please report every problem you find! It will only be a few days until > the 7.1 release, so please take a little time right now to check it out. I noticed that filetype.vim does not include the patch that I submitted to this list 2006-07-25 to fix the recognition of mutt temporary files on SunOS. Is there something else I can do to have this patch accepted? Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim version 7.1a BETA has been released
On 2007-05-05, "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote: > Bram Moolenaar wrote: > > Announcing: Vim (Vi IMproved) version 7.1a BETA > > This is a BETA release of Vim 7.1. It consists of Vim 7.0 plus all > > patches and updated runtime files. > > I expect this to be stable, since the patches have been used by many > > people already. This BETA is mainly to check that the files has been > > setup properly. It's been almost a year since the last one! > > Please report every problem you find! It will only be a few days until > > the 7.1 release, so please take a little time right now to check it out. > > Once you have installed Vim 7.1a BETA you can find details about the > > changes since Vim 7.0 with ":help version-7.1". > [...] > > Compiles as a breeze :-). Yes indeed. I've compiled it so far on SunOS 5.8 and HP-UX 10.20. I may try Cygwin if I'm feeling adventurous enough. I've never done that except from Cygwin sources. > The binary is now in /usr/local/vim (but we still have /usr/local/vim70 as a > backup); the runtime files go in /usr/local/vim/vim71a and below, where the > binary will find them with no problem (and the 7.0 runtime files in > /usr/local/vim/vim70 [or wherever] aren't touched). I think some directories were omitted from the paths in that paragraph and that it should read: The binary is now in /usr/local/bin/vim (but we still have /usr/local/bin/vim70 as a backup); the runtime files go in /usr/local/share/vim/vim71a and below, where the binary will find them with no problem (and the 7.0 runtime files in /usr/local/share/vim/vim70 [or wherever] aren't touched). > (Warning: In the "ln" command as used here, the target name comes before the > link name. I find this counter-intuitive.) It's not just me then. I have to think carefully about that every time I use ln. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: [PATCH] new ex command :lscscope
On 2007-04-27, Gary Johnson <[EMAIL PROTECTED]> wrote: > On 2007-04-26, Navdeep Parhar <[EMAIL PROTECTED]> wrote: > > Hello, > > > > Currently :cscope has a variant :lcscope that allows the use of > > the location list instead of the quickfix list. However, :scscope > > has no equivalent that uses the location list. Please note that > > :scs splits only if cscope returns some results, so :scs is not > > the same as ":split cs". Due to this reason ":split lcscope" can > > not be used to get the same behaviour as the proposed :lscscope. > > > > I was looking for a way to open the results of a cscope query in a > > new tab, and use the location list at the same time. That's when > > I realized the need for :lscsope. ":tab lsc ..." does what I > > need. > > > > Here is a patch to add :lscscope to vim. I have tested it on > > Solaris and Linux and it works for me. Feedback is welcome. > > Wonderful! Thank you. I have applied it to vim on SunOS 5.8 and am > testing it now. The lack of this feature has kept me from using > location lists until now, so I'm not sure yet how this _should_ > work. I'll also have to remember to use the location-list form of > several commands. > > I use a combination of tags, :grep and ":scscope find" to search the > code I'm working on. I often find myself in the process of > traversing one quickfix list when I'd like to follow some other > quickfix list in another window, but be able to easily come back to > the original quickfix list just by changing to the original window. > > I'll let you know how this works out. I'm confused. I tried exercising this patch and I'm not getting the results I expect, but I don't know if it's the patch, the behavior of location lists, or me. Here's an example. I cd'd to the src directory of my vim installation which is currently at patch level 208. Then I built a cscope database. $ cscope -b Then I opened one of the source files, $ view +3725 buffer.c added the cscope database, :cs add cscope.out moved the cursor to the get_fileformat symbol and opened a new window containing a location list of the places where that function is called. :lscscope find c ^R^W (1 of 10): <> else if (num == CAR && get_fileformat(wp->w_buffer) == EOL_MAC) That happens to be the same line in buffer.c that the cursor had been on. Then I went to the third location in the list, :3ll (3 of 10): <> fileformat = get_fileformat(curbuf); which is line 925 of fileio.c. I moved the cursor to the top of this function, readfile (line 209), and opened a new window containing a location list of the places where this function is called. :lscscope find c ^R^W (1 of 12): <> retval = readfile(curbuf->b_ffname, curbuf->b_fname, This window contains buffer.c, which is also being viewed in the bottom window. The location list is new. We can check the location list stack state as follows: :lold error list 1 of 2; 10 errors :lnew error list 2 of 2; 12 errors Then I went to the 5th location in this list. :5ll (5 of 12): <> if (readfile(otmp, NULL, line2, (linenr_T)0, (linenr_T)MAXLNUM, This is line 1209 of ex_cmds.c. At this point, I wanted to stop following this location list, close this window and return to the place where I executed the :lscscope command, then pick up where I was in the first location list. :q This closed the top window and made the second window "active" with the cursor on the first line of the readline() function. So far so good. When I left this window, I had been at location 3 of 10 in the first location list. Therefore, I expected that executing :ll would put the cursor back on line 925 of this file, fileio.c. :ll (1 of 12): <> retval = readfile(curbuf->b_ffname, curbuf->b_fname, Not only did the :ll command use the "wrong" (i.e., unexpected) location list, but it jumped to the first location in that list instead of the last location used, which was number 5. Checking the location list stack state, :lold error list 1 of 2; 10 errors :lnew error list 2 of 2; 12 errors shows that there are still two location lists. I would have expected that closing that top window would have deleted the newest list. So is this a bug, or am I just not getting it? $ vim --version VIM - Vi IMproved 7.0 (2006 May 7, compiled Apr 27 2007 14:19:23) Included patches: 1-208 Compiled by [EMAIL PROTECTED] Normal version with GTK GUI. Features included (+) or not (-): -arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdl
Re: [PATCH] new ex command :lscscope
On 2007-04-26, Navdeep Parhar <[EMAIL PROTECTED]> wrote: > Hello, > > Currently :cscope has a variant :lcscope that allows the use of > the location list instead of the quickfix list. However, :scscope > has no equivalent that uses the location list. Please note that > :scs splits only if cscope returns some results, so :scs is not > the same as ":split cs". Due to this reason ":split lcscope" can > not be used to get the same behaviour as the proposed :lscscope. > > I was looking for a way to open the results of a cscope query in a > new tab, and use the location list at the same time. That's when > I realized the need for :lscsope. ":tab lsc ..." does what I > need. > > Here is a patch to add :lscscope to vim. I have tested it on > Solaris and Linux and it works for me. Feedback is welcome. Wonderful! Thank you. I have applied it to vim on SunOS 5.8 and am testing it now. The lack of this feature has kept me from using location lists until now, so I'm not sure yet how this _should_ work. I'll also have to remember to use the location-list form of several commands. I use a combination of tags, :grep and ":scscope find" to search the code I'm working on. I often find myself in the process of traversing one quickfix list when I'd like to follow some other quickfix list in another window, but be able to easily come back to the original quickfix list just by changing to the original window. I'll let you know how this works out. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: wish: collaboration of N vim instances editing same file
On 2007-04-11, Yakov Lerner <[EMAIL PROTECTED]> wrote: > Hello Bram, > Is it possible to add this item to the vim voting list ?: > > "collaboration of N vim instances editing same file" > -- Ability of N instances of vim to absorb, merge and show changes > to the same file made by other running vim instances [ either by reading > other vim's swapfiles, or somehow else ] ? > > Can this be added to SOC ? If you want this collaboration to occur in real time, then I would recommend that you use a screen session in multi-user mode. This solution already exists; it works with applications other than vim; it avoids complicating the vim code. See the screen(1) man page and search for "multi". HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: copyindent/preserveindent question
On 2007-03-07, Alexei Alexandrov <[EMAIL PROTECTED]> wrote: > Hi All! > > I was hesitating where to post this message to: editors.vim or > editor.vim.devel, since I'm not sure if it's bug or I'm just > missing something. Finally I decided to treat this as a bug. > > Problem: I can't get copyindent/preserveindent options working. > > The scenario to reproduce: > > $ gvim -u NONE -U NONE --noplugin > > Then, go to insert mode (i), type a Tab (C-V, C-I), type hello. Go > back to normal mode. > Do: set preserveindent copyindent autoindent expandtab > Go to insert mode again and add a new line after the existing one. > > The new line will be indented with spaces, while it is expected > that the tab from the previous line will be copied. >From ":help preserveindent": Normally the indent is replaced by a series of tabs followed by spaces as required (unless |'expandtab'| is enabled, in which case only spaces are used). HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: [!] missing from :cb and related commands?
On 2007-03-06, Yegappan Lakshmanan <[EMAIL PROTECTED]> wrote: > Hi, > > On 3/6/07, Gary Johnson <[EMAIL PROTECTED]> wrote: > > It seems pretty clear that there has been an oversight in the > > implementation of the :cb and :lb commands, even pointed to by the > > text of E37. If there is some reason that the :cb and :lb commands > > should not be extended to accept !, then the current text of E37 is > > inappropriate for that error condition. > > > > Try using the attached patch which enables the "!" modifier for the > ":cbuffer" and ":lbuffer" commands. That was quick! And it works great (applied to vim 7.0.66 on SunOS)! Thank you! Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: [!] missing from :cb and related commands?
On 2007-03-07, "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote: > Gary Johnson wrote: > > If I open a new window, read into it the results of a grep command, > > e.g., > > > > :r !grep -nH somepattern somefileset > > > > and then try to use that buffer as a quickfix list or location list > > with either the :cb or :lb commands, respectively, I get > > > > E37: No write since last change (add ! to override) > > > > If I then try to add ! to the :cb or :lb commands, I get > > > > E477: No ! allowed > > > > It seems to me that the :cb and :lb commands are missing the ability > > to handle a !. > > > > The most recent version of vim I had to verify this with was > > 7.0.178. > > > > Regards, > > Gary > > > > If what you want to do with the output of grep is use it as a quickfix > error list, then use ":grep" or ":lgrep" instead of ":r !grep". Or you can > also use ":vimgrep" or ":lvimgrep" for internal grep (with Vim-style > regexps). > > See ":help grep". I use :grep all the time. I've also started using :lgrep to go off on "side searches" so that I can return to the main quickfix list without having to remember how many times to execute :cold. In the present case, I wanted to build a quickfix/location list with a very specific set of targets, so the best way seemed to be to create the whole list of targets in a buffer, then edit that list before committing it to the quickfix/location list. I just learned about the :cb command recently from a post in some mailing list (probably vim, but I can't find it now). This was my first attempt at using it, and it worked beautifully except for the error message. It seems pretty clear that there has been an oversight in the implementation of the :cb and :lb commands, even pointed to by the text of E37. If there is some reason that the :cb and :lb commands should not be extended to accept !, then the current text of E37 is inappropriate for that error condition. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: [!] missing from :cb and related commands?
On 2007-03-06, Yegappan Lakshmanan <[EMAIL PROTECTED]> wrote: > Hi Gary, > > On 3/6/07, Gary Johnson <[EMAIL PROTECTED]> wrote: > > If I open a new window, read into it the results of a grep command, > > e.g., > > > > :r !grep -nH somepattern somefileset > > > > and then try to use that buffer as a quickfix list or location list > > with either the :cb or :lb commands, respectively, I get > > > > E37: No write since last change (add ! to override) > > > > If I then try to add ! to the :cb or :lb commands, I get > > > > E477: No ! allowed > > > > It seems to me that the :cb and :lb commands are missing the ability > > to handle a !. > > > > The most recent version of vim I had to verify this with was > > 7.0.178. > > > > You can try using the ":cgetbuffer" and ":lgetbuffer" commands. > These commands will not automatically jump to the first error. True, but I _do_ want to jump to the first error. The workaround I had been using was to execute ":set nomodified" before :cb or :lb, but :cgetbuffer or :lgetbuffer followed by :cc! or :ll! would do for now as workarounds, too. Thanks. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
[!] missing from :cb and related commands?
If I open a new window, read into it the results of a grep command, e.g., :r !grep -nH somepattern somefileset and then try to use that buffer as a quickfix list or location list with either the :cb or :lb commands, respectively, I get E37: No write since last change (add ! to override) If I then try to add ! to the :cb or :lb commands, I get E477: No ! allowed It seems to me that the :cb and :lb commands are missing the ability to handle a !. The most recent version of vim I had to verify this with was 7.0.178. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Subject: Re: vim on cygwin using win32 clipboard
On 2007-03-01, Frodak Baksik <[EMAIL PROTECTED]> wrote: > On 2/28/07, Matthew Woehlke <[EMAIL PROTECTED]> wrote: > > 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. > Try getting ncurses and gettext libraries. Both are available > packages in cygwin. There are several ncurses packages to choose from, but I finally figured out that I needed libncurses-devel, so I installed that, reconfigured and rebuilt vim and voila: color! It's not as clear to me what I need to resolve these differences: 36c36 < +gettext --- > -gettext 111c111 < Linking: gcc -L/usr/local/lib -o vim.exe -lncurses -liconv -lintl --- > Linking: gcc -L/usr/local/lib -o vim.exe -lncurses -liconv My Cygwin installation already has /usr/include/libintl.h /usr/lib/libintl.a /usr/lib/libintl.dll.a /usr/lib/libintl.la which appear to be what /usr/src/vim-7.0.122-1/src/auto/configure is looking for, so I don't understand what is missing and therefore which of the following likely-looking Cygwin packages I should install: gettext gettext-devel if either. On the other hand, I don't think I ever use any of vim's internationalization features, so it probably doesn't matter, especially for the purpose of evaluating this patch. In fact, I just checked the vims I use on HP-UX, SunOS and Linux and none of them have +gettext or -lintl. Thanks again for your help. I'll let you know if I find any issues with the clipboard. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
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
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 -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Error in eval.txt (:help let-option)
There appears to be an error in one of the tag names given to the
help entry for let-option:
:let &{option-name} = {expr1} *:let-option* *:let-star*
The second tag should be "*:let-&*" rather than ":let-star*". This
is in the 2006 May 06 version of doc/eval.txt. A patch follows.
- cut here -
*** eval.txt.orig Sun May 7 05:16:44 2006
--- eval.txtWed Jan 31 11:21:19 2007
***
*** 5684,5690
Append {expr1} to register {reg-name}. If the
register was empty it's like setting it to {expr1}.
! :let &{option-name} = {expr1} *:let-option* *:let-star*
Set option {option-name} to the result of the
expression {expr1}. A String or Number value is
always converted to the type of the option.
--- 5684,5690
Append {expr1} to register {reg-name}. If the
register was empty it's like setting it to {expr1}.
! :let &{option-name} = {expr1} *:let-option* *:let-&*
Set option {option-name} to the result of the
expression {expr1}. A String or Number value is
always converted to the type of the option.
- cut here -----
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Re: [PATCH] cygwin: Trouble recognizing absolute path
On 2006-10-13, Corinna Vinschen <[EMAIL PROTECTED]> wrote: > On Oct 13 21:53, Yakov Lerner wrote: > > On 10/13/06, Corinna Vinschen <[EMAIL PROTECTED]> wrote: > > >Hi, > > > > > >I got a report on the Cygwin mailing list that the following message > > >appears when trying to open /etc/hosts in vim: > > > > > > E303: Unable to open swap file for "/etc/hosts", recovery impossible > > > > > >What happens is this: > > > > > >/etc/hosts is by default a symbolic link which points to the hosts file > > >in the Windows system directory. The symbolic link is created as a link > > >to the DOS path, for instance: > > > > > > $ ls -l /etc/hosts > > > lrwxrwxrwx 1 corinna None 37 Oct 13 18:32 /etc/hosts -> > > > c:\WINDOWS\system32\drivers\etc\hosts > > > > I bet you can solve the problem by relinking /etc/hosts to > > /cygdrive/c/windows/system32/drivers/etc/hosts. > > > > This is how it *should* be linked. > > Sure, but that's not the problem. If it's not /etc/hosts it's another > symlink created by a user. DOS paths do work, usually. Hi Corinna, I thought the purpose of Cygwin was to provide a Linux-like environment for applications, so that, for example, one could simply recompile under Cygwin an application written for Linux and not have to rewrite the file-handling routines to recognize DOS file names. That's the purpose of the cygdrive directory, is it not? It seems to me that if "DOS paths do work, usually," it's because the application was written to deal with them or it never looks at any file names, but simply hands them whole to the Cygwin file I/O API. As Yakov said, it seems to me that the proper solution is for Cygwin to link /etc/hosts to /cygdrive/c/windows/system32/drivers/etc/hosts. If users have problems because they've mounted cygdrive someplace else, or have created symbolic links to DOS file names, then to quote someone on the cygwin list, WDDTT (Well Don't Do That Then). Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: vim -u NONE
On 2006-10-05, Bill McCarthy <[EMAIL PROTECTED]> wrote:
> 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.
Well, I stand corrected. Thanks for explaining that. I was sure
that "-u NONE -i NONE -N" was as sufficient for gvim as it is for
vim. I had no idea that gvim was so insistent on loading certain
files. Sure enough, under ":help -U" it says:
Exception: Reading the system-wide menu file is always done.
But unfortunately it doesn't go on to say that this implies that
'rtp' will be searched for certain other files, e.g.,
autoload/paste.vim.
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'
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Re: vim -u NONE (was: Re: Vim 7.0 (1-109 patches) completion bug.)
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
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Re: Vim's mch_FullName() function and ClearCase versioned file names
On 2006-08-14, "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote:
> Gary Johnson wrote:
> [...]
> > I've also come up with a solution for part of the problem, that of
> > Vim's insistence on converting a name like
> >
> > /project/xyz/system/src/bar.c@@/main/42
> >
> > (through chdir() and getcwd()) to a name like
> >
> > /view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main
> >
> > Using the following autocommand seems to fix that by restoring the
> > original file name. I thought I had tried this solution before and
> > it didn't work, but it seems to work now, so I must have had
> > something set differently before.
> >
> > au VimEnter /view/*@@/* silent windo
> > \ exe 'file' system('cleartool des -short -cview
> > "'.expand("%").'"')
> >
> > The windo command covers the case where vim was invoked as vimdiff
> > to compare two ClearCase versions.
> >
> > Thanks again,
> > Gary
> >
>
> VimEnter doesn't cover the case when you ":edit" or ":view" (etc.) the
> file after starting Vim. Maybe:
>
> :au BufReadPost /view/*@@/* silent exe 'file' system(...etc...)
Thanks, Tony. That makes sense, but so far I haven't needed to
address that case. If I :edit or :view a version-extended path
name, e.g.,
:e /project/abc/def/src/foo.c/@@main/73
Vim does not try to rename it to the /view/garyjohn_main@@/project/...
form. I don't understand why, but it seems to do that only when the
file name is given on the command line. So for the time being, I've
just added your suggestion as a comment above the VimEnter
autocommand in my ClearCase plugin in case the VimEnter solution
does turn out to be insufficient.
Thanks,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Re: Vim's mch_FullName() function and ClearCase versioned file names
On 2006-08-12, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> On 8/12/06, Gary Johnson <[EMAIL PROTECTED]> wrote:
> > I just finished troubleshooting a problem that had several
> > contributing factors, one of which was the way Vim's mch_FullName()
> > function behaves with ClearCase versioned file names.
> >
> > If you open a file under ClearCase using the full path name and a
> > version extension, e.g.,
> >
> > /project/xyz/system/src/bar.c@@/main/42
> >
> > Vim will ask mch_FullName() for the full name of that file.
> > mch_FullName() will then extract everything to the left of the last
> > '/' as the directory containing the file and chdir() to that
> > directory, e.g.,
> >
> > chdir("/project/xyz/system/src/bar.c@@/main")
> >
> > mch_FullName() then calls getcwd() to determine the operating
> > system's name for that directory, which from ClearCase is
> >
> > /view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main
> >
> > mch_FullName() then puts back the trailing "file name" of "42" in
> > this case and returns the full file name as
> >
> > /view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main/42
> >
> > This is the name that is then given to the buffer used for that file
> > and which appears in the status line.
> >
> > This is a valid file name which points to the correct file and works
> > with most external commands. However, it does not work with those
> > external commands or Vim autocommands whose behavior depend on the
> > file name suffix. It's also really ugly in the status line.
>
> How about using a symlink ?
That would work. It could be messy figuring out where to put it
where its name would be unique, but not impossible.
> Regarding statusline, you can use custom statusline
> and replace %f to %{MyFilename()} which knows to handle @@.
Good idea. There's even a ClearCase command that can convert from
one form of the file name to another.
On 2006-08-12, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> On 8/12/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > On 8/12/06, Gary Johnson <[EMAIL PROTECTED]> > > If you open a file
> > under ClearCase using the full path name and a
> > > version extension, e.g.,
> > >
> > > /project/xyz/system/src/bar.c@@/main/42
>
> If I'm not mistaken, 42 is version name here, and your problem is that
> such pathname does not have .c extension.
>
> How about creating "automatic" symlinks: have autocommand autocreate
> symlinks these lines:
>
> :au BufNew /project/xyz/system/src/*.v*.c :!ver=`basename .c
> | sed 's/^.*\.v//'`; base=`basename .c | sed
> 's/\.v[0-9]*\$//`; ln -s /project/xyz/system/src/\$base.c@@/main/\$ver
>
>
> This is untested, but the idea is that when you open
>
> % vim bar.v42.c
>
> the proper symlink is automatically created to version
> 42 of bar.c This solves the problem of proper extension
> and of ugly @@ filenames.
Hmm. That could work. Thanks.
One of the situations in which I've had trouble giving a
properly-extended file name to an external program is when I've used
the ClearCase Vtree Browser to select a C file to opened in Vim,
then tried to run 'lint' on the file. In that case, I could modify
my :Lint command to create a temporary file with the proper suffix,
either as a copy of the file in the Vim buffer or as a symbolic link
from the ClearCase file as in your suggestion.
I've also come up with a solution for part of the problem, that of
Vim's insistence on converting a name like
/project/xyz/system/src/bar.c@@/main/42
(through chdir() and getcwd()) to a name like
/view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main
Using the following autocommand seems to fix that by restoring the
original file name. I thought I had tried this solution before and
it didn't work, but it seems to work now, so I must have had
something set differently before.
au VimEnter /view/*@@/* silent windo
\ exe 'file' system('cleartool des -short -cview "'.expand("%").'"')
The windo command covers the case where vim was invoked as vimdiff
to compare two ClearCase versions.
Thanks again,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Vim's mch_FullName() function and ClearCase versioned file names
I just finished troubleshooting a problem that had several
contributing factors, one of which was the way Vim's mch_FullName()
function behaves with ClearCase versioned file names.
If you open a file under ClearCase using the full path name and a
version extension, e.g.,
/project/xyz/system/src/bar.c@@/main/42
Vim will ask mch_FullName() for the full name of that file.
mch_FullName() will then extract everything to the left of the last
'/' as the directory containing the file and chdir() to that
directory, e.g.,
chdir("/project/xyz/system/src/bar.c@@/main")
mch_FullName() then calls getcwd() to determine the operating
system's name for that directory, which from ClearCase is
/view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main
mch_FullName() then puts back the trailing "file name" of "42" in
this case and returns the full file name as
/view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main/42
This is the name that is then given to the buffer used for that file
and which appears in the status line.
This is a valid file name which points to the correct file and works
with most external commands. However, it does not work with those
external commands or Vim autocommands whose behavior depend on the
file name suffix. It's also really ugly in the status line.
I've used autocommands like this one,
au BufRead *@@/main* exe "doau BufRead " .
\ strpart(expand(""),0,stridx(expand(""),"@@"))
to solve the problem of getting filetype.vim to recognize the file
types of version-extended file names, but I haven't been able to
come up with anything that will force Vim to use the
version-extended file name for the buffer name when the full path to
the file is given.
Sd does anyone here have any thoughts on this, such as an
autocommand or an alternative implementation of mch_FullName()?
Regards
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Bug in filetype.vim w.r.t. mutt temp file names
I noticed recently that vim does not always set 'filetype' to "mail"
when I edit mutt temporary files, e.g., postponed messages. I
traced the problem to mutt's use of mktemp() with the pattern
"muttXX". I don't know about other OSs, but mktemp() on SunOS
5.8 replaces those Xs with characters from the POSIX portable
filename character set:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -
The pattern used in filetype.vim to match file names of this form is
mutt\w\{6\}
The "\w" character class does not include the characters '.' or '-'.
I replaced that pattern with this one:
mutt[[:alnum:]._-]\{6\}
I was surprised that [:alnum:] worked in the context of an
autocommand filename pattern. I didn't want to use "\f" because it
included too much.
A patch is attached. I have posted it here rather than sending it
to Bram directly to allow others to comment in case I missed
something.
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
*** filetype.vim.orig Mon May 8 16:43:45 2006
--- filetype.vimTue Jul 25 13:27:55 2006
***
*** 877,883
au BufNewFile,BufRead *.mgp setf mgp
" Mail (for Elm, trn, mutt, rn, slrn)
! au BufNewFile,BufRead
snd.\d\+,.letter,.letter.\d\+,.followup,.article,.article.\d\+,pico.\d\+,mutt{ng,}-*-\w\+,mutt\w\{6\},ae\d\+.txt,/tmp/SLRN[0-9A-Z.]\+,*.eml
setf mail
" Mail aliases
au BufNewFile,BufRead /etc/mail/aliases,/etc/aliases setf mailaliases
--- 877,883
au BufNewFile,BufRead *.mgp setf mgp
" Mail (for Elm, trn, mutt, rn, slrn)
! au BufNewFile,BufRead
snd.\d\+,.letter,.letter.\d\+,.followup,.article,.article.\d\+,pico.\d\+,mutt{ng,}-*-\w\+,mutt[[:alnum:]._-]\{6\},ae\d\+.txt,/tmp/SLRN[0-9A-Z.]\+,*.eml
setf mail
" Mail aliases
au BufNewFile,BufRead /etc/mail/aliases,/etc/aliases setf mailaliases
Re: Suggestion for a change to compiler/gcc.vim
On 2006-07-22, Nikolai Weibull <[EMAIL PROTECTED]> wrote: > On 7/22/06, Ilya <[EMAIL PROTECTED]> wrote: > > Nikolai Weibull wrote: > > > > So the addition of %-G%.%# to exclude anything but the defined formats > > > from the listing saves us the trouble of seeing useless compiler > > > command-lines in the list of changes. > > > If this is really such a drastic change, then maybe you could make it > > optional? So that one who likes (or dislikes) pressing enter could add > > let g:compiler_gcc_show_success_lines = 1 (or let > > g:compiler_gcc_hide_success_lines = 1) to his or her .vimrc to have > > desired behavior. > > Yes, that's certainly a way of doing it. Anyone have any more input? > I guess to stay with how things have worked we should use > g:compiler_gcc_hide_success_lines. > > Also, am I the only one annoyed by having to deal with the extra lines > after a successful compile? No, they annoy me too. I have had %-G%.%# as the last component of my gcc errorformat for as long as I can remember and have never had any problems with it. I suppose for backwards compatibility you should use g:compiler_gcc_hide_success_lines. On the other hand, it seems unlikely that a script or a user would depend on the presence of those extra lines, and the new or inexperienced user who would be most likely to be confused by those extra lines is also the user least likely to find the g:compiler_gcc_hide_success_lines option. So if you wanted to keep it simple, I think it would be OK to just add that term unconditionally. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Suggestion for difference mode
On 2006-07-22, Christ van Willegen <[EMAIL PROTECTED]> wrote: > Hi, > > I only recently joined, I don't know if this has been discussed before... > > At the company where I work, we sometimes copy source from one project > to another, usually between classes of the same fuctionality, but > different naming. > > vim -d does almost what I want, but: > - Highlights differences in class names, and > - When putting/getting differencens, the class name is not updated. > > It would be nice to have options to 'tweak' the difference mode so > that some strings can be set as identical between one window and > another, also enabling the 'get' and 'put' commands to auto-replace > these strings on getting/putting. This may not be quite what you're looking for, but what I have done in similar situations is to rename all the conflicting symbols in the "from" buffer to the names used in the "to" buffer, then execute ":diffu". Then I can more easily see the differences I'm really interested in. When I'm done editing, I save the changes to the "to" file but discard the changes made in the "from" buffer. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Terminal-based auto-paste.
On 2006-07-10, Sean Reifschneider <[EMAIL PROTECTED]> wrote: > On Mon, Jul 10, 2006 at 07:38:02AM +, Yakov Lerner wrote: > >package-maintiners and expect them to fine-tune binary packages > >to your inquiries/needs/wishes. Unless you are package-maintiner > > Having an expert tune the packages for the general cases is probably going > to work much better on average than having the layman try to tune it > themselves. A good package maintainer can make it so that a package fits > nearly everyone's needs. I have submitted a suggestion to the Fedora > packager that they extend the "vim-x11" package to include not only "gvim", > but also "xvim", leaving the stock "vim" package being compiled with > --with-x=no. This way you get the fairly minimal package in "vim-minimal", > and users who want vim on a server without X installed are happy. And > users who want enhanced X capabilties can install "vim-x11" and get > enhanced functionality by calling (or aliasing) gvim or xvim. Since you mention aliasing, I think the simplest solution to this would be: alias vim="gvim -v" That will give you a terminal-mode vim with all the X features that were compiled into your gvim. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
typo in vim70/doc/autocmd.txt
In the description of the QuickFixCmdPre event in vim70/doc/autocmd.txt, the second reference to "vimgrepadd" should instead be to "lvimgrepadd". Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA *** autocmd.txt.origMon May 8 17:11:01 2006 --- autocmd.txt Fri Jun 23 12:17:09 2006 *** *** 656,662 QuickFixCmdPreBefore a quickfix command is run (|:make|, |:lmake|, |:grep|, |:lgrep|, |:grepadd|, |:lgrepadd|, |:vimgrep|, |:lvimgrep|, ! |:vimgrepadd|, |:vimgrepadd|). The pattern is matched against the command being run. When |:grep| is used but 'grepprg' is set to "internal" it still matches "grep". --- 656,662 QuickFixCmdPreBefore a quickfix command is run (|:make|, |:lmake|, |:grep|, |:lgrep|, |:grepadd|, |:lgrepadd|, |:vimgrep|, |:lvimgrep|, ! |:vimgrepadd|, |:lvimgrepadd|). The pattern is matched against the command being run. When |:grep| is used but 'grepprg' is set to "internal" it still matches "grep".
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
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: matchparen bug?
On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > On 06/07/2006 15:10, Gary Johnson wrote: > > On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > > I haven't been following this discussion very closely, but I just > > tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP > > with vim 7.0, no patches, and the cursor always goes to the 'o' in > > the third line. Is that what you were looking for? > > Which test case are you using? My original snippet: > > let g:loaded_autoit_completion = 1 > let s:cache_name = [] > " This function is used for the 'omnifunc' option. > > Or Benji's: > > long line > () > another > > Reason I'm asking is because if you're using mine, then you do NOT see the > bug. If you're using Benji's then you do see the bug. It's an unfortunate > coincidence that 'o' signifies a success in one case but a failure in the > other. I was using Benji's. To be precise, I started vim at the shell prompt in Unix and at the Command Prompt in Windows as vim -u NONE Then I executed :set nocp Then I either typed or pasted long line () another and deleted the empty line 4, if present, so that the buffer contained only those three lines. Then I executed :runtime plugin/matchparen.vim And finally, I moved the cursor to the first line, typed $i and the cursor went to the 'o' in 'another' in all three cases. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: matchparen bug?
On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > On 06/06/2006 23:47, Benji Fisher wrote: > > I am stumped. I tried it with > > > > $ vim -u NONE > > :set nocp > > :runtime plugin/matchparen.vim > > > > and I still get the cursor on the "o" in the third line. > > Benji, Ilya, > > I appreciate both of you taking the time to investigate. I'm a little > puzzled why Benji and I are seeing this issue, but Ilya is not. > > Can anyone else either confirm or refute this? Is it perhaps a > Windows-specific bug? I only currently have access to Vim 7 on a Windows > system, so I'm unable to test it under Linux. I haven't been following this discussion very closely, but I just tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP with vim 7.0, no patches, and the cursor always goes to the 'o' in the third line. Is that what you were looking for? HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Bug: :cn doesn't open folds when rhs of map
On 2006-05-09, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > Gary Johnson wrote: > > > Summary: > > > > By default, :cn should open a closed fold, and when executed as > > ":cn", it does so. But when :cn is the rhs of a map and the lhs > > of the map is typed, closed folds do not open. I think :cn > > should behave the same whether executed directly or as part of a > > map. > > Nope. If you make a mapping you need to open folds in the mapping. > > It's done this way to make it possible to move around in a mapping > without folds opening everywhere. It's simple to open a fold when you > want to. OK, I can understand that. Per Nikolai's suggestion, I added zv at the end of the mappings, which seems to work fine. Thank you both. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Bug: :cn doesn't open folds when rhs of map
Summary: By default, :cn should open a closed fold, and when executed as ":cn", it does so. But when :cn is the rhs of a map and the lhs of the map is typed, closed folds do not open. I think :cn should behave the same whether executed directly or as part of a map. This behavior is the same in Vim-7.0 and Vim-6.4. I just noticed it now because I'm starting to work with some file types that open with folds initially closed. The behavior is also the same in vim built for SunOS 5.8 and in gvim on Windows XP. Replication Instructions: 1. Create the following test file, mary. --- cut here --- Mary had a little lamb, Its fleece was white as snow, And everywhere that Mary went, The lamb was sure to go. It followed her to school one day, Which was against the rule, And made the children laugh and play To see a lamb at school. --- cut here --- 2. Start vim in the same directory as mary. vim -N -u NONE 3. Execute the following vim commands. map :cn set foldmethod=expr set foldexpr=getline(v:lnum)!~'^$' grep lamb mary The foldexpr makes each paragraph a fold. 4. The file opens with the first paragraph/fold open and the second paragraph/fold closed, as it should. 5. Type twice. The second paragraph/fold remains closed. I believe this is a bug. 6. Execute :cp :cn The second paragraph/fold is now opened, as it should be. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: More about 7.0g
On 2006-05-02, Robert Webb <[EMAIL PROTECTED]> wrote: > > > - I'd like to be able to put whatever name I want on the tabs. > > > There doesn't seem to be a way to do this. 'guitablabel' is an > > > option *shared* by all tabs, so I can't set one tab to "Work" and > > > another to "Play" for example, and can only set them to different > > > names if the names are based on their files etc. All I want to do > > > is set the name of each tab to a fixed string. > > > > You can set 'guitablabel' to a function, as shown in the example > > under ":help setting-guitablabel". Then you can define a function > > to do something as a function of the tab number returned by > > tabpagenr(), such as returning the name of the tab stored in a list > > indexed by tab number. > > Hmm, good idea. So maybe it is possible, but still not exactly > user-friendly or easy. A per-tab setting similar to 'guitablabel' > would make things much easier. Agreed. > I would probably also only want to set a specific name for some of the > tabs, leaving the others with the default behaviour. That would > require my function to reproduce all the cleverness of the built-in > behaviour. Or can I just return an empty string from the function to > make that happen for selected tabs? I don't think so. > Also, depending on the tab number means I can't rearrange the tabs > without breaking the function. Whereas I presume per-tab options move > when their tabs are moved. All good points. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: More about 7.0g
On 2006-05-02, Robert Webb <[EMAIL PROTECTED]> wrote: > Some more suggestions that are probably too late for this release: > - I'd like to be able to put whatever name I want on the tabs. There > doesn't seem to be a way to do this. 'guitablabel' is an option > *shared* by all tabs, so I can't set one tab to "Work" and another to > "Play" for example, and can only set them to different names if the > names are based on their files etc. All I want to do is set the > name of each tab to a fixed string. You can set 'guitablabel' to a function, as shown in the example under ":help setting-guitablabel". Then you can define a function to do something as a function of the tab number returned by tabpagenr(), such as returning the name of the tab stored in a list indexed by tab number. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Vim-7.0f: error in help for :tabmove
:help :tabmove now (in 7.0f) contains this: *:tabm* *:tabmove* :tabmove N Move the current tab page to after tab page N. Use zero to make the current tab page the first one. Without N the tab page is made the last one. I believe that the command should be shown with brackets around the optional part, like this: :tabm[ove] NMove the current tab page to after tab page N. Use zero to Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: netrw 'filetype'
On 2006-04-13, Gary Johnson <[EMAIL PROTECTED]> wrote: > 7.x plugins, for those of use who will be using both versions for s/use/us/ I'm not from Chicago, really; I just can't type. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: netrw 'filetype'
On 2006-04-13, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: > Hari Krishna Dara wrote: > > > This is exactly the reason, I didn't suspect this at all. I had netrw in > > my plugin directory for use with 6.3 Vim. Now, how do I make sure I can > > use the same plugin directory for both 6.3 and 7.0? I think the > > g:loaded_xxx variable should be different for these two so that we can > > control them independently. Since it took the role of explorer plugin > > in 7.0, how about using the loaded_explorer instead of loaded_netrw in > > 7.0 (unless there is a better solution)? > Bottom line: there's no point. Netrw, now a vim 7.0 autoload-using > plugin, just isn't compatible with 6.x. > Attempts to use vim 6.x with 7.0-plugins is going to result in lots of > errors. In light of that, is there a preferred method for using both 6.x and 7.x plugins, for those of use who will be using both versions for possibly quite a while? My thought was to create two new .vim directories, ~/.vim_6_only and ~/.vim_7_only, for those plugins that will work with only one version or the other. Then put this in your ~/.vimrc if v:version >= 700 let &rtp = "$HOME/.vim_7_only," . &rtp . ",$HOME/.vim_7_only/after" else let &rtp = "$HOME/.vim_6_only," . &rtp . ",$HOME/.vim_6_only/after" endif Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
