On 28/12/11 08:18, Ben wrote:
[...]
I've tried compiling with GUI enabled on both Cygwin and Mac OS X, and
I haven't had success. On Cygwin, I got the message "no GUI support"
during configuration, while on Mac OS X, compilation of gui_mac.c
failed with some strange looking errors. However, I'm pretty sure
Cygwin vim executables can't be run in both console and GUI mode (at
least I've never seen that), and all the modules to which I've added
code already include preprocessor tests for various GUI defines, so I
assume they are all compiled regardless of console/GUI configuration.
Thus, I've added preprocessor conditions to exclude all the new code
in the case that FEAT_GUI is defined.
IIUC, to make a gvim "for Cygwin" you need the Cygwin X11 libraries and
development environment, and at least one of the GUI packages (Motif,
GTK, etc.) which can be compiled into gvim. Then to make it run you
first need a Cygwin X11 server. IMHO it is usually not worth the
trouble: a Cygwin console-mode vim, and a vim.exe and gvim.exe for
"native Windows", are usually all one needs.
Under Mac OSX, Björn Winckler maintains the MacVim port, which is a
"flavour" of gvim for current versions of the Mac operating system.
Check the vim_mac list if you're interested.
Also, IIRC, during gvim startup (when it's known that we're going to
start gvim, has('gui_running') returns true, but we haven't yet (e.g.
we're still sourcing the vimrc), setting 'guicursor' to values typical
of the GUI gives no error even if the new values are invalid in console
mode, they are remembered, and applied when starting the GUI (about when
the GUIEnter event is triggered).
3. I'm not sure about how much testing needs to be done for a new
patch (this is the first patch I've ever submitted); I've only tested
it on one Windows 7 machine.
I suppose that it should be tested as extensively as possible, to ensure
that:
- it works in all Cygwin versions you could lay hands on, in as many
Windows versions as possible;
- it doesn't introduce new bugs in non-Cygwin Windows builds (which you
can test) or in non-Windows builds (meaning Linux and Mac OSX at the
very least, others if possible; here I suppose other people would have
to do the testing)
I've now tested the code change on 3 systems: Cygwin console on
Windows XP Home Edition SP3 (using the latest Cygwin version), Cygwin
console on Windows 7 Home Premium SP1 (using the latest Cygwin
version), and Mac OS X 10.6.8 console version. As I said before, I
haven't been able to compile a GUI version for testing, so hopefully
someone else can cover that territory (and likewise for Linux/other
systems).
Is there a beta release or the equivalent that we can include this in
to try to get as much coverage as possible?
hm, no, Bram does not maintain experimental branches of the code, except
temporarily when exploring a soon-to-come new point release, and I
haven't yet seen any sign of a 7.4 or 8.0 release of Vim; but you could
upload your patch (in context diff form with Unix line endings) anywhere
convenient, so that any interested tester can have a go at it. I see you
have copied it to the end of your post, but if you can get it a "place
to live" on the web that would be more permanent.
One thing you might also try is compiling a Windows gvim (not for
Cygwin) from your modified source, to check that there's no missing #ifdef
A small nit about that patch: Bram's "house style" indents preprocessor
conditionals by one space per level after the #, as follows:
#ifdef MCH_CURSOR_SHAPE
# if defined(__CYGWIN__) && !defined(FEAT_GUI)
# include <windows.h>
...
# endif /* Cygwin console */
#endif /* MCH_CURSOR_SHAPE */
and avoids C++ comments in C source. I know, most modern compilers
accept both kinds of comments, but there are so many different OSes and
compilers supported by Vim, we have to be particularly "conservative in
what we emit". There's no way we can test them all ourselves, from
VAX/VMS to zOS to smartphone Linux to whatever, so Bram's custom is to
bend over backwards to make the code as compatible as possible, if
necessary by means of a coding style so obsolete that all C compilers
are guaranteed to support it; and (notwithstanding my pejorative
phrasing) I believe that it's the right thing to do.
Best regards,
Tony.
--
There are three ways to get something done: do it yourself, hire
someone, or forbid your kids to do it.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
