demyanrogozhin / elhome Goto Github PK

Hi,

I was looking at using literate programming to convert my emacs config into org files, something like:
https://ryan.himmelwright.net/post/org-babel-setup/

I'm pretty sure at the moment the use of org file(s) to represent settings and startup files won't work with elhome out the box?

I suspect I could have one-line *-settings.el type files that then called out to a *-settings.org file and these would then contain everything apart from the customizations which would always be written to the original *-settings.el lisp file? eg

foo-settings.el:
(org-babel-load-file "foo-settings.org")

I also suspect that to get the customizations into an org file would probably require changes to the underlying init-split.el as well as elhome?

Has anyone tried this?

Hi! I know I've tried to express my opinion on this score before and failed utterly, but hopefully I'm a year or two better-spoken, so let me try again :). I'm trying to speak very explicitly here so that if you disagree you can easily point out exactly which part of my train of thought you disagree with. I hope that this will make it easier to reach agreement about this issue.

One of the standard elhome startup files is 10-el-get.el. This file installs el-get if necessary and then invokes it. However, if you use el-get to load elhome, and then elhome invokes el-get, you get a recursion that cannot end well. This is how I load elhome, and every time I set up my customizations on a new machine, I comment out the last line of 10-el-get.el because it causes emacs init to break.

I would like some change made to elhome so that I don't have to modify it every time I set up a new machine.

I believe that most people who will use elhome are going to try it first through el-get. It seems to me that most such users are going to encounter a problem similar to mine -- they are going to set up el-get to load elhome, and elhome is going to try to run el-get, causing a bad recursion. Thus, I believe that any change that resolves my personal problem is going to be good for most potential users of elhome.

In the past, you've suggested that instead of using el-get to load elhome, I should use elhome to load el-get, and that this would fix my problem. In your eyes, elhome is a framework which conveniently manages el-get for you, so it's natural that elhome run el-get. I believe most current users of elhome today follow this pattern of using elhome to run el-get and thus don't see my problem. However, I don't like this solution because elhome is being installed as an el-get package, so it seems more natural to me that el-get load elhome. I believe most emacs users are more familiar with el-get than are familiar with elhome, and will therefore conceptualize things the way I do, which is to say will try to use el-get to load elhome rather than the other way around. So again, I believe that there is value in elhome supporting being loaded by el-get.

I'm not committed to any strategy by which elhome may be changed in order to resolve my problem. It seems to me that if most current elhome users expect elhome to run el-get, then we cannot simply remove 10-el-get.el. Instead, we should provide a means of disabling it for those users who, like me, run elhome from el-get instead of el-get from elhome. Ideally, I would like the mechanism to be as lightweight and effortless for users in my position, both because I am personally lazy and because I believe that making it easy to run elhome via el-get will make it easier to attract new users.

Here are some ideas for such a mechanism.

1. A simple variable which controls whether to run el-get from inside elhome. Alternately, a variable that tells elhome what packages to load when running el-get from inside elhome. In either case, a user like me who does not want elhome to run el-get can add an additional setq to his init.el.
2. More generally, a variable or parameter to (elhome-init) that specifies which files in startup to include or exclude. A user like me who wants to run elhome from el-get might specify (let ((elhome-startup-exclude "10-el-get.el")) (elhome-init)), or (elhome-init :without "10-el-get.el").
3. Startup files could be merged from the main elhome/startup and the user's startup directories. A user like me could insert his own 10-el-get.el which would shadow the current 10-el-get.el.
4. 10-el-get.el could include code to look at the current call stack to see if elhome was invoked from el-get. If so, elhome would know not to invoke el-get itself. If not, it could go ahead and invoke el-get.

Of these, I like 4 the best -- while a little hacky, it should be possible to use backtrace-frame to look for a call to el-get, and it would require no work for either category of users (but more for the developers ;)). After 4, I like 2 best, because it provides an easy way for users of elhome to use it "à la carte", that is, deciding which parts of elhome they like and which they don't. But like I said, I don't have a strong preference and would even consider other mechanisms if you had any in mind. I'll even try to implement whichever mechanism you think you will like best.

Thanks for your time, and thanks for elhome, which I still use even since it causes me this inconvenience.

me-minor-mode is just a much less-evolved version of what John Wiegley put in bind-key; see https://github.com/jwiegley/use-package/blob/master/bind-key.el

use-package is effective whenever you don't want to—or can't—rely on a package manager to set everything up for you.

Both of these are super lightweight.

Must force it to load first. Problem?

See http://stackoverflow.com/questions/683425/globally-override-key-binding-in-emacs

If a filename appears more than once in any of the customization alists (used by the function initsplit-custom-alist ), then some customizations can be erased.

Explanation: The first time the filename appears in an alist entry, the associated customizations are written. Those customizations are no longer considered unsaved. The second time the filename appears in an alist, the file will be overwritten, without any of the (no longer unsaved) customizations that the first alist entry wrote.

One approach to making things safer:
initsplit.el could check for a filename in the existing customization-alists before adding an entry to the dynamic alist. If the filename was already present, it could instead OR its regexp to the existing regexp. This would mostly work, but it could change the effective overall ordering of the regexp matching.

el-get is kind of evil, but the README for elhome and elhome itself both use it.

Right now they are in 10-el-get.el

it looks like we go to some lengths to install dabrahams/el-get, which is somewhat outdated and contains a bug that prevents clean installation (calls el-get-post-install with two arguments when it's defined with one). Why not just use dmitri's el-get, which works fine?

For example, setting up global keybindings. Best idea so far: do it with something like an autoload cookie, in a comment, and have it processed into a startup file, just like autoloads are.