Re: VIM 7.1 compilation error
Edward L. Fox
> [...]
> gui_gtk_x11.c: In function 'gui_mch_set_fontset':
> gui_gtk_x11.c:5348: error: 'gui_T' has no member named 'current_font'
> gui_gtk_x11.c: In function 'gui_mch_free_fontset':
> gui_gtk_x11.c:5374: warning: passing argument 1 of 'gdk_font_unref' from
> incompatible pointer type
> make: *** [objects/gui_gtk_x11.o] Error 1
>
> Turning off the '--enable-hangulinput' option might temporally resolve that.
> Now I'm also finding a way to settle the matter completely even turning on
> it.
> But no one has seemed to know it, poor...:-(
Try this patch:
Index: src/gui_gtk_x11.c
===================================================================
--- src/gui_gtk_x11.c (revision 396)
+++ src/gui_gtk_x11.c (working copy)
@@ -5347,7 +5347,7 @@
void
gui_mch_set_fontset(GuiFontset fontset)
{
- gui.current_font = fontset;
+ gui.fontset = fontset;
}
#endif
> [...]
By the way, please always use bottom-posting or interlaced-posting in
this mailing list. Bram hates top-posting.
Regards,
Edward L. Fox
Edward L. Fox
On 8/3/07, um.k...@gmail.com <um.k...@gmail.com> wrote:
> Thanks Edward.
>
> It works just in compiling manner, not actual.
> Hangul inputting is incorrect, all is shown as broken characters.
Sorry but I know nothing about Hangul input. Could you give me a brief
introduction of the basic usage of Hangul input? That is, how do I set
up the Hangul input and what result is expected? Then I could do some
basic debugging about this problem.
Any way, as the Vim build-in Hangul input conflicts with XIM
interface, I think you'd better enable XIM interface rather than
Hangul interface, then you could use some more powerful input method
engine such as SCIM instead.
> By the way, what does the "bottom-posting or interlaced-posting" mean?
> Is it "Reply to Author"?
FYI
http://en.wikipedia.org/wiki/Posting_style
> Sorry for bothering you. I'm just first time here.
Just feel free to post any thing here. All people here are very
friendly. But you should obey the basic rules and the principles here.
For example, bottom-posting. :-)
>
> Best regards,
> Kiwon Um
> [...]
Cheers,
Edward L. Fox
Shawn Y. Kim
On 8월3일, 오후6시16분, "Edward L. Fox" <edy...@gmail.com> wrote:
> Hi Kiwon,
Hi, Kiwon.
It seems that you were trying to compile vim using following options
combined together:
--enable-hangulinput
--enable-xim=no
--enable-gui=gtk2
--enable-fontset
--enable-multibyte
--enable-multilang
The problem that caused the compile error is that the hangulinput
module depends on xfontset.
And the fontset feature causes sort of "conflict" with gtk2.
Gtk2 has whole different font system than that of gtk1.2.
I've also been through the same what you're going through.
There could be a couple of solutions :
1. You could just use your xim. Try to configure vim with these
options :
--enable-xim --enable-gui=gtk2 --enable-multibyte --enable-multilang
2. If you really hate XIMs like SCIM and nabi,
2-1. you coluld choose to use gtk instead of gtk2
--enable-hangulinput --enable-gui=gtk --enable-multibyte --enable-
multilang --enable-xim=no --enable-fontset
2-2. If you want to use the built-in hangulinput module with GTK2,
there's a way. I'm gonna describe how to do that later.
Above, I can see Mr.Fox has posted a solution about this. Frankly, I
didn't really tried that one out.
I, however, got another one, though it has a "critical" limitation.
Here it is:
shawn.ygdrasil:~/work/vim7/src$ svn diff feature.h
Index: feature.h
===================================================================
--- feature.h (revision 392)
+++ feature.h (working copy)
@@ -674,7 +674,10 @@
* turn to english mode
*/
# if !defined(FEAT_XFONTSET) && defined(HAVE_X11)
-# define FEAT_XFONTSET /* Hangul input
requires xfontset */
+# if !defined(HAVE_GTK2)
+# define FEAT_XFONTSET /* Hangul input
requires xfontset
+ only if not featured with
gtk2 */
+#endif
# endif
# if defined(FEAT_XIM) && !defined(LINT)
Error: You should select only ONE of XIM and HANGUL INPUT
shawn.ygdrasil:~/work/vim7/src$
The one thing that may be bothering you when you use this patch is
that you HAVE TO always use euc-kr as your encoding.
If the locale settings of your machine is UTF-8, you've gotta add
these lines to your .vimrc file :
set encoding=euc-kr
set fileencoding=utf-8
As to the details of encoding and fileencoding, refer to the vim help
page.
Except for that, it works great with GTK+2 with alti-aliased fonts,
easy to set font, huh?
But, personally, I prefer to use GTK+1.2 with rasterized, highly-
optimized fonts like sun-gothic + fixed combination.
Any way, good look.
BRGD.
Shawn from Seoul ;-)
Edward L. Fox
Sorry for sending mail in HTML format, as the following content has some images to display.
Do you think we should deprecate the build-in Hangul supporting since the next version of VIM? So far as I know, the Hangul supporting conflicted with XIM module, which is more useful for Asian users. That's why the official Vim pre-built binary never enable this option. Some Korean users also noticed that the latest sources couldn't be built with this option enabled. I think all the users will use input method later, so I'd like to disable the "Hangul automata" from now on.
And if possible, we could also supply a Hangul input method by using the keymap mechanism, just like the kana (Japanese letters) keymap ported by me. I know nothing about Korean so I hope any Korean friend could help me with this issue.
Best regards,
Edward L. Fox
---------- Forwarded message ----------
From: Kiwon Um <um.k...@gmail.com >
Date: Aug 3, 2007 7:42 PM
Subject: Re: VIM 7.1 compilation error
To: "Edward L. Fox" <edy...@gmail.com>
Thanks for reply.
Edward L. Fox wrote:
Hi Kiwon, On 8/3/07, um.k...@gmail.com <um.k...@gmail.com> wrote:Thanks Edward. It works just in compiling manner, not actual. Hangul inputting is incorrect, all is shown as broken characters.Sorry but I know nothing about Hangul input. Could you give me a brief introduction of the basic usage of Hangul input? That is, how do I set up the Hangul input and what result is expected? Then I could do some basic debugging about this problem. Any way, as the Vim build-in Hangul input conflicts with XIM interface, I think you'd better enable XIM interface rather than Hangul interface, then you could use some more powerful input method engine such as SCIM instead.
In good case, i.e. without "--enable-hangulinput"option, the result is as follow:
In bad case, i.e. with that option, the result is as follow:(In this case, I used "SCIM")
VIM with SCIM is works quite well.
So.. just in my opinion, the next version of VIM might not need to have even that configure option.
It rather makes some user, like me, confused.
By the way, what does the "bottom-posting or interlaced-posting" mean? Is it "Reply to Author"?FYI http://en.wikipedia.org/wiki/Posting_style
Sorry for bothering you. I'm just first time here.Just feel free to post any thing here. All people here are very friendly. But you should obey the basic rules and the principles here. For example, bottom-posting. :-)
Anyhow I know now. :-)
Best regards, Kiwon Um [...]Cheers, Edward L. Fox
Best regards,
Kiwon Um
Edward L. Fox
(Cross-posting to vim-multibytes)
Thanks for your reply!
On 8/3/07, Shawn Y. Kim <orch...@gmail.com> wrote:
> [...]
> I've also been through the same what you're going through.
>
> There could be a couple of solutions :
>
> 1. You could just use your xim. Try to configure vim with these
> options :
> --enable-xim --enable-gui=gtk2 --enable-multibyte --enable-multilang
> 2. If you really hate XIMs like SCIM and nabi,
> 2-1. you coluld choose to use gtk instead of gtk2
> --enable-hangulinput --enable-gui=gtk --enable-multibyte --enable-
> multilang --enable-xim=no --enable-fontset
> 2-2. If you want to use the built-in hangulinput module with GTK2,
> there's a way. I'm gonna describe how to do that later.
>
> Above, I can see Mr.Fox has posted a solution about this. Frankly, I
> didn't really tried that one out.
In fact as Um. Kiwon reported, my patch doesn't work at all. :-(
I don't actually know how many Vimmers in Korean are still using the
Hangul automata. In my impression, I think every Asian user is using
at least one Input Method Engine (IME). If so, the Hangul automata may
not be necessary at all. Or if possible, we could use keymap to
simulate the Hangul automata.
Um, it seems that with these settings, I will not be able to edit
files in other CJK languages...
> As to the details of encoding and fileencoding, refer to the vim help
> page.
>
> Except for that, it works great with GTK+2 with alti-aliased fonts,
> easy to set font, huh?
> But, personally, I prefer to use GTK+1.2 with rasterized, highly-
> optimized fonts like sun-gothic + fixed combination.
By the way, I guess that Gothic was a Japanese font... Three widely
used Korean fonts are named "BatangChe", "DotumChe", "Gulim" and
"GulimChe". Maybe I am wrong...
>
> Any way, good look.
>
> BRGD.
> Shawn from Seoul ;-)
Shalom,
Edward L. Fox
Shawn Kim
>>
>>> Thanks Edward.
>>>
>>> It works just in compiling manner, not actual.
>>> Hangul inputting is incorrect, all is shown as broken characters.
>>>
>> Sorry but I know nothing about Hangul input. Could you give me a brief
>> introduction of the basic usage of Hangul input? That is, how do I set
>> up the Hangul input and what result is expected? Then I could do some
>> basic debugging about this problem.
>>
>> Any way, as the Vim build-in Hangul input conflicts with XIM
>> interface, I think you'd better enable XIM interface rather than
>> Hangul interface, then you could use some more powerful input method
>> engine such as SCIM instead.
>>
> I append two figures to compare between with "--enable-hangulinput"
> option and without. (I just captured two screen shots.)
> In good case, i.e. without "--enable-hangulinput"option, the result is
> as follow:
>
>
> In bad case, i.e. with that option, the result is as follow:
>
>
> VIM with SCIM is works quite well.
> So.. just in my opinion, the next version of VIM might not need to
> have even that configure option.
> It rather makes some user, like me, confused.
>>> By the way, what does the "bottom-posting or interlaced-posting" mean?
>>> Is it "Reply to Author"?
>>>
>> FYI
>>
>> http://en.wikipedia.org/wiki/Posting_style
>>
> Like this style, what I'm writing down, huh? :-)
>>> Sorry for bothering you. I'm just first time here.
>>>
>> Just feel free to post any thing here. All people here are very
>> friendly. But you should obey the basic rules and the principles here.
>> For example, bottom-posting. :-)
>>
> I didn't know if that was really rule.
> Anyhow I know now. :-)
>>
>>> Best regards,
>>> Kiwon Um
>>> [...]
>>>
>> Cheers,
>>
>> Edward L. Fox
>>
> Thanks again.
>
> Best regards,
> Kiwon Um
>
>
> >
You told about getting rid of built-in Hangul input feature from vim.
I'm afraid that I don't feel like getting it out of vim.
There are a lot of systems where XIM is not available at all out there.
For example, at my office, we run a bunch of "servers".
I just ssh to one of them and set DISPLAY environment variable to point
to my local laptop which runs Ubuntu linux.
And then I run gvim to edit source codes.
Systems like AIX, True64, Solaris, SunOS, HP-UX, and older versions of
RedHat linux does not even have GTK.
In those system, I don't seem to have many choices.
I MUST compile vim enabling hangulinput feature and then use it to
type in Hangul.
It would never be enough to stress the necessity and the importance of
that feature for Koreans.
I would be devastated if that feature is to removed :'O
Regards,
Shawn.
P.S. Personally, using XIM with vim is kind of confusing.
If you were typing Hangul in input mode, and then you escape from that
mode by pressing upon ESC,
XIM is still in Hangul input mode. So, any of your comands won't work
until you switch to English input mode by
pressing Shift+Space. It is very unconvinient and confusing.
As it seems that I can seem to control XIM out of it, like sending
signal or something, for me,
it is just more appreciated using hangulinput feature. :-)
Edward L. Fox
On 8/3/07, Shawn Kim <orch...@gmail.com> wrote:
> [...]
> In those system, I don't seem to have many choices.
> I MUST compile vim enabling hangulinput feature and then use it to
> type in Hangul.
> It would never be enough to stress the necessity and the importance of
> that feature for Koreans.
> I would be devastated if that feature is to removed :'O
OK, I see. But I'm still wondered that could this feature be
implemented as a keymap? Like this:
1. :set keymap=kana
2. Type "ohayougozaimasu" will produce:
おはようございます。
If we could implement the Hangul input as a keymap, we can simply drop
the Hangul automata without any difficulty then.
>
> Regards,
> Shawn.
>
> P.S. Personally, using XIM with vim is kind of confusing.
> If you were typing Hangul in input mode, and then you escape from that
> mode by pressing upon ESC,
> XIM is still in Hangul input mode. So, any of your comands won't work
> until you switch to English input mode by
> pressing Shift+Space. It is very unconvinient and confusing.
> As it seems that I can seem to control XIM out of it, like sending
> signal or something, for me,
> it is just more appreciated using hangulinput feature. :-)
Just type ":help imactivatekey" and read this part of the manual,
maybe it's useful for you. :-)
>
> [...]
In peace,
Edward L. Fox
Shawn Y. Kim
On 8월4일, 오전12시04분, "Edward L. Fox" <edy...@gmail.com> wrote:
> Hi Shawn Y. Kim,
>
> (Cross-posting to vim-multibytes)
>
> Thanks for your reply!
My pleasure ;-)
>
> On 8/3/07, Shawn Y. Kim <orchis...@gmail.com> wrote:
>
>
>
> > [...]
> > I've also been through the same what you're going through.
>
> > There could be a couple of solutions :
>
> > 1. You could just use your xim. Try to configure vim with these
> > options :
> > --enable-xim --enable-gui=gtk2 --enable-multibyte --enable-multilang
> > 2. If you really hate XIMs like SCIM and nabi,
> > 2-1. you coluld choose to use gtk instead of gtk2
> > --enable-hangulinput --enable-gui=gtk --enable-multibyte --enable-
> > multilang --enable-xim=no --enable-fontset
> > 2-2. If you want to use the built-in hangulinput module with GTK2,
> > there's a way. I'm gonna describe how to do that later.
>
> > Above, I can see Mr.Fox has posted a solution about this. Frankly, I
> > didn't really tried that one out.
>
> In fact as Um. Kiwon reported, my patch doesn't work at all. :-(
>
> I don't actually know how many Vimmers in Korean are still using the
> Hangul automata. In my impression, I think every Asian user is using
> at least one Input Method Engine (IME). If so, the Hangul automata may
> not be necessary at all. Or if possible, we could use keymap to
> simulate the Hangul automata.
OK, there's no statistical report, yet ;-)
Sure, it's true that every Asian user's using at least one IME.
As far as I'm concerned, there also are many users who just can't use
one.
It could be because they don't have root privilege and their system
administrators just
do not even want to bother paying much attention to stuffs like IME or
incompetent :-(
Bottom line.
As far as I'm concerned, the hangulinput feature needs to be at least
kept as it is now.
Yes, that is true, Gulim or GulimChe are widely appreciated as they
are system fonts in the Windows OSs.
But the landscape has been changed as "Un-Gothic" font has become
available.
Almost every recent linux distribution use "Un-Gothic" (I am not sure
the name is correctly spelled out :-( ).
Moreover, GulimChe, Gulim and BatangChe are commercial fonts :-(
As to sun-gothic font, yes it is also a commercial font that comes
with Sun microsystem's openwin.
IMHO, sun-gothic font is the most readable hangul "bitmap" font.
>
>
>
> > Any way, good look.
>
> > BRGD.
> > Shawn from Seoul ;-)
>
> Shalom,
>
> Edward L. Fox
Regards,
Shawn Y. Kim.
Shawn Y. Kim
> OK, I see. But I'm still wondered that could this feature be
> implemented as a keymap? Like this:
>
> 1. :set keymap=kana
>
> 2. Type "ohayougozaimasu" will produce:
>
> おはようございます。
>
> If we could implement the Hangul input as a keymap, we can simply drop
> the Hangul automata without any difficulty then.
It could be possible :-)
To be frank with you, I didn't even know of that option. My
shortcoming.
IMHO, however, many would prefer to type directly in Hangul words.
There IS so-called "standard" Hangul-Roman denoting rule that's been
adopted by Korean government.
Though the "standard" has been changed rather drastically a bunch of
times.
Now, virtually everyone in Korea has their own "standard".
On top of that Hangul is not that simple as Kana.
But not that complicated as Chinese.
You can refer to the page about Hangul at wikipedia if you're
interested :-)
http://en.wikipedia.org/wiki/Hangul
Anyway, as to this matter of inputting hangun with keymaps, I can't
say for sure.
May I've got to gather some Korean Vimmers' thoughts on this.
I could open a poll at a popular Korean developer's site :-)
> Just type ":help imactivatekey" and read this part of the manual,
> maybe it's useful for you. :-)
I did not know of that option either.
But I highly doubt that it would work for me.
Because what is inconvenient with using IM is that the IM is not
automatically de-activated entering into normal mode from input mode.
But, I appreciate you tipping me off with that option :-D
Respectfully,
Shawn Y. Kim.
Shawn Kim
> Hi,
>
> Wouldn't hangul be a very big keymap? If the keymap was for individual jamo it would be manageable but I'm not sure how vim would then combine the jamo. If it is for all hangul characters it will be very large -- unless I am missing something.
>
> On the other hand, it should also be relatively easy to generate the keymap automatically...
>
> Benjamin
>
>
Replying to all,
Hi, Benjamin,
Yes, It is a huge set of letters.
There are more than 10,000 letters that can possibly be made up, even
excluding obsoleted ones.
And there is a criticism I found about that method :
http://en.wikipedia.org/wiki/Revised_Romanization_of_Korean#Criticism
Thanks for your comment
Shawn.
Bram Moolenaar
Edward L. Fox wrote:
> Sorry for sending mail in HTML format, as the following content has some
> images to display.
>
> Do you think we should deprecate the build-in Hangul supporting since the
> next version of VIM? So far as I know, the Hangul supporting conflicted with
> XIM module, which is more useful for Asian users. That's why the official
> Vim pre-built binary never enable this option. Some Korean users also
> noticed that the latest sources couldn't be built with this option enabled.
> I think all the users will use input method later, so I'd like to disable
> the "Hangul automata" from now on.
>
> And if possible, we could also supply a Hangul input method by using the
> keymap mechanism, just like the kana (Japanese letters) keymap ported by me.
> I know nothing about Korean so I hope any Korean friend could help me with
> this issue.
I hesitate removing the Hangul support without knowing for sure that it
is not needed. Browsing through the messages I do see remarks that it
might still be useful to a few people.
Perhaps the Hangul support can be changed to also work for UTF-8?
The compilation error is easy to fix: Don't define FEAT_XFONTSET when
using GTK2.
--
From "know your smileys":
:-) Funny
|-) Funny Oriental
(-: Funny Australian
/// 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 ///
Kiwon Um
These solutions worked well.
Now I'm just using VIM with SCIM.
But still one more question...
I've tested something more with Hangul i.e. Korean text.
I have some 'euckr' encoded text files but my VIMs (such gvim or vim)
cannot read/show these files correctly.
Although I set 'encoding=euckr' and 'fileencoding=euckr or utf8', it
show me some broken characters.
I think it might be a quite different problem with --enable-
hangulinput.
Anyhow I just want to resolve Hangul-cencerned problems.
> that you HAVE TO always useeuc-kras your encoding.
> If the locale settings of your machine is UTF-8, you've gotta add
> these lines to your .vimrc file :
>
> set encoding=euc-kr
> set fileencoding=utf-8
>
> As to the details of encoding and fileencoding, refer to the vim help
> page.
>
> Except for that, it works great with GTK+2 with alti-aliased fonts,
> easy to set font, huh?
> But, personally, I prefer to use GTK+1.2 with rasterized, highly-
> optimized fonts like sun-gothic + fixed combination.
>
I didn't try these yet.
> Any way, good look.
>
> BRGD.
> Shawn from Seoul ;-)
It was my extremely short thought to get rid of the --enable-
hangulnput fixture.
I didn't care about persons who should use that.
Thanks again for your cares.
Best regards,
Kiwon Um
Tony Mechelynck
[...]
> But still one more question...
> I've tested something more with Hangul i.e. Korean text.
> I have some 'euckr' encoded text files but my VIMs (such gvim or vim)
> cannot read/show these files correctly.
> Although I set 'encoding=euckr' and 'fileencoding=euckr or utf8', it
> show me some broken characters.
How to solve that will depend on which kinds of files you usually edit; the
following assumes that you have 'encoding' set to utf-8:
a) Most files are either Unicode with BOM, UTF-8 (even without BOM), or euc-kr:
:set fileencodings=ucs-bom,utf-8,euc-kr,latin1
If some euc-kr file is wrongly detected as UTF-8:
:e ++enc=euc-kr filename
If you need to edit some Unicode file without BOM in another encoding than
UTF-8, use (for instance):
:e ++enc=utf-16le filename
b) You have only a few euc-kr files, and you know what they are:
:set fileencodings=ucs-bom,utf-8,latin1
Always open euc-kr files with
:e ++enc=euc-kr filename
c) All (or almost all) your Unicode files have a BOM:
:set fileencodings=ucs-bom,euc-kr,latin1
If you need to edit a Unicode file without a BOM, use for instance
:e ++enc=utf8 filename
etc.
To set the BOM on all _new_ Unicode files by default, use
:setglobal bomb
This setting does not affect non-Unicode files. For existing files, the
presence or absence of a BOM is detected automatically if 'fileencodings'
starts with "ucs-bom".
See
:help 'fileencodings'
:help ++opt
:help 'bomb'
Shawn Y. Kim
>
> I hesitate removing the Hangul support without knowing for sure that it
> is not needed. Browsing through the messages I do see remarks that it
> might still be useful to a few people.
>
> Perhaps the Hangul support can be changed to also work for UTF-8?
I guess I can work on this.
It will take some time though.
As to how widely hangulinput features is being used, I can just say "a
few" people.
Even though not so many people is using that one as they use IME,
there still are people making use of hangulinput feature, including
me.
Shawn Y. Kim.
Kang Seonghoon
> It will take some time though.
>
> As to how widely hangulinput features is being used, I can just say "a
> few" people.
> Even though not so many people is using that one as they use IME,
> there still are people making use of hangulinput feature, including
> me.
Or, can we make Hangeul input plugin separately instead? I personally
prefer this way, since it could be separately developed and possibly
included in the standard distribution without any compile option.
Keymap can be another alternative but it is not suitable for Hangeul
input; it conflicts with well-known input methods, because an
incomplete letter will not be shown up for instance.
After heard of this thread I have written an experimental plugin
enabling Hangeul input. It has some known bugs I have to deal with,
but I think this plugin is helpful for people without hangul_input
option set.
-- Kang Seonghoon
Tony Mechelynck
For a Vim plugin, it would have to be written in vimscript, wouldn't it? I
suppose it would be waiting for input most of the time, so speed wouldn't be a
factor. But you would have to have ways to enable/disable it: I wouldn't like
Vim to force me into Hangeul input, as I just know barely enough about Korean
to tell the difference between hangeul and hanja in printed text, but not
enough to make head or tail of it. ;-)
Maybe leave it disabled by default (in $VIMRUNTIME/macros/ or something) and
enable it the same way as matchit?
Best regards,
Tony.
--
Cahn's Axiom:
When all else fails, read the instructions.