bug#57531: 28.1; Character encoding missing for "eo"

bug#57531: 28.1; Character encoding missing for "eo"

[Jonathan Reeve]

When my language and locale are set to "eo," (Esperanto), the character
encoding in Emacs is the wrong character encoding. It should be UTF-8,
but instead it's something else. I think the problem is in the
=locale-language-names= variable, which has these lines:

    ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
    ("en" "English" iso-8859-1) ; English
    ("eo" . "Esperanto") ; Esperanto
    ("es" "Spanish" iso-8859-1)

The line ("eo" . "Esperanto") should probably instead be ("eo"
"Esperanto" utf-8).

To test this, set your LANG variable to "eo" and then notice that the
character encooding (locale-coding-system) is not utf-8, as it should be.

-JR




In GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12201003
System Description: NixOS 22.11 (Raccoon)

Configured using:
 'configure
 --prefix=/nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1
 --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft
 --with-cairo --with-native-compilation'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $EMACSLOADPATH:
  value of $EMACSNATIVELOADPATH: /nix/store/p59mfplm858bb4b2g0hpa7sfmn7fknxq-emacs-packages-deps/share/emacs/native-lisp::
  value of $LANG: eo
  locale-coding-system: utf-8-unix

Major mode: Elisp

Minor modes in effect:
  evil-traces-mode: t
  global-anzu-mode: t
  anzu-mode: t
  whitespace-mode: t
  flycheck-popup-tip-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  eros-mode: t
  highlight-quoted-mode: t
  rainbow-delimiters-mode: t
  vi-tilde-fringe-mode: t
  highlight-numbers-mode: t
  display-line-numbers-mode: t
  save-place-mode: t
  global-so-long-mode: t
  envrc-global-mode: t
  envrc-mode: t
  hl-todo-mode: t
  org-roam-bibtex-mode: t
  org-roam-db-autosync-mode: t
  outline-minor-mode: t
  global-git-commit-mode: t
  ranger-override-dired-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  recentf-mode: t
  gcmh-mode: t
  global-hl-line-mode: t
  hl-line-mode: t
  winner-mode: t
  ws-butler-global-mode: t
  ws-butler-mode: t
  global-emojify-mode: t
  emojify-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  projectile-mode: t
  delete-selection-mode: t
  which-key-mode: t
  savehist-mode: t
  better-jumper-mode: t
  better-jumper-local-mode: t
  global-company-mode: t
  company-mode: t
  vertico-mode: t
  all-the-icons-completion-mode: t
  marginalia-mode: t
  evil-goggles-mode: t
  evil-escape-mode: t
  evil-snipe-override-mode: t
  evil-snipe-mode: t
  evil-snipe-override-local-mode: t
  evil-snipe-local-mode: t
  persp-mode: t
  doom-modeline-mode: t
  solaire-global-mode: t
  shell-dirtrack-mode: t
  evil-mode: t
  evil-local-mode: t
  windmove-mode: t
  +popup-mode: t
  override-global-mode: t
  general-override-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  prettify-symbols-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  window-divider-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/jon/.emacs.d/.local/straight/build-28.1/use-package/use-package-core hides /home/jon/.emacs.d/.local/straight/repos/use-package/use-package-core
/home/jon/.emacs.d/.local/straight/build-28.1/use-package/use-package-lint hides /home/jon/.emacs.d/.local/straight/repos/use-package/use-package-lint
/home/jon/.emacs.d/.local/straight/build-28.1/bind-key/bind-key hides /home/jon/.emacs.d/.local/straight/repos/use-package/bind-key
/home/jon/.emacs.d/.local/straight/build-28.1/use-package/use-package-bind-key hides /home/jon/.emacs.d/.local/straight/repos/use-package/use-package-bind-key
/home/jon/.emacs.d/.local/straight/build-28.1/use-package/use-package hides /home/jon/.emacs.d/.local/straight/repos/use-package/use-package
/home/jon/.emacs.d/.local/straight/build-28.1/use-package/use-package-diminish hides /home/jon/.emacs.d/.local/straight/repos/use-package/use-package-diminish
/home/jon/.emacs.d/.local/straight/build-28.1/use-package/use-package-jump hides /home/jon/.emacs.d/.local/straight/repos/use-package/use-package-jump
/home/jon/.emacs.d/.local/straight/build-28.1/use-package/use-package-ensure hides /home/jon/.emacs.d/.local/straight/repos/use-package/use-package-ensure
/home/jon/.emacs.d/.local/straight/build-28.1/use-package/use-package-delight hides /home/jon/.emacs.d/.local/straight/repos/use-package/use-package-delight
/home/jon/.emacs.d/.local/straight/build-28.1/straight/straight hides /home/jon/.emacs.d/.local/straight/repos/straight.el/straight
/home/jon/.emacs.d/.local/straight/build-28.1/straight/straight-x hides /home/jon/.emacs.d/.local/straight/repos/straight.el/straight-x
/home/jon/.emacs.d/.local/straight/build-28.1/straight/straight-ert-print-hack hides /home/jon/.emacs.d/.local/straight/repos/straight.el/straight-ert-print-hack
/home/jon/.emacs.d/.local/straight/build-28.1/password-store/password-store hides /run/current-system/sw/share/emacs/site-lisp/password-store
/home/jon/.emacs.d/.local/straight/build-28.1/password-store/password-store hides /etc/profiles/per-user/jon/share/emacs/site-lisp/password-store
/run/current-system/sw/share/emacs/site-lisp/site-start hides /nix/store/p59mfplm858bb4b2g0hpa7sfmn7fknxq-emacs-packages-deps/share/emacs/site-lisp/site-start
/run/current-system/sw/share/emacs/site-lisp/site-start hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/site-lisp/site-start
/home/jon/.emacs.d/.local/straight/repos/straight.el/indent hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/indent
/home/jon/.emacs.d/.local/straight/build-28.1/transient/transient hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/transient
/home/jon/.emacs.d/.local/straight/build-28.1/project/project hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/progmodes/project
/home/jon/.emacs.d/.local/straight/build-28.1/xref/xref hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/progmodes/xref
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-perl hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-perl
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-publish hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-publish
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-docview hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-docview
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-attach-git hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-attach-git
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-rmail hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-rmail
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-ascii hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-ascii
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-eshell hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-eshell
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-gnuplot hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-gnuplot
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-latex hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-latex
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-duration hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-duration
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-ref hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-ref
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-fortran hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-fortran
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-mobile hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-mobile
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-awk hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-awk
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-icalendar hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-icalendar
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-macro hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-macro
/home/jon/.emacs.d/.local/straight/build-28.1/org/oc-csl hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/oc-csl
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-crypt hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-crypt
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-org hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-org
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-scheme hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-scheme
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-octave hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-octave
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-dot hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-dot
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-archive hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-archive
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-keys hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-keys
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-sass hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-sass
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-haskell hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-haskell
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-agenda hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-agenda
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-compat hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-compat
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-processing hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-processing
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-org hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-org
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-man hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-man
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-core hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-core
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-src hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-src
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-lint hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-lint
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-id hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-id
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-gnus hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-gnus
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-texinfo hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-texinfo
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-goto hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-goto
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-pcomplete hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-pcomplete
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-bbdb hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-bbdb
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-exp hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-exp
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-julia hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-julia
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-entities hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-entities
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-emacs-lisp hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-emacs-lisp
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-capture hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-capture
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-version hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-version
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-clock hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-clock
/home/jon/.emacs.d/.local/straight/build-28.1/org/oc-natbib hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/oc-natbib
/home/jon/.emacs.d/.local/straight/build-28.1/org/org hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-css hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-css
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-beamer hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-beamer
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-md hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-md
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-table hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-table
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-doi hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-doi
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-ditaa hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-ditaa
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-loaddefs hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-loaddefs
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-sql hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-sql
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-element hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-element
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-macs hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-macs
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-lisp hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-lisp
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-man hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-man
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-tangle hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-tangle
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-js hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-js
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-ruby hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-ruby
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-ctags hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-ctags
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-R hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-R
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-clojure hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-clojure
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-habit hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-habit
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-eshell hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-eshell
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-sed hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-sed
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-C hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-C
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-faces hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-faces
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-list hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-list
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-eval hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-eval
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-latex hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-latex
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-comint hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-comint
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-mhe hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-mhe
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-eww hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-eww
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-plantuml hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-plantuml
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-num hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-num
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-sqlite hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-sqlite
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-feed hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-feed
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-irc hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-irc
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-shell hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-shell
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-java hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-java
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-matlab hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-matlab
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-plot hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-plot
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-calc hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-calc
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-table hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-table
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-bibtex hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-bibtex
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-html hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-html
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-lob hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-lob
/home/jon/.emacs.d/.local/straight/build-28.1/org/oc hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/oc
/home/jon/.emacs.d/.local/straight/build-28.1/org/oc-biblatex hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/oc-biblatex
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-attach hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-attach
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-lilypond hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-lilypond
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-protocol hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-protocol
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-mouse hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-mouse
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-datetree hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-datetree
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-koma-letter hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-koma-letter
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-w3m hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-w3m
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-lua hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-lua
/home/jon/.emacs.d/.local/straight/build-28.1/org/ox-odt hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ox-odt
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-maxima hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-maxima
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-python hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-python
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-colview hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-colview
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-tempo hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-tempo
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-indent hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-indent
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-forth hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-forth
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-timer hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-timer
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-ocaml hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-ocaml
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-groovy hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-groovy
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-inlinetask hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-inlinetask
/home/jon/.emacs.d/.local/straight/build-28.1/org/ol-info hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ol-info
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-refile hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-refile
/home/jon/.emacs.d/.local/straight/build-28.1/org/oc-basic hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/oc-basic
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-screen hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-screen
/home/jon/.emacs.d/.local/straight/build-28.1/org/org-footnote hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/org-footnote
/home/jon/.emacs.d/.local/straight/build-28.1/org/ob-makefile hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/org/ob-makefile
/nix/store/p59mfplm858bb4b2g0hpa7sfmn7fknxq-emacs-packages-deps/share/emacs/site-lisp/elpa/let-alist-1.0.6/let-alist hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/emacs-lisp/let-alist
/home/jon/.emacs.d/.local/straight/build-28.1/map/map hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/emacs-lisp/map
/nix/store/p59mfplm858bb4b2g0hpa7sfmn7fknxq-emacs-packages-deps/share/emacs/site-lisp/elpa/nadvice-0.3/nadvice hides /nix/store/c6j5affvi4yf2xvlhs60y0cfbs8d3d5k-emacs-28.1/share/emacs/28.1/lisp/emacs-lisp/nadvice

Features:
(vc-hg vc-svn vc company-ispell company-dabbrev evil-collection-help
shadow adaptive-wrap emacsbug macrostep-c cmacexp
evil-collection-macrostep macrostep cc-mode-expansions smartparens-c
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs evil-collection-view view solar cal-dst holidays
hol-loaddefs org-duration cal-iso evil-org-agenda org-mu4e mu4e-alert
time alert log4e notifications gntp org-msg htmlize gnus-msg
gnus-icalendar icalendar diary-lib diary-loaddefs gnus-dired gnus-cite
evil-collection-mu4e mu4e mu4e-org mu4e-main mu4e-view gnus-art mm-uu
mml2015 mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo
gnus-start gnus-dbus dbus gnus-cloud nnimap nnmail mail-source utf7
netrc nnoo gnus-spec gnus-int gnus-range gnus-win evil-collection-gnus
gnus nnheader mu4e-headers mu4e-compose mu4e-draft mu4e-actions smtpmail
sendmail mu4e-search mu4e-lists mu4e-bookmarks mu4e-mark mu4e-message
shr kinsoku svg xml dom flow-fill mu4e-contacts mu4e-update mu4e-folders
mu4e-server mu4e-context mu4e-vars mu4e-helpers evil-traces evil-ex
org-crypt org-eldoc toc-org evil-org spell-fu ispell nix-mode ffap smie
nix-repl nix-shell nix-store nix-instantiate nix-shebang nix-format nix
evil-collection-evil-mc evil-mc evil-mc-command-execute
evil-mc-command-record evil-mc-cursor-make evil-mc-region
evil-mc-cursor-state evil-mc-undo evil-mc-vars evil-mc-known-commands
evil-mc-common elisp-demos evil-collection-indent
evil-collection-helpful helpful trace evil-collection-edebug edebug
backtrace info-look evil-collection-info info help-fns radix-tree
evil-collection-elisp-refs elisp-refs tabify company-yasnippet evil-anzu
anzu git-gutter-fringe fringe-helper git-gutter evil-collection-vc-git
vc-git vc-dispatcher jka-compr auto-minor-mode whitespace
flycheck-popup-tip evil-collection-popup popup flycheck-cask
evil-embrace evil-surround embrace expand-region text-mode-expansions
the-org-mode-expansions er-basic-expansions expand-region-core
expand-region-custom eros highlight-quoted rainbow-delimiters
vi-tilde-fringe highlight-numbers parent-mode display-line-numbers
saveplace evil-collection-so-long so-long envrc inheritenv
consult-flycheck evil-collection-consult consult-vertico consult
compat-28 magit-bookmark evil-collection-bookmark bookmark
eshell-syntax-highlighting fish-completion smartparens-config
smartparens-rst smartparens-markdown smartparens-text smartparens
em-term em-script em-ls em-hist em-pred em-glob em-cmpl em-basic
em-banner em-alias em-tramp esh-help evil-collection-man man em-unix
eshell-z em-dirs esh-var evil-collection-eshell em-prompt
eshell-did-you-mean esh-mode eshell esh-cmd esh-ext esh-opt esh-proc
esh-io esh-arg esh-module esh-groups esh-util vertico-directory
mule-util cursor-sensor vertico-repeat evil-collection-magit-todos
magit-todos pcre2el rxt re-builder hl-todo async org-roam-protocol
org-protocol org-habit oc-natbib oc-csl org-roam-ui org-roam-dailies
simple-httpd websocket bindat citar citar-file citar-cache citar-format
org-ref org-ref-core org-ref-glossary org-ref-bibtex avy doi-utils
org-ref-utils org-ref-export citeproc citeproc-itemgetters
citeproc-biblatex parse-time citeproc-bibtex ol-bibtex ox-pandoc ox-org
ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn
nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar
org-agenda ox-ascii ox-md ox-html table ox-publish ox org-ref-misc-links
org-ref-label-link org-ref-ref-links org-ref-citation-links
evil-collection-xref xref project org-ref-bibliography-links hydra lv
org-roam-bibtex orb-core orb-compat orb-utils bibtex-completion biblio
biblio-download biblio-dissemin biblio-ieee biblio-hal biblio-dblp
biblio-crossref biblio-arxiv timezone biblio-doi biblio-core url-queue
ido parsebib org-indent evil-collection-org evil-collection-org-roam
org-roam-migrate org-roam-log org-roam-mode org-roam-capture org-roam-id
org-roam-node org-roam-db org-roam-utils org-roam-compat org-roam
org-capture org-attach emacsql-sqlite url-http url-auth url-gw nsm
emacsql emacsql-compiler smartparens-org org-yt org-element org-persist
xdg org-id org-refile avl-tree generator org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold
org-fold-core org-keys citeproc-cite citeproc-subbibs citeproc-sort
citeproc-name citeproc-formatters citeproc-number rst citeproc-proc
citeproc-disamb citeproc-itemdata citeproc-generic-elements
citeproc-macro citeproc-choose citeproc-date citeproc-context
citeproc-prange citeproc-style citeproc-locale citeproc-term citeproc-rt
citeproc-lib citeproc-s queue bibtex iso8601 oc-biblatex oc org-compat
org-macs org-loaddefs evil-collection-calendar cal-menu calendar
cal-loaddefs magit-autoloads evil-collection-magit magit-submodule
magit-obsolete magit-popup magit-blame magit-stash magit-reflog
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status
magit magit-repos magit-apply magit-wip magit-log which-func magit-diff
smerge-mode evil-collection-diff-mode diff-mode magit-core
magit-autorevert magit-margin magit-transient magit-process magit-mode
git-commit magit-git magit-base evil-collection-magit-section
magit-section crm compat-27 compat-26 transient format-spec
evil-collection-log-edit log-edit message rmc puny ranger
evil-collection-dired dired dired-loaddefs rfc822 mml mml-sec gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mailabbrev mail-utils
gmm-utils mailheader pcvs-util add-log with-editor compat doom-snippets
doom-snippets-lib yasnippet evil-collection-elisp-mode elisp-mode
recentf tree-widget time-date gcmh hl-line winner ws-butler emojify
evil-collection-apropos apropos evil-collection-tar-mode tar-mode
evil-collection-arc-mode arc-mode archive-mode ht undo-tree diff
flycheck-package package-lint evil-collection-imenu imenu
evil-collection-finder finder evil-collection-flycheck flycheck
find-func projectile lisp-mnt mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr evil-collection-grep grep ibuffer-vc ibuf-ext
evil-collection-ibuffer ibuffer ibuffer-loaddefs delsel hide-mode-line
multi-term evil-collection-term term ehelp evil-collection-which-key
which-key savehist better-jumper company-capf php-extras company
evil-collection-vertico vertico orderless all-the-icons-completion
marginalia evil-goggles evil-easymotion evil-escape evil-snipe server
autorevert filenotify nav-flash evil-collection-compile compile pulse
color persistent-soft list-utils pcache eieio-base font-utils
unicode-fonts persp-mode dtrt-indent doom-modeline
doom-modeline-segments doom-modeline-env doom-modeline-core shrink-path
f f-shortdoc shortdoc text-property-search s all-the-icons
all-the-icons-faces data-material data-weathericons data-octicons
data-fileicons data-faicons data-alltheicons dash
doom-themes-ext-treemacs doom-themes-ext-org solaire-mode face-remap
doom-one-theme doom-themes doom-themes-base doom-start epa-file
evil-collection-epa epa epg rfc6068 epg-config finder-inf
evil-collection-package-menu evil-collection-custom cus-edit cus-load
wid-edit evil-collection-comint evil-collection annalist doom-packages
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
mu4e-config html2text let-alist auth-source-pass url-parse url-vars
auth-source eieio password-cache json map ibuf-macs evil
evil-integration evil-maps evil-commands reveal flyspell evil-jumps
evil-command-window evil-search shell pcomplete comint ansi-color
evil-types evil-macros evil-repeat evil-states evil-core comp comp-cstr
warnings rx advice evil-common windmove calc calc-loaddefs calc-macs
thingatpt rect evil-digraphs evil-vars ring derived use-package-bind-key
bind-key edmacro kmacro doom-editor doom-projects doom-ui easy-mmode
doom-keybinds pp general cl-extra help-mode seq byte-opt cl-seq
use-package-core bytecomp byte-compile cconv eieio-core eieio-loaddefs
cl doom-modules doom doom-lib pcase cl-macs gv jansson dynamic-modules
subr-x cl-loaddefs cl-lib disp-table iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 1915125 219341)
 (symbols 48 90414 15)
 (strings 32 508207 43438)
 (string-bytes 1 13601560)
 (vectors 16 185106)
 (vector-slots 8 6241377 160081)
 (floats 8 2117 3319)
 (intervals 56 21071 1018)
 (buffers 992 130))

--
--
Jonathan Reeve
https://jonreeve.com

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Thu, 01 Sep 2022 18:47:10 +0000
> From: Jonathan Reeve <jonathan@jonreeve.com>
> 
> 
> When my language and locale are set to "eo," (Esperanto), the character
> encoding in Emacs is the wrong character encoding. It should be UTF-8,
> but instead it's something else.

Thank you for your report.

Can you tell what is the default encoding in that case?

> I think the problem is in the =locale-language-names= variable,
> which has these lines:
> 
>     ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
>     ("en" "English" iso-8859-1) ; English
>     ("eo" . "Esperanto") ; Esperanto
>     ("es" "Spanish" iso-8859-1)
> 
> The line ("eo" . "Esperanto") should probably instead be ("eo"
> "Esperanto" utf-8).

If you want the UTF-8 encoding to be the default, why is your locale
set to "eo" and not to "eo.UTF-8"?

In general, Emacs prefers taking the locale's codeset from your
system's definitions, to avoid overriding the user's system setup.  It
only applies default encoding when the locale doesn't specify the
codeset, or when a locale can support only a single codeset.

> To test this, set your LANG variable to "eo" and then notice that the
> character encooding (locale-coding-system) is not utf-8, as it should be.

Are you saying that the Esperanto locale _must_ use UTF-8?  If so,
why?  AFAIK, ISO-8859-3 covers the Esperanto characters, so UTF-8 is
not the only possible codeset for Esperanto locales.

bug#57531: 28.1; Character encoding missing for "eo"

[Jonathan Reeve]

“Eli Zaretskii” <eliz@gnu.org> writes:

> Can you tell what is the default encoding in that case?

It looks like it’s `iso-latin-3', which is not working, since all my unicode characters get mangled. See [the screenshot in this question of mine on StackExchange.]

> If you want the UTF-8 encoding to be the default, why is your locale
> set to “eo” and not to “eo.UTF-8”?

There is no eo.UTF-8 locale available to the system, as you can see [from the glibc documentation]. The “eo” locale is actually UTF-8, however. It’s interpreted as such just fine, across my whole system, except for in the emacs terminal, where it gets interpreted as `iso-latin-3'.

> Are you saying that the Esperanto locale _must_ use UTF-8?  If so,
> why?  AFAIK, ISO-8859-3 covers the Esperanto characters, so UTF-8 is
> not the only possible codeset for Esperanto locales.

If you look at that glibc document, you’ll see that the “eo” locale is actually UTF-8. Unlike `en_US', which has variants like  `en_US.UTF-8' which is UTF-8 and `en_US' which is ISO-8859-1, there is only `eo/UTF-8', i.e., `eo' which is UTF-8.


[the screenshot in this question of mine on StackExchange.] <https://emacs.stackexchange.com/questions/73393/how-can-i-fix-bad-character-encoding-in-the-terminal-and-other-functions-that-r>

[from the glibc documentation] <https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/SUPPORTED>

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Sat, 03 Sep 2022 01:28:56 +0000
> From: Jonathan Reeve <jonathan@jonreeve.com>
> Cc: 57531@debbugs.gnu.org
> 
> “Eli Zaretskii” <eliz@gnu.org> writes:
> 
> > Can you tell what is the default encoding in that case?
> 
> It looks like it’s `iso-latin-3', which is not working, since all my unicode characters get mangled. See [the screenshot in this question of mine on StackExchange.]

The characters in that post are supported by Latin-3, and I had no
problem saving them.

> > If you want the UTF-8 encoding to be the default, why is your locale
> > set to “eo” and not to “eo.UTF-8”?
> 
> There is no eo.UTF-8 locale available to the system, as you can see [from the glibc documentation]. The “eo” locale is actually UTF-8, however. It’s interpreted as such just fine, across my whole system, except for in the emacs terminal, where it gets interpreted as `iso-latin-3'.

That's okay, but then all you need to say in Emacs is

  (prefer-coding-system 'utf-8)

Put that in your init file, and see if your problem with non-ASCII
characters is fixed.

> > Are you saying that the Esperanto locale _must_ use UTF-8?  If so,
> > why?  AFAIK, ISO-8859-3 covers the Esperanto characters, so UTF-8 is
> > not the only possible codeset for Esperanto locales.
> 
> If you look at that glibc document, you’ll see that the “eo” locale is actually UTF-8. Unlike `en_US', which has variants like  `en_US.UTF-8' which is UTF-8 and `en_US' which is ISO-8859-1, there is only `eo/UTF-8', i.e., `eo' which is UTF-8.

I don't know why glibc did that, and glibc-supported systems are not
the only ones where we want to support Esperanto.  So if the above
simple customization fixes your problem, I'd prefer not changing the
default for everyone.

Thanks.

bug#57531: 28.1; Character encoding missing for "eo"

[Jonathan Reeve]

> The characters in that post are supported by Latin-3, and I had no
> problem saving them.

It’s not about saving them, it’s about how they’re displayed. If the rest of my system correctly uses unicode for the `eo' locale, /because it’s a unicode locale,/ but emacs is the only one that guesses it should be Latin-3 instead (for no reason that I can find), then it’s emacs which incorrectly handling this locale.

> That’s okay, but then all you need to say in Emacs is
>
>   (prefer-coding-system ’utf-8)

If emacs were really following system settings, it would set the encoding to utf-8 without needing extra customization from the user, since `eo' is a UTF-8 locale. And incidentally, there’s no such locale as `eo.utf-8', from what I can tell.

> I don’t know why glibc did that, and glibc-supported systems are not
> the only ones where we want to support Esperanto.  So if the above
> simple customization fixes your problem, I’d prefer not changing the
> default for everyone.

It’s not about changing the default for everyone, it’s about fixing an incorrect character encoding, making it so that emacs correctly respects the locale’s character set. There’s no reason to have the latin-3 character set, except for backwards compatibility, but that’s irrelevant in the case of Esperanto, since I know of no program, document, or anything else that would use latin-3 for Esperanto. Since the locale for Esperanto is a relatively new invention, it doesn’t have the same history of legacy character encodings as a language like English.

In fact, not even emacs seems to define it as such, judging from this line in `locale-language-names': `("eo" . "Esperanto")'. It just seems as if the author of that variable didn’t know what character set to assign, and left it blank.

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Sat, 03 Sep 2022 16:54:52 +0000
> From: Jonathan Reeve <jonathan@jonreeve.com>
> Cc: 57531@debbugs.gnu.org
> 
> > The characters in that post are supported by Latin-3, and I had no
> > problem saving them.
> 
> It’s not about saving them, it’s about how they’re displayed.

I believe this is due to the fact that the text was saved in UTF-8,
and Emacs was trying to decode it as if it were in Latin-3.

Using the prefer-coding-system customization should fix that.

> If the rest of my system correctly uses unicode for the `eo' locale, /because it’s a unicode locale,/ but emacs is the only one that guesses it should be Latin-3 instead (for no reason that I can find), then it’s emacs which incorrectly handling this locale.

I disagree.  I think your system doesn't tell Emacs enough to guess
correctly.

> > That’s okay, but then all you need to say in Emacs is
> >
> >   (prefer-coding-system ’utf-8)
> 
> If emacs were really following system settings, it would set the encoding to utf-8 without needing extra customization from the user, since `eo' is a UTF-8 locale.

There's no evidence of "eo" being a UTF-8 locale, except what we see
in glibc.  Which is just one library on just one OS.

> And incidentally, there’s no such locale as `eo.utf-8', from what I can tell.

OK.  I didn't say there were, I just assumed there could be.

> > I don’t know why glibc did that, and glibc-supported systems are not
> > the only ones where we want to support Esperanto.  So if the above
> > simple customization fixes your problem, I’d prefer not changing the
> > default for everyone.
> 
> It’s not about changing the default for everyone, it’s about fixing an incorrect character encoding, making it so that emacs correctly respects the locale’s character set.

Emacs cannot know the system character set unless the system tells
that.  The way to tell that is via the locale's codeset.  If that is
impossible, the next best is for you to tell that to Emacs in your
init file.  I don't understand why you insist on not using the
solution I proposed.

Please try the solution I proposed, and if it doesn't work, let's see
what else is needed.  If you keep insisting on defaulting Esperanto to
UTF-8, I see now way to make any progress here.

bug#57531: 28.1; Character encoding missing for "eo"

[Andreas Schwab]

On Sep 03 2022, Eli Zaretskii wrote:

> Emacs cannot know the system character set unless the system tells
> that.  The way to tell that is via the locale's codeset.

(locale-info 'codeset)

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Jonathan Reeve <jonathan@jonreeve.com>,  57531@debbugs.gnu.org
> Date: Sat, 03 Sep 2022 19:32:46 +0200
> 
> On Sep 03 2022, Eli Zaretskii wrote:
> 
> > Emacs cannot know the system character set unless the system tells
> > that.  The way to tell that is via the locale's codeset.
> 
> (locale-info 'codeset)

We already use that.

bug#57531: 28.1; Character encoding missing for "eo"

[Jonathan Reeve]

> I believe this is due to the fact that the text was saved in UTF-8,
> and Emacs was trying to decode it as if it were in Latin-3.

That’s the problem. Emacs should decode UTF-8 as UTF-8, not Latin-3. The fact that it assumes a UTF-8 locale is in fact a Latin-3 locale, without any reasoning for that, is a problem.

> Using the prefer-coding-system customization should fix that.

The user shouldn’t have to customize an encoding system to have a UTF-8 locale be interpreted as UTF-8. A UTF-8 locale should be encoded as such, without needing to be told otherwise.

> I disagree.  I think your system doesn’t tell Emacs enough to guess
> correctly.

It does, though. The locale data is already there, which is why I only have this problem in Emacs, and nowhere else on my whole system. The problem is in this line from `locale-language-names'. Here’s what it says:

`("eo" . "Esperanto")'

Here’s what it should say:

`("eo" "Esperanto" utf-8)'

> There’s no evidence of “eo” being a UTF-8 locale, except what we see
> in glibc.  Which is just one library on just one OS.

The evidence is everywhere, in fact, across my whole system, and every other system I’ve used. And glibc is not just one library on one OS: it’s the reference data for locales across any UNIX-like or POSIX system.

Show me any other library on any other OS that has locale data that suggests that “eo” is anything other than UTF-8. In particular, show me a library that shows that the eo locale should be encoded as latin-3.

> Emacs cannot know the system character set unless the system tells
> that.  The way to tell that is via the locale’s codeset.  If that is
> impossible, the next best is for you to tell that to Emacs in your
> init file.  I don’t understand why you insist on not using the
> solution I proposed.

The system says that it’s a UTF-8 locale. It’s interpreted as a UTF-8 locale by every other program except for emacs. It’s only emacs that incorrectly assumes latin-3, and for no reason, as far as I can tell. That’s because it’s getting its locale/encoding information from `locale-language-names', which is incorrect, or at least incomplete.

> Please try the solution I proposed, and if it doesn’t work, let’s see
> what else is needed.  If you keep insisting on defaulting Esperanto to
> UTF-8, I see now way to make any progress here.

You’re not proposing a solution, you’re proposing a workaround. Any other user with the “eo” locale will have this same problem, and they shouldn’t be expected to find this email thread, in order to find a special hack to have their system work as expected.

There’s no reason at all why Esperanto should be encoded in latin-3. It never has been, as far as I can tell, and it never well be, in latin-3, with the eo locale. If you can find any good reason why it should be in latin-3, I’m all ears, but as far as I can tell, this is a mistake.

Please keep in mind that /I’m trying to help improve emacs,/ by submitting a bug report about behavior in emacs that is incorrect and potentially causing problems for many users. Language like “I see now way to make any progress here” doesn’t extend any courtesy, any effort towards understanding this problem, or even any effort towards giving it the benefit of the doubt. It makes the bug reporting process unnecessarily adversarial, and, quite frankly, feels unprofessional.

bug#57531: 28.1; Character encoding missing for "eo"

[Andreas Schwab]

On Sep 03 2022, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Jonathan Reeve <jonathan@jonreeve.com>,  57531@debbugs.gnu.org
>> Date: Sat, 03 Sep 2022 19:32:46 +0200
>> 
>> On Sep 03 2022, Eli Zaretskii wrote:
>> 
>> > Emacs cannot know the system character set unless the system tells
>> > that.  The way to tell that is via the locale's codeset.
>> 
>> (locale-info 'codeset)
>
> We already use that.

Why doesn't it work then?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: jonathan@jonreeve.com,  57531@debbugs.gnu.org
> Date: Sat, 03 Sep 2022 22:13:31 +0200
> 
> On Sep 03 2022, Eli Zaretskii wrote:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: Jonathan Reeve <jonathan@jonreeve.com>,  57531@debbugs.gnu.org
> >> Date: Sat, 03 Sep 2022 19:32:46 +0200
> >> 
> >> On Sep 03 2022, Eli Zaretskii wrote:
> >> 
> >> > Emacs cannot know the system character set unless the system tells
> >> > that.  The way to tell that is via the locale's codeset.
> >> 
> >> (locale-info 'codeset)
> >
> > We already use that.
> 
> Why doesn't it work then?

It does work.

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Sat, 03 Sep 2022 20:00:41 +0000
> From: Jonathan Reeve <jonathan@jonreeve.com>
> Cc: 57531@debbugs.gnu.org
> 
> > I believe this is due to the fact that the text was saved in UTF-8,
> > and Emacs was trying to decode it as if it were in Latin-3.
> 
> That’s the problem. Emacs should decode UTF-8 as UTF-8, not Latin-3.

It tries, but it isn't always 100% successful.

> > Using the prefer-coding-system customization should fix that.
> 
> The user shouldn’t have to customize an encoding system to have a UTF-8 locale be interpreted as UTF-8. A UTF-8 locale should be encoded as such, without needing to be told otherwise.

Ideally, I agree.  But in practice, we've found that goal unreachable
in some cases.

> > I disagree.  I think your system doesn’t tell Emacs enough to guess
> > correctly.
> 
> It does, though. The locale data is already there, which is why I only have this problem in Emacs, and nowhere else on my whole system. The problem is in this line from `locale-language-names'. Here’s what it says:
> 
> `("eo" . "Esperanto")'
> 
> Here’s what it should say:
> 
> `("eo" "Esperanto" utf-8)'

That's only correct for glibc systems, though, as I already explained.
I found no authoritative place on the Internet which would mandate
that the Esperanto locale should use or prefer UTF-8 as its encoding.
Once again, glibc is just one C library on just one OS.

If you can show me some authoritative source of information about this
locale which says it should use UTF-8, that could be a reason good
enough to make such an incompatible change.  And we need good reasons
for such incompatible changes, because some users out there could have
configurations or applications that depend on previous behavior.

> The system says that it’s a UTF-8 locale.

How does it say so?

> > Please try the solution I proposed, and if it doesn’t work, let’s see
> > what else is needed.  If you keep insisting on defaulting Esperanto to
> > UTF-8, I see now way to make any progress here.
> 
> You’re not proposing a solution, you’re proposing a workaround.

Would you please try it nonetheless?

> There’s no reason at all why Esperanto should be encoded in latin-3. It never has been, as far as I can tell, and it never well be, in latin-3, with the eo locale. If you can find any good reason why it should be in latin-3, I’m all ears, but as far as I can tell, this is a mistake.

No, it isn't a mistake.  Latin-3 was introduced to cover Esperanto
(and some other languages).  That's why the Emacs Esperanto locale
was configured to use it.  It wasn't a random choice.

> Please keep in mind that /I’m trying to help improve emacs,/

Please keep in mind that so am I.  For many years, as a matter of
fact.

bug#57531: 28.1; Character encoding missing for "eo"

[Andreas Schwab]

On Sep 04 2022, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: jonathan@jonreeve.com,  57531@debbugs.gnu.org
>> Date: Sat, 03 Sep 2022 22:13:31 +0200
>> 
>> On Sep 03 2022, Eli Zaretskii wrote:
>> 
>> >> From: Andreas Schwab <schwab@linux-m68k.org>
>> >> Cc: Jonathan Reeve <jonathan@jonreeve.com>,  57531@debbugs.gnu.org
>> >> Date: Sat, 03 Sep 2022 19:32:46 +0200
>> >> 
>> >> On Sep 03 2022, Eli Zaretskii wrote:
>> >> 
>> >> > Emacs cannot know the system character set unless the system tells
>> >> > that.  The way to tell that is via the locale's codeset.
>> >> 
>> >> (locale-info 'codeset)
>> >
>> > We already use that.
>> 
>> Why doesn't it work then?
>
> It does work.

If it would work then Emacs would use UTF-8, but it doesn't.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: jonathan@jonreeve.com,  57531@debbugs.gnu.org
> Date: Sun, 04 Sep 2022 08:32:20 +0200
> 
> On Sep 04 2022, Eli Zaretskii wrote:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: jonathan@jonreeve.com,  57531@debbugs.gnu.org
> >> Date: Sat, 03 Sep 2022 22:13:31 +0200
> >> 
> >> On Sep 03 2022, Eli Zaretskii wrote:
> >> 
> >> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> >> Cc: Jonathan Reeve <jonathan@jonreeve.com>,  57531@debbugs.gnu.org
> >> >> Date: Sat, 03 Sep 2022 19:32:46 +0200
> >> >> 
> >> >> On Sep 03 2022, Eli Zaretskii wrote:
> >> >> 
> >> >> > Emacs cannot know the system character set unless the system tells
> >> >> > that.  The way to tell that is via the locale's codeset.
> >> >> 
> >> >> (locale-info 'codeset)
> >> >
> >> > We already use that.
> >> 
> >> Why doesn't it work then?
> >
> > It does work.
> 
> If it would work then Emacs would use UTF-8, but it doesn't.

Because it uses Latin-3, as it should.

As already explained, I see absolutely no convincing evidence anywhere
that Esperanto should prefer UTF-8 by default.  If you know of any
authoritative source of such information, please point me to it.

bug#57531: 28.1; Character encoding missing for "eo"

[Andreas Schwab]

On Sep 04 2022, Eli Zaretskii wrote:

> If you can show me some authoritative source of information about this
> locale

(locale-info 'codeset)

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Jonathan Reeve <jonathan@jonreeve.com>,  57531@debbugs.gnu.org
> Date: Sun, 04 Sep 2022 09:03:00 +0200
> 
> On Sep 04 2022, Eli Zaretskii wrote:
> 
> > If you can show me some authoritative source of information about this
> > locale
> 
> (locale-info 'codeset)

If you mean that set-locale-environment should use that, please say
that explicitly.  And then feel free to suggest a patch that does TRT
with all the convoluted logic and preferences there, so that we don't
disrupt the setup it took us decades to come up to, for the benefit of
a single obscure locale.

bug#57531: 28.1; Character encoding missing for "eo"

[Andreas Schwab]

On Sep 04 2022, Eli Zaretskii wrote:

> Because it uses Latin-3, as it should.

Nope, it should use UTF-8.

> If you know of any authoritative source of such information, please
> point me to it.

(locale-info 'codeset)

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57531: 28.1; Character encoding missing for "eo"

[Andreas Schwab]

On Sep 04 2022, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Jonathan Reeve <jonathan@jonreeve.com>,  57531@debbugs.gnu.org
>> Date: Sun, 04 Sep 2022 09:03:00 +0200
>> 
>> On Sep 04 2022, Eli Zaretskii wrote:
>> 
>> > If you can show me some authoritative source of information about this
>> > locale
>> 
>> (locale-info 'codeset)
>
> If you mean that set-locale-environment should use that, please say
> that explicitly.  And then feel free to suggest a patch that does TRT
> with all the convoluted logic and preferences there, so that we don't
> disrupt the setup it took us decades to come up to, for the benefit of
> a single obscure locale.

It's not for a single obscure locale, it's for all of them.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: jonathan@jonreeve.com,  57531@debbugs.gnu.org
> Date: Sun, 04 Sep 2022 09:34:44 +0200
> 
> On Sep 04 2022, Eli Zaretskii wrote:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: Jonathan Reeve <jonathan@jonreeve.com>,  57531@debbugs.gnu.org
> >> Date: Sun, 04 Sep 2022 09:03:00 +0200
> >> 
> >> On Sep 04 2022, Eli Zaretskii wrote:
> >> 
> >> > If you can show me some authoritative source of information about this
> >> > locale
> >> 
> >> (locale-info 'codeset)
> >
> > If you mean that set-locale-environment should use that, please say
> > that explicitly.  And then feel free to suggest a patch that does TRT
> > with all the convoluted logic and preferences there, so that we don't
> > disrupt the setup it took us decades to come up to, for the benefit of
> > a single obscure locale.
> 
> It's not for a single obscure locale, it's for all of them.

Does that mean you do suggest that set-locale-environment calls
locale-info?  Or do you suggest something different?

Anyway, for all the other locales, the current code already works, and
works well.  So we will be risking breakage while fixing one locale
that on one particular OS works less well.

But like I said: feel free to submit a patch that doesn't potentially
destroy everything we have in that setup.  If the patch is safe
enough, I see no reason not to accept it.

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Cc: jonathan@jonreeve.com, 57531@debbugs.gnu.org
> Date: Sun, 04 Sep 2022 10:46:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> But like I said: feel free to submit a patch that doesn't potentially
> destroy everything we have in that setup.  If the patch is safe
> enough, I see no reason not to accept it.

Something like the below could be acceptable, if it solves the
problem.

diff --git a/lisp/international/mule-cmds.el b/lisp/international/mule-cmds.el
index 4137642..6866291 100644
--- a/lisp/international/mule-cmds.el
+++ b/lisp/international/mule-cmds.el
@@ -2317,7 +2317,7 @@ locale-language-names
     ;; en_IN -- fx.
     ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
     ("en" "English" iso-8859-1) ; English
-    ("eo" . "Esperanto") ; Esperanto
+    ("eo" "Esperanto" locale-info) ; Esperanto
     ("es" "Spanish" iso-8859-1)
     ("et" . "Latin-9") ; Estonian
     ("eu" . "Latin-1") ; Basque
@@ -2522,8 +2522,12 @@ locale-language-names
   (LOCALE-REGEXP LANG-ENV CODING-SYSTEM)
 The first element whose LOCALE-REGEXP matches the start of a
 downcased locale specifies the LANG-ENV \(language environment)
-and CODING-SYSTEM corresponding to that locale.  If there is no
-appropriate language environment, the element may have this form:
+and CODING-SYSTEM corresponding to that locale.
+CODING-SYSTEM can be the special symbol `locale-info', which
+means we should call `locale-info' to request the codeset of
+the current locale.
+If there is no appropriate language environment, the element may
+have this form:
   (LOCALE-REGEXP . LANG-ENV)
 In this case, LANG-ENV is one of generic language environments for an
 specific encoding such as \"Latin-1\" and \"UTF-8\".")
@@ -2794,9 +2798,23 @@ set-locale-environment
 	    ;; locale-language-names specify both lang-env and coding.
 	    ;; But, what specified in locale-preferred-coding-systems
 	    ;; has higher priority.
-	    (setq coding-system (or coding-system
-				    (nth 1 language-name))
-		  language-name (car language-name))
+            (progn
+	      (setq coding-system (or coding-system
+				      (nth 1 language-name))
+		    language-name (car language-name))
+              ;; If locale-language-names specifies we should query
+              ;; the underlying libc, do that now, but only when we
+              ;; are setting up for the current locale, i.e. when this
+              ;; function is called from startup.el with an argument
+              ;; of nil.
+              (if (eq coding-system 'locale-info)
+                  (if locale-name
+                      (setq coding-system nil)
+                    (let ((locale-codeset (locale-info 'codeset)))
+                      (when (stringp locale-codeset)
+                        (setq coding-system (intern (downcase locale-codeset)))
+                        (unless (coding-system-p coding-system)
+                          (setq coding-system nil)))))))
 	  ;; Otherwise, if locale is not listed in locale-language-names,
 	  ;; use what listed in locale-charset-language-names.
 	  (if (not language-name)

bug#57531: 28.1; Character encoding missing for "eo"

[Andreas Schwab]

What does grep ^eo /usr/share/X11/locale/locale.alias return?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Cc: 57531@debbugs.gnu.org
> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sun, 04 Sep 2022 10:39:34 +0200
> 
> What does grep ^eo /usr/share/X11/locale/locale.alias return?

FWIW, here it returns:

  eo                                              eo_XX.ISO8859-3
  eo_EO                                           eo_EO.ISO8859-3
  eo_EO.ISO8859-3                         eo_EO.ISO8859-3
  eo_XX                                           eo_XX.ISO8859-3
  eo_XX.ISO8859-3                         eo_XX.ISO8859-3
  eo:                                             eo_XX.ISO8859-3
  eo_EO:                                          eo_EO.ISO8859-3
  eo_EO.ISO8859-3:                                eo_EO.ISO8859-3
  eo_XX:                                          eo_XX.ISO8859-3
  eo_XX.ISO8859-3:                                eo_XX.ISO8859-3

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>> The problem is in this line from `locale-language-names'. Here's what 
>> it says:
>>
>> `("eo" . "Esperanto")'
>>
>> Here's what it should say:
>>
>> `("eo" "Esperanto" utf-8)'
>
> That's only correct for glibc systems, though, as I already explained. I 
> found no authoritative place on the Internet which would mandate that 
> the Esperanto locale should use or prefer UTF-8 as its encoding.
>

I don't think it's possible to find a truly authoritative source of 
information about an artificial language.  One semi-authoritative source 
is Bertilo Wennergren, who is (according to Wikipedia) a member of the 
Esperanto Academy and "holds the post of director of the Academy's General 
Dictionary section".  He appears to be the expert on that matter (namely 
computer encodings for Esperanto), and explains on his website that:

Latino 3 is made for Esperanto and for the Galician, Maltese and Turkish 
languages. However, few computer programs support Latin 3, and some bodies 
have even directly discouraged the use of Latin 3. The Turks currently 
prefer the character code Latin 5 (ISO 8859-9) . Esperantists also 
currently prefer and should prefer Unicode instead of Latin 3. [1, 
translation from Google]

He also gives instructions on how to configure a GNU/Linux distribution 
for Esperanto:

To be able to use Esperanto well in Linux, it is necessary that the system 
uses a Unicode locale. Fortunately, more or less all Linux distributions 
currently use Unicode locales by default. To check which character code 
your system's locale uses, type the following command: "locale charmap". 
If the answer appears "UTF-8" (that is the most commonly used code 
representation of Unicode), then everything about character code in your 
locale is already in order. [2, translation from Google]

Amusingly, at the bottom of that page one finds:

It is also possible to speak Esperanto in the powerful text editor 
"Emacs", but I know nothing about "Emacs".  I myself mainly use the Vim 
editor. Here are instructions for installing and configuring Unicode Vim 
7.

So it seems safer to assume that the coding system is UTF-8 when the 
locale is "eo" (which IIUC is what the above suggested change does), and 
to expect users who would not like that default to add

(prefer-coding-system 'iso-latin-3)

in their init file, than to assume ISO-8859-3 when the locale is "eo" 
(which IIUC is what Emacs currently does), and to expect users who do not 
like that default to add

(prefer-coding-system 'utf-8)

in their init file.

[1] https://bertilow.com/html/signokodoj/latino3.html

[2] https://bertilow.com/komputo/linukso.html

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>>> (locale-info 'codeset)
>>
>> If you mean that set-locale-environment should use that, please say 
>> that explicitly.  And then feel free to suggest a patch that does TRT 
>> with all the convoluted logic and preferences there, so that we don't 
>> disrupt the setup it took us decades to come up to, for the benefit of 
>> a single obscure locale.
>
> It's not for a single obscure locale, it's for all of them.
>

Except that most other locales have "UTF-8" in their name when UTF-8 
should be used, so the current logic selects the right encoding, without 
consulting (locale-info 'codeset).  For example, with the locale "mt_MT", 
Emacs uses ISO-8859-3, and with the locale "mt_MT.UTF-8", Emacs uses 
UTF-8.

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>>>> (locale-info 'codeset)
>>> 
>>> If you mean that set-locale-environment should use that, please say 
>>> that explicitly.  And then feel free to suggest a patch that does TRT 
>>> with all the convoluted logic and preferences there, so that we don't 
>>> disrupt the setup it took us decades to come up to, for the benefit of 
>>> a single obscure locale.
>> 
>> It's not for a single obscure locale, it's for all of them.
>
> Except that most other locales have "UTF-8" in their name when UTF-8 
> should be used, so the current logic selects the right encoding, without 
> consulting (locale-info 'codeset).  For example, with the locale 
> "mt_MT", Emacs uses ISO-8859-3, and with the locale "mt_MT.UTF-8", Emacs 
> uses UTF-8.
>

(BTW, this also means that the OP could solve his problem by using 
"eo.UTF-8" for his locale instead of only "eo".)

bug#57531: 28.1; Character encoding missing for "eo"

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> (BTW, this also means that the OP could solve his problem by using
> "eo.UTF-8" for his locale instead of only "eo".)

That locale doesn't seem to exist on Debian systems, for instance:

$ grep eo /etc/locale.gen
# eo UTF-8
# eo_US.UTF-8 UTF-8

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>> (BTW, this also means that the OP could solve his problem by using 
>> "eo.UTF-8" for his locale instead of only "eo".)
>
> That locale doesn't seem to exist on Debian systems, for instance:
>
> $ grep eo /etc/locale.gen
> # eo UTF-8
> # eo_US.UTF-8 UTF-8
>

Sorry, I meant "eo" and "eo.utf8".  You can try (after activating the "eo" 
locale):

env LC_ALL=eo emacs -Q
env LC_ALL=eo.utf8 emacs -Q

and you'll see that in the latter case UTF-8 is used and in the former 
Latin-3.  You'd get the same result with LANG instead of LC_ALL.

bug#57531: 28.1; Character encoding missing for "eo"

[Andreas Schwab]

On Sep 05 2022, Lars Ingebrigtsen wrote:

> Gregory Heytings <gregory@heytings.org> writes:
>
>> (BTW, this also means that the OP could solve his problem by using
>> "eo.UTF-8" for his locale instead of only "eo".)
>
> That locale doesn't seem to exist on Debian systems, for instance:

Yes, it does.

$ LC_ALL=eo.UTF-8 locale -k title
title="Esperanto language locale"

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>>> (BTW, this also means that the OP could solve his problem by using 
>>> "eo.UTF-8" for his locale instead of only "eo".)
>>
>> That locale doesn't seem to exist on Debian systems, for instance:
>
> Yes, it does.
>
> $ LC_ALL=eo.UTF-8 locale -k title
> title="Esperanto language locale"
>

Oh yes, indeed.  So in fact you can use both "eo.utf8" (which is what 
locale -a displays) or "eo.UTF-8".

bug#57531: 28.1; Character encoding missing for "eo"

[Andreas Schwab]

On Sep 05 2022, Gregory Heytings wrote:

> Sorry, I meant "eo" and "eo.utf8".

eo.UTF-8 is the same as eo.utf8.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Sun, 04 Sep 2022 23:35:37 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Jonathan Reeve <jonathan@jonreeve.com>, 57531@debbugs.gnu.org
> 
> >> `("eo" "Esperanto" utf-8)'
> >
> > That's only correct for glibc systems, though, as I already explained. I 
> > found no authoritative place on the Internet which would mandate that 
> > the Esperanto locale should use or prefer UTF-8 as its encoding.
> >
> 
> I don't think it's possible to find a truly authoritative source of 
> information about an artificial language.  One semi-authoritative source 
> is Bertilo Wennergren, who is (according to Wikipedia) a member of the 
> Esperanto Academy and "holds the post of director of the Academy's General 
> Dictionary section".  He appears to be the expert on that matter (namely 
> computer encodings for Esperanto), and explains on his website that:
> 
> Latino 3 is made for Esperanto and for the Galician, Maltese and Turkish 
> languages. However, few computer programs support Latin 3, and some bodies 
> have even directly discouraged the use of Latin 3. The Turks currently 
> prefer the character code Latin 5 (ISO 8859-9) . Esperantists also 
> currently prefer and should prefer Unicode instead of Latin 3. [1, 
> translation from Google]
> 
> He also gives instructions on how to configure a GNU/Linux distribution 
> for Esperanto:
> 
> To be able to use Esperanto well in Linux, it is necessary that the system 
> uses a Unicode locale. Fortunately, more or less all Linux distributions 
> currently use Unicode locales by default. To check which character code 
> your system's locale uses, type the following command: "locale charmap". 
> If the answer appears "UTF-8" (that is the most commonly used code 
> representation of Unicode), then everything about character code in your 
> locale is already in order. [2, translation from Google]

If we were designing support for this locale today, we'd probably have
used UTF-8 as its default encoding.  But this is not the case: this
locale with its data exists for many years, and I'd like to avoid
changing the default encoding if a better solution exists.  Especially
since at this point it is not yet clear why this doesn't work on OP's
system, given the fact that locale.alias should have told Emacs what
encoding to use, before falling back on what we have in
language-info-alist.  See also my other message.

> So it seems safer to assume that the coding system is UTF-8 when the 
> locale is "eo" (which IIUC is what the above suggested change does), and 
> to expect users who would not like that default to add
> 
> (prefer-coding-system 'iso-latin-3)
> 
> in their init file, than to assume ISO-8859-3 when the locale is "eo" 
> (which IIUC is what Emacs currently does), and to expect users who do not 
> like that default to add

It is not clear to me yet that we need to change the current
assumption, since on well-configured system the correct encoding
should be stated in locale.alias, in which Emacs looks before it falls
back to language-info-alist.

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Mon, 05 Sep 2022 08:16:18 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: jonathan@jonreeve.com, Eli Zaretskii <eliz@gnu.org>, 57531@debbugs.gnu.org
> 
> > Except that most other locales have "UTF-8" in their name when UTF-8 
> > should be used, so the current logic selects the right encoding, without 
> > consulting (locale-info 'codeset).  For example, with the locale 
> > "mt_MT", Emacs uses ISO-8859-3, and with the locale "mt_MT.UTF-8", Emacs 
> > uses UTF-8.
> >
> 
> (BTW, this also means that the OP could solve his problem by using 
> "eo.UTF-8" for his locale instead of only "eo".)

That was suggested, but rejected, because the system in question (or
maybe any GNU/Linux system?) doesn't have such a locale.

But AFAIU locale.alias should have told Emacs which encoding is
appropriate for "eo".  Andreas asked the OP what does locale.alias say
about that, but I saw no response yet.

What does "grep ^eo /usr/share/X11/locale/locale.alias" say on your
system?

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  jonathan@jonreeve.com,  Eli
>  Zaretskii <eliz@gnu.org>,  57531@debbugs.gnu.org
> Date: Mon, 05 Sep 2022 10:58:29 +0200
> 
> Gregory Heytings <gregory@heytings.org> writes:
> 
> > (BTW, this also means that the OP could solve his problem by using
> > "eo.UTF-8" for his locale instead of only "eo".)
> 
> That locale doesn't seem to exist on Debian systems, for instance:
> 
> $ grep eo /etc/locale.gen
> # eo UTF-8
> # eo_US.UTF-8 UTF-8

What does the below say on your Debian system?

  grep ^eo /usr/share/X11/locale/locale.alias

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>> Sorry, I meant "eo" and "eo.utf8".
>
> eo.UTF-8 is the same as eo.utf8.
>

It's not completely the same, though: "eo.utf8" is a glibc-specific alias 
of "eo.UTF-8", "eo.UTF-8" is the standard name.  So I take back what I 
said above, and the OP should indeed use "eo.UTF-8".

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>> (BTW, this also means that the OP could solve his problem by using 
>> "eo.UTF-8" for his locale instead of only "eo".)
>
> That was suggested, but rejected, because the system in question (or 
> maybe any GNU/Linux system?) doesn't have such a locale.
>

That was probably a misinterpretation of the OP.  I'd bet that it would 
work, even though, as Lars observed, the exact string "eo.UTF-8" does not 
appear in /etc/locale.gen for example.

>
> But AFAIU locale.alias should have told Emacs which encoding is 
> appropriate for "eo".
>

If Emacs relies on locale.alias, Latin-3 will be chosen.  The "eo" locale 
follows what other locales do, without ".UTF-8" the legacy encoding is 
used.  E.g. "en_US" is Latin-1 here but "en_US.UTF-8" is UTF-8, and 
likewise "tr_TR" is Latin-9 but "tr_TR.UTF-8" is UTF-8.

>
> Andreas asked the OP what does locale.alias say about that, but I saw no 
> response yet.
>
> What does "grep ^eo /usr/share/X11/locale/locale.alias" say on your 
> system?
>

eo						eo_XX.ISO8859-3
eo_XX						eo_XX.ISO8859-3
eo:						eo_XX.ISO8859-3
eo_XX:						eo_XX.ISO8859-3

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>
> It is not clear to me yet that we need to change the current assumption, 
> since on well-configured system the correct encoding should be stated in 
> locale.alias, in which Emacs looks before it falls back to 
> language-info-alist.
>

I think expecting systems to be well-configured and to contain accurate 
information about that exotic locale is a bit too optimistic.

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Mon, 05 Sep 2022 12:00:12 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: schwab@linux-m68k.org, jonathan@jonreeve.com, 57531@debbugs.gnu.org
> 
> > But AFAIU locale.alias should have told Emacs which encoding is 
> > appropriate for "eo".
> 
> If Emacs relies on locale.alias, Latin-3 will be chosen.  The "eo" locale 
> follows what other locales do, without ".UTF-8" the legacy encoding is 
> used.  E.g. "en_US" is Latin-1 here but "en_US.UTF-8" is UTF-8, and 
> likewise "tr_TR" is Latin-9 but "tr_TR.UTF-8" is UTF-8.

Emacs looks in locale.alias before it uses the fallback info in
language-info-alist.

> > Andreas asked the OP what does locale.alias say about that, but I saw no 
> > response yet.
> >
> > What does "grep ^eo /usr/share/X11/locale/locale.alias" say on your 
> > system?
> >
> 
> eo						eo_XX.ISO8859-3
> eo_XX						eo_XX.ISO8859-3
> eo:						eo_XX.ISO8859-3
> eo_XX:						eo_XX.ISO8859-3

If this is what locale.alias says, doesn't it mean that the system
wants us to use Latin-3 by default for this locale?  IOW, why does
nl_langinfo return a value that is different from what this file says?
Is that because locale.alias comes from X11, not from glibc?

In any case, unless we change the code in mule-cmds.el, as long as
locale.alias says the above, what we say in language-info-alist about
this locale doesn't matter.  At least that's my reading of the code in
mule-cmds.el.

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Mon, 05 Sep 2022 12:07:23 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: jonathan@jonreeve.com, 57531@debbugs.gnu.org
> 
> 
> >
> > It is not clear to me yet that we need to change the current assumption, 
> > since on well-configured system the correct encoding should be stated in 
> > locale.alias, in which Emacs looks before it falls back to 
> > language-info-alist.
> >
> 
> I think expecting systems to be well-configured and to contain accurate 
> information about that exotic locale is a bit too optimistic.

What would you suggest that Emacs does instead?

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>> eo		eo_XX.ISO8859-3
>> eo_XX	eo_XX.ISO8859-3
>> eo:		eo_XX.ISO8859-3
>> eo_XX:	eo_XX.ISO8859-3
>
> If this is what locale.alias says, doesn't it mean that the system wants 
> us to use Latin-3 by default for this locale?  IOW, why does nl_langinfo 
> return a value that is different from what this file says? Is that 
> because locale.alias comes from X11, not from glibc?
>

I guess so, yes, given that glibc only knows of one encoding for the "eo" 
locale, namely "UTF-8".

>
> In any case, unless we change the code in mule-cmds.el, as long as 
> locale.alias says the above, what we say in language-info-alist about 
> this locale doesn't matter.  At least that's my reading of the code in 
> mule-cmds.el.
>

You are correct.  I should have tried the suggested patch before.  It has 
no effect indeed, at least here.

I think the conclusion is that the OP should either set his locale to 
"eo.UTF-8", or add (prefer-coding-system 'utf-8) in his init file.

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>> I think expecting systems to be well-configured and to contain accurate 
>> information about that exotic locale is a bit too optimistic.
>
> What would you suggest that Emacs does instead?
>

I don't know, because anything that it could do would be backward 
incompatible.  What is clear is that, on reasonably modern systems, legacy 
locales are not used anymore, and their use is discouraged (e.g. the 
Debian installer does not present you with any legacy encoding, they 
remain available but to activate them you need to edit the /etc/locale.gen 
file manually).  So perhaps Emacs could always assume UTF-8, and use 
another encoding only when there are good reasons to do so (e.g. when 
opening a file with a legacy encoding).  The presence of the equivalence 
eo / Latin-3 in locale.alias is IMO not a good enough reason.

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Mon, 05 Sep 2022 12:38:24 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: schwab@linux-m68k.org, jonathan@jonreeve.com, 57531@debbugs.gnu.org
> 
> >> eo		eo_XX.ISO8859-3
> >> eo_XX	eo_XX.ISO8859-3
> >> eo:		eo_XX.ISO8859-3
> >> eo_XX:	eo_XX.ISO8859-3
> >
> > If this is what locale.alias says, doesn't it mean that the system wants 
> > us to use Latin-3 by default for this locale?  IOW, why does nl_langinfo 
> > return a value that is different from what this file says? Is that 
> > because locale.alias comes from X11, not from glibc?
> 
> I guess so, yes, given that glibc only knows of one encoding for the "eo" 
> locale, namely "UTF-8".

There's also /usr/share/locale/locale.alias, but on GNU/Linux system to
which I have access it doesn't have any information for the eo or
Esperanto locales.

> > In any case, unless we change the code in mule-cmds.el, as long as 
> > locale.alias says the above, what we say in language-info-alist about 
> > this locale doesn't matter.  At least that's my reading of the code in 
> > mule-cmds.el.
> 
> You are correct.  I should have tried the suggested patch before.  It has 
> no effect indeed, at least here.

You mean, the patch I proposed in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57531#64?  For that to
work, we need to make 'locale-info' pseudo-encoding override what
locale.alias file says, I presume.

> I think the conclusion is that the OP should either set his locale to 
> "eo.UTF-8", or add (prefer-coding-system 'utf-8) in his init file.

That was suggested, yes.

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Mon, 05 Sep 2022 12:59:21 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: jonathan@jonreeve.com, 57531@debbugs.gnu.org
> 
> >> I think expecting systems to be well-configured and to contain accurate 
> >> information about that exotic locale is a bit too optimistic.
> >
> > What would you suggest that Emacs does instead?
> 
> I don't know, because anything that it could do would be backward 
> incompatible.

The only change I could think of that is almost backward-compatible
(except for this single locale) is the one I posted, if we modify it
to also make the 'lang-info' pseudo-encoding override the locale.alias
file.

> What is clear is that, on reasonably modern systems, legacy 
> locales are not used anymore, and their use is discouraged (e.g. the 
> Debian installer does not present you with any legacy encoding, they 
> remain available but to activate them you need to edit the /etc/locale.gen 
> file manually).  So perhaps Emacs could always assume UTF-8, and use 
> another encoding only when there are good reasons to do so (e.g. when 
> opening a file with a legacy encoding).  The presence of the equivalence 
> eo / Latin-3 in locale.alias is IMO not a good enough reason.

I have no idea what this kind of change could do.  Maybe nothing,
maybe breakage across the board.  Keep in mind that the default
encoding is used for stuff other than decoding text in files Emacs
visits, and also for some important tasks during startup.

I also think our encoding detection doesn't always succeed to discern
between UTF-8 and single-byte Latin-N encodings.

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>>> Is that because locale.alias comes from X11, not from glibc?
>>
>> I guess so, yes, given that glibc only knows of one encoding for the 
>> "eo" locale, namely "UTF-8".
>
> There's also /usr/share/locale/locale.alias, but on GNU/Linux system to 
> which I have access it doesn't have any information for the eo or 
> Esperanto locales.
>

That file is obsolete: "This file is obsolete and is kept around for the 
time being for backward compatibility.  Nobody should rely on the names 
defined here."  Neither that file nor the X11 one is used by glibc.

>> I should have tried the suggested patch before.  It has no effect 
>> indeed, at least here.
>
> You mean, the patch I proposed in 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57531#64?
>

I meant both the one that the OP suggested and the one that you suggested.

>
> For that to work, we need to make 'locale-info' pseudo-encoding override 
> what locale.alias file says, I presume.
>

Indeed, given that ATM locale-language-names is only consulted when 
locale.alias says nothing (IIUC).

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]


>>> What would you suggest that Emacs does instead?
>>
>> I don't know, because anything that it could do would be backward 
>> incompatible.
>
> The only change I could think of that is almost backward-compatible 
> (except for this single locale) is the one I posted, if we modify it to 
> also make the 'lang-info' pseudo-encoding override the locale.alias 
> file.
>

Agreed, yes.

>> What is clear is that, on reasonably modern systems, legacy locales are 
>> not used anymore, and their use is discouraged (e.g. the Debian 
>> installer does not present you with any legacy encoding, they remain 
>> available but to activate them you need to edit the /etc/locale.gen 
>> file manually).  So perhaps Emacs could always assume UTF-8, and use 
>> another encoding only when there are good reasons to do so (e.g. when 
>> opening a file with a legacy encoding).  The presence of the 
>> equivalence eo / Latin-3 in locale.alias is IMO not a good enough 
>> reason.
>
> I have no idea what this kind of change could do.
>

I have no idea either, I was thinking aloud.  But what is clear (at least 
to me) is that this change is inevitable at some point.  UTF-8 has been 
the default encoding almost everywhere for two decades or so, and that's 
unlikely to change in the forseeable future.  In that world we cannot 
continue forever to let Emacs choose another encoding based on some 
heuristics, because "nobody" expects that anymore.  Unless there's a good 
reason to do so, of course.

>
> Maybe nothing, maybe breakage across the board.  Keep in mind that the 
> default encoding is used for stuff other than decoding text in files 
> Emacs visits, and also for some important tasks during startup.
>
> I also think our encoding detection doesn't always succeed to discern 
> between UTF-8 and single-byte Latin-N encodings.
>

I keep all that in mind, yes 😃

bug#57531: 28.1; Character encoding missing for "eo"

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What does the below say on your Debian system?
>
>   grep ^eo /usr/share/X11/locale/locale.alias


$ grep ^eo /usr/share/X11/locale/locale.alias
eo						eo_XX.ISO8859-3
eo_XX						eo_XX.ISO8859-3
eo:						eo_XX.ISO8859-3
eo_XX:						eo_XX.ISO8859-3

bug#57531: 28.1; Character encoding missing for "eo"

[Andreas Schwab]

On Sep 05 2022, Eli Zaretskii wrote:

> Is that because locale.alias comes from X11

Nothing else uses that file.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#57531: 28.1; Character encoding missing for "eo"

[Jonathan Reeve]

In my case, on NixOS, the system only supports glibc locales. [The nix configuration option for locales] says this:

      List of locales that the system should support. The value “all” means that all locales supported by Glibc will be installed. A full list of supported locales can be found at <https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/SUPPORTED>.

And if you try to do it anyway, for instance, with this configuration:

┌────
│   i18n = {
│     defaultLocale = "eo.UTF-8";
│     supportedLocales = [ "eo.UTF-8/UTF-8" "eo/UTF-8" "en_US.UTF-8/UTF-8" ];
│   };
└────

you’ll end up getting an error like this:

      Error: unsupported locales detected:
      eo.UTF-8/UTF-8 \
      You should choose from the list above the error.

The “list above the error” is the same list from [the full list of supported locales], and doesn’t include `eo.UTF-8' or `eo.utf-8'.

So on my system, at least, there is effectively no separate `eo.UTF-8' locale. Nor would you need one, since the `eo' locale is UTF-8.

FWIW, my system doesn’t have the obsolete X11 locale.alias file, and I don’t use X11.

But if there’s one thing I can ascertain, just from using my system, is that it works just as expected everywhere (terminals, other programs), and characters are displayed fine everywhere (e.g., in UTF-8, as they should be) /except in emacs/. The emacs terminal, especially, displays characters incorrectly.

Here’s the output of `locale charmap':

┌────
│ $ LANG=eo locale charmap
│ UTF-8
└────

So it seems to me transparently clear that the encoding for the `eo' locale is UTF-8, and yet somehow emacs has its own, separate opinions, which don’t seem to be based on fact.

Changing the default emacs encoding won’t break backwards compatibility so much as it will fix a long-standing mistake.


“Andreas Schwab” <schwab@linux-m68k.org> writes:

> On Sep 05 2022, Eli Zaretskii wrote:
>
>> Is that because locale.alias comes from X11
>
> Nothing else uses that file.


[The nix configuration option for locales] <https://search.nixos.org/options?channel=unstable&show=i18n.supportedLocales&from=0&size=50&sort=relevance&type=packages&query=locale>

[the full list of supported locales] <https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/SUPPORTED>

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]


>
> Error: unsupported locales detected:
> eo.UTF-8/UTF-8 \
> You should choose from the list above the error.
>

Well, "eo.UTF-8/UTF-8" is indeed not a supported locale.  Why did you 
include it in your configuration?  "eo.UTF-8" (without a "/UTF-8") is 
definitely supported by glibc.  What do you get if you configure it like 
this:

i18n = { defaultLocale = "eo.UTF-8"; };

?

>
> FWIW, my system doesn’t have the obsolete X11 locale.alias file, and I 
> don’t use X11.
>

Then I guess Emacs doesn't use it, which is why your suggested fix worked 
on NixOS but wouldn't work on a Debian-based system.

>
> So it seems to me transparently clear that the encoding for the `eo' 
> locale is UTF-8, and yet somehow emacs has its own, separate opinions, 
> which don’t seem to be based on fact.
>

The story is a bit more complex than that, as you may have seen in the 
previous messages in this thread.

bug#57531: 28.1; Character encoding missing for "eo"

[Jonathan Reeve]

“Gregory Heytings” <gregory@heytings.org> writes:

> Well, “eo.UTF-8/UTF-8” is indeed not a supported locale.  Why did you
> include it in your configuration?  “eo.UTF-8” (without a “/UTF-8”) is
> definitely supported by glibc.  What do you get if you configure it like
> this:
>
> i18n = { defaultLocale = “eo.UTF-8”; };
>
> ?

Well, this is getting into the weeds a bit about NixOS, and isn’t really relevant here, but just to humor you, configuring it like that results in the same error. Look at [the documentation for supportedLocales] and [the documentation on defaultLocale], in particular their examples. “eo.UTF-8/UTF-8” is the way they want you to write that in `supportedLocales'. You can also [check out the way it’s implemented], which involves normalizing those locale strings such that they match the ones provided by glibc.
>
>>
>> FWIW, my system doesn’t have the obsolete X11 locale.alias file, and I
>> don’t use X11.
>>
>
> Then I guess Emacs doesn’t use it, which is why your suggested fix worked
> on NixOS but wouldn’t work on a Debian-based system.
>

It’s an obsolete file, as has been pointed out upthread, so it’s not in use at all, period. And whether or not you use X11 has nothing to do with whether or not you use Debian. The fix I’m suggesting would work equally as well on Debian as NixOS, or any Linux-based system, since they use the same system for locales. But don’t take my word for it. Try it yourself.

>>
>> So it seems to me transparently clear that the encoding for the `eo’
>> locale is UTF-8, and yet somehow emacs has its own, separate opinions,
>> which don’t seem to be based on fact.
>>
>
> The story is a bit more complex than that, as you may have seen in the
> previous messages in this thread.

If there’s a reason that Emacs needs to maintain its own locale/charset mapping, separate and different from that of the system, I’m all ears. But to me it looks unnecessary and causes errors, like the one I’m trying to report here.


[the documentation for supportedLocales] <https://search.nixos.org/options?channel=unstable&show=i18n.supportedLocales&from=0&size=50&sort=relevance&type=packages&query=i18n>

[the documentation on defaultLocale] <https://search.nixos.org/options?channel=unstable&show=i18n.defaultLocale&from=0&size=50&sort=relevance&type=packages&query=i18n>

[check out the way it’s implemented] <https://github.com/NixOS/nixpkgs/blob/93c57a988470c1948976b1bb70abbd5855c5b810/nixos/modules/config/i18n.nix#L57>

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]


>
> Well, this is getting into the weeds a bit about NixOS, and isn’t really 
> relevant here, but just to humor you, configuring it like that results 
> in the same error. Look at [the documentation for supportedLocales] and 
> [the documentation on defaultLocale], in particular their examples. 
> “eo.UTF-8/UTF-8” is the way they want you to write that in 
> `supportedLocales'. You can also [check out the way it’s implemented], 
> which involves normalizing those locale strings such that they match the 
> ones provided by glibc.
>

Then it sounds like it's a NixOS bug.  As I said, eo.UTF-8 is definitely a 
valid locale, and is supported by glibc, so there is no reason that NixOS 
should reject it just because it's not present in some text file.  You can 
try it:

#include <stdio.h>
#include <locale.h>
#define CHECK(L) if (!setlocale (LC_ALL, L)) printf ("invalid locale %s\n", L);
int main ()
{
   CHECK ("eo");
   CHECK ("eo.UTF-8");
}

>> Then I guess Emacs doesn’t use it, which is why your suggested fix 
>> worked on NixOS but wouldn’t work on a Debian-based system.
>
> It’s an obsolete file, as has been pointed out upthread, so it’s not in 
> use at all, period. And whether or not you use X11 has nothing to do 
> with whether or not you use Debian. The fix I’m suggesting would work 
> equally as well on Debian as NixOS, or any Linux-based system, since 
> they use the same system for locales. But don’t take my word for it. Try 
> it yourself.
>

No, it's another one that is obsolete: /usr/share/locale/locale.alias is 
obsolete, /usr/share/X11/locale/locale.alias is not, it has last been 
updated on February 2nd.  It is used at least by libx11 and by Emacs.

And no, the fix you suggested does not work on Debian.  I tried it myself, 
it has no effect whatsoever.  When /usr/share/X11/locale/locale.alias is 
present, the information it contains takes precedence over those in 
locale-language-names.

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>
> You can try it:
>
> #include <stdio.h>
> #include <locale.h>
> #define CHECK(L) if (!setlocale (LC_ALL, L)) printf ("invalid locale %s\n", L);
> int main ()
> {
>  CHECK ("eo");
>  CHECK ("eo.UTF-8");
> }
>

You can also just type "locale -a", you will see two lines starting with 
"eo":

eo
eo.utf8

bug#57531: 28.1; Character encoding missing for "eo"

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Something like the below could be acceptable, if it solves the
> problem.
>
> diff --git a/lisp/international/mule-cmds.el b/lisp/international/mule-cmds.el
> index 4137642..6866291 100644
> --- a/lisp/international/mule-cmds.el
> +++ b/lisp/international/mule-cmds.el
> @@ -2317,7 +2317,7 @@ locale-language-names
>      ;; en_IN -- fx.
>      ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
>      ("en" "English" iso-8859-1) ; English
> -    ("eo" . "Esperanto") ; Esperanto
> +    ("eo" "Esperanto" locale-info) ; Esperanto

(etc).  This does not seem to fix the problem.

LANG=eo ./src/emacs -Q

still says

current-locale-environment
"eo_XX.ISO8859-3"

This does work (with or without the patch):

LANG=eo.UTF-8 ./src/emacs -Q
current-locale-environment
"eo.UTF-8"

Anyway, re-skimming this thread, I think we have these points:

1) The "eo" environment should be in utf-8 -- all the indications seem
to point to that, except some outdated Debian files that nobody else
uses but Emacs.

2) Using eo.UTF-8 is a work-around that works fine.

3) Changing what Emacs does here might be disruptive to people that are
used to Emacs defaulting to Latin-3 for the "eo" locale.

So the question is whether Emacs should start doing the right thing as
1), or worry more about 3).

I'm leaning more towards 1), but I don't have a strong opinion.

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jonathan@jonreeve.com,  57531@debbugs.gnu.org,  schwab@linux-m68k.org
> Date: Tue, 04 Oct 2022 13:44:10 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Something like the below could be acceptable, if it solves the
> > problem.
> >
> > diff --git a/lisp/international/mule-cmds.el b/lisp/international/mule-cmds.el
> > index 4137642..6866291 100644
> > --- a/lisp/international/mule-cmds.el
> > +++ b/lisp/international/mule-cmds.el
> > @@ -2317,7 +2317,7 @@ locale-language-names
> >      ;; en_IN -- fx.
> >      ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
> >      ("en" "English" iso-8859-1) ; English
> > -    ("eo" . "Esperanto") ; Esperanto
> > +    ("eo" "Esperanto" locale-info) ; Esperanto
> 
> (etc).  This does not seem to fix the problem.

It won't solve the problem if you have that X11 file on your system,
because we read it before we get to the code I changed.

> This does work (with or without the patch):
> 
> LANG=eo.UTF-8 ./src/emacs -Q
> current-locale-environment
> "eo.UTF-8"

But it requires the eo.UTF-8 locale to be available, AFAIU, and for
that reason somehow didn't work for the OP.  I don't think I
understood why it didn't work for him.  I still hope the OP will come
back and help us understand that.

> 1) The "eo" environment should be in utf-8 -- all the indications seem
> to point to that, except some outdated Debian files that nobody else
> uses but Emacs.
> 
> 2) Using eo.UTF-8 is a work-around that works fine.
> 
> 3) Changing what Emacs does here might be disruptive to people that are
> used to Emacs defaulting to Latin-3 for the "eo" locale.
> 
> So the question is whether Emacs should start doing the right thing as
> 1), or worry more about 3).
> 
> I'm leaning more towards 1), but I don't have a strong opinion.

If we think 2) will work for (almost) everyone, maybe the problem is
not serious enough to have to decide between two extremes?

bug#57531: 28.1; Character encoding missing for "eo"

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Emacs looks in locale.alias before it uses the fallback info in
> language-info-alist.

And all this is extremely important, because that is the file the X
library and X input methods use to determine the real locale underlying
a locale name.

If an X input method specifies the locale "EO", then it is actually
referring to "eo_EO.ISO8859-3", whose coded charset is ISO8859-3.

> If this is what locale.alias says, doesn't it mean that the system
> wants us to use Latin-3 by default for this locale?  IOW, why does
> nl_langinfo return a value that is different from what this file says?
> Is that because locale.alias comes from X11, not from glibc?

X can have different ideas about locale names than the system C
library.  (nl_langinfo)

Emacs must follow the X definition in order to decode keyboard input
correctly.

bug#57531: 28.1; Character encoding missing for "eo"

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jonathan Reeve <jonathan@jonreeve.com> writes:

> FWIW, my system doesn’t have the obsolete X11 locale.alias file, and I don’t use X11.

locale.alias is not an obsolete file.  The X library always looks there
when resolving locale names.

If you do not use X Windows, then that file should not be there in the
first place.

bug#57531: 28.1; Character encoding missing for "eo"

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It won't solve the problem if you have that X11 file on your system,
> because we read it before we get to the code I changed.

Ah, right.

>> This does work (with or without the patch):
>> 
>> LANG=eo.UTF-8 ./src/emacs -Q
>> current-locale-environment
>> "eo.UTF-8"
>
> But it requires the eo.UTF-8 locale to be available, AFAIU, and for
> that reason somehow didn't work for the OP.  I don't think I
> understood why it didn't work for him.  I still hope the OP will come
> back and help us understand that.

Yes, that would be helpful.  On this Ubuntu system, I just uncommented
the "eo" line in locale.gen and ran locale-gen, and that made both the
"eo" and "eo.UTF-8" locales available.

> If we think 2) will work for (almost) everyone, maybe the problem is
> not serious enough to have to decide between two extremes?

Yes, that's quite possible.

But this might also be an opportunity to stop parsing that apparently
outdated file X11 file completely...

bug#57531: 28.1; Character encoding missing for "eo"

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 1) The "eo" environment should be in utf-8 -- all the indications seem
> to point to that, except some outdated Debian files that nobody else
> uses but Emacs.

/usr/share/locale/locale.alias may be an obsolete Debian file, but
/usr/share/X11/locale/locale.alias is not; the X library looks there to
resolve locales that come from many sources, including input methods.

That means if an input method asks for "EO", it really means
"eo_EO.ISO8859-3", and the text it generates will also be Latin-3.

If we make "eo" mean UTF-8, then that text will no longer be decoded
correctly.

bug#57531: 28.1; Character encoding missing for "eo"

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But this might also be an opportunity to stop parsing that apparently
> outdated file X11 file completely...

The outdated file present on Debian systems is completely distinct from
the X11 file, which must be parsed if we want input methods to keep
working correctly.

It's used by every program that uses one of Xlib or XIM, which is just
about every GUI program in existence.

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>>> This does work (with or without the patch):
>>>
>>> LANG=eo.UTF-8 ./src/emacs -Q
>>> current-locale-environment
>>> "eo.UTF-8"
>>
>> But it requires the eo.UTF-8 locale to be available, AFAIU, and for 
>> that reason somehow didn't work for the OP.  I don't think I understood 
>> why it didn't work for him.  I still hope the OP will come back and 
>> help us understand that.

Actually that problem has been debugged: it's a NixOS bug.  NixOS rejects 
the locale to "eo.UTF-8" in its configuration files, even though 
"eo.UTF-8" is a perfectly valid locale.  It rejects it because the 
"eo.UTF-8" string is not present in some text file (apparently the 
"localedata/SUPPORTED" file from glibc).

>
> Yes, that would be helpful.  On this Ubuntu system, I just uncommented 
> the "eo" line in locale.gen and ran locale-gen, and that made both the 
> "eo" and "eo.UTF-8" locales available.
>

Another similar example is the en_IL (English Israel) locale.  X11's 
locale.alias indicates that "en_IL" alone means "en_IL.ISO8859-1", yet 
glibc provides only one encoding for "en_IL", namely "UTF-8".

To avoid such bugs, the most reasonable thing to do for users is to always 
specify the encoding.

bug#57531: 28.1; Character encoding missing for "eo"

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> Actually that problem has been debugged: it's a NixOS bug.  NixOS
> rejects the locale to "eo.UTF-8" in its configuration files, even
> though "eo.UTF-8" is a perfectly valid locale.  It rejects it because
> the "eo.UTF-8" string is not present in some text file (apparently the
> "localedata/SUPPORTED" file from glibc).

Ah, right.  Somebody should report this to the NixOS people, I guess?

>> Yes, that would be helpful.  On this Ubuntu system, I just
>> uncommented the "eo" line in locale.gen and ran locale-gen, and that
>> made both the "eo" and "eo.UTF-8" locales available.
>>
>
> Another similar example is the en_IL (English Israel) locale.  X11's
> locale.alias indicates that "en_IL" alone means "en_IL.ISO8859-1", yet
> glibc provides only one encoding for "en_IL", namely "UTF-8".
>
> To avoid such bugs, the most reasonable thing to do for users is to
> always specify the encoding.

So I think the conclusion here is that after taking all the options into
consideration, we don't want to change anything on the Emacs side here,
both because of backwards compat issues, and the X encoding issues noted
by Po Lu.

I'm therefore closing this bug report.

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Thu, 06 Oct 2022 11:28:59 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, jonathan@jonreeve.com, 57531@debbugs.gnu.org, 
>     schwab@linux-m68k.org
> 
> Actually that problem has been debugged: it's a NixOS bug.  NixOS rejects 
> the locale to "eo.UTF-8" in its configuration files, even though 
> "eo.UTF-8" is a perfectly valid locale.  It rejects it because the 
> "eo.UTF-8" string is not present in some text file (apparently the 
> "localedata/SUPPORTED" file from glibc).
> 
> >
> > Yes, that would be helpful.  On this Ubuntu system, I just uncommented 
> > the "eo" line in locale.gen and ran locale-gen, and that made both the 
> > "eo" and "eo.UTF-8" locales available.
> >
> 
> Another similar example is the en_IL (English Israel) locale.  X11's 
> locale.alias indicates that "en_IL" alone means "en_IL.ISO8859-1", yet 
> glibc provides only one encoding for "en_IL", namely "UTF-8".
> 
> To avoid such bugs, the most reasonable thing to do for users is to always 
> specify the encoding.

Should we perhaps have an entry in PROBLEMS with that information?

bug#57531: 28.1; Character encoding missing for "eo"

[Gregory Heytings]

>> To avoid such bugs, the most reasonable thing to do for users is to 
>> always specify the encoding.
>
> Should we perhaps have an entry in PROBLEMS with that information?
>

Would it not be better if Emacs checked the LANG environment variable on 
startup and warned the user when LANG does not specify an encoding?  Like 
this:

diff --git a/lisp/startup.el b/lisp/startup.el
index 50a8f491d8..338fb47f64 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -824,6 +824,14 @@ normal-top-level
         (unless inhibit-startup-hooks
           (run-hooks 'window-setup-hook))))

+    (when (< (length (split-string (getenv "LANG") "\\.")) 2)
+      (display-warning 'initialization
+                       (format "%s%s%s"
+                               "The LANG environment variable, set to `"
+                               (getenv "LANG")
+                               "', does not specify an encoding.")
+                       :warning))
+
      ;; Subprocesses of Emacs do not have direct access to the terminal, so
      ;; unless told otherwise they should only assume a dumb terminal.
      ;; We are careful to do it late (after term-setup-hook), although the

bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii]

> Date: Thu, 06 Oct 2022 15:15:51 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: jonathan@jonreeve.com, larsi@gnus.org, schwab@linux-m68k.org, 
>     57531@debbugs.gnu.org
> 
> 
> >> To avoid such bugs, the most reasonable thing to do for users is to 
> >> always specify the encoding.
> >
> > Should we perhaps have an entry in PROBLEMS with that information?
> >
> 
> Would it not be better if Emacs checked the LANG environment variable on 
> startup and warned the user when LANG does not specify an encoding?  Like 
> this:

We could do that, but:

 . issuing a warning doesn't solve the problem
 . experience shows that warnings shown at startup time frequently go
   unnoticed, since they might "drown in the sea" of the many messages
   shown by startup (for example, I use desktop, which emits gobs of
   messages when it restores a session)

So I'm not objected to having a warning, but an entry in PROBLEMS
would still be good.

Also:

> +                       (format "%s%s%s"
> +                               "The LANG environment variable, set to `"
> +                               (getenv "LANG")
> +                               "', does not specify an encoding.")

I believe the accepted terminology for that is "codeset".