summaryrefslogtreecommitdiff
path: root/lisp/emacs-lisp/bytecomp.el
diff options
context:
space:
mode:
authorStefan Monnier <monnier@iro.umontreal.ca>2021-01-27 12:25:52 -0500
committerStefan Monnier <monnier@iro.umontreal.ca>2021-01-27 12:25:52 -0500
commit89327ce68d096da9539f5032f598870ba97155c7 (patch)
tree6fbb0497aafb4560819fbd81aacaa4a418cee75d /lisp/emacs-lisp/bytecomp.el
parentb0e96e554c0e78c17ee6e092e307112e814e5a65 (diff)
downloademacs-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/bytecomp.el')
0 files changed, 0 insertions, 0 deletions