feature request: don't write backup if the file is unmodified
Hi, Would it be possible to make Vim overwrite a backup file only if the buffer was actually modified? Look at the following scenario: 1. I edit file foobar.txt, make some change and save it. -> the backup file foobar.txt~ is created 2. I edit again foobar.txt, but this time I don't make any change. I do however write the file with ':w' by mistake... -> the backup file foobar.txt~ is replaced and both files have now the same content. If there is some problem in replacing the current behaviour, could it maybe be an option? Thanks, David -- David Schweikert| phone: +41 44 632 7019 System manager ISG.EE | walk: ETH Zentrum, ETL F24.1 ETH Zurich, Switzerland | web: http://people.ee.ethz.ch/dws
[Fwd: Re: vimshell feature? [oops]]
Apparently the second try didn't succeed any better than the first one. This way you (David) won't need to try a third time. I'm sending it to vim-dev rather than vim@ because IMHO it's more on-topic for that list. Original Message Subject: Re: vimshell feature? [oops] Date: Thu, 12 Oct 2006 17:47:21 -0700 (PDT) From: David Thompson <[EMAIL PROTECTED]> To: A.J.Mechelynck <[EMAIL PROTECTED]> oops, I meant to send that vim@vim.org ... stand by as I resend ... --- David Thompson <[EMAIL PROTECTED]> wrote: --- "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote: > David Thompson wrote: > > I've been playing with ':vimshell' command from > > > > http://www.wana.at/vimshell/ > > > > and was wondering what the current opinion is > > about officially adding a shell feature into vim. > > > > Please please, Bram, can you add this to vim? > > > > (*ducks for cover*) > > I think you're right to duck for cover: AFAIK, Bram's standing on that matter > has not changed for years and is not going to change overnight: see ":help > design-not". Yeah, I recall some of that history. But Vim windows are a viewport onto a buffer, and just because the buffer is being filled with text from shell commands, and I can input commands into that buffer that are executed by a shell, well ... It just seems like vim is becoming extremely powerful and customizable enough that *it should be able* to handle the simple thought extension that a window is a viewport onto a shell (or debugger) session, kinda like the thought process of what this vimshell patch tries to do. Besides, Bram's argument is antiquated. Vim has become bloated to the point of interfacing with everything else under the sun, such as perl, python, c-scope ... and, mind you, there exists feature.h which can DISABLE these cool bloated things which are pet projects and wonderful features for their believers. So, why not interface vim with a shell? Then, why not add a #define to feature.h to disable this feature? It seems this argument of "pinciple" is becoming abused. For those who spend all day interfacing to perl, python, cscope, etc, it is a Good Thing for vim to interface to their environment. I see no difference in this argument in why the shell and the debugger don't qualify for such interfaces. (*runs for cover again*) -- David Personally I don't feel any need to run bash or cmd inside Vim rather than as a distinct process. This feeling of mine (or lack of one) may be related to the fact that I can open any number of program windows (gvim, a shell, a browser, a mail client, ...) in a Windows or X11 session, and that even in the non-X runlevels of Linux I can have up to six "virtual consoles" in parallel (so I can run Vim in, say, /dev/tty2, and a shell in /dev/tty3, and switch from one to the other by [Ctrl-]Alt-F2 or [Ctrl-]Alt-F3. Also, I'm not convinced of the portability of shell embedding between Unix and Windows. Is it worth trying to add a complex feature of dubious utility if it cannot even be reconciled between the two major Vim platforms? (And I'm not forgetting the Mac but I don't know it well enough.) As an unofficial patch (or set of patches), I'm not against it as long as I don't have to maintain or compile it myself; but I don't see the usefulness of having it in the "official" distribution (where Bram would have to maintain it if ever its maintainer disappeared). Best regards, Tony.
Re: vim and 64bit xp
Brian Krusic wrote: Thanks fo rthe reply. Still no shell extension. I did the regedit approach. Any ideas? Is Gvimext.dll in a directory in your PATH? Check it at the dos-box prompt: echo %PATH% or in Vim: :echo $PATH If it isn't, you can set it in (IIRC) Control Panel -> System -> Advanced -> Environment variables The Dos/Windows PATH is a semicolon-separated list of directories; the directory containing that DLL may be either the same as for gvim.exe (usually something like "C:\Program Files\Vim\vim70") or a "gvimext" subdirectory of that (I'm not on Windows at the moment and can't check). Best regards, Tony.
Re: Why not commit runtime files?
David Brown wrote: [...] I had the same kind of problem when maintaining CVS for vim 6. I tried updating the runtime files, and would occasionally get a patch that wouldn't apply, because something did get patched in a runtime file. Dave Yeah. Nowadays I rsync my runtime files from time to time; and now and then there is a "hunk" for a runtime file that gets rejected in a patch. Then I compare the file with the patch text and usually it's because the patch is already included in the file I have. Not really a problem. Best regards, Tony.
Re: Why not commit runtime files?
> I don't know exactly; but I think the various repositories (rsync, FTP, > CVS, SVN) are not maintained by the same people. I think CVS and SVN use > the FTP site as a "master" with automated updates (but not every day), > so that the FTP updates "trickle down" to the CVS/SVN repositories after > a delay of a few days or weeks. Only source files and some runtime files maintained directly by Bram. Updates send by other authors are rarely or never committed to CVS. SVN is synchronised only with CVS. Yes, it is a pity runtime files are not updated in CVS :( Theoretically I (and probably other people) could rsync directory according to your tip but it would wreak havoc in CVS structure... m.
Re: Why not commit runtime files?
A.J.Mechelynck wrote: >> I see some comment about runtime files not having patches; but >> committing to cvs does not require creating a patch; one can just >> command cvs to commit a local directory to the repository. > I don't know exactly; but I think the various repositories (rsync, FTP, > CVS, SVN) are not maintained by the same people. I think CVS and SVN use > the FTP site as a "master" with automated updates (but not every day), so > that the FTP updates "trickle down" to the CVS/SVN repositories after a > delay of a few days or weeks. That used to be the case (before vim 7). I was the latest person who pushed the patches through to cvs. I got them the same time everyone else did, and had scripts that would push them through to CVS. Now Bram is maintaining CVS himself, which is probably why the runtime files don't get maintained regularly, since he's not the one that regularly does that. I had the same kind of problem when maintaining CVS for vim 6. I tried updating the runtime files, and would occasionally get a patch that wouldn't apply, because something did get patched in a runtime file. Dave
Re: Why not commit runtime files?
Suresh Govindachar wrote: A.J.Mechelynck wrote: >Suresh Govindachar wrote: >> Hello, >> >> I have just found out that while the runtime directory is >> periodically updated on the ftp site, it is not committed to >> the cvs repository. >> >> What is the reason for not committing runtime files into cvs? >> >> I see some comment about runtime files not having patches; but >> committing to cvs does not require creating a patch; one can >> just command cvs to commit a local directory to the repository. > > I don't know exactly; but I think the various repositories > (rsync, FTP, CVS, SVN) are not maintained by the same people. I > think CVS and SVN use the FTP site as a "master" with automated > updates (but not every day), so that the FTP updates "trickle > down" to the CVS/SVN repositories after a delay of a few days > or weeks. I thought Bram (and only Bram) maintained the cvs repository; and that all other repositories, such as svn, are "copies" of the cvs repository. Anyway, even though the .c and .h files in the svn repository change, the runtime files in the svn repository are not changing -- at least netrw seems to be stuck at v98. --Suresh Dr Chip's scripts have been updated only a few days ago on the FTP site; I suppose the next CVS sync run will pick them up. Do you know the timestamp of the latest runtime file on CVS? Best regards, Tony.
RE: Why not commit runtime files?
A.J.Mechelynck wrote: >Suresh Govindachar wrote: >> Hello, >> >> I have just found out that while the runtime directory is >> periodically updated on the ftp site, it is not committed to >> the cvs repository. >> >> What is the reason for not committing runtime files into cvs? >> >> I see some comment about runtime files not having patches; but >> committing to cvs does not require creating a patch; one can >> just command cvs to commit a local directory to the repository. > > I don't know exactly; but I think the various repositories > (rsync, FTP, CVS, SVN) are not maintained by the same people. I > think CVS and SVN use the FTP site as a "master" with automated > updates (but not every day), so that the FTP updates "trickle > down" to the CVS/SVN repositories after a delay of a few days > or weeks. I thought Bram (and only Bram) maintained the cvs repository; and that all other repositories, such as svn, are "copies" of the cvs repository. Anyway, even though the .c and .h files in the svn repository change, the runtime files in the svn repository are not changing -- at least netrw seems to be stuck at v98. --Suresh
Re: Why not commit runtime files?
Suresh Govindachar wrote: Hello, I have just found out that while the runtime directory is periodically updated on the ftp site, it is not committed to the cvs repository. What is the reason for not committing runtime files into cvs? I see some comment about runtime files not having patches; but committing to cvs does not require creating a patch; one can just command cvs to commit a local directory to the repository. --Suresh I don't know exactly; but I think the various repositories (rsync, FTP, CVS, SVN) are not maintained by the same people. I think CVS and SVN use the FTP site as a "master" with automated updates (but not every day), so that the FTP updates "trickle down" to the CVS/SVN repositories after a delay of a few days or weeks. Best regards, Tony.
Why not commit runtime files?
Hello, I have just found out that while the runtime directory is periodically updated on the ftp site, it is not committed to the cvs repository. What is the reason for not committing runtime files into cvs? I see some comment about runtime files not having patches; but committing to cvs does not require creating a patch; one can just command cvs to commit a local directory to the repository. --Suresh
Re: Win32 vim.exe blows up reading from stdin
Dave Roberts wrote: > Somewhere between v7.0.118 and v7.0.131 Vim started blowing up when > started with a "-" to read from stdin. Ex. "vim -u NONE -" > > If no one else is having this problem I'll supply more > compile/environment info. > > I use gvim as a "less" program all the time so I know this wasn't > happening earlier. I'll fix it. -- hundred-and-one symptoms of being an internet addict: 30. Even though you died last week, you've managed to retain OPS on your favorite IRC channel. /// 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///
Patch 7.0.132
Patch 7.0.132 (after 7.0.130)
Problem:Win32: Crash when Vim reads from stdin.
Solution: Only use mch_nodetype() when there is a file name.
Files: src/fileio.c
*** ../vim-7.0.131/src/fileio.c Tue Oct 10 18:43:50 2006
--- src/fileio.cThu Oct 12 20:50:35 2006
***
*** 416,435
msg_scroll = msg_save;
return FAIL;
}
- }
- #endif
! #if defined(MSDOS) || defined(MSWIN) || defined(OS2)
! /*
! * MS-Windows allows opening a device, but we will probably get stuck
! * trying to read it.
! */
! if (!p_odev && mch_nodetype(fname) == NODE_WRITABLE)
! {
! filemess(curbuf, fname, (char_u *)_("is a device (disabled with
'opendevice' option"), 0);
! msg_end();
! msg_scroll = msg_save;
! return FAIL;
}
#endif
--- 416,435
msg_scroll = msg_save;
return FAIL;
}
! # if defined(MSDOS) || defined(MSWIN) || defined(OS2)
! /*
!* MS-Windows allows opening a device, but we will probably get stuck
!* trying to read it.
!*/
! if (!p_odev && mch_nodetype(fname) == NODE_WRITABLE)
! {
! filemess(curbuf, fname, (char_u *)_("is a device (disabled with
'opendevice' option"), 0);
! msg_end();
! msg_scroll = msg_save;
! return FAIL;
! }
! # endif
}
#endif
*** ../vim-7.0.131/src/version.cTue Oct 10 21:56:37 2006
--- src/version.c Thu Oct 12 21:13:34 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 132,
/**/
--
hundred-and-one symptoms of being an internet addict:
31. You code your homework in HTML and give your instructor the URL.
/// 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: Convert2HTML Again
On 12/10/06, Benji Fisher <[EMAIL PROTECTED]> wrote: (text) in the body, while the non-CSS version will have something like (text) and now the CSS version is easier to read. Yes I see, If i had written this from scratch i would have not included tags atall because they are depricated. I was just respecting the existing code to be honest. This would have to be something you take up with the original writer(?) or Bram(?). I'll check the syntax error highlight for you too. Will probably get a chance at the weekend. Thanks for your time. Best Regards Edd
Re: Convert2HTML Again
On Wed, Oct 11, 2006 at 06:48:47PM +0100, Edd Barrett wrote: > > On 10/10/06, Benji Fisher <[EMAIL PROTECTED]> wrote: > > > > The samples look fine to me (using Mozilla 1.7.12 on Linux). I > >would like to see an example where the background color changes, if only > >so that I can see some situation where > > > > (text) > > > >looks simpler (by rudimentary measures such as character count) than > > > > (text) > > I'm not sure what you mean here. Please explain... I just mean that, looking at the above example and just thinking about how easy it is to read the source, there does not seem to be any advantage to using CSS. With CSS, there will be extra material in the header (defining the attributes for the foo class) and the markup in the body will be about as complicated. However, if the bar class defines foreground and background colors, then the CSS version will still have something like (text) in the body, while the non-CSS version will have something like (text) and now the CSS version is easier to read. If you add a syntax error to your example file, then it should show up with Error highlighting. With most color schemes, this will change the background color as well as the text color. Then we can see how this gets translated into HTML or XHTML. HTH --Benji Fisher
