Interesting, but you know what might even be better? If it could be done directly from emacs.
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.
As there are currently no Javascript dependencies, it is possible to use the site using EWW: M-x eww https://emacs.amodernist.com/ RET.
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.
The customize interface built into Emacs already provides this. Though it supports customizing far more things, so it might be overwhelming. Maybe a new user customization group would be good.
> Interesting, but you know what might even be better? If it could be done directly from emacs.
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.
> First, Emacs should have sensible defaults like Ctrl-c for copying and Ctrl-v for pasting.
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.
> You'd be making it hard for someone who already knows Emacs to use it.
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.
Sadly emacs as a community is moving too glacially towards user friendliness for the sake of maintaining backwards compatibility. I don't see this trend changing any time soon, so fewer people every year will stick with it.
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.
> 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.
Emacs is more widely used today than ever before. There are more high quality packages being produced by the community today than I ever remember it being the case.
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.
And a single setting for someone to change now if they want cua-mode.
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.
Neat tool. I tried generating a config similar to mine, and it was surprisingly close, although it looks quite different without use-package. Did you not add use-package because it's not in the repositories you're using, or something else? Great choice adding Modus themes! I feel like making something similar just for hydras. A few mostly minor things I think could improve:
* 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.
Thanks for noticing the issues, I will fix the issues and add the other features.
> 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).
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.
I believe it to have had issues that lead to inconsistencies and unnecessary complications. More details can be read out of my comparison between the package I wrote and use-package: https://www.emacswiki.org/emacs/SetupEl#h5o-20.
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.
This looks like it solves a very real pain point for anyone getting started with Emacs, and likely many people who have been using Emacs for a long time sub-optimally. Could save hours or days of learning about how to configure Emacs.
Reminds me of a Spring Initializr, as a way to quickly get started with a new tech tool.
For me, configuration a tool or system is actually a likeable experience. It's almost a hobby to keep tinkering with my various configs.
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.
I think people will eventually do this. But giving them a sane, simple starting point is probably a good idea. (Though I awhile ago threw all mine out and went with basic Doom setup, but everyone's journey will be different)
I discovered this project recently via some random HN post, and I've been contemplating using it to start over with my very chaotic Emacs configuration.
bbatsov/prelude is great stuff! I've been using it since 2012 and the base system has only gotten better over the years (I've also customized it over time).
The Emacs built-in “Customize” tool is very close to that, and there’s also the built-in package manager. I guess this kind of generator could be implemented inside Emacs itself as a “starter package” instead of a web page, would be pretty cool.
Neat. I like the fact that it is opinionated providing a decent setup
to get things done.
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.
As you might have noticed, I am not a web developer, but I will try and look into resolvi g the issues you brought up. 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.
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.
As an alternative solution,
you can ask if the user would like to setup their font on start of
emacs and invoke `menu-set-font`. But i think this won't work for people
who want to run their emacs in console, another problem i see with this
solution is, it would prompt every time emacs starts, which would lead to more confusion.
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".
> As an alternative solution, you can ask if the user would like to setup their font on start of emacs and invoke `menu-set-font`. But i think this won't work for people who want to run their emacs in console, another problem i see with this solution is, it would prompt every time emacs starts, which would lead to more confusion.
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".
Very neat tool. Ive been getting more and more into using emacs. I like the options you provide like disabling the tool bar, line numbers etc. these are quality of life changes that probably everybody goes through.
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.
If you haven't yet I'd recommend going through the tutorial and looking at the elisp manual. Both are accessible if you press `C-h i` (there's a lot of other goodies in the list of manuals you get there, the calc one is great).
Except on Debian and Debian-derived systems. Apparently there's an issue with license compatibility, on those you may need to install this package: emacs-common-non-dfsg.
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.
Ill definitely give that a go. I feel like I NEED to learn Lisp. My college data structures prof had his own book where all the java examples had a lisp counterpart.
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.
If you know some Common Lisp, Emacs Lisp isn't hard to learn (and they're even closer than when I learned elisp 15-20 years ago). Some minor gotchas with literal syntax (literal arrays/vectors and chars are represented differently in each) and some differences in their standard libraries. A more major gotcha is elisp's dynamic scope, which comes up if you're used to lexical scope.
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:
I strongly recommend storing your config in an org file and using Babel to load the init. I find it the only way to preserve my sanity as my config grows.
Org provides a lot more features than an outline mode. Org-babel lets you mix code with prose, and execute (for many languages) the code in the code blocks. It works cleanly with the agenda/diary system. You can schedule items, marking both due and start dates and times. Tag items and query based on tags, it's a very handy thing.
I recognize the advantage of tags, but everything else seems superfluous for a personal configuration. For beginners it just one more thing that can go wrong. I have read dozens of supposedly literate configurations on the web, and most of them are just header, begin_src, code, end_src, repeat. There are rare exceptions, but these cannot be generated automatically.
> but everything else seems superfluous for a personal configuration.
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.
I actually switched back to a plain elisp config file instead of having an org file loaded by babel. After spending about a year with an org-mode powered config file I felt like the surrounding "prose" just distracted me. The very few lines of config that required some explanation were easily documented with one or two lines of comments in elisp.
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.
The surrounding prose are distdacting, byt surrounding code is even more distracting. Org-mode allows simply folding away stuff not under focus, and it helps a lot with ADHD.
Yes. The idea is you store your init as code blocks in an org file, and you can organize your config into common headings (e.g. all C++ related config goes into the C++ heading, which itself goes under the Programming heading). The other benefit is that you can write prose around the code blocks describing what you're trying to do here (you can do that with comments, but org markup is much richer).
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.
Not all of these (like the packages) fall out of emacs' built-in customize. Though they aren't far (package-list-packages, find them). Also you need to know that these options are even there (customize-apropos is good, but it's not hard to get stuck finding the right keyword to get to the option or option group you want).
The intended audience are people who haven't yet got into Emacs, and are therefore not familiar with Elisp, the packages and the options. Of course if you have a basic understanding of Emacs and an overview of the package space (and perhaps the time + motivation), you don't need anything like this.
I wouldn't say so, customize is a useful interface to get an overview of all the options a package or feature might provide, but without any order or structure beyond the group hierarchy.
I don't know what's the basis for denying it, but the parent is correct about the intention when it was developed. I don't understand why it should be thought to imply Lisp knowledge. It is useful to lay out the customization possibilities, but that's a bonus.
Ok, I might have misread the comment. But to clarify my own position, I it doesn't necessarily have to be the lack of Experience with Elisp, but with the way you use Emacs and how it behaves (managing buffers and windows, how scrolling works, the little differences in how GUI features behave, etc.). To make use of the easy customization interface, and not get frustrated by it, it help to have some basic experience with Emacs. My intention is to provide a guided tour of what someone might want to have in Emacs, before they begin using it. That way they can get common annoyances out of the way before starting, and have less friction when dealing with whatever remains.
Again, not questioning your goals/intentions at all.
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]!
For rust, it might be nice to add the option to use either rust-mode (basic) or rustic-mode (more fully featured, depends on rust-mode). Rustic-mode is mentioned as the go to option for more features even in the rust-mode readme.
Cool tool! Would be interesting to integrate it straight to Emacs itself. But I think it is cool to be able to copy and paste it to one's own init.el
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.
> 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.
That is unintentional, I will review the packages I have missed.
> 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.
Quick question; I was a little confused by the fact that after asking for LSP support, and answering affirmatively, I went through a list of programming language modes to install. Shouldn't the LSP be handling that? Or what am I missing? I don't have much experience with LSP--it's something I've been wanting to get to trying out, but haven't yet.
The short answer is that LSP doesn't mean universal LSP. You still need to pick and choose which LSP servers you want to install, because they are language specific. There are dozens of them and there is no point to downloading a C++ LSP if you work in Typescript.
That and LSP just provides the intelligence for Emacs. The rest (syntax highlighting, navigation, ...) is implemented via so called "major modes" [0], that integrate various generic functionality for a specific language, and may often go beyond what LSP can provide, e.g. implementing REPL support.
I cannot comment on the differences, all I can say that I chose Eglot because it is more in line with my understanding of an ideomatic Emacs package, and it is available via GNU ELPA.
I’m a VSCode user interested in exploring eMacs as a Python IDE: does anyone have any recommendations for things I would need beyond a basic config? I am a frequent user of the debugger over remote connections so the more seamlessly I can use eMacs in a similar way the more likely I can use it instead of VSCode.
This is really cool. I'd recommend it for people who are into customization but want a solid foundation to start. For people who are looking for a more batteries included experience I'd recommend Doom Emacs.
I can see that distinction. I think this might get me to poke at Emacs again because the starter kits I've tried feel like they just include too many damn batteries. :)
I like it. I installed Doom Emacs a few weeks back but had to give it up. I personally don’t like to bring in a huge config set in the beginning. I like this idea and will try to give it a spin.
The worst thing about emacs is there is no good newbie init.el that has no more than 10 packages to fix the very common starter pain points.
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.
Yes and I would say that is the same for any bigger editor or configurable piece of software. I just tried doom cause the last time I tried emacs it didn’t klick either so I tried it from the other side. I will give it another go because I have issues with VSCode which I use for semi big projects at the moment.
Good point. I will add backup file configuration. Tough disabling them all together is rarely worth it, moving them to some other directory is usually preferable.
this is definitely a useful tool, thank you for putting the work into it!
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.
I have no experience with Evil or that entire space. I would be interested to look into how the situation can be improved, but then again, I do believe that evil-mode is fundamentally just an emulation layer, and shouldn't be regarded as an equal to the regular keybindings.
> I do believe that evil-mode is fundamentally just an emulation layer, and shouldn't be regarded as an equal to the regular keybindings.
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.
I understand your point, but I am not convinced. Nit because I belive in some inherent superiority of some or another set of keybindings, but rather because on the one hand evil isn't a perfect emulation (any somewhat experienced Vim user can always name me a few faults), and on the other the very need for evil-collections to bridge the gap between Emacsy conventions that packages conventionally use and Vims keys (e.g. Dired becomes practically useless if it were to overwritten by Evil keys).
ok, i think i went off half cocked here and read more into your earlier post than i should have. it sounds like you take issue with a particular implementation rather than the core concept, which is of course reasonable.
Could you elaborate on what you mean? The intention is not to have a finished configuration that requires no more work, but to provide a template on which further customizations can be made.
This is certainly a prototype, there is a lot that can be added (both option and UI-wise). If you could find the time to report the issues you found (either here or per mail), I would be glad to try and fix them.
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.