GNU bug report logs - #80071
31.0.50; [FR] File-local language variable

Previous Next

To reply to this bug, email your comments to 80071 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; [FR] File-local language variable
Date: Wed, 24 Dec 2025 11:52:36 +0100

I would like to propose a new file-local variable `file-language' (or
`local-language' or `document-language' depending on color of the bike)
which holds one ore multiple languages of the file as an ISO code. The
global language can be determined from `current-locale-environment'.

There are multiple packages or modes which need to know the language of
the current file:

1. Spell checking packages: Ispell, Flyspell, Jinx, Jit-spell, ...
These packages sometimes come with their own language variable.

2. Dictionary completion: For example the Capf `cape-dict' from the GNU
ELPA package cape accesses a word list file to offer completion. If a
file-local language variable were present, it could be used to determine
the appropriate dictionary.

3. Text-to-speech software like the GNU ELPA package greader need to
know the language of the file. Greader comes with a bunch of
variables which hold the language, e.g., `greader-speechd-language', but
it could instead take advantage of a file-local language variable.

The file language can be provided in multiple ways. For example some
files specify the language directly as in Org files with `#+language`
keyword or HTML files in a meta header. The corresponding modes can set
a local language variable (e.g. Org or Eww). Furthermore `file-language'
can be stored as a file-local or directory-local variable, such that the
user can configure the language of files.

By introducing a file-local variable `file-language' we can connect
packages/modes which know the language with packages/modes which need to
know the language. Right now, I abuse the `jinx-language' variable from
my GNU ELPA Jinx package, but I would prefer a universal solution, which
can be supported directly by other packages and modes.

All that is needed for support is to add the following definition to
files.el or subr.el.

(defcustom file-language nil ;; or some default like `current-locale-environment'
  "File local languages as ISO codes, separated by space."
  :type 'string
  :local t
  :safe #'stringp)

Then packages/modes can be extended to take advantage of this variable
if present. The definition can be ported back via the Compat package,
such that packages installed on older Emacs versions can take advantage.
Alternatively packages can just check for the variable with
(bound-and-true-p file-language).

As a bonus, I propose the variable `file-words', which holds a list of
words which are valid in the context of the current file. This variable
only matters to spell-checking packages, but would be nice to have
nevertheless for consistency with `file-language'.

(defcustom file-words "some words separated by space"
  "File local words, separated by space."
  :type 'string
  :local t
  :safe #'stringp)

I had discussed this a while ago with Augusto (cc'ed) on
https://github.com/astoff/jit-spell/issues/20 and there have been a few
discussions about spell checking packages on emacs-devel. Thanks.

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.49, cairo version 1.18.4) of 2025-12-23
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)

Configured using:
 'configure --prefix=$HOME/.local/share/emacs
 --without-compress-install --with-tree-sitter --with-native-compilation
 --with-dbus --without-selinux --without-threads --disable-gc-mark-trace
 --without-gsettings --without-gpm --with-cairo --with-cairo-xcb
 --with-xinput2 --with-x-toolkit=gtk3 --without-toolkit-scroll-bars
 'CFLAGS=-O3 -mtune=native -march=native''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBOTF LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 TIFF TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB

Message #8 received at 80071 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 80071 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#80071: 31.0.50; [FR] File-local language variable
Date: Wed, 24 Dec 2025 16:30:43 +0200

> Cc: Augusto Stoffel <arstoffel <at> gmail.com>
> Date: Wed, 24 Dec 2025 11:52:36 +0100
> From:  Daniel Mendler via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> I would like to propose a new file-local variable `file-language' (or
> `local-language' or `document-language' depending on color of the bike)
> which holds one ore multiple languages of the file as an ISO code. The
> global language can be determined from `current-locale-environment'.

It's a good idea, IMO, but I don't think I like the suggestion to use
ISO codes.  This is basically a user-facing feature, and such features
shouldn't require users to know about cryptic ISO language codes.
Besides, not all potential consumers of this feature will want the
language as its ISO code.  It isn't a coincidence that the Emacs
language-environment doesn't use the ISO codes, but a plain-English
name of the language.

So my suggestion would be to allow users to specify the language in
plain English (and/or maybe even in the language itself), and have
Emacs convert that into whatever is needed using some database, per
the requirements of the relevant consumer features.

> (defcustom file-language nil ;; or some default like `current-locale-environment'
>   "File local languages as ISO codes, separated by space."
>   :type 'string
>   :local t
>   :safe #'stringp)

If you want to allow a list of languages, stringp is not enough.

> As a bonus, I propose the variable `file-words', which holds a list of
> words which are valid in the context of the current file. This variable
> only matters to spell-checking packages, but would be nice to have
> nevertheless for consistency with `file-language'.

We already have LocalWords, see ispell.el, so why do we need a new
variable?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.