6:40 a.m.
Symbol's function definition is void: kana-keyboard-define-keys
This is what I get when building No Gnus in the Japanese locale
using XEmacs 21.5-b29. A workaround is to set LC_ALL to C. In
that case XEmacs runs with the -no-autoloads option. Probably
you may reproduce this problem like the following:
LC_ALL=ja_JP.UTF-8 xemacs -no-autoloads
In relation to this, I realized there are two japan-utils.el's.
One is in lisp/mule/, the other is in the mule-base package,
the later is preferred because of load-path, and only it calls
`kana-keyboard-define-keys'. I guess I have to use the one in
lisp/mule/ because it looks newer than the one in mule-base.
Is it right? If so, how do I configure XEmacs 21.5-b29 so as to
prefer lisp/mule/ than that of mule-base in load-path? I used:
./configure\
--with-site-prefixes=/usr/local/canna\
--with-site-lisp\
--with-site-modules=no\
--with-package-path=/usr/local/lib/xemacs/site-packages:/usr/local/lib/xemacs/mule-packages:/usr/local/lib/xemacs/xemacs-packages\
--with-mule\
--with-xim=no\
--with-canna\
--with-wnn=no\
...
Thanks.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:49 a.m.
Katsumi Yamaoka writes:
In relation to this, I realized there are two japan-utils.el's.
One is in lisp/mule/, the other is in the mule-base package,
the later is preferred because of load-path, and only it calls
`kana-keyboard-define-keys'. I guess I have to use the one in
lisp/mule/ because it looks newer than the one in mule-base.
Is it right? If so, how do I configure XEmacs 21.5-b29 so as to
prefer lisp/mule/ than that of mule-base in load-path? I used:
You probably shouldn't do that, although
(push (file-name-as-directory (expand-file-name "mule" lispdir)))
in site-start.el will do the trick.
I disagreed with Ben about copying files from packages into core, but
as usual he went ahead and committed anyway. What he proposed should
happen is that mule-base's japan-util.el should declare itself to be
unusable by 21.5, which then would continue searching load-path.
Reported as issue737 in the tracker, no promise as to when I can get
to fixing it or when it will get into the SUMO, though.
If you want to fix it locally, see the docstring of `package-suppress'
and the usage example in xemacs-base/Makefile. A patch would be
welcome (but see the issue for a prerequisite for application).
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:27 a.m.
Stephen J. Turnbull wrote:
You probably shouldn't do that, although
(push (file-name-as-directory (expand-file-name "mule"
lispdir)))
in site-start.el will do the trick.
I tried it. Thanks. But it doesn't help XEmacs 21.5-b29 that
runs with the -no-autoloads option in the Japanese locale.
I disagreed with Ben about copying files from packages into core,
but
as usual he went ahead and committed anyway. What he proposed should
happen is that mule-base's japan-util.el should declare itself to be
unusable by 21.5, which then would continue searching load-path.
Reported as issue737 in the tracker, no promise as to when I can get
to fixing it or when it will get into the SUMO, though.
If you want to fix it locally, see the docstring of
`package-suppress'
and the usage example in xemacs-base/Makefile. A patch would be
welcome (but see the issue for a prerequisite for application).
How about moving japan-util.el in mule-base to XEmacs 21.4? ;-)
I think it is desirable that the packages are usable with both
XEmacs 21.4 and 21.5. Though I'm not sure whether the byte codes
that XEmacs 21.4 generates are all compatible with XEmacs 21.5.
Moreover there will be differences in many macros, i.e., improvements
made in XEmacs 21.5 will not get effective or some functions may get
not to work as expected. So, the best may be to offer the ready-made
packages for 21.4 and 21.5 separately.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:27 a.m.
Katsumi Yamaoka writes:
Stephen J. Turnbull wrote:
> You probably shouldn't do that, although
> (push (file-name-as-directory (expand-file-name "mule" lispdir)))
> in site-start.el will do the trick.
I tried it. Thanks. But it doesn't help XEmacs 21.5-b29 that
runs with the -no-autoloads option in the Japanese locale.
Why are you running with -no-autoloads in a Japanese locale? I think
this is a very bad idea, anyway. The kinds of situations where
-no-autoloads makes sense (ie, building XEmacs or the packages) really
ought to be running in the POSIX locale, and using only Mule
facilities for internationalization.
How about moving japan-util.el in mule-base to XEmacs 21.4? ;-)
Talk to Vin about that, but I think it's a bad idea. We should fix
the thing and move it back out of 21.5. It's really ugly that any
language-specific support is in the core, IMO. In 21.5, we should
suppress locale-based language environment setting when running
-vanilla, as well as other user settings like the init file. It's
reasonable to set various coding systems to match the locale, but
that's as far as it should go until we get localized messages.
I think it is desirable that the packages are usable with both
XEmacs 21.4 and 21.5.
The packages in general do work with both if compiled by 21.4. The
current problem is due to a bad design decision to try to support the
same module in two different places in the same XEmacs, not to
packages failing to work in both.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:04 a.m.
Stephen J. Turnbull wrote:
Katsumi Yamaoka writes:
> But it doesn't help XEmacs 21.5-b29 that runs with the
> -no-autoloads option in the Japanese locale.
Why are you running with -no-autoloads in a Japanese locale?
I have no need to use the -no-autoloads option usually, but No
Gnus' installer does so when building it for XEmacs. Setting
LC_ALL to C does the trick, however why I say it annoyingly is
because I think it may be hard for people to find that way.
The use of the -no-autoloads option was introduced to No Gnus by
Steve Youngs 6.5 years ago, but I had no problem to build No Gnus
in a Japanese locale until recently (I update XEmacs whenever
changes are made in hg). Adding LC_ALL=C to No Gnus' installer
may be a solution.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:20 p.m.
On Mon, Nov 1, 2010 at 2:04 AM, Katsumi Yamaoka <yamaoka(a)jpl.org> wrote:
Stephen J. Turnbull wrote:
> Katsumi Yamaoka writes:
>> But it doesn't help XEmacs 21.5-b29 that runs with the
>> -no-autoloads option in the Japanese locale.
> Why are you running with -no-autoloads in a Japanese locale?
I have no need to use the -no-autoloads option usually, but No
Gnus' installer does so when building it for XEmacs. Setting
LC_ALL to C does the trick, however why I say it annoyingly is
because I think it may be hard for people to find that way.
The use of the -no-autoloads option was introduced to No Gnus by
Steve Youngs 6.5 years ago, but I had no problem to build No Gnus
in a Japanese locale until recently (I update XEmacs whenever
changes are made in hg). Adding LC_ALL=C to No Gnus' installer
may be a solution.
Perhaps adding a suggestion about that to the"xemacs --help" output
would be wise?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:39 a.m.
Samuel Bronson writes:
Perhaps adding a suggestion about that to the"xemacs
--help" output
would be wise?
That would not help experienced users who rarely invoke --help.
I think the right thing to do is to invoke language environments as
part of loading the user environment, and anything -q or purer should
not invoke a language environment, beyond setting a default terminal
coding-system according to locale (everything else probably ought to
be autodetect giving UTF-8, other Unicode, and ISO 8859/1 precedence
until explicitly specified).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4922
days inactive
4926
days old
6 comments
3 participants
participants (3)
-
Katsumi Yamaoka -
Samuel Bronson -
Stephen J. Turnbull