From: Eli Zaretskii <eliz@elta.co.il>
Cc: harder@ifa.au.dk, emacs-devel@gnu.org
Subject: Re: [harder@ifa.au.dk: `set-locale-environment' bug]
Date: 12 Nov 2003 08:29:30 +0200 [thread overview]
Message-ID: <un0b2cd6d.fsf@elta.co.il> (raw)
In-Reply-To: <200311120240.LAA02931@etlken.m17n.org> (message from Kenichi Handa on Wed, 12 Nov 2003 11:40:15 +0900 (JST))
> Date: Wed, 12 Nov 2003 11:40:15 +0900 (JST)
> From: Kenichi Handa <handa@m17n.org>
>
> It seems that all settings about display table and terminal coding
> system is done by dos-codepage-setup via term-setup-hook.
Yup.
> So, mule-cmds.el should do nothing for them on DOS, right?
I'm not sure. First, dos-cpNNN-setup still calls
set-language-environment (and the user could theoretically set some
language environment manually). standard-display-european-internal
could also be called in some unexpected way, even on DOS. So
mule-cmds.el shouldn't do anything that's wrong for the DOS port; this
the DOS-specific code in standard-display-european-internal and in
set-language-environment. We could, of course, move the DOS-specific
parts to term/internal.el so that mule-cmds.el is cleaner.
> I think we must think over making the code in mule-cmds
> clearer now. The current code is quite confusing and it
> seems that there are bugs.
I wouldn't be surprised, given the amount of changes that went under
the bridge since that code was written.
> So, for instance, if we start in some European locale in
> multibyte mode, standard-display-european-internal is
> called, but when we switch to Japanese lang. env., the
> standard-display-table is not reset. On the other hand, if
> we start in Japanese locale in multibyte mode, even if we
> switch to some European locale,
> standard-display-european-internal is not called.
I see how this happens (set-display-table-and-terminal-coding-system
is called in the multibyte mode from set-locale-environment, not from
set-language-environment), but I'm not 100% sure this is a bug. I
think we need to discuss the meaning of changing the language
environment without switching the locale. When would a user want to
do that, and what should Emacs do to adapt itself to such a situation?
next prev parent reply other threads:[~2003-11-12 6:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1AEH21-00079f-Je@fencepost.gnu.org>
2003-10-28 7:14 ` [harder@ifa.au.dk: `set-locale-environment' bug] Kenichi Handa
2003-10-28 14:21 ` Jesper Harder
2003-10-28 20:26 ` Eli Zaretskii
2003-10-28 23:52 ` Jesper Harder
2003-10-29 6:39 ` Eli Zaretskii
2003-10-29 16:49 ` Jesper Harder
2003-10-29 17:48 ` Eli Zaretskii
2003-11-10 2:36 ` Kenichi Handa
2003-11-10 5:31 ` Eli Zaretskii
2003-11-12 2:40 ` Kenichi Handa
2003-11-12 6:29 ` Eli Zaretskii [this message]
2003-10-29 19:01 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=un0b2cd6d.fsf@elta.co.il \
--to=eliz@elta.co.il \
--cc=emacs-devel@gnu.org \
--cc=harder@ifa.au.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).