On the other hand, the power of emacs comes from the fact that it's essentially a lisp interpreter which is good at doing text editor stuff. If you abstract this away then what you get is an editor which is implemented in emacs, but is ultimately comparable to any other text editor.
Emacs really shines when you make it your own. And that goes far beyond the usual "customisation" that you see. I have files full of macros that help me write lisp which eventually changes the way the editor works. And some of that functionality helps me write the macros that help me write lisp that (...and so on).
For those that don't use emacs the above might sound bizarre. Maybe it's only attractive to a few programmers. Or maybe you have to try it before you really understand. I don't know. But that's why I have mixed feelings.
However, ever since Sublime and now VS Code came about, I've been having this internal debate of whether I should just switch to a text editor that I can fix, but come configured sensibly OOTB, and let sunk time costs be. This used to be a tall order but VS Code seems to be really close to this ideal now.
My gut feeling is that people who haven't looked up from emacs or vi for a decade or two have no idea what modern IDEs are capable of out of the box.
I'm not sure what reason the emacs team has for just not adding MELPA but it would change the game for me if it were an official addition and would require it's addition to work out of the box. Till then, emacs is a long way away from being my default editor, and VS Code and JetBrains are more of my defaults.
Out of the box functionality is key for any editor in my opinion.
For me, my emacs config is my text editor, and it works out of the box on any system I install it to. Emacs is often very easy to install, but if I'm going to spend significant time on a machine I'll build it myself, and then my config is a simple git clone away and that's it. I'm working in an exact copy of my own personal text editor that I've built up over many years.
My instances of emacs also stay running for weeks at a time. I'll edit the config while it's running. If it's useful I'll commit it and pull it to other instances and run the modifications on them while they're running. It's a completely different way to work than most people are used to and it's liberating.
If this frontmacs grown in the proper direction to support a effortless mix of own and external settings, then it could become even more important than spacemacs for the community and growth of emacs.
Getting all of our tools into similar management forms ultimately makes all of coding more accessible.
I got into Linux with Mandrake. A year later I was running Slack.
Not everyone sticks with their first tool when starting out
Anyway, I am a simple man. I see people using Emacs and I become happy.
Judging from the comments we didn't do a very good job at messaging that while this is a starter pack, it's also meant for you to build on top of and customize. My config does not use the default theme and tweaks a couple of settings.
We intended frontmacs to be something _like_ prelude but make updating the core packages easier (rather than pulling in the changes from upstream & solving merge conflicts). We wanted nice defaults that you could then build on top of.
Does anyone know if you can actually write code on Emacs, like HTML/CSS/Javascript?
Do you mean modifying Emacs while it is running?
If you switch to the "* scratch * "[1] buffer and type one of these and after each of these either press «Ctrl-J» or «Alt-x eval-print-last-sexp»:
(message "Hello, World!")
(setq cursor-type 'hbar)
(setq cursor-type 'box)
(setq indicate-empty-lines t)
(setq show-trailing-whitespace t)
[1] I have no idea how to get a normal asterisk on HN.
Yes.
(awesome-mode t)
You might want to warn people that this enables auto-saving buffers on many buffer/frame events that are usually considered safe.
https://github.com/thefrontside/frontmacs/blob/master/frontm...
(defadvice switch-to-buffer (before save-buffer-now activate)
(when buffer-file-name (save-buffer)))
; the same defadvice is applied to:
; other-window
; windmove-{up,down,left,right}
(add-hook 'focus-out-hook
(lambda () (when buffer-file-name
(save-buffer))))
For your information, defadvice is deprecated[0]. Alternatives like advice-add can be used instead.
[0] https://www.gnu.org/software/emacs/manual/html_node/elisp/Po...
I wouldn't go back now that I'm used to it.
> Most of the planet doesn't treat editor configuration as software. We do.
This is so true! And it applies to many, many other types of configuration as well.
Awhile ago, we've used this code as data approach in a game development studio for everything. For example, maps/levels were stored as a Lua scripts that get executed on load and contain a sequence of PlaceObject, SetProperty, etc invocations.
It doesn't come without drawbacks, though. For example, Autodesk Maya stores scenes as Mel code (as a bunch of createNode, connectAttribute, setAttribute commands). This script gets executed on load in a single thread (utilizing a single from your N cores) and scene loading can take ~30 min on large scenes. Security is also an issue but it's fixable with proper environment sanitation and sandboxing.
Just because you treat data as code doesn't mean you have to force it into a Turing-complete language. It just means that you should document it, format it properly, put it into version control and deliver it for deployment.
Moreover, Turing-complete languages are more of an anti-pattern here. The proper design pattern here is the Rule of Least Power:
https://en.wikipedia.org/wiki/Rule_of_least_power
It means you should choose the least powerful language suitable for a given purpose.
And this is where DSLs or "data as code" can play its advantages: Not just makes it things shorter and simpler, but you can also force it into a less powerful language, which allows you to eradicate certain types of bugs and security issues by not making them even expressible anymore. Moreover, you can run your data structure through different "interpreters" doing different things with it, which is completely inpractical of your data structure describes a too powerful language.
I also find the description filled with buzzwords and buzz-phrases to the point where it becomes meaningless.
"after a while". Agree. I think they are called "starter kits" for a reason :).
> I also find the description filled with buzzwords and buzz-phrases to the point where it becomes meaningless.
I have looked into their config today. Nothing very amazing, but indeed a better default experience. It's much simpler (compared to Spacemacs) which I think is more beginner friendly.
The phrase "download more awesome" makes me very strongly doubt whether the authors are genuinely experienced with the difficulties of software engineering.
mkdir /tmp/.emacs.d
wget -P /tmp/.emacs.d https://raw.githubusercontent.com/thefrontside/frontmacs/master/scripts/init-frontmacs.el
echo '(load (expand-file-name "init-frontmacs.el" user-emacs-directory))' > /tmp/.emacs.d/init.el
env HOME=/tmp emacsA slight gripe I have with Frontmacs is everything is loaded eagerly on startup. I'd imagine this massively increases start up time given how heavy weight some of the packages are (yasnippet, magit, tide). I also find issues with it calling itself awesome without integrating with any emacs window management package.
Most config in emacs these days is just installing a couple of packages and toggling on and off a couple customizable variables, and occasionally a couple of `add-hook` calls. These are all low hanging fruits since packages became an official thing in Emacs. The most annoying and non-obvious part of Emacs is how it manages windows. To tame the totally insane default window management system, you pretty much have to shop for a layout manager of some sort, and in order to do that, you have to know what Emacs is doing under the hood. That's hard and I wish more of these Emacs distros would come integrated with some sane window management package.
I used to just rely on popwin and desktop mode mainly, and used golden-ratio and centered-window-mode for a while. Recently I've completely ripped them out of my config and replaced them with [purpose](https://github.com/bmag/emacs-purpose) and [perspective](https://github.com/nex3/perspective-el). I'm loving them so far, others seem to like e2wm, tile, rotate and others.
[1]: https://github.com/wyuenho/dotfiles/blob/master/.emacs [2]: https://github.com/wyuenho/dotfiles/blob/master/.emacs.d/cus...
But I also wanna be the cool kid, and not a part of the herd :'(