Proposal: Support personal configuration directory

[mrzor]

Support a <nano-emacs-srcdir>/personal directory to store user configuration.

This is similar to what bbatsov/prelude does. This allows nano-emacs to be used as a first-class Emacs distribution, rather than an embedable one: i.e. you can checkout rougier/nano-emacs into .emacs.d and start configuring your own stuff in .emacs.d/personal. Whenever one wants to upgrade, git pull.

This would be the natural place for you to store your personal settings as well, which are currently versioned in master :wink: It's also the natural place for users to add their own (require ... or (add-to-list 'auto-mode-alist ... or (use-package ... code.

I plan to actually replace my GNU Nano with such a config, once the work is done. Except that my .emacs.d will not be used. I like the idea of having a very lightweight Emacs based on Nano as my terminal editor (i.e. set as EDITOR) while my full blown Emacs IDE remains as it is (for now!).

It's a fairly straightforward change to nano.el, I'll contribute the change and documentation update if you're ok with the idea.

[jacksonbenete]

I'm not familiar with prelude, but I don't see how the actual implementation doesn't allow personal configuration, both for this and issue #18 . Maybe I just don't understand correctly what you need.

In my initi.el I have:

;;; Nano Emacs
(add-to-list 'load-path "~/.emacs.d/nano-emacs")
(require 'nano-layout)
(require 'nano-theme-light)
(require 'nano-modeline)

;;; Custom Style
;; "Correct" nano-emacs design
(add-to-list 'load-path "~/.emacs.d/personal/")
(load-library "custom-style")

In this custom-style.el I can change anything I want, like the font size, fringe, faces... Since I use Emacs for daily code I had to change the font-faces for my preferences and some other minor details for compatibility with some minor-modes.

You can just put a if/when detecting if emacs is as gui or terminal to load or not nano-emacs or any customization you want, you could even create a personal-gui, and personal-terminal files for different customization. There is no need to change nano code for this. But that's just my opinion.

(if (display-graphic-p)
    (progn
    ;; if graphic
      (your)
      (code))
    ;; else (optional)
    (your)
    (code))

[mrzor]

Prelude, Doom and other Emacs distributions claim the emacs.d folder so to speak.

In your examples, you are maintaining your own emacs.d, from which you use nano and whatever else you fancy. This is fine, and it's probably the best way to go about it for persons who don't mind doing some casual emacs-lisp. It is also the only way to go about it if you are already using another Emacs distribution. To paraphrase, this is 'using nano as a library'; a leaf in your configuration tree.

OTOH, other people do not want to deal with elisp to begin with. To them, we could say git checkout https://github.com/rougier/nano-emacs ~/.emacs.d && ln -s ~/.emacs.d/nano.el ~/.emacs.d/init.el then start Emacs. You can git pull whenever to update. You can add elisp snippets to your personal/ directory as needs arise. This mode of operation is 'using nano as a framework'; the trunk of your configuration tree.

In the "checked out" mode of operation, editing nano files means re-merging your edits on updates. Having a personal directory enables the user to add whatever without conflicting with nano-emacs.

On the subject of issue 18, since you brought it up, I meant customization through the use of custom mode. In current form, Custom will not allow you to customize the faces, which is the point of the issue there. Customizing the faces programmatically using (set-face-attribute .. is indeed possible, but it is not what the issue is bout.

[mrzor]

I do not mind the discussion at all, but I'll admit the broad scope of your questions put me off answering for longer that I would have thought.

You ask several fair questions.

I think that once a package is on Elpa/Melpa following all the guidelines then it's the distribution responsibility to make it compatible don't you think?

I do not. Distribution authors and maintainers are free to do as they please with the code, which is clearly stated in the license. The responsibility to make anything work always rests on the end user. Most Emacs distributions have a set of packages they rely on, and maybe some opt-ins they support. Anything beyond that and I would assume you're on your own. Which doesn't imply you will get no help to make xxx.el work, but in the end, it's your problem.

Sounds a good idea to adapt a package to a big distro if that's means that more people would be able to know and use nano! And nano isn't on a package repository like Elpa or Melpa, but just sounds a little strange to me to see a package maintainer changing the package for it to fit other people (distros) standards.

Using nano as a library inside another Emacs distro, or inside a user-authored conf, is still very much supported. When that's the case, feel free to not care about nano.el at all - as things stand, if you are using nano as a library, nano.el is a tutorial for how you can integrate nano modules into your conf.

On the other hand, if you want to use nano as a minimal distribution of sorts, then having support for personal/ based configuration makes sense. This way you can install nano directly into .emacs.d and get started right away.

The purpose of this proposal is not to fit nano to other people standards, but to smooth up the "nano as a distribution" use case. You don't have to use it yourself, but some people - including myself - may find it handy.

You talk about people that wouldn't need to deal with elisp to begin with, but then said that they could add elisp snippets to the personal/ directory. Isn't that to deal with elisp?

My phrasing was probably weird on this. Emphasis on to begin with. Coming back to "nano as a distribution", you don't have to jump into elisp right away. Follow the instructions, start Emacs, and get stuff done. You can jump into elisp whenever you're ready. Contrast with "use nano as a library", and then knowing elisp is suddenly a pre-requisite for using nano. It doesn't have to be this way.

Maybe would be the case to clarify a little more what's nano purpose, is it to be a "library" or is it to be a "framework" as you've said? Is it to be a theme/package or a distro?

Why not both ? It's small enough to support both use cases.

[jacksonbenete]

Thanks for taking your time to answer, and sorry for the long questions. I end up deleting the post a few hours after because I thought it was not a contribution to the issue. Hopefully Github Discussions will thrive some day for talkative people like me. :P