Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 26 Oct 2005 00:37:29 -0400 (EDT) From: Igor Pechtchanski Reply-To: cygwin AT cygwin DOT com To: Arend-Jan Westhoff cc: cygwin AT cygwin DOT com Subject: Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34 In-Reply-To: <20051026033721.9D13C268F@dot.warande.net> Message-ID: References: <20051020144227 DOT GB28514 AT trixie DOT casa DOT cgf DOT cx> <20051026033721 DOT 9D13C268F AT dot DOT warande DOT net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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/ |\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com |,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/