Cross-platform multi-lingual support and Windows
ron
I'm trying to add a 'language' menu to my vim setup so my users can
select a UI language. The scripts work great on Linux, and I finally
managed to get them working properly (mostly) on Windows XP. However,
Windows 7 is puzzling me.
I can get the menus to appear, but the messages never appear in the
correct language. Again, this works fine for me on Linux and XP.
The relevant scripts are here: http://ronware.org/lang.zip
Is there any way vimscript can distinguish windows versions?
Any help appreciated...
Tony Mechelynck
In brad terms, yes; but not necessarily with the precision you want.
has('win16') is nonzero (TRUE) in w3, w3.1, w3.11, with or without w32s;
all obsolete by now
has('dos16') and has('dos32') are TRUE in versions of Vim compiled to
run with 16- or 32-bit code, respectively, on DOS systems (with DJGPP
for 32 bit); some such versions may still be running on Windows.
has('win32') is TRUE in any 32-Vim for Windows; of these, versions for
w95/w98/wME also have has('win95') TRUE. This item also applies to
32-bit Vim running on 64-bit Windows IIUC.
has('win64') is TRUE in Vim versions compiled for 64-bit Windows (such
an executable will of course not be able to run unless it has both a
64-bit processor and a 64-bit OS). This was added by patch 7.2.328 which
is relatively recent; before that, there was no way for a script to know
that you had a 64-bit version of Vim.
has('gui_win32') is TRUE in gvim for w32 (and presumably for w64) but
not in console versions. On Windows, unlike on Unix, a single executable
can be either a GUI or a console application but not both.
see
:help has()
:help feature-list
To test if you have patch 7.2.328 compiled-in (cf. :help has-patch):
if (version > 702) || (version == 702 && has('patch328'))
echo "7.2.328 or better"
if has('win64')
echo "64-bit Vim"
elseif has('win32')
echo "32-bit, NOT 64-bit Vim"
else
echo "Neither Win32 nor Win64: Cygwin? Unix? Dos?"
endif
else
echo "not yet 7.2.328"
if has('win32')
echo "Windows Vim, don't know if 64-bit"
else
echo "Neither Win32 nor Win64: Cygwin? Unix? Dos?"
endif
endif
I'm intentionally testing |version| rather than |v:version| (q.v.) so
that even very old Vim versions will still react correctly (by returning
a version value much lower than 702).
Best regards,
Tony.
--
After an instrument has been assembled, extra components will be found
on the bench.
ron
wrote:
> :help has()
> :help feature-list
Thanks, I know that ...
It turns out it was Programmer Error (on my part). My NSIS installer
was not running with high enough privileges to set VIMRUNTIME in the
environment. By the way, requiring that to be set is really odd ...
but anyway, my stuff now works on Vista and Windows7
Thanks again,
Ron
Tony Mechelynck
You should not need to set VIMRUNTIME in the permanent environment; on
Windows, Vim sets it (for itself and the processes it spawns, but not
permanently), usually to the directory from which it was loaded
("C:\Program Files\vim\vim72" or similar). In addition, that setting
changes from one version to the next so it really should _not_ be
permanent (if you run two different Vims in parallel, each of them
should set VIMRUNTIME in its own environment according to its version).
Similarly Vim sets VIM, usually to the parent of VIMRUNTIME. You may
want to set it if you want to access, let's say, $VIM/vimfiles from the
command (shell) prompt, but it is not necessary.
...and if you mean that setting variables temporarily in one's own
environment requires superuser privileges on Windows Vista and later,
that's one more proof (if I needed any) that Gates & Co. don't
understand a thing to what security means: such a measure won't make
fewer users set environment variables, it will make more of them grab
superuser privs permanently, which is the opposite of the desired result.
Best regards,
Tony.
--
The men sat sipping their tea in silence. After a while the
klutz said, "Life is like a bowl of sour cream."
"Like a bowl of sour cream?" asked the other. "Why?"
"How should I know? What am I, a philosopher?"
ron
On Apr 8, 2:11 pm, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
> You should not need to set VIMRUNTIME in the permanent environment; on
I don't install in the 'usual' manner, but rather have a e.g. 'c:\vim
\'
directory where the executable is in 'c:\vim\bin' and the runtime is
in
'c:\vim\runtime'. My special runtime files are in 'c:\vim\global'.
Don't
ask, it's to support various needs of different people.
Anyway, vim has never been happy with my layout. I do set VIMRUNTIME
in the
_vimrc file -- however, it needs to be set *before* _vimrc is sourced,
because
... well, I suppose the gettext initialization happens early so that
any
messages appear correctly.
In any case, it's not too onerous to set it in the environment, but...
it
makes installation a bit more fragile than it could be. BTW, I do
also set
VIM to e.g. 'c:\vim\bin'.
> ...that's one more proof (if I needed any) that Gates & Co. don't
> understand a thing to what security means
No argument from me. I use Linux almost exclusively... but I support
users on
a variety of Windows flavors, and I need to be able to deploy nicely
on them.
Best,
Ron
ron
In 'main.c', around line 382, there is an 'init_locale()' which is
intended to happen after 'gui_init_check()'.
However, this only happens for the GTK UI. My question is, would it
cause a problem to move this outside of that conditional and enable it
for all versions of vim (not just GUI version).
I ask, because I modify $VIMRUNTIME in my startup scripts, early,
before the UI starts up. If the 'init_locale()' was re-done after my
vimrc had been processed, then I would not need to have VIMRUNTIME set
(on Windows boxen) in order to have the gettext stuff work correctly.
Thanks,
Ron
Bram Moolenaar
Ron Aaron wrote:
What version of NSIS are you using? Later versions have support for
Windows7.
We should detect that the installer is running with wrong privileges.
Can that be done?
--
We apologise again for the fault in the subtitles. Those responsible for
sacking the people who have just been sacked have been sacked.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
Bram Moolenaar
Ron Aaron wrote:
Perhaps the best solution is to put the code that uses $VIMRUNTIME to
another function and only call that part again after sourcing the vimrc
file.
I don't know how much overhead this has on different systems. Only
calling bindtextdomain() again if $VIMRUNTIME has changed requires
keeping the value used the first time. Or detecting that it's changed.
--
Mynd you, m00se bites Kan be pretty nasti ...
ron
systems. Maybe it would be ok to just add it for WIN32 systems?
ron
I'm running the latest NSIS. I simply had to put the right line in
my .nsi file, to wit: "RequestExecutionLevel highest"