diff options
author | Stefan Monnier <monnier@iro.umontreal.ca> | 2021-01-27 12:25:52 -0500 |
---|---|---|
committer | Stefan Monnier <monnier@iro.umontreal.ca> | 2021-01-27 12:25:52 -0500 |
commit | 89327ce68d096da9539f5032f598870ba97155c7 (patch) | |
tree | 6fbb0497aafb4560819fbd81aacaa4a418cee75d /lisp/emacs-lisp | |
parent | b0e96e554c0e78c17ee6e092e307112e814e5a65 (diff) | |
download | emacs-89327ce68d096da9539f5032f598870ba97155c7.tar.gz emacs-89327ce68d096da9539f5032f598870ba97155c7.tar.bz2 emacs-89327ce68d096da9539f5032f598870ba97155c7.zip |
* lisp/international/titdic-cnv.el: Revert to utf-8 encoding
While it's true that using the iso-2022-jp encoding on the file does
allow Emacs to render the two strings differently, this only applies to
the source file. The .elc files all use `utf-8-emacs` encoding anyway,
so that info is lost. And the difference is even lost before we write
the .elc file because when Emacs byte-compiles that code the
byte-compiler considers those two strings as "equal" and emits only one
string in the byte-code (so the two branches return `eq` strings).
So, I think using `iso-2022-jp` is a bad idea here: it gives the
illusion that the the `charset` info exists, even it will be lost.
Eli discussed it with Handa-san a year ago, and they arrived at the
conclusion that the charset information is indeed no longer important.
Diffstat (limited to 'lisp/emacs-lisp')
0 files changed, 0 insertions, 0 deletions