RE: filename completion
>Let's say I want to see which files end with t. When I do > :e *t >vim shows not only files anding with t but all files >containing t, as if I did :e *t*. >How can I limit the filename completion only to files ending with t ? Hmm, would think it's by design, but I tried :e *t$ and that didn't work, so dunno. Imagine it's by design, because you *want* to be able to just hit :e ab and *not* have to specify :e ab* right? Ie, same like 4DOS, various'n'sundry Eunuchs shells, etc., all seem to do. The leading '*' should wildcard any leading chars 'til it finds the literal pattern to match, but yeah, there should be a way to force it match the last char of the filename, eg, by forcing a '$' as I tried, unsuccessfully.
filename completion
Let's say I want to see which files end with t. When I do :e *t vim shows not only files anding with t but all files containing t, as if I did :e *t*. How can I limit the filename completion only to files ending with t ? Yakov
Re: Filename completion with all directories in 'path'?
On Apr 19, 2007, at 7:12 PM, Jean-Rene David wrote: Is there a way to make filename completion (pressing tab at the command line in :find) use all the directories in the 'path'? Not exactly what you ask, but here is a nice little script I use quite a bit which you might find helpful: http://www.vim.org/scripts/script.php?script_id=1581 Thank you, Jean-Rene. I will give this a try. Ben
Re: Filename completion with all directories in 'path'?
* Ben Kovitz [2007.04.19 20:00]: > Is there a way to make filename completion > (pressing tab at the command line in :find) use > all the directories in the 'path'? Not exactly what you ask, but here is a nice little script I use quite a bit which you might find helpful: http://www.vim.org/scripts/script.php?script_id=1581 HTH, -- JR
Filename completion with all directories in 'path'?
Is there a way to make filename completion (pressing tab at the command line in :find) use all the directories in the 'path'? A little background: I have unit tests in one directory, and mainline code in a separate directory. This is needed for source-code control and other things. But it would be nice if, in vim, I could pretend that everything is in one directory. I've done :set path=unit/test/dir,main/code/dir and stuff like ]f and :find works fine. It's just a little jarring that pressing tab when I type :fin only runs through the files in the directory I started in. Ben Kovitz
Re: filename completion not recognising pdf's
On Thu, Oct 19, 2006 at 11:57:22PM +0200, Eric Smith wrote: > Vim does not complete pdf files with C-X C-F. > > Is there a place where I can alter this (mis)behavior? > > -- > Eric Smith It does for me. Two options that may affect this are 'suffixes' and 'wildignore'. The first just gives listed suffixes lower priority, and the second removes them completely. :help 'suffixes' :help 'wildignore' :verbose set suffixes? wildignore? HTH --Benji Fisher
filename completion not recognising pdf's
Vim does not complete pdf files with C-X C-F. Is there a place where I can alter this (mis)behavior? -- Eric Smith
Re: filename completion and filereadable
On 8/15/06, Alexander 'boesi' Bösecke <[EMAIL PROTECTED]> wrote:
Hi
Am 09.08.2006 13:49:15 schrieb Alexander 'boesi' Bösecke:
Well all the discussion about single and double quoted didn't solve my
problem - the completion of a filename adds a \ before a space.
Try the following:
:let s = "g:\\CS\ Simple\\"
:echo s
g:\CS Simple
As you can see the additional \ is removed. I think the same happens in
the following, because it just works:
:e g:\CS\ Simple\run.pyw " Here I've used file completion
But when using input(...), the \ isn't removed. And the problem is now,
that filereadable doesn't accept that.
So the question is, where is the bug?
The bug is in completion in the input() function.
Since filename is unlikely to begin with whitespace, you have a workaround:
let fn = input('Mainfile: ', expand('%:p'), 'file')
fn = substitute(fn, '\\ ', ' ', 'g')
Yakov
Re: filename completion and filereadable
Hi Am 09.08.2006 13:49:15 schrieb Alexander 'boesi' Bösecke: Well all the discussion about single and double quoted didn't solve my problem - the completion of a filename adds a \ before a space. Try the following: :let s = "g:\\CS\ Simple\\" :echo s g:\CS Simple As you can see the additional \ is removed. I think the same happens in the following, because it just works: :e g:\CS\ Simple\run.pyw " Here I've used file completion But when using input(...), the \ isn't removed. And the problem is now, that filereadable doesn't accept that. So the question is, where is the bug? cu boesi -- was ist rl? und muss man das wissen? ...der moment wo einem klar wird, dass man zuviel chattet...
Re: filename completion and filereadable
Alexander 'boesi' Bösecke wrote: Hi Am 10.08.2006 16:02:54 schrieb Alan G Isaac: On Thu, 10 Aug 2006, Matthew Winn apparently wrote: But "..." versus '...' is just as explicit. Ah, that explains why the question keeps coming up on this list and never in a Python forum ... Or not? In fact, apart from Python and XML I can't think of any languages that don't make a distinction between double and single quotes, as it's an extremely useful difference and it's a waste of a limited character set to ignore it. Hmm, "I guess you 'never need' nested quotes?" As an additional note not especially related to ViM - with '...' and "..." you have 2 kind of strings. But how do you express unicode-strings? Use `...` or something like that? And what happens, when in the future there will be a 4. string-type? With the syntax of python that's no problem. cu boesi What happens in the future when there's a 4th string type? The whole point of this argument is to show you that there's even no need for a 3rd one. If the script is in Unicode, I can enter any character into a 'raw' or "cooked" string, using digraphs, a keymap, or the method described under ":help i_CTRL-V_digit". No problem. To describe, in a non-Unicode script, strings containing Unicode codepoints not available in the script's encoding, I would have to use a "cooked" string with \u or maybe \ in it, where every h is a nybble, or else (for one or a few particular codepoints) move them to a data item at the start of the script, using for instance 'let s:bom = "\uFEFF"' then use string concatenation elsewhere in the script. This only shows that when describing strings containing non-Latin characters, Latin1 is not the best encoding for the script (and BTW, the ":scriptencoding" command may come in handy if the script is neither in Latin1 nor in UTF-8 with BOM.) Best regards, Tony.
Re: filename completion and filereadable
Alan G Isaac wrote: On Thu, 10 Aug 2006, Matthew Winn apparently wrote: But "..." versus '...' is just as explicit. Ah, that explains why the question keeps coming up on this list and never in a Python forum ... Or not? In fact, apart from Python and XML I can't think of any languages that don't make a distinction between double and single quotes, as it's an extremely useful difference and it's a waste of a limited character set to ignore it. Hmm, "I guess you 'never need' nested quotes?" In any case, I did not suggest changing the current quote behavior, just adding an additional syntax. Cheers, Alan Isaac No, in Vim v7, 'I don''t need nested quotes.' because a pair of single quotes within a single-quoted string means a single single-quote at that point in the resulting string. In pre-v7 Vim, I could have used string concatenation, which is less elegant, but works too. Best regards, Tony.
Re: filename completion and filereadable
Hi Am 10.08.2006 16:02:54 schrieb Alan G Isaac: > On Thu, 10 Aug 2006, Matthew Winn apparently wrote: > > But "..." versus '...' is just as explicit. > > Ah, that explains why the question keeps coming up on this > list and never in a Python forum ... Or not? > > > In fact, apart from Python and XML I can't think of any > > languages that don't make a distinction between double and > > single quotes, as it's an extremely useful difference and > > it's a waste of a limited character set to ignore it. > > Hmm, "I guess you 'never need' nested quotes?" As an additional note not especially related to ViM - with '...' and "..." you have 2 kind of strings. But how do you express unicode-strings? Use `...` or something like that? And what happens, when in the future there will be a 4. string-type? With the syntax of python that's no problem. cu boesi -- A Achkatz'l ofm Baam des hot a schins Laam braucht keen Pfenng Gald un freit sich of dr Walt
Re[4]: filename completion and filereadable
On Thu, 10 Aug 2006, Matthew Winn apparently wrote: > But "..." versus '...' is just as explicit. Ah, that explains why the question keeps coming up on this list and never in a Python forum ... Or not? > In fact, apart from Python and XML I can't think of any > languages that don't make a distinction between double and > single quotes, as it's an extremely useful difference and > it's a waste of a limited character set to ignore it. Hmm, "I guess you 'never need' nested quotes?" In any case, I did not suggest changing the current quote behavior, just adding an additional syntax. Cheers, Alan Isaac
Re: Re[2]: filename completion and filereadable
On Wed, 9 Aug 2006 23:03:12 -0400, Alan G Isaac <[EMAIL PROTECTED]> wrote: > On Thu, 10 Aug 2006, "A.J.Mechelynck" apparently wrote: > > What is "the raw string notation from Python" ? > > IMHO it would only create one additional type of string. We already have > > single-quoted 'raw' strings in Vim, yet many people constantly forget > > that double-quoted strings in Vim are "cooked". > > Yes, that is my point: > Many people forget the difference between single and double > quoted strings. Indeed when reading vimscript the difference > is not immediately obvious (easily forgettable), which is > unfortunate. > > Taking the Python approach that values explicitness, > http://docs.python.org/ref/strings.html > a raw string can be created > r'like this' or r"like this". But "..." versus '...' is just as explicit. It's also something shared by every Unix shell I've used, along with quite a few other languages such as Perl. In fact, apart from Python and XML I can't think of any languages that don't make a distinction between double and single quotes, as it's an extremely useful difference and it's a waste of a limited character set to ignore it. -- Matthew Winn
Re[2]: filename completion and filereadable
On Thu, 10 Aug 2006, "A.J.Mechelynck" apparently wrote: > :let q=r"like this" Yes, this would be parsed in a new way. I wager this would bite very few (since it is horrible style beyond belief). Cheers, Alan Isaac
Re: filename completion and filereadable
Alan G Isaac wrote: On Thu, 10 Aug 2006, "A.J.Mechelynck" apparently wrote: What is "the raw string notation from Python" ? IMHO it would only create one additional type of string. We already have single-quoted 'raw' strings in Vim, yet many people constantly forget that double-quoted strings in Vim are "cooked". Yes, that is my point: Many people forget the difference between single and double quoted strings. Indeed when reading vimscript the difference is not immediately obvious (easily forgettable), which is unfortunate. Taking the Python approach that values explicitness, http://docs.python.org/ref/strings.html a raw string can be created r'like this' or r"like this". The preceding 'r' is obviously for 'raw'. Very explicit; unlikely ever to be forgotten; and I think backwards compatible (i.e., ordinary single and double quoted strings can remain what they are). Cheers, Alan Isaac Dunno what Bram would think of your proposal, but I wouldn' bet a eurocent on it. And what about :let q=r"like this" where r happens to be a variable? With current Vim syntax, it is legal (move r to q, the rest is a Vim comment). Similarly :if q==r"like this" :while q
Re[2]: filename completion and filereadable
On Thu, 10 Aug 2006, "A.J.Mechelynck" apparently wrote: > What is "the raw string notation from Python" ? > IMHO it would only create one additional type of string. We already have > single-quoted 'raw' strings in Vim, yet many people constantly forget > that double-quoted strings in Vim are "cooked". Yes, that is my point: Many people forget the difference between single and double quoted strings. Indeed when reading vimscript the difference is not immediately obvious (easily forgettable), which is unfortunate. Taking the Python approach that values explicitness, http://docs.python.org/ref/strings.html a raw string can be created r'like this' or r"like this". The preceding 'r' is obviously for 'raw'. Very explicit; unlikely ever to be forgotten; and I think backwards compatible (i.e., ordinary single and double quoted strings can remain what they are). Cheers, Alan Isaac
Re: filename completion and filereadable
Alan G Isaac wrote:
Am 09.08.2006 14:08:04 schrieb Yakov Lerner:
Looks like an input() bug to me.
On 8/9/06, Alexander 'boesi' Bösecke <[EMAIL PROTECTED]> wrote:
To me it looks even more strange. I've tested a bit more.
:echo filereadable("G:\Projekte\CS Simple\run.pyw")
On Wed, 9 Aug 2006, Yakov Lerner apparently wrote:
Use single quotes, where backslash is not treated specially.
Otherwize "..\r..." will be treated as CR char, "...\t..." as
tab char etc, which is not what you want.
Since this is stumbled over so often,
I have an enhancement request:
allow raw strings to be created
with the raw string notation from Python.
This would be backwards compatible, I believe.
Cheers,
Alan Isaac
What is "the raw string notation from Python" ?
IMHO it would only create one additional type of string. We already have
single-quoted 'raw' strings in Vim, yet many people constantly forget
that double-quoted strings in Vim are "cooked".
Best regards,
Tony.
Re[2]: filename completion and filereadable
>> Am 09.08.2006 14:08:04 schrieb Yakov Lerner:
>>> Looks like an input() bug to me.
> On 8/9/06, Alexander 'boesi' Bösecke <[EMAIL PROTECTED]> wrote:
>> To me it looks even more strange. I've tested a bit more.
>> :echo filereadable("G:\Projekte\CS Simple\run.pyw")
On Wed, 9 Aug 2006, Yakov Lerner apparently wrote:
> Use single quotes, where backslash is not treated specially.
> Otherwize "..\r..." will be treated as CR char, "...\t..." as
> tab char etc, which is not what you want.
Since this is stumbled over so often,
I have an enhancement request:
allow raw strings to be created
with the raw string notation from Python.
This would be backwards compatible, I believe.
Cheers,
Alan Isaac
Re: filename completion and filereadable
Hi Am 09.08.2006 15:16:08 schrieb Yakov Lerner: > Use single quotes, where backslash is not treated specially. > Otherwize "..\r..." will be treated as CR char, "...\t..." as > tab char etc, which is not what you want. Umm sorry I always forgot the difference between single and double quoted. Python does not have this... *G* But :e G:\Projekte\CS\ Simple\run.pyw This works! So the behaviour of ViM is a bit inconsistent, isn't it? Either file-completion should not add the \ or filereadable (and other functions) should accept it. cu boesi -- was ist rl? und muss man das wissen? ...der moment wo einem klar wird, dass man zuviel chattet...
Re: filename completion and filereadable
On 8/9/06, Alexander 'boesi' Bösecke <[EMAIL PROTECTED]> wrote:
Hi
Am 09.08.2006 14:08:04 schrieb Yakov Lerner:
> Looks like an input() bug to me.
To me it looks even more strange. I've tested a bit more.
:echo filereadable("G:\Projekte\CS Simple\run.pyw")
Use single quotes, where backslash is not treated specially.
Otherwize "..\r..." will be treated as CR char, "...\t..." as
tab char etc, which is not what you want.
Yakov
Re: filename completion and filereadable
Hi
Am 09.08.2006 14:08:04 schrieb Yakov Lerner:
> Looks like an input() bug to me.
To me it looks even more strange. I've tested a bit more.
:echo filereadable("G:\Projekte\CS Simple\run.pyw")
:echo filereadable("G:\Projekte\CS\ Simple\run.pyw")
returns 0
:echo filereadable("G:\\Projekte\\CS Simple\\run.pyw")
:echo filereadable("G:\\Projekte\\CS\ Simple\\run.pyw")
:echo filereadable("G:/Projekte/CS Simple/run.pyw")
returns 1
In my script versions 1, 3 and 5 work. So there filereadable has a
problem with the quoted space. And in command mode the unqouted
backslash is the problem.
Here is the function from my script:
---snip---
function! s:SetMainScript()
if s:mainfile == ""
let fnInput = expand('%:p')
else
let fnInput = s:mainfile
endif
call inputsave()
let fn = input('Mainfile: ', fnInput, 'file')
call inputrestore()
" input precedes with \, but filereadable does not like that
" let fn = substitute(fn, " ", " ", "g")
if filereadable(fn) == 1
let s:mainfile = fn
let s:ExeDir = fnamemodify(fn, ':p:h')
echo s:mainfile . ' set as the starting program.'
else
echoerr fn . ' is not readable'
endif
endfunction
---snap---
cu boesi
--
...schlafen ist sowieso ungesund...
.-==Police Academy I==-.
Re: filename completion and filereadable
On 8/9/06, Alexander 'boesi' Bösecke <[EMAIL PROTECTED]> wrote:
Hi
I'm using
let fn = input('Mainfile: ', expand('%:p'), 'file')
to ask for a filename. When I press Tab to complete the filename, a
""will be replaced by a "\". So "G:\Projekte\CS
Simple\run.pyw" becomes "G:\Projekte\CS\ Simple\run.pyw". When I check
this filename with filereadable, it returns False. But when the filename
is "G:\Projekte\CS Simple\run.pyw" (ie. not using completion),
filereadable returns True.
Well I could modify the filename with
let fn = substitute(fn, " ", " ", "g")
before calling filereadable. But I think this can not be the right way.
So where is the error - is it me, is it input or is it filereadable?
Looks like an input() bug to me. Confirmed in Linux for filenames
containing spaces:
:cd /tmp
:!touch "a b"
:let x=input("file->","","file")
Enter: 'a', space, 'b' , press Tab. Input turns into 'a\ b' and after
Enter, variable contains 4 chars 'a\ b'
Yakov
filename completion and filereadable
Hi
I'm using
let fn = input('Mainfile: ', expand('%:p'), 'file')
to ask for a filename. When I press Tab to complete the filename, a
""will be replaced by a "\". So "G:\Projekte\CS
Simple\run.pyw" becomes "G:\Projekte\CS\ Simple\run.pyw". When I check
this filename with filereadable, it returns False. But when the filename
is "G:\Projekte\CS Simple\run.pyw" (ie. not using completion),
filereadable returns True.
Well I could modify the filename with
let fn = substitute(fn, " ", " ", "g")
before calling filereadable. But I think this can not be the right way.
So where is the error - is it me, is it input or is it filereadable?
thanks and cu boesi
--
Wenn de Lüch net waer un dr Neid
gäbs lauter glückliche Leid
Uhne Lüch un Neid = ganz gewiß
wär uf dr Ard is Paradies
Re: Vim 7 filename completion menu location bug
Neil Bird wrote: >Fedora Core 5, vim 7.0.012: the following line, in a file of type 'cfg' > [I was editing a doxygen file when I saw it] with 132 columns, xterm and > GTK+ GUI (the filename here is not the inital trigger, but also causes the > failure; not all long lines do, though): > > INPUT = /usr/share/doc/kernel-doc-2.6.16/Documentation/kbuild > /usr/share/doc/kernel-doc-2.6.16/Documentation/kbuild > /usr/share/doc/kernel-doc-2.6.16/Documentation/kbuild/ > > >With the cursor at then end, I type to do filename completion, > and the selection menu comes up partially off-screen on the right. I'll > try to capture it below, but the email might wrap it. > > > INPUT = /usr/share/doc/kernel-doc-2.6.16/Documentation/kbuild > /usr/share/doc/kernel-doc-2.6.16/Documentation/kbuild /usr/share/doc/k > ernel-doc-2.6.16/Documentation/kbuild/00-INDEX > ~ > /usr/share/doc/k > ~ > /usr/share/doc/k > ~ > /usr/share/doc/k > ~ > /usr/share/doc/k > I don't understand what the problem is. Can you make a dump of the window? The "xv" program can do that (use the "Grab" button). -- ROBIN: The what? ARTHUR: The Holy Hand Grenade of Antioch. 'Tis one of the sacred relics Brother Maynard always carries with him. ALL:Yes. Of course. ARTHUR: (shouting) Bring up the Holy Hand Grenade! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// 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///
Vim 7 filename completion menu location bug
Fedora Core 5, vim 7.0.012: the following line, in a file of type 'cfg' [I was editing a doxygen file when I saw it] with 132 columns, xterm and GTK+ GUI (the filename here is not the inital trigger, but also causes the failure; not all long lines do, though): INPUT = /usr/share/doc/kernel-doc-2.6.16/Documentation/kbuild /usr/share/doc/kernel-doc-2.6.16/Documentation/kbuild /usr/share/doc/kernel-doc-2.6.16/Documentation/kbuild/ With the cursor at then end, I type to do filename completion, and the selection menu comes up partially off-screen on the right. I'll try to capture it below, but the email might wrap it. INPUT = /usr/share/doc/kernel-doc-2.6.16/Documentation/kbuild /usr/share/doc/kernel-doc-2.6.16/Documentation/kbuild /usr/share/doc/k ernel-doc-2.6.16/Documentation/kbuild/00-INDEX ~ /usr/share/doc/k ~ /usr/share/doc/k ~ /usr/share/doc/k ~ /usr/share/doc/k -- [EMAIL PROTECTED] ~]# rm -f .signature [EMAIL PROTECTED] ~]# ls -l .signature ls: .signature: No such file or directory [EMAIL PROTECTED] ~]# exit
Re: filename completion ignorecase for Vim 7
Gerald Lai wrote: On Sat, 17 Jun 2006, A.J.Mechelynck wrote: Gerald Lai wrote: On Sat, 17 Jun 2006, Bram Moolenaar wrote: Gerald Lai wrote: For Vim 7, it seems that filename completion in the :cmdline ignores case when searching for matches. For example, :e F matches both foo.txt Foo.txt This is different from Vim 6 where it only matches Foo.txt Is there any way to revert back to the old behavior? What system? On MS-Windows case of filenames is ignored, on Unix it matters, on Mac it depends. I'm on Windows for Vim 7, Linux for Vim 6 :) That explains it. I guess this is a matter of discrepancy between what the user wants to match, and what the OS cares to read. IMHO, what the user wants to match should take priority over whether the OS cares about the case of its filenames. Perhaps for Windows, we could have a 'smartcase' setup for filename completion matching where it's ignorecase only when all the characters are lowercase. Thanks. -- Gerald IIUC, under Windows it is not possible to have in the same directory two files whose names differ only in case. Let's say you have "Makefile" in some directory. Creating "makefile" or "MAKEFILE" in the same directory will overwrite it. Similarly foo.c, FOO.C and Foo.C are indistinguishable. If Vim tries to open one of them, and another one exists, the OS will deliver it. Thus a 'smartcase' or 'noignorecase' setting for Windows filenames makes no sense. True. But how about filenames that aren't the same? Let's say we have these files on a Windows system: franticallysearching_0_alongfilename.txt franticallysearching_1_alongfilename.txt .. franticallysearching_641237_alongfilename.txt Franticallysearching_641238_alongfilename.txt franticallysearching_641239_alongfilename.txt .. franticallysearching_99_alongfilename.txt and we know we want to edit the file that starts with the capital F. When we do :e F would we expect it to match :e franticallysearching_ where we have to follow up by typing in the unknown number for that capital F file? I'd rather have it match :e Franticallysearching_641238_alongfilename.txt where it does what it's told to do. I could care less that Windows treats these files the same: franticallysearching_641238_alongfilename.txt Franticallysearching_641238_alongfilename.txt fraNtIcallysearChiNg_641238_alongfilename.txt to let it affect what I'm searching for. In the end, it's a matter of preference :) -- Gerald Ah, in filenames with wildcards, or in filename completion. It might be hard to do, because I would expect Vim to take advantage of the OS's "directory search with wildcards" functions -- and when the OS is Windows, these functions disregard case differences. In the case above, you could "edit the directory" then search the directory buffer using Vim search for /^F Best regards, Tony.
Re: filename completion ignorecase for Vim 7
On Sat, 17 Jun 2006, A.J.Mechelynck wrote: Gerald Lai wrote: On Sat, 17 Jun 2006, Bram Moolenaar wrote: Gerald Lai wrote: For Vim 7, it seems that filename completion in the :cmdline ignores case when searching for matches. For example, :e F matches both foo.txt Foo.txt This is different from Vim 6 where it only matches Foo.txt Is there any way to revert back to the old behavior? What system? On MS-Windows case of filenames is ignored, on Unix it matters, on Mac it depends. I'm on Windows for Vim 7, Linux for Vim 6 :) That explains it. I guess this is a matter of discrepancy between what the user wants to match, and what the OS cares to read. IMHO, what the user wants to match should take priority over whether the OS cares about the case of its filenames. Perhaps for Windows, we could have a 'smartcase' setup for filename completion matching where it's ignorecase only when all the characters are lowercase. Thanks. -- Gerald IIUC, under Windows it is not possible to have in the same directory two files whose names differ only in case. Let's say you have "Makefile" in some directory. Creating "makefile" or "MAKEFILE" in the same directory will overwrite it. Similarly foo.c, FOO.C and Foo.C are indistinguishable. If Vim tries to open one of them, and another one exists, the OS will deliver it. Thus a 'smartcase' or 'noignorecase' setting for Windows filenames makes no sense. True. But how about filenames that aren't the same? Let's say we have these files on a Windows system: franticallysearching_0_alongfilename.txt franticallysearching_1_alongfilename.txt .. franticallysearching_641237_alongfilename.txt Franticallysearching_641238_alongfilename.txt franticallysearching_641239_alongfilename.txt .. franticallysearching_99_alongfilename.txt and we know we want to edit the file that starts with the capital F. When we do :e F would we expect it to match :e franticallysearching_ where we have to follow up by typing in the unknown number for that capital F file? I'd rather have it match :e Franticallysearching_641238_alongfilename.txt where it does what it's told to do. I could care less that Windows treats these files the same: franticallysearching_641238_alongfilename.txt Franticallysearching_641238_alongfilename.txt fraNtIcallysearChiNg_641238_alongfilename.txt to let it affect what I'm searching for. In the end, it's a matter of preference :) -- Gerald
Re: filename completion ignorecase for Vim 7
Gerald Lai wrote: On Sat, 17 Jun 2006, Bram Moolenaar wrote: Gerald Lai wrote: For Vim 7, it seems that filename completion in the :cmdline ignores case when searching for matches. For example, :e F matches both foo.txt Foo.txt This is different from Vim 6 where it only matches Foo.txt Is there any way to revert back to the old behavior? What system? On MS-Windows case of filenames is ignored, on Unix it matters, on Mac it depends. I'm on Windows for Vim 7, Linux for Vim 6 :) That explains it. I guess this is a matter of discrepancy between what the user wants to match, and what the OS cares to read. IMHO, what the user wants to match should take priority over whether the OS cares about the case of its filenames. Perhaps for Windows, we could have a 'smartcase' setup for filename completion matching where it's ignorecase only when all the characters are lowercase. Thanks. -- Gerald IIUC, under Windows it is not possible to have in the same directory two files whose names differ only in case. Let's say you have "Makefile" in some directory. Creating "makefile" or "MAKEFILE" in the same directory will overwrite it. Similarly foo.c, FOO.C and Foo.C are indistinguishable. If Vim tries to open one of them, and another one exists, the OS will deliver it. Thus a 'smartcase' or 'noignorecase' setting for Windows filenames makes no sense. Best regards, Tony.
Re: filename completion ignorecase for Vim 7
On Sat, 17 Jun 2006, Bram Moolenaar wrote: Gerald Lai wrote: For Vim 7, it seems that filename completion in the :cmdline ignores case when searching for matches. For example, :e F matches both foo.txt Foo.txt This is different from Vim 6 where it only matches Foo.txt Is there any way to revert back to the old behavior? What system? On MS-Windows case of filenames is ignored, on Unix it matters, on Mac it depends. I'm on Windows for Vim 7, Linux for Vim 6 :) That explains it. I guess this is a matter of discrepancy between what the user wants to match, and what the OS cares to read. IMHO, what the user wants to match should take priority over whether the OS cares about the case of its filenames. Perhaps for Windows, we could have a 'smartcase' setup for filename completion matching where it's ignorecase only when all the characters are lowercase. Thanks. -- Gerald
Re: filename completion ignorecase for Vim 7
Gerald Lai wrote: > For Vim 7, it seems that filename completion in the :cmdline ignores > case when searching for matches. For example, > >:e F > > matches both > >foo.txt >Foo.txt > > This is different from Vim 6 where it only matches > >Foo.txt > > Is there any way to revert back to the old behavior? What system? On MS-Windows case of filenames is ignored, on Unix it matters, on Mac it depends. -- He was not in the least bit scared to be mashed into a pulp Or to have his eyes gouged out and his elbows broken; To have his kneecaps split and his body burned away And his limbs all hacked and mangled, brave Sir Robin. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// 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: filename completion ignorecase for Vim 7
try :noic On Sat, Jun 17, 2006 at 02:32:46AM -0700, Gerald Lai wrote: > Hi all, > > For Vim 7, it seems that filename completion in the :cmdline ignores > case when searching for matches. For example, > > :e F > > matches both > > foo.txt > Foo.txt > > This is different from Vim 6 where it only matches > > Foo.txt > > Is there any way to revert back to the old behavior? > -- > Gerald
filename completion ignorecase for Vim 7
Hi all, For Vim 7, it seems that filename completion in the :cmdline ignores case when searching for matches. For example, :e F matches both foo.txt Foo.txt This is different from Vim 6 where it only matches Foo.txt Is there any way to revert back to the old behavior? -- Gerald
