[redirected from vim_use to vim_dev]
Good idea!
OK, I got confused. I think in vim.h FEAT_GUI should be defined even
when NO_X11_INCLUDES is defined. If there is some place where FEAT_GUI
causes trouble then add a check for NO_X11_INCLUDES there. That should
be a lot cleaner an avoids unexpected side effects. NO_X11_INCLUDES
suggests only the includes are skipped, nothing else.
I agree. It is a much bigger and more complicated patch, though, as not
including those files has a lot of side-effects in terms of which
structures can be defined. I've done what I think is most sensible in
the attached patch. What do you think?
Phew, that's a mess. I didn't expect so many dependencies.
Can we think of another solution? Perhaps we can split os_macosx.c into
a part that conflicts with the X11 headers and doesn't contain any GUI
stuff and a part with the rest, that may use GUI stuff? Or is there
code that both uses the GUI and conflicts with X11 headers?
I think that is essentially already the situation. The trouble is more
that once you don't include the X11 headers, a bunch of structures,
which aren't particularly GUI-related (i.e. they exist in console Vim),
such as Vim windows, syntax groups, etc., can't be defined, as they
contain GUI-related members. And even if they are unused in the .c file
being compiled, as they are defined in the header files, of which Vim
has few, they are somewhat inavoidable. Without adding an extra layer of
indirection to all these structures (to go via a pointer rather than use
the GUI members directly, so at least the strctures can remain constant
with or without the GUI/X11 datatypes defined), or splitting Vim's
header files up a lot more (so it is more modular and we can pull in
what, and only what we want/need in any given source file), we are a bit
stuck.
I don't think the code that conflicts with X11 headers actually does
much, or uses many structures, so either of those approaches above could
potentially work (well, indirection will always work, and modularisation
could work or mostly work, and just fall back to indirection where
necessary). But both are quite a bit of work, for little gain, IMHO.
The current code, of course, is a bit dangerous--just turning off the
GUI features when compiling certain source files means a whole bunch of
structures are defined really very differently for just those files. If
any are allocated or members past where the two versions match are used,
things could go horribly wrong, and in a hard-to-find way. With the new
patch I forwarded, there is at least only one such structure (which I
reordered so that the one member that needs to be included/excluded is
at the end, so it's as safe as possible). So at least it's better. Still
not pretty, though.
All depends which risks you prefer, really, as I, like you, don't think
we should spend too much time on this.
Ben.
--
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
