Split out basic color definitions from themes.

[mrzor]

• nano-base-colors: customizable base colors
• nano.el: support for -default arg, to use default Emacs colors
• nano.el: opt-in support for customize even when running with -q

What this is

This is in line of my previous PR aiming at making nano-emacs easier to integrate into existing configurations. This separates color definitions from themes, and adds a small new set of default colors that are derived from a few basic Emacs theme. This allows smooth, zero-config, integration into existing themes - to some extent.

With this change, I can finally load nano-emacs modeline with minimal code in my existing config. It looks like this:

(add-to-list 'load-path "/home/zor/taf/my-nano-emacs")

(require 'nano-faces)
(nano-faces)

(require 'nano-theme)
(nano-theme--mode-line)

(require 'nano-modeline)

Not perfect, but good enough.

Customize !

I also added some machinery to nano.el to make customize work again if and only if a nano-custom.el file is created by the user next to it and emacs was started with -q. In effect, this allows a user to checkout this directory, alias nane=\emacs -q -l <path-to-nano-emacs>/nano.el -dark and have a working setup coexisting with another Emacs (which is my use-case).

I believe there are a few more aspects to consider when talking about standalone nano-emacs installed outside .emacs.d - I'd be delighted to share some ideas in a dedicated issue if you are interested to go down this route.

As things stand, changing colors require an Emacs restart (!) to see any impact, mostly because faces are derived proceduraly. I'm interested in fixing that next, but I haven't yet figured out if it will be with some form of hooks, or with more substantial refactoring of the (nano-faces) function.

[rougier]

Thanks. how do you set the light/dark without nano-custom?

[mrzor]

It works as before -light and -dark to load a given theme. By default, it loads light. There is a new -default to not load a theme and experiment with the new default-derived colors.

[rougier]

Sorry, my question was not clear. How do you set the theme programmatically if you import only some modules in your configuration? Through custom only?

[mrzor]

If you mean theme in a general sense (i.e. not what the nano-theme.el module specifically does), then, as of this PR, you can set the theme programmatically by either:

• Using setq on the relevant color variables after requiring nano-base-colors. (Custom will complain the value was "Modified outside customize)
  • You can (require one of the existing theme files (which do the setq on the relevant color variables for you). They also require the base colors, so you don't have to. There is no harm is requiring the same module twice.
  • Using custom to roll your own the same thing
  • Doing none of the above, but loading any other Emacs "theme" (i.e. a, redefinition of Emacs common faces), and then require nano-base-colors. (Custom will say you are using default values)

Once the "nano color palette" has been defined (aha, wouldn't that be a better name ?) - you can require the full nano-theme or parts of it, depending on your preferences (as introduced by my previous PR).

I hope that made sense :hot_face:

[rougier]

Now I got it, brillant! And your code is really nice. I need to commit some local changes first and I'll merge (hopefully without too much conflicts). In term of faces, I added nano-face-tag-xxx family for potentially having SVG tags. I'll integrate them after merging your PR. Now be prepared for the merging mess...

[mrzor]

Thanks :blush: I can do the rebase once you are done pushing your changes.

[rougier]

Done and only one conflict. Not so bad. Also with your custom solution we can integrate the different session variables into is instead of having them hard-code ("~/.nano-savehist", "~/.nano-recentf", etc.)

[mrzor]

I'm not sure if savehist / recentf data can be saved alongside custom data. nano-custom.el is stored wherever nano sourcecode is for convenience (or wherever the custom-file var points at). We could apply to same logic to nano-savehist and nano-recentf, i.e. if no location is set for those, then store them as dotfiles alongside nano sourcecode. I can PR that later on.

[mrzor]

That was a very easy rebase indeed :)

This conflict was hardly one. FYI, nano-what-faces is a utility function that I wrote for myself a while back for customization purposes. It's meant to be used interactively, by doing M-x nano-what-faces. It will list the faces used at point.