VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34

[Arend-Jan Westhoff]

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 X.sh
succeeds, while:
 	ls X*
fails miserably in displaying the file in the above example. 
(Assuming default case sensitivity settings.)

My goal is to attempt to reduce the weirdness that Cygwin introduces on top 

of the weirdness put into Windows by Microsoft. The Cygwin weirdness
we can do something about. (Just for the record, so you know I'm really not 
into Cygwin bashing I'll relate one Microsoft weirdness item with filename 
completion at the end.)

>>  (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...
>

In general when we explicitly provide a new filename we want the system to use
that one. If in that place we want to provide something that matches an 
existing filename e.g. cmd filename completion can help with that. 
To stick with the above example where we have file:
 	x.sh
We want to rename file foo into a format similar to this existing file but we
have the erroneous notion that it has the other format:
 	X.sh
So we start with:
 	rename foo X<TAB>
then this is completed into:
 	rename foo x.sh
So our wrong notion is corrected by filename completion and we can now 
complete the rename so it matches the case of x.sh by executing e.g.:
 	rename foo y.sh
As I understand from you and Eric Blake bash filename completion is much
more powerful, so I'll assume it can do as much. (But I have not verified 
that case insensitivity settings carry over into vim, so one might have to 
explicitly vary the case there.)
For the record: Basic vim filename completion:
 	vim foo
 	:set nocp
 	:w x<TAB>
 	modify destination

>> 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

Thanks for the pointers.
With regard to case sensitivity settings I found some notes I made on that
earlier this year. Comparing them with what you are saying I have the
following
questions:
1. <http://cygwin.com/faq/faq_3.html#SEC38> states, additionally:
Add the following to your ~/.bashrc file: 
 	shopt -s nocaseglob
Am I correct in understanding: Is in use and handles wildcard expansion?
2. What about the Cygwin variable setting:
 	glob:ignorecase
Is this still in use? If so, is this the way to influence Cygwin programs
when 
running them from cmd instead of bash?

Now the promised example of Windows weirdness with filename completion:
cmd filename completion does not work on files starting with e.g.: 
 	+
when you provide some initial characters of the filename.
(At least not on my Windows 2000 system.)

Arend-Jan.

--
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/