|Date:||Wed, 7 Sep 2016 15:59:23 +0100|
> From: "address@hidden" <address@hidden>
> Date: Tue, 6 Sep 2016 16:24:56 +0100
> I would request that this package (after revision and a possible API change) becomes part of GNU Emacs. I would also suggest that ~/.config/emacs/init.el (the result of "(locate-user-emacs-config-
file "init.el") becomes in vanilla emacs part of the chain to determine user-init-file.Thanks. Some comments below.
. IMO, we need to figure out where this stuff fits into Emacs. Do
the XDG places override the traditional Emacs places, or the other
way around? Do we even want this, and if so, why?
. If the XDG places override the traditional ones, an important
aspect to consider is the transition period: the first Emacs
version that turns on this feature will need to help users migrate
from the old places to the new ones. This requires support code
that I don't see in your package.
. The package in its present form "needs work" before it can be
admitted into Emacs:
. The few settings that must be preloaded and the minimal support
code should go to files.el; the rest of the package doesn't have
to be preloaded, AFAICT.
. The package currently depends on s.el for a single function; I
think that dependency should be removed, and standard facilities
. The usage of shell commands, such as xdg-user-dir, is
problematic, at least on non-Posix platforms. I wonder if that
script is really needed, or how important it is for the overall
functionality. AFAICS, the script just accesses some environment
variables and reads a file, something we could do from Lisp.
. Symbols (functions, variables) defined by the package should have
a unique package-specific prefix, in this case probably "xdg-".
. Maybe it's just me, but I find some of the terminology, and the
respective variable/function names, confusing, because they clash
with the long tradition of the Emacs terminology. For example,
"user file" has a precise meaning in Emacs, so the purpose of
xdg-get-user-file is a surprise. Likewise with "emacs data
file". More generally, the naming convention doesn't sound
consistent: some functions that return file names are called
locate-SOME-file, but other similar functions are
. The doc strings need various minor fixes, as they include typos
and copy/paste errors.
. A minor nit: GNU coding standards frown on using "path" to refer
to anything but PATH-style directory lists; use "file name" or
"directory name" instead.
Thanks for working on this.
|[Prev in Thread]||Current Thread||[Next in Thread]|