Re: Default for image-dired-main-image-directory

[Ihor Radchenko <yantar92@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Essentially, it is similar to XDG directory set, but all the directories
>> are inside .emacs.d by default.
>
> That's a different philosophy, and since it contradicts XDG, which
> many people want, I don't think we can go that way, except as an
> opt-in feature (which will then become a maintenance burden, as it
> will be yet another, third, set of defaults).

Not necessarily.  no-littering provides a unified directory structure to
be used by other packages. Yes, it defaults to structure inside .emacs.d
(and thus do not need to bother with OS-specific conventions), but
that's not required:

(defvar no-littering-etc-directory
  (expand-file-name (convert-standard-filename "etc/") user-emacs-directory)
  "The directory where packages place their configuration files.
This variable has to be set before `no-littering' is loaded.")

From point of view of a package author, I usually have difficulty
deciding where to put files. Package install dir? Directly into
.emacs.d? User home dir? I would prefer to have a convention about
default dirs. I would prefer Emacs to handle variations of directory
structure in different OS.

no-littering proposes a set of Emacs-specific conventions about where to
put package files:

>> (A) File names
>> 
>> File names are based on the name of the respective Emacs lisp variables
>> and the name of the respective Emacs package.
>> 
>> The name of the respective Emacs package should serve as the prefix of
>> the file name, unless the file is in a subdirectory in which case the
>> name of the subdirectory serves as the prefix.
>> 
>> If the name of the package and the prefix of the variable do not match,
>> then we prefer the name of the package.
>> 
>> If the name of a path variable ends with -file, -default-file,
>> -directory, -default-directory, or something similar, then that suffix
>> is usually dropped from the file name.
>> 
>> If applicable, the appropriate extension is added to the file name so
>> that files are visited using the appropriate major-modes and also to
>> provide a hint about the kind of data stored in the file. E.g. if a file
>> contains an S-expression, then the suffix should be *.el.
>> 
>> B) File location and subdirectories If a package has only one data file,
>> then that is usually placed in no-littering-var-directory itself.
>> Likewise if a package has only one config file, then that is placed in
>> no-littering-etc-directory itself.
>> 
>> If a package has multiple data (or config files), then those files are
>> placed in a subdirectory of no-littering-var-directory (or
>> no-littering-etc-directory).
>> 
>> If a subdirectory is used for a package's data (or config) file
>> variables, then the name of the directory should match the name of the
>> package in most cases. The subdirectory name may serve as the package
>> prefix of the file name.
>> 
>> If a package provides a "framework" for other packages to use, then we
>> may reuse its directories for other packages that make use of that
>> framework or otherwise "extend" the "main package". E.g. we place all
>> helm related files in helm/.
>> 
>> If a package only defines a single variable that specifies a data (or
>> config) directory, then the directory name should nevertheless be just
>> the package name. E.g. the path used for sx-cache-directory from the sx
>> package is sx/cache/, not sx-cache/.
>> 
>> However if the name of the directory variable implies that the package
>> won't ever define any data (or config) files that won't be placed in
>> that directory, then we use a top-level directory. E.g. when the name of
>> the variable is <package>-directory, in which case we would use just
>> <package>/ as the path.

Best,
Ihor