This is the mail archive of the
cygwin
mailing list for the Cygwin project.
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/
|\ _,,,---,,_ pechtcha@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.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/