Илья wrote:

/C after a command interpreter name, in all versions of Dos and Windows,
means: what follows is a command to be executed, and after that the
command interpreter should terminate. No need to disambiguate.
Best regards,
Tony.

--- Make_dos.mak.orig 2005-10-23 03:30:08.507667200 +0300
+++ Make_dos.mak 2005-10-23 03:30:14.926897600 +0300
@@ -59,7 +65,7 @@
$(VIMPROG) -u dos.vim -U NONE --noplugin -s dotest.in $*.in
diff test.out $*.ok
-del $*.out
- rename test.out $*.out
+ $(COMSPEC) /C rename test.out $*.out
-del X*
-del test.ok
-del viminfo

I'd like to try out the vim7 alpha.  But when I try to install it with
a-a-p, I get an error.  After downloading and inflating vim-7.0157.zip,
the log file reads:

     changedir:    Entering directory `C:\vim7_alpha'
     depend:    1 - Updating "all" from "fetch": virtual target
     extra:    Executing recipe "vim7/src/main.aap"
     changedir:    Entering directory `C:\vim7_alpha\vim7\src'
     extra:    Reading recipe "C:\aap\Exec\default.aap"
     log:    Checking for MingW
     log:    No mingw compiler found
     extra:    Finished reading recipe "C:\aap\Exec\default.aap"
     extra:    Reading recipe "main.aap"
     depend:    Start :update "auto/config.aap"
     depend:    1 - updating target "auto\config.aap"
     depend:    2 - Using dependency "config{virtual=1} auto/config.h
auto/config.aap : auto/configure.aap configure.aap config.arg
config.h.in config.aap.in" for target "auto\config.aap"
     depend:    3 - updating target "auto\configure.aap"
     depend:    4 - Using dependency "auto/configure.aap : auto/configure"
     depend:    5 - updating target "auto\configure"
     depend:    6 - Using dependency
"auto/configure{signfile=C:\vim7_alpha\vim7\src\mysign} : configure.in"
     depend:    7 - updating target "configure.in"
     depend:    7 - Target has no build commands and exists: "configure.in"
     depend:    5 - Updating "auto\configure" from "configure.in":
"configure.in" has changed
     print:    Can't find autoconf, using existing configure script.
     note:    Cannot read sign file "auto/aapdir/sign": [Errno 2] No such
file or directory: 'c:/vim7_alpha/vim7/src/auto/aapdir/sign'
     depend:    3 - Updating "auto\configure.aap" from "auto\configure":
no old signature for "auto\configure"
     print:    Adjusting auto/configure for A-A-P.
     depend:    3 - updating target "configure.aap"
     depend:    4 - Using dependency "configure.aap : "
     depend:    3 - Updating "configure.aap" from "": it doesn't exist
     error:    Error in recipe "c:/vim7_alpha/vim7/src/main.aap" line 48:
:symlink "auto/configure.aap" "configure.aap" failed: 'module' object
has no attribute 'symlink'

I'm using a modern machine with WindowsXP Pro SP2, Python 2.4.2.  I
don't have MinGW installed, as I didn't see any requirement for it.  Can
anyone offer advice about how to properly install & build the vim7 alpha?

Thanks!

Terrance Cohen said the following on 24/10/2005 4:29 PM:

> I'd like to try out the vim7 alpha....

The easy way?
http://users.skynet.be/antoine.mechelynck/vim/


--
Mark

Terrance Cohen wrote:
[...]
> I'm using a modern machine with WindowsXP Pro SP2, Python 2.4.2.  I
> don't have MinGW installed, as I didn't see any requirement for it.  Can
> anyone offer advice about how to properly install & build the vim7 alpha?
>
> Thanks!


See my compiling HowTo,
http://users.skynet.be/antoine.mechelynck/vim/compile.htm

HTH,
Tony.

Because there was some discussion about changing omni completion behavior.

What about this idea:

The writer of the omni completion plugin can define some characters or strings
at which the omnifunc is called automatically.

For C++ code, one should say:

:set omnifunctriggers=".,->,::,("

or if multicharacter strings are too difficult to handle, then just:

:set omnifunctriggers=".,>,:,("

and the checking if a completion is needed would be done in the
cppcomplete#Complete() function.

After one of these characters is written, the popup menu is automatically
displayed with all choices for this context, but NO selection is done.

If you now continue writing, the popupmenu narrows the available matches and
you can select the right one with ctrl-n.

You still should be able to use the normal ctrl-x,ctrl-o command the way it is
currently working (selecting the first matching entry in the list of
completions) if you don't like this automatic behavior.

To enable this real "intelli*" behavior with automatic popup after . -> or ::
are pressed, one would just :set completeopt=menu,auto

What do you think about this idea?

BTW: I just released a new version of my icomplete program on:
http://www.vim.org/scripts/script.php?script_id=1265
which now uses the omnifunc.

However, I would like to extend it to make it work like other intellisens
completion systems with this automatic behavior, but think things like this
should rather go in the vim core, instead of remapping nearly all keys.
--
Martin Stubenschrott

On Oct 22 22:35, Yegappan Lakshmanan wrote:
> Hello,
>
> On 10/21/05, Corinna Vinschen <vinschen@...> wrote:
> > Hi,
> >
> > I got reports on the Cygwin list, that the new vim 6.4 would accidentally
> > change the case of filenames, if the filename case was different when
> > loading the file.  Well, that sounds complicated... just try this:
> >
> >  $ touch X.sh
> >  $ ls
> >  X.sh
> >  $ vim x.sh
> >  :w
> >  :x
> >  $ ls
> >  x.sh
> >
> > With vim 6.3, the case was still correct afterwards.  How can this be
> > fixed?
> >
>
> I think, you will get a fix for this problem only after Bram comes
> back from his vacation (around a month or so).

Thanks for the hint.  However, we can scratch this mail.  I have been
told that 6.3 doesn't change the case in this scenario, but I didn't
try it myself.  Now I did and guess what?  Exactly!  So there's no
regression in this case.  Maybe we should just leave it as it is.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Dnia poniedzia�ek, 24 pa�dziernika 2005 14:04, Martin Stubenschrott
napisa�:
> Because there was some discussion about changing omni completion
> behavior.
>
> What about this idea:
>
> The writer of the omni completion plugin can define some characters or
> strings at which the omnifunc is called automatically.
>
> For C++ code, one should say:
> :set omnifunctriggers=".,->,::,("
>
> or if multicharacter strings are too difficult to handle, then just:
> :set omnifunctriggers=".,>,:,("
>
[cut]
>
> To enable this real "intelli*" behavior with automatic popup after . ->
> or :: are pressed, one would just :set completeopt=menu,auto
>
> What do you think about this idea?

I like it with extension behaviour of omnifunctriggers by function
(similar to indent, folding etc.).

Not always completion is required after some character but in broader
context.

m.

Corinna Vinschen wrote:
> On Oct 22 22:35, Yegappan Lakshmanan wrote:
>> Hello,
>>
>> On 10/21/05, Corinna Vinschen <vinschen@...> wrote:
>> > Hi,
>> >
>> > I got reports on the Cygwin list, that the new vim 6.4 would
>> > accidentally
>> > change the case of filenames, if the filename case was different when
>> > loading the file.  Well, that sounds complicated... just try this:
>> >
>> >  $ touch X.sh
>> >  $ ls
>> >  X.sh
>> >  $ vim x.sh
>> >  :w
>> >  :x
>> >  $ ls
>> >  x.sh
>> >
>> > With vim 6.3, the case was still correct afterwards.  How can this be
>> > fixed?
>> >
>>
>> I think, you will get a fix for this problem only after Bram comes
>> back from his vacation (around a month or so).
>
> Thanks for the hint.  However, we can scratch this mail.  I have been
> told that 6.3 doesn't change the case in this scenario, but I didn't
> try it myself.  Now I did and guess what?  Exactly!  So there's no
> regression in this case.  Maybe we should just leave it as it is.

It may not be a regression, but it definitely sounds like a bug.  Hm, I
don't see this behaviour in native Win32 Vim 6.4 or 7.0aa.  I'm curious why
Cygwin would make a difference.

On Oct 24 15:25, Craig Barkhouse wrote:
> Corinna Vinschen wrote:
> >On Oct 22 22:35, Yegappan Lakshmanan wrote:
> >>Hello,
> >>
> >>On 10/21/05, Corinna Vinschen <vinschen@...> wrote:
> >>> Hi,
> >>>
> >>> I got reports on the Cygwin list, that the new vim 6.4 would
> >>> accidentally
> >>> change the case of filenames, if the filename case was different when
> >>> loading the file.  Well, that sounds complicated... just try this:
> >>>
> >>>  $ touch X.sh
> >>>  $ ls
> >>>  X.sh
> >>>  $ vim x.sh
> >>>  :w
> >>>  :x
> >>>  $ ls
> >>>  x.sh
> >>>
> >>> With vim 6.3, the case was still correct afterwards.  How can this be
> >>> fixed?
> >>>
> >>
> >>I think, you will get a fix for this problem only after Bram comes
> >>back from his vacation (around a month or so).
> >
> >Thanks for the hint.  However, we can scratch this mail.  I have been
> >told that 6.3 doesn't change the case in this scenario, but I didn't
> >try it myself.  Now I did and guess what?  Exactly!  So there's no
> >regression in this case.  Maybe we should just leave it as it is.
>
> It may not be a regression, but it definitely sounds like a bug.  Hm, I
> don't see this behaviour in native Win32 Vim 6.4 or 7.0aa.  I'm curious why
> Cygwin would make a difference.

Cygwin is not using Windows-specific code at all, it's entirely based
on the Unix code base.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

On 10/24/05, Corinna Vinschen  wrote:

> > >>>  $ touch X.sh
> > >>>  $ ls
> > >>>  X.sh
> > >>>  $ vim x.sh
> > >>>  :w
> > >>>  :x
> > >>>  $ ls
> > >>>  x.sh
[snip]
> Cygwin is not using Windows-specific code at all, it's entirely based
> on the Unix code base.
>

I would think the above behavior is an artifact of trying to emulate
POSIX on top of a case-insensitive filesystem. I wonder if setting
"CYGWIN=check_case:strict" changes vim's behavior (I can't test, I've
moved on to use a POSIX OS and don't boot into Windows much
anymore...).  I know that code has bitrot, but you never know...

--
Alejandro L�pez-Valencia

On Oct 24 14:45, Alejandro L?pez-Valencia wrote:
> On 10/24/05, Corinna Vinschen  wrote:
>
> > > >>>  $ touch X.sh
> > > >>>  $ ls
> > > >>>  X.sh
> > > >>>  $ vim x.sh
> > > >>>  :w
> > > >>>  :x
> > > >>>  $ ls
> > > >>>  x.sh
> [snip]
> > Cygwin is not using Windows-specific code at all, it's entirely based
> > on the Unix code base.
> >
>
> I would think the above behavior is an artifact of trying to emulate
> POSIX on top of a case-insensitive filesystem. I wonder if setting

It is.

> "CYGWIN=check_case:strict" changes vim's behavior (I can't test, I've
> moved on to use a POSIX OS and don't boot into Windows much
> anymore...).  I know that code has bitrot, but you never know...

You're right, that option solves the problem on the Cygwin side.  However,
I'd rather solve the problem in the application if at all necessary since
the check_case option is deprecated.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Corinna Vinschen wrote:
>> It may not be a regression, but it definitely sounds like a bug.  Hm, I
>> don't see this behaviour in native Win32 Vim 6.4 or 7.0aa.  I'm curious
>> why
>> Cygwin would make a difference.
>
> Cygwin is not using Windows-specific code at all, it's entirely based
> on the Unix code base.

Understood.  Upon further reflection, perhaps that explains the behaviour.
When your typical UNIX app successfully opens "myfile", then it for some
reason assumes the file was called "myfile" and not "Myfile".  Go figure.
:)

But I'm also assuming that this is a consequence of the way Vim saves files.
The save code is extremely long, so I didn't read through it all, but my
understanding is that it somehow deletes the old file and creates a new file
from scratch (and this may vary depending on backup options).  Maybe someone
who has a better understanding of it can clarify.  In any case, given this
description, it makes sense that the written file would potentially have the
wrong case, as it is a brand new file.  However, if Vim instead wrote files
by truncated the existing file and then appending the new contents, I would
certainly expect the case of the existing filename to remain unchanged.

Although you say it is based entirely on the UNIX code base, I do see a
number of code fragments that depend on __CYGWIN__ or __CYGWIN32__.
Accordingly, I guess you could add in a Cygwin-specific code fragment to
determine the filename of the file you just opened.  Offhand, I can't even
think of how to do this in UNIX.  The hard way would be reading the
directory entries and picking the filename that case-insensitively matches.
That seems cumbersome.

Craig

Craig Barkhouse wrote:

> Corinna Vinschen wrote:
>
>>> It may not be a regression, but it definitely sounds like a bug.  Hm, I
>>> don't see this behaviour in native Win32 Vim 6.4 or 7.0aa.  I'm
>>> curious why
>>> Cygwin would make a difference.
>>
>>
>> Cygwin is not using Windows-specific code at all, it's entirely based
>> on the Unix code base.
>
> [snip]
>
> Although you say it is based entirely on the UNIX code base, I do see
> a number of code fragments that depend on __CYGWIN__ or __CYGWIN32__.
> Accordingly, I guess you could add in a Cygwin-specific code fragment
> to determine the filename of the file you just opened.  Offhand, I
> can't even think of how to do this in UNIX.  The hard way would be
> reading the directory entries and picking the filename that
> case-insensitively matches. That seems cumbersome.


But, I suspect, necessary.  Unix files don't have names; they have
"inodes"; names are provided by mapping directory entries to inodes.  So
the only place where the names are present are in the directory
entries.  Thus I expect one would need to use opendir(), readdir(), and
closedir().

Regards,
Chip Campbell

On Oct 26 10:46, Charles E. Campbell, Jr. wrote:
> Craig Barkhouse wrote:
>
> >Corinna Vinschen wrote:
> >
> >>>It may not be a regression, but it definitely sounds like a bug.  Hm, I
> >>>don't see this behaviour in native Win32 Vim 6.4 or 7.0aa.  I'm
> >>>curious why
> >>>Cygwin would make a difference.
> >>
> >>
> >>Cygwin is not using Windows-specific code at all, it's entirely based
> >>on the Unix code base.
> >
> >[snip]
> >
> >Although you say it is based entirely on the UNIX code base, I do see
> >a number of code fragments that depend on __CYGWIN__ or __CYGWIN32__.
> >Accordingly, I guess you could add in a Cygwin-specific code fragment
> >to determine the filename of the file you just opened.  Offhand, I
> >can't even think of how to do this in UNIX.  The hard way would be
> >reading the directory entries and picking the filename that
> >case-insensitively matches. That seems cumbersome.
>
>
> But, I suspect, necessary.  Unix files don't have names; they have
> "inodes"; names are provided by mapping directory entries to inodes.  So
> the only place where the names are present are in the directory
> entries.  Thus I expect one would need to use opendir(), readdir(), and
> closedir().

Right.  On further reflection, it just occured to me that another UNIX
based system, Apple's OS/X, also supports case preserving file systems.
I don't have OS/X myself, but shouldn't it have the very same problem?

This would lead to the question, if it might make sense to add some sort
of compile time switch like HAVE_CASE_PRESERVING_FS instead of adding
a Cygwin-only solution.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Corinna Vinschen wrote:
> On Oct 26 10:46, Charles E. Campbell, Jr. wrote:
>> Craig Barkhouse wrote:
>>
>>> Corinna Vinschen wrote:
>>>
>>>>> It may not be a regression, but it definitely sounds like a bug.  Hm, I
>>>>> don't see this behaviour in native Win32 Vim 6.4 or 7.0aa.  I'm
>>>>> curious why
>>>>> Cygwin would make a difference.
>>>>
>>>> Cygwin is not using Windows-specific code at all, it's entirely based
>>>> on the Unix code base.
>>> [snip]
>>>
>>> Although you say it is based entirely on the UNIX code base, I do see
>>> a number of code fragments that depend on __CYGWIN__ or __CYGWIN32__.
>>> Accordingly, I guess you could add in a Cygwin-specific code fragment
>>> to determine the filename of the file you just opened.  Offhand, I
>>> can't even think of how to do this in UNIX.  The hard way would be
>>> reading the directory entries and picking the filename that
>>> case-insensitively matches. That seems cumbersome.
>>
>> But, I suspect, necessary.  Unix files don't have names; they have
>> "inodes"; names are provided by mapping directory entries to inodes.  So
>> the only place where the names are present are in the directory
>> entries.  Thus I expect one would need to use opendir(), readdir(), and
>> closedir().
>
> Right.  On further reflection, it just occured to me that another UNIX
> based system, Apple's OS/X, also supports case preserving file systems.
> I don't have OS/X myself, but shouldn't it have the very same problem?
>
> This would lead to the question, if it might make sense to add some sort
> of compile time switch like HAVE_CASE_PRESERVING_FS instead of adding
> a Cygwin-only solution.
>
>
> Corinna
>

IIUC, all Unix-like systems distinguish upper-case and lower-case. The
problem with Cygwin is that it is an emulator, presenting a Unix-like
interface to Unix-like programs (which will then only need recompilation
to run), but the underlying OS is a Dos-like one, where case differences
in file and directory names are disregarded.

Best regards,
Tony.

On 26/10/05, A. J. Mechelynck <antoine.mechelynck@...> wrote:
> IIUC, all Unix-like systems distinguish upper-case and lower-case. The
> problem with Cygwin is that it is an emulator, presenting a Unix-like
> interface to Unix-like programs (which will then only need recompilation
> to run), but the underlying OS is a Dos-like one, where case differences
> in file and directory names are disregarded.

Sadly, this is not the case.  The default filesystem and configuration
for Mac OS X, which is Unix-like, preserves case but is not case
sensitive.  It really is tragic.

Thanks,
Chris Allen

On Oct 26 21:16, Chris Allen wrote:
> On 26/10/05, A. J. Mechelynck <antoine.mechelynck@...> wrote:
> > IIUC, all Unix-like systems distinguish upper-case and lower-case. The
> > problem with Cygwin is that it is an emulator, presenting a Unix-like
> > interface to Unix-like programs (which will then only need recompilation
> > to run), but the underlying OS is a Dos-like one, where case differences
> > in file and directory names are disregarded.
>
> Sadly, this is not the case.  The default filesystem and configuration
> for Mac OS X, which is Unix-like, preserves case but is not case
> sensitive.  It really is tragic.

Actually, to add another tragic note to this, the difference between
case preserving and case sensitive is not in the hand of the OS itself,
but a property of the file system driver and the underlying file system
the file is stored on.

I didn't test this lately, so I'm not sure how the Linux FAT or NTFS
driver behave, but the correct behaviour would be to act case preserving
when accessing files on a FAT or NTFS file system, not forcing case
sensitivity on them.

The behaviour of Samba is interesting.  I mounted a samba FS, provided
by one Linux box, on the second Linux box.  All access is case preserving,
not case sensitive, so you can chdir into a directory FOO with `cd foo'.
OTOH, when trying this:

   $ touch X.sh
   $ vim x.sh
   :w
   :q
   $ ls
   X.sh

the file is still called X.sh, not x.sh.  Weird.  I can only assume that
Samba is carefully maintaining the case of the filename.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Hello,

I'm a member of the [0]pugs project. Pugs is an implementation of a Perl
6 compiler/interpreter in haskell, which is quite popular in the Perl
world at the moment and expected to boostrap the real perl6 in the
future.

0. http://pugscode.org

Our SVN repository contains [1]util/perl6.vim. I don't think it belongs
there. Therefor I ask you to include this file in the next release of
vim.

1. http://svn.openfoundry.org/pugs/util/perl6.vim

Regards,
Flo

--
BOFH excuse #34:
(l)user error

Hi everyone,

> The default filesystem and configuration for Mac OS X, which is Unix-like,
preserves case but is not case sensitive.  It really is tragic.

In addition to Chris statement, the tragedy of which I concur...

Although the default OS X filesystem is case-preserving-yet-insensitive, it
is possible to use UFS (which is case sensitive, of course) or
HFSX-with-case-sensitivity-enabled.  (HFSX is the successor to HFS+.)

Caution:  do *not* put OS X on a case sensitive volume.  Apple's OS itself
is not properly case-sensitive correct/savvy.  Which is so funny it makes me
cry.  But ancillary volumes can be case-sensitive.

On NT-kernel-based Windows OS's, NTFS can be made sort-of case sensitive
(POSIX compliant-ish?) using SFU (Windows Services for Unix) or Interix 2.2
-- but note there are special case-sensitive OS API calls for file
manipulation that Explorer does not use (doh!).  If I recall correctly,
those case-sensitive OS API calls no longer appear in MSDN (funny that), so
don't expect to see them in Cygwin would be my guess.

Registry entry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Kernel
Value Name: ObCaseInsensitive
Data Type: REG_DWORD
Value Data: 0 (Case sensitive)

Ref:
http://support.microsoft.com/default.aspx?scid=kb;en-us;817921

Sincerely,
--Eljay

Since tar says "Argument list too long".
This patch can fix it by prepare the runtime files in two step.

--- old/Makefile 2005-10-28 01:40:53.645750000 +0800
+++ Makefile 2005-10-28 01:11:56.505125000 +0800
@@ -70,8 +70,8 @@
  #    compiled binaries.
  #    Before creating an archive first delete all backup files, *.orig, etc.

-MAJOR = 6
-MINOR = 3
+MAJOR = 7
+MINOR = 0aa

  # Uncomment this line if the Win32s version is to be included.
  #DOSBIN_S =  dosbin_s
@@ -429,6 +429,8 @@
 	 mkdir dist/vim/$(VIMRTDIR)
 	 tar cf - \
 		 $(RT_ALL) \
+  | (cd dist/vim/$(VIMRTDIR); tar xf -)
+ tar cf - \
 		 $(RT_SCRIPTS) \
 		 $(RT_DOS) \
 		 $(RT_NO_UNIX) \


--
Goddess light my path!

On 27.10.2005, at 15:36, John Love-Jensen wrote:
>> The default filesystem and configuration for Mac OS X, which is
>> Unix-like,
>>
> preserves case but is not case sensitive.  It really is tragic.

Sorry for my ignorance an offtopic but why is that really so tragic?
I've not had any problems with that during my 3 or so years with my
mac. What have I missed?

Greetings,
Jussi


--
Jussi Hagman, jhagman@..., iChat/AIM: jussihagman, ICQ: 54004113
Studentbyn 4 D 33, 20540 �bo, Finland +358 50 56 51 170

On 27/10/05, Jussi Hagman <jhagman@...> wrote:
>
> On 27.10.2005, at 15:36, John Love-Jensen wrote:
> >> The default filesystem and configuration for Mac OS X, which is
> >> Unix-like,
> > preserves case but is not case sensitive.  It really is tragic.
>
> Sorry for my ignorance an offtopic but why is that really so tragic?

Well, it is bad for OS X users because it can break packages from the
Unix world.  Make comes to mind, especially if a package has the
traditional INSTALL file and the traditional 'make install' target.
You can get around that with a dummy target, but not everyone does
that, since they expect a sensible file system.  I tripped over one of
these just recently and it is pretty baffling the first time.

It is bad for others since programs developed on OS X can not be said
to be correct and complete by their authors.

But, mostly, it is Just Wrong ;)  It is also a senseless, needless
violation of Single Unix Specification.  OS X may only be Unix-like,
but it wouldn't take much effort to be significantly more like Unix in
this case.

HTH,
Chris Allen

Hi all,

I return on the problem of the lost translations in Win32 version of vim
because I think I've found the cause of the malfunction. I copy and paste
a portion of the previous message describing the failure:

> I have a problem with the translations of the Windows shell extensions
> for vim. When I login into my PC (OS Win2000 SP4 - Italian) the shell
> extensions for vim (explorer context menus) are in the correct language
> and remain correct for a variable time. At a certain moment, I don't
> know why, the menu item appears in English; this is true for Vim 6.3
> and 6.4. If I logout and re-login the menu items revert to the correct
> translation.

I've found that this sudden "amnesia" of Vim is due to an adding/removing
of an environment variable (any environment variable). I suppose this
brings to an incorrect "reinitialization" of the DLL gvimext.dll that
lose the link to the current language, restoring the default (English).
I've verified the same problem on another PC (OS Win2000 SP4 - Italian)
with Vim 6.2. I am not sure this is a gvimext.dll bug (perhaps the real
problem is Windows), but I've thought it would be better signaling this.
Obviously, if someone has any ideas, I'll read the replies with great
interest.

Best regards.
Stefano Gibellini

On Thu, Oct 27, 2005 at 01:47:00PM +0200, Florian Ragwitz wrote:
> I'm a member of the [0]pugs project. Pugs is an implementation of a Perl
> 6 compiler/interpreter in haskell, which is quite popular in the Perl
> world at the moment and expected to boostrap the real perl6 in the
> future.
>
> 0. http://pugscode.org
>
> Our SVN repository contains [1]util/perl6.vim. I don't think it belongs
> there. Therefor I ask you to include this file in the next release of
> vim.
>
> 1. http://svn.openfoundry.org/pugs/util/perl6.vim

Given that the syntax of Perl6 is still changing, does it make sense to
distribute a syntax file as part of Vim at this stage?  Unless it's kept
very simple it'll start to be out of date within a few days.

--
Matthew Winn (matthew@...)

On Oct 27 22:53, Chris Allen wrote:
> On 27/10/05, Jussi Hagman <jhagman@...> wrote:
> >
> > On 27.10.2005, at 15:36, John Love-Jensen wrote:
> > >> The default filesystem and configuration for Mac OS X, which is
> > >> Unix-like,
> > > preserves case but is not case sensitive.  It really is tragic.
> >
> > Sorry for my ignorance an offtopic but why is that really so tragic?
>
> Well, it is bad for OS X users because it can break packages from the
> Unix world.  Make comes to mind, especially if a package has the
> traditional INSTALL file and the traditional 'make install' target.

Argh, yes, same on Windows.  I rather don't want to know the number of
people suffering a nervous breakdown before figuring out why `make
install' only returns "make: `install' is up to date." ;-)


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Stefano Gibellini wrote:
> Hi all,
>
> I return on the problem of the lost translations in Win32 version of vim
> because I think I've found the cause of the malfunction. I copy and paste
> a portion of the previous message describing the failure:
>
>> I have a problem with the translations of the Windows shell extensions
>> for vim. When I login into my PC (OS Win2000 SP4 - Italian) the shell
>> extensions for vim (explorer context menus) are in the correct language
>> and remain correct for a variable time. At a certain moment, I don't
>> know why, the menu item appears in English; this is true for Vim 6.3
>> and 6.4. If I logout and re-login the menu items revert to the correct
>> translation.
>
> I've found that this sudden "amnesia" of Vim is due to an adding/removing
> of an environment variable (any environment variable). I suppose this
> brings to an incorrect "reinitialization" of the DLL gvimext.dll that
> lose the link to the current language, restoring the default (English).
> I've verified the same problem on another PC (OS Win2000 SP4 - Italian)
> with Vim 6.2. I am not sure this is a gvimext.dll bug (perhaps the real
> problem is Windows), but I've thought it would be better signaling this.
> Obviously, if someone has any ideas, I'll read the replies with great
> interest.
>
> Best regards.
> Stefano Gibellini
>
>
>
>

Depending on your OS version, your shell, and the size of your
environment, adding too many environment variables might create an
"overflow". I'm not sure where the "leeway" left in the environment for
additional variables defined by the program is defined; but IIUC no
environment can exceed 65520 characters in Dos-like systems. This includes:

- for every NAME=value string, the length of the name plus the length of
the value plus one for the equal sign plus one for the terminating null
- three additional bytes, the first of which is a null, after the last
ASCIIZ name=value string
- the length of the pathfilename of the current program, expressed as an
ASCIIZ string
- optionally, a user- or OS-defined number of "leeway" bytes for extra
environment strings which will be added by the program (as distinct of
by the shell).

If the result of the above is not a multiple of 16, it is rounded up
until it is.

For more details, you may have to invoke CMD /? or something similar --
I don't have the exact same flavour of Windows as you, and the details
may vary. (In COMMAND.COM there is a command-line option for environment
size but in my version of CMD.EXE I see nothing similar.)

Best regards,
Tony.

Hi VIM developers,

I deeply hope that Vim script can support gettext so that I can translate the
user interface of a Vim plugin into another language much more easily. Here is
the sample script:

=================================== begin ====================================
" Define a function named "_"
" to make the scanning program work easier when parsing this file
" for strings to be translated
"
function! _(msgid)
     return dgettext("testgt", a:msgid)
endfunction

" Initialize the gettext function
"
bindtextdomain("testgt", expand("<sfile>:h")."/lang")

" Output a translated sample text
"
echo _("This is a test")
==================================== end =====================================

I think this feature can reduce the number of menu*.vim in $VIMRUNTIME/lang to
only one file, moving the translation into one .mo file and improve the
performance of the menu text translation (maybe). And it will make the
internationalization and localization of a script much easier.

I made a patch to support this feature in Vim7. See attachment for more
details. Hope this feature can be merged into Vim soon.


Regards,

Edward L. Fox

Index: runtime/syntax/vim.vim
===================================================================
RCS file: /cvsroot/vim/vim7/runtime/syntax/vim.vim,v
retrieving revision 1.23
diff -r1.23 vim.vim
58c58
< syn keyword vimFuncName contained add append argc argidx argv browse browsedir
bufexists buflisted bufloaded bufname bufnr bufwinnr byte2line byteidx call
char2nr cindent col complete_add complete_check confirm copy count
cscope_connection cursor deepcopy delete did_filetype diff_filler diff_hlID
empty escape eval eventhandler executable exists expand expr8 extend
filereadable filewritable filter finddir findfile fnamemodify foldclosed
foldclosedend foldlevel foldtext foldtextresult foreground function
garbagecollect get getbufline getbufvar getchar getcharmod getcmdline getcmdpos
getcmdtype getcwd getfontname getfperm getfsize getftime getftype getline
getqflist getreg getregtype getwinposx getwinposy getwinvar glob globpath has
has_key hasmapto histadd histdel histget histnr hlexists hlID hostname iconv
indent index input inputdialog inputlist inputrestore inputsave inputsecret
insert isdirectory islocked items join keys len libcall libcallnr line line2byte
lispindent localtime map maparg mapcheck match matchend matchlist matchstr max
min mkdir mode nextnonblank nr2char prevnonblank printf range readfile
remote_expr remote_foreground remote_peek remote_read remote_send remove rename
repeat resolve reverse search searchdecl searchpair server2client serverlist
setbufvar setcmdpos setline setqflist setreg setwinvar simplify sort soundfold
spellbadword spellsuggest split strftime stridx string strlen strpart strridx
strtrans submatch substitute synID synIDattr synIDtrans system tagfiles taglist
tempname tolower toupper tr type values virtcol visualmode winbufnr wincol
winheight winline winnr winrestcmd winwidth writefile
---
> syn keyword vimFuncName contained add append argc argidx argv bindtextdomain
browse browsedir bufexists buflisted bufloaded bufname bufnr bufwinnr byte2line
byteidx call char2nr cindent col complete_add complete_check confirm copy count
cscope_connection cursor deepcopy delete dgettext did_filetype diff_filler
diff_hlID empty escape eval eventhandler executable exists expand expr8 extend
filereadable filewritable filter finddir findfile fnamemodify foldclosed
foldclosedend foldlevel foldtext foldtextresult foreground function
garbagecollect get getbufline getbufvar getchar getcharmod getcmdline getcmdpos
getcmdtype getcwd getfontname getfperm getfsize getftime getftype getline
getqflist getreg getregtype getwinposx getwinposy getwinvar glob globpath has
has_key hasmapto histadd histdel histget histnr hlexists hlID hostname iconv
indent index input inputdialog inputlist inputrestore inputsave inputsecret
insert isdirectory islocked items join keys len libcall libcallnr line line2byte
lispindent localtime map maparg mapcheck match matchend matchlist matchstr max
min mkdir mode nextnonblank nr2char prevnonblank printf range readfile
remote_expr remote_foreground remote_peek remote_read remote_send remove rename
repeat resolve reverse search searchdecl searchpair server2client serverlist
setbufvar setcmdpos setline setqflist setreg setwinvar simplify sort soundfold
spellbadword spellsuggest split strftime stridx string strlen strpart strridx
strtrans submatch substitute synID synIDattr synIDtrans system tagfiles taglist
tempname tolower toupper tr type values virtcol visualmode winbufnr wincol
winheight winline winnr winrestcmd winwidth writefile
Index: src/eval.c
===================================================================
RCS file: /cvsroot/vim/vim7/src/eval.c,v
retrieving revision 1.112
diff -r1.112 eval.c
638a639,644
> /* TODO: Use a feature descriptor to shadow this feature. */
> #if 1
> static void f_bindtextdomain __ARGS((typval_T *argvars, typval_T *rettv));
> static void f_dgettext __ARGS((typval_T *argvars, typval_T *rettv));
> #endif
>
6734a6741,6744
> /* TODO: Use a feature descriptor to shadow this feature. */
> #if 1
>     {"bindtextdomain",  2, 2, f_bindtextdomain},
> #endif
6762a6773,6776
> /* TODO: Use a feature descriptor to shadow this feature. */
> #if 1
>     {"dgettext",        2, 2, f_dgettext},
> #endif
15231a15246,15275
> /* TODO: Use a feature descriptor to shadow this feature. */
> #if 1
> /*
>  * "bindtextdomain" function
>  */
>     static void
> f_bindtextdomain(argvars, rettv)
>     typval_T *argvars;
>     typval_T *rettv;
> {
>     rettv->v_type = VAR_STRING;
>     rettv->vval.v_string = vim_strsave(
>         bindtextdomain(get_tv_string(&argvars[0]),
>         get_tv_string(&argvars[1])));
> }
>
> /*
>  * "dgettext()" function
>  */
>     static void
> f_dgettext(argvars, rettv)
>     typval_T *argvars;
>     typval_T *rettv;
> {
>     rettv->v_type = VAR_STRING;
>     rettv->vval.v_string = vim_strsave(dgettext(get_tv_string(&argvars[0]),
>         get_tv_string(&argvars[1])));
> }
> #endif
>

Hi,

When I set LC_CTYPE to zh_TW.Big5 and opn a HTML, vim gives me these
warnings:

Error detected while processing /usr/share/vim/vim64/syntax/css.vim:
line   41:
E16: Invalid range
E475: Invalid argument: cssIdentifier "#[A-Za-z?-�@][A-Za-z?-?-9_@-]*"

I guess this is because the big5 charset doesn't contain some of the
characters list in the bracket.

When I set LC_CTYPE back to C or undo the change
http://cvs.sourceforge.net/viewcvs.py/vim/vim/runtime/syntax/css.vim?r1=1.11&r2=\
1.12
then it's OK again.

I am running debian unstable + vim 6.4.
--
Regards,
olv

Mail transaction failed. Partial message is available.