Show HN: Emacs Configuration Generator
emacs.amodernist.com
emacs.amodernist.com
E.g. if you start with a brand new emacs then you could paste a line into scratch, eval it, and then these question would come up, you give answers and then an emacs file is generated, written, evalled and you get your configured emacs instantly.
But of course a web interface also has its advantages, it's prettier than barebones emacs,so it's more appealing to config there.
That being said, the screenshots get in the way so it isn't that great (ironically emacs -nw appears to work better). But a long term goal is to find a way in which the configuration options could be detached from the configuration generator, as mentioned in the last section here: http://amodernist.com/texts/ecg.html. An alternative could also be to have the configuration generator generate an Elisp script, that could be evaluated and used in Emacs itself.
The reason that I decided to implement this for the browser first, is that the interface is probably more familiar, especially if someone has had no experience with Emacs before.
First, Emacs should have sensible defaults like Ctrl-c for copying and Ctrl-v for pasting.
Second, there should be a menu item to choose among particular setups. A new user shouldn't have to go through the less-than-fun process of installing a bunch of stuff to get a common sense setup.
Emacs has a loyal user base, and changing to having cua-mode as the default would likely anger most, if not all of them. I highly doubt that the number of long-term users gained by the change would be even remotely significant.
This sums up well the gigantic hurdles Emacs faces as it attempts to stay relevant over the next 20 years. We're talking about a single keyboard shortcut to switch back to legacy mode.
It's only when you stop looking at growing absolute user numbers and instead get into percentage, is when you reach a conclusion like Emacs is struggling to stay relevant. That's like saying Lamborghini is struggling to stay relevant because of Toyota or something.
My point was that making the default cua-mode won't lead to a significant number of new long-term users, so it isn't worth the hassle it would create for people who are already using it.
Also, emacs is not struggling to stay relevant. I fully expect that it will appeal to an audience of users similar to the one it appeals to today for decades to come.
Except that would break a ton of existing commands, since ctrl-c is use as a prefix for a bunch of stuff already.
You'd be making it hard for someone who already knows Emacs to use it. It shouldn't be a problem on personal machines, since you can override the defaults. But if you ssh into a server and need to use emacs, it would be problematic.
Also, on macOS, cmd+c and cmd+v work be default.
It would be a burden for a longtime user to have to enter one keyboard shortcut to move into legacy mode? As opposed to making it weird and difficult for everyone else and then watching Emacs die.
New users should not be recommended to use barebones emacs, because it's too alien. They should use a nicely preconfigured system instead.
Whoa. Long-time user and I had no idea.
* undo-tree.
* y-or-n-p. Typing yes or no is annoying.
* Smooth scroll.
* Emacs server or daemon support.
* Magit keybind seems redundant as the package itself adds them, and it's swapped.
* Some comments are misplaced. "Enable LSP support" is followed by (vertico-mode t) in my case.
* I think eglot enables flymake itself.
* I think evil isn't being enabled.
* Selecting auto-save and backup-dir.
> Did you not add use-package because it's not in the repositories you're using, or something else?
Mainly that, but also I am not too fond of use-package. If I add support, it would be with my own package (setup) as an alternative.
> Great choice adding Modus themes!
Well they are bundled in by default.
> * undo-tree. Not sure about this, I have heard people having issues with undo-tree due to the way it is implemented. Vundo seems to be an interesting alternative, but that is Emacs 28+ only.
> * Magit keybind seems redundant as the package itself adds them, and it's swapped. True, but it binds to the C-x prefix which I think is a mistake (especially because it is one automatically).
What do you dislike about it?
It seems like almost a standard now. Even if you don't personally like it, it might be useful to beginner Emacs users to use the tools that everyone else is using. I could say the same about helm.
Yet in principle I do agree that it would be nice to have the option. The issue is how to explain this to someone who doesn't know anything yet about Emacs. Talking about the advantages or disadvantages of using a configuration macro requires some basic understanding of what the issue even is.
The child of the beast, Vim, another popular editor is
often mistakenly used instead of Emacs. Some have sadly
gotten used to the sinful ways, and prefer the modal
approach to Emacs default bindings. If you too are affected
by this curse, this package might help.Reminds me of a Spring Initializr, as a way to quickly get started with a new tech tool.
Of course, that doesn't mean every tool should require massive amounts of time invested in configuring sensible defaults. Not everyone wants to do this.
https://github.com/bbatsov/prelude
The list of features:
* Improved UX, that's still in line with Emacs traditions
* Sane defaults of baseline Emacs functionality
* Automatic installation of many major programming modes on demand
* A curated set of 3rd party packages to enhance the base functionality
* Simple modular architecture
* Easy customization
Can't wait to mess with this.
For extra nerd cred, output a .org file that can use babel to generate init.el ;)
Here are some of the things i was confused about, or thought could be improved.
1. The label of checkbox don't seem to respond to clicks.
2. On Font Input, There's no description or selections on what inputs are acceptable.
3. There is no mention of Javascript in programming language support section. iirc typescript package can handle js mode apart from the default builtin support for js. A mention of js would have be nice.
The programming language section is also difficult, content-wise, because I don't use most of those languages, and am thus not familiar with their options. My hope is to gather feedback from other users or the package maintainers on what would be interesting.
> I have an idea of how to solve the font issue (https://git.sr.ht/~pkal/ecg/tree/master/item/ecg.lisp#L342), but on my systems this never gives me all the fonts.
if i read it correctly `document.fonts` reads like "get all the fonts used on this web page" rather than "get me all the fonts installed on this computer".
Interesting idea. It might be possible to generate a snippet that will remove itself after the first initialization, but if that doesn't work at least a comment could be inserted.
> if i read it correctly `document.fonts` reads like "get all the fonts used on this web page" rather than "get me all the fonts installed on this computer".
Ok, I see. Another possibility would be to use https://developer.mozilla.org/en-US/docs/Web/API/FontFaceSet to check for the avaliablility fixed set of popular fonts.
The most difficult part for me was setting up a LSP with golang. I would say it was difficult because I was trying to rush through by copying random bits from everywhere to make it work.
I did eventually get it to work but then noticed I have no idea modify or tinker with anything without fear of bricking my setup.
So i started fresh and actually made a point to try to understand what each lisp snippet is used for and did my best to just get default packages without any extra flavor or config all while keeping track of it in git. Its been fun learning lisp.
But on pretty much every other system with a standard emacs install, yes, `C-h i` is all you need to get to the documentation.
He wouldn’t allow us to use normal Java data structures for assignments rather a lisp data structure called “cons”.
Not sure how different elisp and lisp is but syntax wise they look identical to me.
https://www.gnu.org/software/emacs/manual/html_node/elisp/Dy...
In practice, I've never been bitten by this except when I tried to do some fancier functional programming things in elisp that I normally would use another language for. And you can specify that you want lexical scope:
https://www.gnu.org/software/emacs/manual/html_node/elisp/Le...
The whole section those two come from: https://www.gnu.org/software/emacs/manual/html_node/elisp/Va...
https://www.cs.utexas.edu/users/novak/cs31436.html
this is the book i mentioned earlier if you’re interested. e.g. of building a linked list
I might go through some of it purely in lisp for the heck of it.
I've not used outline minor mode, but reading up on it, it seems it's merely for presentation vs editing. As an example, can I move a heading and its subtree to another part of the document? Doing so makes managing configs much easier.
> I have read dozens of supposedly literate configurations on the web, and most of them are just header, begin_src, code, end_src, repeat.
Most code I've read is crap. That doesn't mean one can't write code well. My own literate configuration is probably 80+% as you describe, but it's the remaining 10-20% where I do write some prose, with links, etc that make it worthwhile.
I agree that it is yet another level of complexity for beginners. My own personal experience, though, was it would be much harder to debug plain init.el files than the org ones.
In any case, I have no objection to using outline-minor-mode instead. I just think that many users are going to learn org mode sooner or later, and it's less cognitive load to just jump into org mode. I'm pretty sure most people who put their config in outline mode will eventually migrate it to org anyway :-) And I don't see any actual advantage to outline minor mode in general.
ill look into it
I'm not saying you should do this now. My recommendation is you learn the basics of org mode, and then look up how to do this.
Seems like majority of the time Ill be spending in emacs is configuring rather coding! :’)
After using it myself and viewing plenty of org-mode powered config files, I feel it's mostly good for people who publish their config files for others to read / learn. But for my own use it felt like just too much verbosity.
I'm more questioning the reaction to the project. The project suggests some ways that Customize could be improved, but the reaction doesn't seem to match that.
i was lucky enough to have had a shell account on the GNU gnu.ai.mit.edu servers back in the 90s and found elisp inspiration from poking around in the $HOMEs of GNU hackers/legends like roland mcgrath and noah friedman and of course rms. i nearly wrote a book back about emacs then with a uni lecturer but he resigned/was fired in some kind of scandal and well, that was that.
amazingly i still have that shell account, though its of course moved a few times and has been for a while a gnu.org box.
i learned a lot about bash and how to structure things properly from ~roland's init scripts.
hah! just ssh'd in to fencepost.gnu.org and all his init scripts are still there[1]!
https://github.com/SystemCrafters/rational-emacs is also a great starting point for new (and why not old) Emacs users who would like to start with at least somewhat preconfigured setup but thinks that doom emacs or spacemacs is a little too much.
According to the internet (I don't use emacs) it's supposed to be "inhibit-splash-screen t" - looks like a copypasta induced mistake is all.
You also have not enabled many of the modes that you install which will be a not fun experience for the newbies you are targeting.
Use-package could actually help a lot in your backend generation code I think (ie because consistent data model).
evil-collection would be a good add as well as quite a few evil quality of life items.
> Use-package could actually help a lot in your backend generation code I think (ie because consistent data model). Theoretically yes, but that would require some restructuring in the backend. It is a goal though, at least as an option next to no configuration macro and Setup.
> evil-collection would be a good add as well as quite a few evil quality of life items. Will look into this, I don't use Evil so it is hard for me to judge.
[0] https://www.gnu.org/software/emacs/manual/html_node/emacs/Ma...
> Org Mode can be used for anything from managing apartments, writing manuals, literate programs or executing code like a programming notebook.
Is that "apartments" or "appointments"? I suppose some people manage their apartments with org-mode, maybe via TODO lists and calc spreadsheets.
I thought I heard someone say "that sounds like a challenge!", but that was probably just my imagination.
I don't recommend first time emacs users start with Doom. Everybody should get their feet wet with plain vanilla emacs, with evil mode turned on if they are coming from vim.
Then after a while, they should try Doom. Just to get a sense of what it can do.
One thing's that seems to be missing is that option to disable those pesky backup~ files.
from the evil camp, it works be really useful if it also included an option to generate doom/spacemacs style mnemonic keybindings, as those are a central facet of why those like us start using them. i’d be interested in switching but for the enormous amount of effort it would take to add those! and if i were coming in as a newer user of emacs, having examples of how to create those kind of layered bindings would be hugely helpful.
With all due respect, that's rather condescending and an example of the kind of myopia that religious adherents of both emacs and vi get accused of. fundamentally both emacs' native keybindings and vi keybindings are methods of connecting keyboard events to elisp functions. That's the boring truth, and there's nothing inherently better about one versus the other. Pretending otherwise is just an attempt at gatekeeping.
mea culpa