Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
On 20-Oct-2005 16:42, Christopher Faylor wrote: On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote: there is a bug in this version: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This behavior is very nasty if such file is used by programs which are case-sensitive for file names, example: SCM program perforce. This isn't a vim problem. Windows filename handling is case-insensitive. I suppose that there could be a vim option to deal with this case but that would require modifying vim, i.e., PTC* by the upstream vim developers. Actually, there already is such an option... $ touch X $ ls -l total 0 -rw-r--r-- 1 mscha None 0 Nov 4 01:29 X $ vim x :wq! $ ls -l total 0 -rw-r--r-- 1 mscha None 0 Nov 4 01:30 x $ rm x $ touch X $ vim -c 'set backupcopy=yes' x :wq! $ ls -l total 0 -rw-r--r-- 1 mscha None 0 Nov 4 01:30 X See :help backupcopy for details. It defaults to auto, which is kinda unpredictable. Set it to yes, and it might be a bit slower, but won't mess with your case. :-) - Michael -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
On Fri, 4 Nov 2005, Michael Schaap wrote: On 20-Oct-2005 16:42, Christopher Faylor wrote: On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote: there is a bug in this version: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This behavior is very nasty if such file is used by programs which are case-sensitive for file names, example: SCM program perforce. This isn't a vim problem. Windows filename handling is case-insensitive. I suppose that there could be a vim option to deal with this case but that would require modifying vim, i.e., PTC* by the upstream vim developers. Actually, there already is such an option... $ touch X $ ls -l total 0 -rw-r--r-- 1 mscha None 0 Nov 4 01:29 X $ vim x :wq! $ ls -l total 0 -rw-r--r-- 1 mscha None 0 Nov 4 01:30 x $ rm x $ touch X $ vim -c 'set backupcopy=yes' x :wq! $ ls -l total 0 -rw-r--r-- 1 mscha None 0 Nov 4 01:30 X See :help backupcopy for details. It defaults to auto, which is kinda unpredictable. Set it to yes, and it might be a bit slower, but won't mess with your case. :-) More interestingly, :help backupcopy says: (Vi default for Unix: yes, otherwise: auto) This means that VIm treats Cygwin as non-Unix. Shouldn't the Cygwin default be the same as for Unix? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
On 4-Nov-2005 1:49, Igor Pechtchanski wrote: On Fri, 4 Nov 2005, Michael Schaap wrote: On 20-Oct-2005 16:42, Christopher Faylor wrote: On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote: there is a bug in this version: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This behavior is very nasty if such file is used by programs which are case-sensitive for file names, example: SCM program perforce. This isn't a vim problem. Windows filename handling is case-insensitive. I suppose that there could be a vim option to deal with this case but that would require modifying vim, i.e., PTC* by the upstream vim developers. Actually, there already is such an option... $ touch X $ ls -l total 0 -rw-r--r-- 1 mscha None 0 Nov 4 01:29 X $ vim x :wq! $ ls -l total 0 -rw-r--r-- 1 mscha None 0 Nov 4 01:30 x $ rm x $ touch X $ vim -c 'set backupcopy=yes' x :wq! $ ls -l total 0 -rw-r--r-- 1 mscha None 0 Nov 4 01:30 X See :help backupcopy for details. It defaults to auto, which is kinda unpredictable. Set it to yes, and it might be a bit slower, but won't mess with your case. :-) More interestingly, :help backupcopy says: (Vi default for Unix: yes, otherwise: auto) This means that VIm treats Cygwin as non-Unix. Shouldn't the Cygwin default be the same as for Unix? Good point, I missed that... Actually, it turns out that Cygwin *does* use the UNIX default. However, when 'compatible' is not set (e.g. when a .vimrc exists) it sets backupcopy=auto. (See :help compatible) That explains the varying experiences in this mailing list... - Michael -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
On Oct 25 12:11, Shankar Unni wrote: Corinna Vinschen wrote: No, it doesn't. I just tried it in 6.3 and this behaviour is the same as in 6.4. ?? % pwd /cygdrive/c/temp/test % ls % touch x % ls -li 20547673299962566 -rw-rw-rw- 1 shankar None 0 Oct 25 12:10 x % vim X % ls -li total 1 20547673299962566 -rw-rw-rw- 1 shankar None 6 Oct 25 12:10 x % mount ... c: on /cygdrive/c type system (textmode,noumount) Case preserved, and looks like it overwrote the old file (instead of moving it out of the way and writing a new file). Running cygwin 1.5.18-1, vim 6.3-1 and cygwin 1.5.18-1, but a snapshot DLL: You're doing something differently here, perhaps in vim itself. I can easily reproduce with vim 6.3: $ touch x $ ls -li $ total 0 3096224744087416 -rw-r--r-- 1 corinna root 0 Oct 26 09:53 x $ vim --version | grep IMp VIM - Vi IMproved 6.3 (2004 June 7, compiled Oct 24 2005 15:22:43) $ vim X :w :q $ ls -li total 0 2814749767376804 -rw-r--r-- 1 corinna root 0 Oct 26 09:54 X Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
Corinna Vinschen wrote: You're doing something differently here, perhaps in vim itself. For example, the following? :set nobackup nowritebackup If you disable both backup and writebackup, it leaves the file name unchanged when you write to it. So there's a workaround if you don't care about those features. :-) -- Looking at the source, I think I found where VIM adjusts for pseudo-case-sensitive file names: the fname_case() function modifies the file name to match an existing file if present. The function is defined in os_win32.c and os_msdos.c but not in os_unix.c. There is also a USE_FNAME_CASE macro to protect calls to it. Simply defining that macro and function isn't enough, since it is used in the os_mswin.c version of mch_FullName(), but not it the version in os_unix.c. But it looks like a conditional call to fname_case() could be added to the end of the UNIX version, since this construct appears elsewhere in common code. You'd most likely want to use a Cygwin-specific implementation of fname_case() that doesn't convert slashes into backslashes, honors mount points, etc. gsw -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
At 00:37 2005-10-26 -0400, Igor Pechtchanski wrote: On Wed, 26 Oct 2005, Arend-Jan Westhoff wrote: Could this for once mean a positive press for text mounts? Or has it something to do with NTFS - FAT32 ? The former is unlikely. The latter is possible. If the latter is true I think that would be bad. (For more: see remark on filesystems below.) How come that if I have text mounts the edit action in the preceding procedure only ads a linefeed but no carriage return? [snip] Ah, because vim has default fileformats=unix,dos instead of dos,unix! Vim autodetects to the mode the file was in. Since you only had one line in your file and no EOL, vim defaulted to Unix fileformat. I thought that was exactly what I was saying with the added bonus of pointing people into the direction how to change it if they want to... (I am sorry I am not as clear a writer as I wish I was.) Though I cannot reproduce the problem I do support those who experience it and want it changed because: -I don't think changing it significantly impacts functionality on other OSs. Huh? Well: 1. The most important other OS is Linux and since that is case sensitive its vim won't be affected by something that affects only case insensitive OSs. (Except perhaps performance wise, but I deem that will be negligible.) (Btw with regard to performance. If I run: bash -c time vim +q and look at the times, I think that compared to a few months ago this and other timings have improved by a factor of 3 to 4. Probably due to compiler modifications. Good work and thanks people!) 2. It would be possible (though perhaps undesirable) to make a Cygwin exception which, by definition, will not impact other OSs. -Whether or not it is a vim bug is irrelevant. What is relevant that it is clearly undesirable behavior. (If vim is the appropriate place to change it it should be done there.) The part of the behavior that's undesirable is creating a new file (i.e., changing the inode). If the file is written in-place (i.e., the inode remains the same), file name changes are irrelevant. Huh? That is not what the OP says: http://cygwin.com/ml/cygwin/2005-10/msg00646.html He only talks about case change and not about inodes. FWIW if I repeat the testcases in my previous post: http://cygwin.com/ml/cygwin/2005-10/msg00875.html and look at inodes I find that the inode does not change. So that is a problem I cannot reproduce either. Also please note that my version is actually somewhate newer than that reported by the OP: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 21 2005 13:43:01) cygcheck.out gives: vim 6.4-2 Can anyone confirm whether any problem with case or inodes as reported in this thread still persists in this version? If it depends on things like filesystems or other local details this is a bad thing, since it implies that a script that runs without problems on one drive/system, may unexpectedly fail on another. -I think the rule should be that where ever a Cygwin utility uses a filename of an existing file it should use the actual name on disk and not the characters the user happened to type. (Wasn't that using something like: _findfirst() ?) (So the dump statement above should not display zz: but ZZ: on its first line of output.) Add check_case:adjust to $CYGWIN for this behavior. Are you saying that you now think differently about this option as in: http://www.cygwin.com/ml/cygwin/2005-01/msg00057.html where you called it pointless, useless and you had nothing against its removal? Anyway the point I was trying to make is not for having to use yet another obscure option that nobody is willing to support but to point out that there is no value in the current default and to advocate a different one. (Which might resemble check_case:adjust. I remember looking at it, probably last year, but apparently I have made no notes of that.) As an illustration of how people can be wrongfooted (twice) by the current default that would be remedied if replaced by the one I propose please imagine the following: -Preparation the user doesn't know about (or doesn't recall): There exists an empty file: x.sh : rm x.sh touch x.sh -User edits: vim X.sh (Thinking he creates the file.) Wrongfooting 1: Vim only talks about: X.sh, e.g. on the titlebar, or when writing the file: X.sh 1 line, 2 characters written -Wrongfooting 2: User checks file X.sh exists by running: ls X.sh which shows: X.sh -In reality all that exists is still: x.sh -User edits again: vim x.sh -Runs: ls Sees: x.sh And user concludes wrongfully that vim has transformed X.sh into x.sh. -Instead of blaming the user I blame the default and propose to change it. (Any similarity between this and OP post might or might not be totally accidental.) Please note that changing this default would also provide some explanation to a user why: ls
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
Corinna Vinschen wrote: No, it doesn't. I just tried it in 6.3 and this behaviour is the same as in 6.4. ?? % pwd /cygdrive/c/temp/test % ls % touch x % ls -li 20547673299962566 -rw-rw-rw- 1 shankar None 0 Oct 25 12:10 x % vim X % ls -li total 1 20547673299962566 -rw-rw-rw- 1 shankar None 6 Oct 25 12:10 x % mount ... c: on /cygdrive/c type system (textmode,noumount) Case preserved, and looks like it overwrote the old file (instead of moving it out of the way and writing a new file). Running cygwin 1.5.18-1, vim 6.3-1 and cygwin 1.5.18-1, but a snapshot DLL: 1762k 2005/09/19 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2005/9/19 8:53 Cygwin DLL version info: DLL version: 1.5.19 [...] Build date: Mon Sep 19 11:53:13 EDT 2005 Snapshot date: 20050919-11:51:47 Shared id: cygwin1S4 Cygcheck not attached, but can be provided if needed. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
At 15:32 2005-10-24 +0200, Corinna Vinschen wrote: On Oct 20 14:16, Shankar Unni wrote: Christopher Faylor wrote: On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This isn't a vim problem. Windows filename handling is case-insensitive. But I think it's worth mentioning that 6.3 doesn't do this (change the case of the name when writing back). It overwrites the old file when writing back, thus preserving its case. No, it doesn't. I just tried it in 6.3 and this behaviour is the same as in 6.4. There is special code in the native Windows port which tests explicitely for the case of the filename, but that's not in the UNIX code which is used for Cygwin. Corinna I cannot reproduce this problem: (Explanatory notes in (). If you don't need them please ignore them.) The procedure creates or overwrites file ZZ: (Should work on both cmd and Cygwin bash. On cmd must have Cygwin\bin dir in PATH.) echo -n ZZ ZZ ( relevance: Use Cygwin echo even on cmd. May be here not strictly necessary, but instructive: In general also return and linefeed will be executed when a vim script is sourced.) (Please note that if a file like Zz preexisted that will still be its name, so:) rename ZZ ZZ (At this point we have a file named: ZZ with contents: ZZ) Now running one of the following two statements produces the same results on my system: vim +s/Z/y/g -s ZZ zz vim +s/Z/y/g +wq zz (Yes, I am violating the standard that files should end with newline, but not relevant IMO.) Results: ls [zZ][zZ] produces: ZZ So no case change: I cannot reproduce the problem. cat zz produces: yy Which shows the edit action was successful. Could this for once mean a positive press for text mounts? Or has it something to do with NTFS - FAT32 ? How come that if I have text mounts the edit action in the preceding procedure only ads a linefeed but no carriage return? dump zz produces: zz: 7979 0a yy. Ah, because vim has default fileformats=unix,dos instead of dos,unix! My cygcheck.out is still the same: http://cygwin.com/ml/cygwin/2005-10/txt00018.txt Though I cannot reproduce the problem I do support those who experience it and want it changed because: -I don't think changing it significantly impacts functionality on other OSs. -Whether or not it is a vim bug is irrelevant. What is relevant that it is clearly undesirable behavior. (If vim is the appropriate place to change it it should be done there.) -I think the rule should be that where ever a Cygwin utility uses a filename of an existing file it should use the actual name on disk and not the characters the user happened to type. (Wasn't that using something like: _findfirst() ?) (So the dump statement above should not display zz: but ZZ: on its first line of output.) (Except of course where the user provides a new name as with the command: rename, or when writing to a different file from vim. One can still use filename completion to match an existing file's name if one wants to.) Please note that my proposal is also in line with the native OS: E.g. Cygwin dir and ls have such problem, the native cmd dir has not: ls zz produces: zz but cmd /c dir /B zz produces ZZ Arend-Jan Westhoff. PS Speaking of filename completion: Windows can be configured to use TAB as cmd file and directory expansion character. I do find the cmd filename completion behaviour more convenient than the default bash version. It is usually not difficult to organize a directory so that TAB or SHIFT-TAB find the desired file/dir quickly. On bash you default get a beep and filename expansion stops whenever there is more than one choice. I hate that. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
tab-completion [was: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34]
PS Speaking of filename completion: Windows can be configured to use TAB as cmd file and directory expansion character. I do find the cmd filename completion behaviour more convenient than the default bash version. It is usually not difficult to organize a directory so that TAB or SHIFT-TAB find the desired file/dir quickly. On bash you default get a beep and filename expansion stops whenever there is more than one choice. I hate that. bash tab-completion is highly programmable. I suggest you read up on 'man bash' and 'man readline'. For example, binding TAB to 'menu-complete' instead of 'complete' changes the behavior of completion to cycle through complete filenames rather than stopping at the unambiguous prefix. Furthermore, with the bash-completion package installed properly, you get some very powerful context-sensitive completions (try doing THAT in windows). Just because the default behavior doesn't match your liking doesn't mean that bash can't do what you want. -- Eric Blake volunteer cygwin bash/bash-completion maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
On Wed, 26 Oct 2005, Arend-Jan Westhoff wrote: Could this for once mean a positive press for text mounts? Or has it something to do with NTFS - FAT32 ? The former is unlikely. The latter is possible. How come that if I have text mounts the edit action in the preceding procedure only ads a linefeed but no carriage return? [snip] Ah, because vim has default fileformats=unix,dos instead of dos,unix! Vim autodetects to the mode the file was in. Since you only had one line in your file and no EOL, vim defaulted to Unix fileformat. Though I cannot reproduce the problem I do support those who experience it and want it changed because: -I don't think changing it significantly impacts functionality on other OSs. Huh? -Whether or not it is a vim bug is irrelevant. What is relevant that it is clearly undesirable behavior. (If vim is the appropriate place to change it it should be done there.) The part of the behavior that's undesirable is creating a new file (i.e., changing the inode). If the file is written in-place (i.e., the inode remains the same), file name changes are irrelevant. -I think the rule should be that where ever a Cygwin utility uses a filename of an existing file it should use the actual name on disk and not the characters the user happened to type. (Wasn't that using something like: _findfirst() ?) (So the dump statement above should not display zz: but ZZ: on its first line of output.) Add check_case:adjust to $CYGWIN for this behavior. (Except of course where the user provides a new name as with the command: rename, or when writing to a different file from vim. One can still use filename completion to match an existing file's name if one wants to.) [snip] Huh? again... PS Speaking of filename completion: Windows can be configured to use TAB as cmd file and directory expansion character. I do find the cmd filename completion behaviour more convenient than the default bash version. It is usually not difficult to organize a directory so that TAB or SHIFT-TAB find the desired file/dir quickly. On bash you default get a beep and filename expansion stops whenever there is more than one choice. I hate that. Bash has programmable completion, which is more than you can say about cmd. One can configure bash completion to act exactly like cmd. Add the following to your ~/.inputrc: set completion-ignore-case on \t:menu-complete (or TAB:menu-complete) to get cmd's behavior (case-insensitive completion and cycling through possibilities). If you want something more sophisticated, read the bash info page on Programmable Completion, or possibly install the bash-completion package (I haven't used it, but it may have what you want). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
On Oct 20 14:16, Shankar Unni wrote: Christopher Faylor wrote: On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This isn't a vim problem. Windows filename handling is case-insensitive. But I think it's worth mentioning that 6.3 doesn't do this (change the case of the name when writing back). It overwrites the old file when writing back, thus preserving its case. No, it doesn't. I just tried it in 6.3 and this behaviour is the same as in 6.4. There is special code in the native Windows port which tests explicitely for the case of the filename, but that's not in the UNIX code which is used for Cygwin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
Shankar Unni wrote: But I think it's worth mentioning that 6.3 doesn't do this (change the case of the name when writing back). It overwrites the old file when writing back, thus preserving its case. More to the point, the windows version of vim 6.4 doesn't do this, either. So there is some code in there somewhere that knows about case-wacky-pseudo-sensitive file systems (OK, it probably just has #ifdef WIN32 around the old method, but still...). gsw P.S. It might be possible to come up with a workaround using some trickery within VIM (e.g., do an ls on the dirname of % via event hook when you open a new file and either rename % somehow or hook into the file write event). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
Hi all, there is a bug in this version: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This behavior is very nasty if such file is used by programs which are case-sensitive for file names, example: SCM program perforce. Thanks, -- Christoph Jeksa, CoCreate Software GmbH Co. KG Posener Str. 1, D-71065 Sindelfingen, Germany E-Mail: [EMAIL PROTECTED] Phone: ( +49 7031 ) 951-2149 Fax:( +49 7031 ) 951-2320 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote: there is a bug in this version: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This behavior is very nasty if such file is used by programs which are case-sensitive for file names, example: SCM program perforce. This isn't a vim problem. Windows filename handling is case-insensitive. I suppose that there could be a vim option to deal with this case but that would require modifying vim, i.e., PTC* by the upstream vim developers. cgf * http://cygwin.com/acronyms/#PTC -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
On Thu, 20 Oct 2005, Christopher Faylor wrote: On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote: there is a bug in this version: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This behavior is very nasty if such file is used by programs which are case-sensitive for file names, example: SCM program perforce. This isn't a vim problem. Windows filename handling is case-insensitive. I suppose that there could be a vim option to deal with this case but that would require modifying vim, i.e., PTC* by the upstream vim developers. Chris, I suppose there's another bet between you and Corinna floaing around in the cygwin-developers land somewhere, but I'll bite. No need to patch vim. This is *exactly* the kind of situation where check_case:strict is useful. With CYGWIN=check_case:strict, vim won't even edit the file x.sh if the file is actually named X.sh. Incidentally, check_case:adjust might also help. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
On Thu, Oct 20, 2005 at 12:26:58PM -0400, Igor Pechtchanski wrote: On Thu, 20 Oct 2005, Christopher Faylor wrote: On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote: there is a bug in this version: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This behavior is very nasty if such file is used by programs which are case-sensitive for file names, example: SCM program perforce. This isn't a vim problem. Windows filename handling is case-insensitive. I suppose that there could be a vim option to deal with this case but that would require modifying vim, i.e., PTC* by the upstream vim developers. Chris, I suppose there's another bet between you and Corinna floaing around in the cygwin-developers land somewhere, but I'll bite. What's the euro/dollar exchange rate these days? No need to patch vim. This is *exactly* the kind of situation where check_case:strict is useful. With CYGWIN=check_case:strict, vim won't even edit the file x.sh if the file is actually named X.sh. Incidentally, check_case:adjust might also help. You're right, I didn't consider recommending an option that Corinna and I consider to be deprecated. Using this option is *guaranteed* to slow Cygwin down and, given that both Corinna and I detest the complications and slow down this option entails, it is entirely possible that it will be broken from time to time. At the risk of being self-indulgent and winning some more bets, I also didn't mention the overkill option of using managed mounts. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
Christopher Faylor wrote: On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This isn't a vim problem. Windows filename handling is case-insensitive. But I think it's worth mentioning that 6.3 doesn't do this (change the case of the name when writing back). It overwrites the old file when writing back, thus preserving its case. I'm guessing 6.4 has been fixed to move the old file out of the way before writing the new file, and you thus end up with the file name in the same case as the command line. Anyway, the use case is illegitimate, so basically, there is no *bug* in Vim behaving either way - it's just undocumented behavior that has changed. Don't mix cases like this .. (P.S. The other way that certain other editors (e.g. Emacs) deal with this, is that they normalize the file name case when they load a file into a buffer, by getting the real path name of the file - that way, even if the rename the old file and create a new one, it'll be created in the right case.) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
