Clarification about Radian / custom user code

[jnboehm]

I am still a bit unclear about what radian is supposed to achieve. As far as I understand it, it is your own customization of Emacs and other software. In essence I am a bit unclear about how to best start off a personal .emacs.d based on this project.

I personally love the idea behind it, although for me it feels a bit personalized with the configured languages (which isn't severe) and the loading of a custom theme. This makes it a bit unclear on where I would put my own use-package stanzas, especially if I want to reconfigure packages like projectile (I don't know whether it's possible to declare a package multiple times, but for me it seems to go against the spirit of the declarative configuraiton).

Furthermore, disabling the toolkits or generally writing to init.el appears like it could break stuff, hence I am unclear on where to put code like that. My guess would be using the hooks offered by radian, but I am not entirely sure about that.

To me the whole configuration done by radian just seems a bit too magical and the preconfiguration appears a bit inaccessible, although the setup seems really elaborate.

[raxod502]

From my init.local.el (almost 1000 lines):

(radian-local-on-hook after-init

  (setq-default epa-file-encrypt-to "Radon Rosborough")

  (add-to-list 'safe-local-eval-forms
               '(when (and
                       buffer-file-name
                       (not (eq major-mode 'web-mode))
                       (string= "ejs" (file-name-extension buffer-file-name)))
                  (web-mode)))

...

  (use-feature compile
    :config

    (setq compile-command "make "))

  (use-feature ps-print
    :config

    (setq ps-print-header nil)
    (setq ps-font-size 11))

  (use-feature lsp-mode
    :init

    (defun radian-local-install-pyls ()
      "Install python-language-server in Pipenv virtual environment."
      (interactive)
      (compile "install-pyls")))

...

  (use-package diary-manager
    :bind* (("C-x C-d" . #'diary-manager-edit)))

  (use-package nusmv-mode
    :straight (:host github :repo "felipeblassioli/nusmv"
                     :files ("contrib/*.el")
                     :fork (:repo "raxod502/nusmv" :branch "fork/1"))
    :mode (("\\.smv\\'" . nusmv-mode)
           ("\\.m4.smv\\'" . nusmv-m4-mode))
    :config

    (set-face-attribute 'nusmv-font-lock-keyword-face nil :foreground "Green"))

...

Such code will execute after radian.el, and you can install your own packages, or add configuration to existing ones, no problem. Any new packages you add will be saved to their own lockfile, so they won't conflict with Radian's. Actually, this feature is the entire reason why I invented the lockfile profile system for straight.el.

You can disable the color theme by (setq radian-color-theme-enable nil), and install your own in init.local.el, if you wish.

I would be happy to answer further questions you may have, or to take suggestions about what things ought to be configurable that are currently not configurable. I will certainly admit that it is not as easy as it ought to be, since allowing arbitrary local changes to an Emacs configuration is a rather hard problem. Basically, nobody has asked before, so I haven't done much work in this area. But I'd be happy to make it more user-friendly.

[raxod502]

And obviously if you think you want to change a lot of things, you can always just fork the configuration. But if you have changes which you think are improvements, I would gladly accept pull requests so that everyone can benefit.

[jnboehm]

Thank you for the quick answer. It does make it a bit clearer, but I still have some questions left. Sorry that this post turned more into my thoughts and opinions.

You can disable the color theme by (setq radian-color-theme-enable nil), and install your own in init.local.el, if you wish.

Will the color-theme still get loaded at the correct point in time? In essence, can your default theme be swapped out by a user-supplied one? Maybe just having a defvar where the theme is specified would be nice (although I am unsure how to tell straight that this is a dependency and should be installed).

Disabling the scroll-bar and other window decorations would ideally also happen before the frame is created, hence I would conceptually like to put them in early-init.el. Or should that be used via one of the hooks? I currently disable it as follows:

(when (fboundp 'menu-bar-mode)       (menu-bar-mode   -1))
(when (fboundp 'tool-bar-mode)       (tool-bar-mode   -1))
(when (fboundp 'scroll-bar-mode)     (scroll-bar-mode -1))
(when (fboundp 'blink-cursor-mode) (blink-cursor-mode -1))

To me, reconfiguring the already specified packages feels a bit clunky, since I know that they have already been declared once via use-package, but it seems to work.

Suggestions

Those are just ideas, and I would assume some are better placed at the corresponding repository.

mode-line

This is more related to blackout. How does it compare to rich-minority? I perosonally like just specifying a regex whitelist and not having to muck with every minor mode that wants to litter my mode line. It does not natively support renaming, so there's that.

And a personal anecdote: my previous config did issue some warnings regarding the mode line. I am not sure whether that is related to that project, but I did not use any other package like diminish et al.

It could also be an idea to blackut the mode lines by default and then explicitly whitelist them in the use-paclage declaration. I like this idea more, but that is probably a feature request for blackout.

unique buffer names

I use uniquify for renaming the buffer names, which places the first unique parent in front of the buffer name, which I find more intuitive.

(use-package uniquify
    :config
    (setq uniquify-buffer-name-style 'forward
          uniquify-separator "/"
          uniquify-after-kill-buffer-p t     ; rename after killing uniquified
          uniquify-ignore-buffers-re "^\\*") ; don't muck with special buffers
    )

I'd guess that use-package would be replaced by use-feature since this is in-built functionality.

backup files

As I understand it, undo-tree uses persistent-history across sessions and thus replaces the auto-save functionality? I am unsure how much information of encrypted files will be leaked by that.

Otherwise I previously configured the autosaves to be placed in another directory so that it would prevent littering the cwd. The configuration was essentially as in this blog post. Additionally, I have set up a small minor mode like so:

(define-minor-mode sensitive-mode                                         
  "For sensitive files like password lists.                               
It disables auto saving.                                                  

With no argument, this command toggles the mode.                          
Non-null prefix argument turns on the mode.                               
Null prefix argument turns off the mode."                                 
  ;; The initial value.                                                   
  nil                                                                     
  ;; The indicator for the mode line.                                     
  " Sensitive"                                                            
  ;; The minor mode bindings.                                             
  nil                                                                     
  (if (symbol-value sensitive-mode)                                       
      (progn                                                              
        ;; disable auto-save                                              
        (if auto-save-default                                             
            (auto-save-mode -1)))                                         
                                      ;resort to default auto save setting
    (if auto-save-default                                                 
        (auto-save-mode 1))))                                             

(setq auto-mode-alist                                                     
      (append '(("\\.gpg$" . sensitive-mode))                             
              auto-mode-alist)))                                          

I do not know where I took the inspiration from and I didn't find it with a quick search.

[jnboehm]

Regarding the tool and menu bars: I just noticed that they are supposed to be disabled by radian, but they are still being displayed for me (running emacs 27.0.90 on Linux). I am starting emacs with emacsclient -a "" which could very well be the issue since it loads the configurtion before creating the frame.

[raxod502]

Will the color-theme still get loaded at the correct point in time?

To my knowledge. You can see for yourself exactly where in radian.el the default color scheme is loaded versus where the after-init hook is run, and judge for yourself.

I would conceptually like to put them in early-init.el

Actually, all Radian code is run in early-init.el, which you can see by inspecting the contents of the provided early-init.el.

reconfiguring the already specified packages feels a bit clunky

It's not. use-package is only syntax sugar for with-eval-after-load, and there's nothing wrong with using more than one of those. You should of course use use-feature instead of use-package, though, to avoid calling into the package management system twice for the same package (this won't cause a problem but does duplicate configuration in the case of a custom :straight keyword).

How does it compare to rich-minority?

You should ask this question on the Blackout issue tracker. I wouldn't object to adding features such as the option to use a whitelist. I have never used rich-minority before (in fact I was not previously aware of it), and making a comparison will take some time.

I find more intuitive

I prefer to keep the default as it is in Radian, but as you observe it is easy to change.

I'd guess that use-package would be replaced by use-feature

Yes.

undo-tree uses persistent-history across sessions

Only if you enable it, which Radian does not. The feature is buggy and commonly causes undo history to be lost.

the auto-save functionality

Auto-save is also disabled by Radian.

I am unsure how much information of encrypted files will be leaked by that.

Me too. If you want a reference implementation, I suspect there may be one in https://github.com/PythonNut/quark-emacs.

Regarding the tool and menu bars

You should open a new issue for this with details on your system configuration and method of starting Emacs.

[ergenekonyigit]

use-feature doesn't compile bu i can compile with use-package

I can't set default theme. It ask overwrite for every openning. @raxod502

[raxod502]

You need to use use-package, not use-feature.

[raxod502]

This thread is being closed automatically by Tidier because it is labeled with "waiting on response" and has not seen any activity for 90 days. But don't worry—if you have any information that might advance the discussion, leave a comment and I will be happy to reopen the thread :)

[hrehfeld]

What's the correct approach for changing binds that radian installs that I'm not satisfied with?

Use-cases I encountered so far:

• don't overwrite dabbrev bind
• don't use return for company-complete-selection
• don't use arrow keys at all (again, company)

Would it make sense to put these into variables? [remap] (but which command/map if the original rebind is a remap itself)? Fork?

Also, there are some traces of opionated config in here (overwrite region for instance), do I just configure them back? Feels weird :-) Good use-case where it's not so easy to free some keys: smartparens.

ps. I'm so glad to have found a config that's not overengineered, thanks a bunch! pps. Any idea what's a good alternative key for dabbrev?

[raxod502]

Hey @hrehfeld, sorry for the delay, I just got back from vacation.

do I just configure them back?

At the moment, yeah, that's the best solution.

Feels weird

I agree! I think it'd be perfectly reasonable to start a pattern of introducing more user options and configurability in general into Radian, where the customizations that are controversial can be enabled/disabled.

correct approach for changing binds that radian installs

I think for keybindings the best approach is simply to overwrite the bindings a second time. We could try to implement something on the level of user options, but that would tend to lead to a lot of code that would potentially make it harder to understand how to configure things as a user of Radian.

[remap] (but which command/map if the original rebind is a remap itself)?

I'm not sure myself about the semantics of chained remaps. But I also don't think you need to go there. If Radian binds [remap foo] to bar, I think you can unbind [remap foo] (unbind-key, or equivalently bind it to nil) and then bind your preferred thing to bar.

thanks a bunch!

And thank you for your patience with the rough edges as we get Radian into a state where it's good for use by other people in practice and not just in theory!

Any idea what's a good alternative key

I'm probably not a good person to ask for advice here, I have a bit of PTSD about keyboard customizations and try not to configure anything when I can get away without it...