Changes to make Vim compile with X on OS X
Hi, I recently had trouble compiling Vim on Mac OS X 10.4.9 with GTK2 GUI. As is mentioned in the Vim source, the X headers and Mac headers clash horribly. This means stuff has to be separated carefully into files that have X headers available and those that have Mac headers available, and they weren't quite sorted out right. The attached patch fixes it by moving code around: - Moved from os_mac_conv.c to mac_gui.c and made static to that file: - mac_utf16_to_enc - mac_enc_to_utf16 - mac_enc_to_cfstring - mac_utf16_to_utf8 - mac_utf8_to_utf16 - A chunk of code from option.c has also been moved to os_mac_conv.c as 'mac_lang_init()'. - And a preprocessor conditional in globals.h was changed so X headers aren't expected when they aren't available. I thought it was the best of a bad bunch of options for fixing the issues. It now compiles for me, configured with ./configure --with-features=huge --enable-pythoninterp --enable-perlinterp --enable-rubyinterp --enable-tclinterp --enable-cscope --enable-gui=gtk2 It would be good to have this or a similar fix in the official distribution. Might this have an effect on MacVim, Bjorn, or vim-coco, Jiang (sorry if names wrong...memory is hazy)? If so, perhaps you could suggest a better solution? Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Changes to make Vim compile with X on OS X [with attachment]
[This copy contains the attachment. Also, I forgot to mention that simply
changing
the logic of preprocessing in, say, vim.h doesn't solve the problem. Features
provided by the conflicting code are indeed needed together--you lose X
functionality or MacRoman encoding functionality depending what is disabled,
and
there's no easy way to reconcile it by playing preprocessor games.]
Hi,
I recently had trouble compiling Vim on Mac OS X 10.4.9 with GTK2 GUI. As is
mentioned in the Vim source, the X headers and Mac headers clash horribly. This
means stuff has to be separated carefully into files that have X headers
available
and those that have Mac headers available, and they weren't quite sorted out
right. The attached patch fixes it by moving code around:
- Moved from os_mac_conv.c to mac_gui.c and made static to that file:
- mac_utf16_to_enc
- mac_enc_to_utf16
- mac_enc_to_cfstring
- mac_utf16_to_utf8
- mac_utf8_to_utf16
- A chunk of code from option.c has also been moved to os_mac_conv.c
as 'mac_lang_init()'.
- And a preprocessor conditional in globals.h was changed so X headers
aren't expected when they aren't available.
I thought it was the best of a bad bunch of options for fixing the issues.
It now compiles for me, configured with
./configure --with-features=huge --enable-pythoninterp --enable-perlinterp
--enable-rubyinterp --enable-tclinterp --enable-cscope --enable-gui=gtk2
It would be good to have this or a similar fix in the official distribution.
Might this have an effect on MacVim, Bjorn, or vim-coco, Jiang (sorry if names
wrong...memory is hazy)? If so, perhaps you could suggest a better solution?
Cheers,
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: src/option.c
===
--- src/option.c(revision 728)
+++ src/option.c(working copy)
@@ -3267,20 +3267,7 @@
}
# else
# ifdef MACOS_CONVERT
-if (mch_getenv((char_u *)LANG) == NULL)
-{
- charbuf[20];
- if (LocaleRefGetPartString(NULL,
- kLocaleLanguageMask | kLocaleLanguageVariantMask |
- kLocaleRegionMask | kLocaleRegionVariantMask,
- sizeof buf, buf) == noErr *buf)
- {
- vim_setenv((char_u *)LANG, (char_u *)buf);
-# ifdef HAVE_LOCALE_H
- setlocale(LC_ALL, );
-# endif
- }
-}
+mac_lang_init();
# endif
# endif
Index: src/proto/os_mac_conv.pro
===
--- src/proto/os_mac_conv.pro (revision 728)
+++ src/proto/os_mac_conv.pro (working copy)
@@ -4,8 +4,6 @@
int enc2macroman __ARGS((char_u *from, size_t fromlen, char_u *to, int
*tolenp, int maxtolen, char_u *rest, int *restlenp));
void mac_conv_init __ARGS((void));
void mac_conv_cleanup __ARGS((void));
-char_u *mac_utf16_to_enc __ARGS((UniChar *from, size_t fromLen, size_t
*actualLen));
-UniChar *mac_enc_to_utf16 __ARGS((char_u *from, size_t fromLen, size_t
*actualLen));
-CFStringRef mac_enc_to_cfstring __ARGS((char_u *from, size_t fromLen));
char_u *mac_precompose_path __ARGS((char_u *decompPath, size_t decompLen,
size_t *precompLen));
+void mac_lang_init __ARGS((void));
/* vim: set ft=c : */
Index: src/gui_mac.c
===
--- src/gui_mac.c (revision 728)
+++ src/gui_mac.c (working copy)
@@ -60,6 +60,9 @@
#ifdef MACOS_CONVERT
# define USE_CARBONKEYHANDLER
static EventHandlerUPP keyEventHandlerUPP = NULL;
+static char_u *mac_utf16_to_enc __ARGS((UniChar *from, size_t fromLen, size_t
*actualLen));
+static UniChar *mac_enc_to_utf16 __ARGS((char_u *from, size_t fromLen, size_t
*actualLen));
+static CFStringRef mac_enc_to_cfstring __ARGS((char_u *from, size_t fromLen));
#endif
@@ -6466,5 +6469,213 @@
RevealDataBrowserItem(dataBrowser, item, kTabsColumn,
kDataBrowserRevealOnly);
}
+#endif // FEAT_GUI_TABLINE
-#endif // FEAT_GUI_TABLINE
+#if defined(MACOS_CONVERT)
+/*
+ * Conversion from UTF-16 UniChars to 'encoding'
+ */
+static char_u *
+mac_utf16_to_enc(from, fromLen, actualLen)
+UniChar *from;
+size_t fromLen;
+size_t *actualLen;
+{
+/* Following code borrows somewhat from os_mswin.c */
+vimconv_T conv;
+size_t utf8_len;
+char_u *utf8_str;
+char_u *result = NULL;
+
+/* Convert to utf-8 first, works better with iconv */
+utf8_len = 0;
+utf8_str = mac_utf16_to_utf8(from, fromLen, utf8_len);
+
+if (utf8_str)
+{
+ /* We might be called before we have p_enc set up. */
+ conv.vc_type = CONV_NONE;
+
+ /* If encoding (p_enc) is any unicode, it is actually in utf-8 (vim
+*
Re: Changes to make Vim compile with X on OS X [with attachment]
Ben Schmidt wrote: [This copy contains the attachment. Also, I forgot to mention that simply changing the logic of preprocessing in, say, vim.h doesn't solve the problem. Features provided by the conflicting code are indeed needed together--you lose X functionality or MacRoman encoding functionality depending what is disabled, and there's no easy way to reconcile it by playing preprocessor games.] Hi, I recently had trouble compiling Vim on Mac OS X 10.4.9 with GTK2 GUI. As is mentioned in the Vim source, the X headers and Mac headers clash horribly. This means stuff has to be separated carefully into files that have X headers available and those that have Mac headers available, and they weren't quite sorted out right. The attached patch fixes it by moving code around: - Moved from os_mac_conv.c to mac_gui.c and made static to that file: - mac_utf16_to_enc - mac_enc_to_utf16 - mac_enc_to_cfstring - mac_utf16_to_utf8 - mac_utf8_to_utf16 I suppose you had to do this because MACOS_CONVERT is defined. Can't you change vim.h not to define MACOS_CONVERT when building with GTK? - A chunk of code from option.c has also been moved to os_mac_conv.c as 'mac_lang_init()'. - And a preprocessor conditional in globals.h was changed so X headers aren't expected when they aren't available. This isn't quite right, Win32 also has the balloon eval functionality. And GTK too, so how can you omit this? I thought it was the best of a bad bunch of options for fixing the issues. It now compiles for me, configured with ./configure --with-features=huge --enable-pythoninterp --enable-perlinterp --enable-rubyinterp --enable-tclinterp --enable-cscope --enable-gui=gtk2 What GTK did you install? It would be good to have this or a similar fix in the official distribution. Only when I'm sure it doesn't break anything. Might this have an effect on MacVim, Bjorn, or vim-coco, Jiang (sorry if names wrong...memory is hazy)? If so, perhaps you could suggest a better solution? -- ARTHUR: Be quiet! DENNIS: --but by a two-thirds majority in the case of more-- ARTHUR: Be quiet! I order you to be quiet! WOMAN: Order, eh -- who does he think he is? ARTHUR: I am your king! The Quest for the Holy Grail (Monty Python) /// 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/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Changes to make Vim compile with X on OS X [with attachment]
- Moved from os_mac_conv.c to mac_gui.c and made static to that file: - mac_utf16_to_enc - mac_enc_to_utf16 - mac_enc_to_cfstring - mac_utf16_to_utf8 - mac_utf8_to_utf16 I suppose you had to do this because MACOS_CONVERT is defined. Can't you change vim.h not to define MACOS_CONVERT when building with GTK? Yeah, you can, but (1) that doesn't fix it, because os_mac_conv.pro contains prototypes with Mac-specific types in them for those functions that weren't static in os_mac_conv.c originally, and (2) if you undefine that, you lose MacRoman support. Maybe the better solution would be to assume the types won't change (they surely never will!) and use some casts. Since the main problem is os_mac_conv.pro, if we can just get the types out of the function signatures, we will be good: UniChar = unsigned short (CFBase.h) CFStringRef is a pointer type (as are all .*Ref, I believe) so could use void *. - And a preprocessor conditional in globals.h was changed so X headers aren't expected when they aren't available. This isn't quite right, Win32 also has the balloon eval functionality. And GTK too, so how can you omit this? OK. I presume it's only a problem when we have Mac headers included, in which case, we can use !defined(NO_X11_INCLUDES) instead of defined(FEAT_X11) and I think that will cover it. What GTK did you install? One that MacPorts installs. 2.0.10, I think. Anyone know how I check easily? It would be good to have this or a similar fix in the official distribution. Only when I'm sure it doesn't break anything. Yeah. I'm quite unsure myself which is why I wrote so much detail about it and suggested something 'similar', by which I mean 'something that also works for me but probably works better for everyone else too'! I'll have a fiddle with it and if it works, send a revised patch in a few minutes. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Changes to make Vim compile with X on OS X [with attachment]
Unfortunately this patch will break MacVim compilation because of the MacRoman encoding support won't get compiled (MacVim does not use gui_mac.c, neither does vim-cocoa for that matter). Why is it not possible to have the encoding functions in a separate source file? The problem is mostly Mac-specific prototypes in os_mac_conv.pro. But if you look, none of the MacRoman functions have moved anyway, only Unicode ones that it seems only things like clipboard support use in plain Vim. The MacRoman stuff was left in os_mac_conv.c. Does MacVim use those same functions, though? But as per my previous email, perhaps it is better to leave them where they are and use casts. I'll see if it works that way and send a patch shortly if it does. Then Bram can choose which he reckons is better. :-) It's probably a good thing to have available for use by other Mac-related GUIs, even if MacVim doesn't use them yet. Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
