nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] proposal to add support for the XDG base directory spec


From: Benno Schulenberg
Subject: Re: [Nano-devel] proposal to add support for the XDG base directory spec
Date: Sun, 8 Oct 2017 11:51:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0


Op  7-10-2017 om 22:01 schreef Brand Huntsman:
On Sat, 7 Oct 2017 18:11:25 +0200 Benno Schulenberg <address@hidden>
wrote:
That is stretching the meaning of "config file".  Past search strings and
cursor positions and executed commands are not configuration, they are
entirely comparable to the recently-used things in other programs.  That's
why my first idea was to put them in $XDG_CACHE_HOME.  They are
non-essential data files -- no real harm is done when they are lost, but...
it *would* be a nuisance.  So they are not cache, they are not config, so
they must be data: data that the program produces and wants to keep for
later reference.

~/.cache/ should have been ~/.tmp/, ~/.config/ should have been ~/.etc/,

I prefer the XDG names: they are more descriptive.

~/.local/share/ should have been ~/.local-share/ or something else besides a
useless nested directory

Yeah, that was silly.

and there should have been a fourth directory for
state, ~/.var/ or something.

True.  It should have been called simply .state, so its purpose would have
been obvious.

XDG_CONFIG_HOME is the best choice unless you want to interpret XDG_DATA_HOME
as static or state like gnome and gtk do for recently used history.

The latter.

A user can copy the syntaxes or png files to ~/.local/share/(nano/icons)/ and
modify to re-theme their system.

I'm not going to make that mechanism.  I would prefer to get rid of /etc/nanorc
entirely.  Nano is a user program and it has a global config file, which is read
for all users?  And the only way to ignore that file has as side effect that the
user's own config file is ignored too?  That's absurd.

There could be an /etc/nanorc, but it should be read only when there is no
~/.nanorc.  If the latter does exist, and the user wants to have the system's
default settings without needing to copy the /etc/nanorc file, we could change
the include mechanism to not artificially exclude anything not syntax related.

Benno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]