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: Brand Huntsman
Subject: Re: [Nano-devel] proposal to add support for the XDG base directory spec
Date: Sun, 8 Oct 2017 17:11:20 -0600

On Sun, 8 Oct 2017 11:51:04 +0200
Benno Schulenberg <address@hidden> wrote:

> > 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.

If include value is relative (value[0] != '/') it could look in XDG_DATA_HOME 
and then each XDG_DATA_DIRS. And /etc/nanorc would need to drop the path from 
all includes.

If I loaded my own c.nanorc from ~/.nanorc but also also included /etc/nanorc 
to get other syntaxes, would it not first load the c.nanorc set in /etc/nanorc, 
increasing startup time? If so, loading relative includes from 
XDG_DATA_HOME/XDG_DATA_DIRS would solve that issue.


> 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.

I agree, that's exactly how Gtk 1&2 worked.

Allowing include inside included files opens up the ability to move 
common/shared syntax expressions to their own files. Changing the color of 
whitespace highlighting could be done in one file instead of many files.




reply via email to

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