I have mixed feelings about emacs starter kits. On the one hand I'm always happy that more people might discover emacs. It's quite simply the most powerful text editor out there. Hands down. I could not imagine using a computer seriously without emacs.
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.
I've been using emacs for over a decade now and I have yet to reach this state of nirvana. I do want to understand every line of elisp and I've been doing a lot of elisp recently. But then again, I also have work to do, and I realize all I've been trying to achieve with my emacs config in the past 10 years is to make it work like a modern IDE. Which is perfect, because the reason I switched to Emacs in the first place is I just needed an IDE that I could fix.
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 use visual studio in my day-to-day job for .net and C# work. I know what it’s capable and it’s a very impressive piece of technology.
What it doesn’t do is allow me to shape it to fit my workflow. I always have to adapt to fit the tool as opposed to the other way around, and any level of customization and extensibility feels extremely shallow compared to Emacs.
With Emacs I get everything my way. And I don’t think that can be said about any other tool I know of.
Needless to say I use both editors side by side and use whatever tool is best for the job at the time.
Edit: IMO standardized technologies like LSP is now bridging the gap for many (but obviously not all) IDE features. I suspect the imminent death of the “plain editor” is vastly exxagerated :)
...and that's where Emacs starter kits come into the picture. Especially when compared to VS, Emacs based solutions always seem superior to me because they don't require me to use the mouse for every. little. effing. thing. I want to achieve.
That, and they are usually much more designed around a more UNIX-focused toolset than most IDEs, which means less interdependent blobs of cruft like Intellisense and the like.
Well, I think I should make it clear that I'm very well aware of what modern IDEs can do, and I think most Emacsens do too. In fact, their killer features haven't really changed much since the late 90s / early 00s.
What I never liked in IDEs is their features come with a huge cost. Their integrated features are great, but their implementations are so complex and opaque, when they inevitably go wrong, I can't just dive into a plugin and fix it myself. Emacs packages still goes wrong, but at least fixing them is a much easier affair. It is this reason, and that Emacs generally just come out with functioning packages for new concepts and ideas way faster than any other IDEs, I've vowed to avoid IDEs written in compiled languages like the plaque.
What I really mean is, I'd love to replicate IDE features on a text editor, but without the pain. Elisp is just a horribly outdated language and runtime environment to be honest. Everything is global, OOTB most of the modern FP constructs is non-existent in this FPL, dependency management is a mess, it's single threaded, it's a terminal app pretending to be a GUI etc, and oh god, don't even get me started with the default window management mechanism. I don't understand why so many people keep romantizing it.
What language is "Scandinavian"? Also, perhaps the intention was that "Emacsen" was the literal name of a version of the emacs family of editors, of which GNU Emacs is only one (XEmacs, for example, being another one).
I can relate to this. The problem is I already know how to get my work done (efficiently) in Emacs and find any change of my everyday tools to be daunting. Any advices on how to experience "what modern IDEs are capable of out of the box" without major pain?
I've found one of the best ways to experiment with other text editors is to use them for one specific type of task or type of file. So when I started using vim I only used it edit config files. Makes it easier to lock into the mental mode of using a particular editor.
This is a very good piece of advice! I do have to configure my emacs every time I take on a new type of task albeit not very often. I'll give it try next time. Thanks!
I don't think I've seen a modern IDE that doesn't either have vi/emacs keybindings included or has a rich enough ecosystem for someone else to do so. I'm someone that cut my teeth in Linux, on many distros that never had pico/nano installed but to this day I still have to lookup basic references just to get anything changed on those systems. If I have the access, I immediately install nano because I can handle those keybindings a little easier.
I feel like Atom or Visual Studio Code are good pseudo IDEs but a lot of people hate the Electron tax. I spend most of my day in PHPStorm (ugh php) but I have both Atom and VSC installed primarily to understand the life in between a seemingly more 'dedicated' IDE like PHPStorm over this in between both editors seem to fill. They're primarily editors with IDE layers on top and for the price of $0 it's a good place to cut your teeth if you can stomach the tax. The JetBrains IDEs do have generous evaluation periods but I don't think you would be in an extremely comfortable place at the end. It took me a little more than 30 days to become as intimately familiar as I am now but like the bigger Visual Studio at my last gig, there's parts of PHPStorm I just don't touch and maybe never will.
This is probably not the best answer but there really isn't a one-size-fits-all kind of transition either. I think the most rudimentary concept that sold me on a proper IDE over an editor was syntax checking. Editors like emacs or vi may have better support for that than Coda or Notepad++ but knowing the script won't compile immediately vs deploying broken code and finding it there has more than paid for the difference. The most powerful feature of PHPStorm for me is setting breakpoints and having the Xdebug integration give me a peek at everything visually. There are still cases where I debug with echo/var_dump statements but if I can attach the debugger, I can do so much more. The likely biggest draw for a JetBrains product is the refactoring capabilities. Again, some editors likely do refactorings really well but when my refactoring in Notepad++ involved just find/replace it really isn't comparable in the slightest.
I think at the end of the day productivity gains through workflow changes are something I'm constantly looking to adjust. Even though I'm very happy with PHPStorm, I have VSCode and Atom primarily as a means to reevaluate my understanding on an ongoing basis. I realize for a lot of people "if it ain't broke, don't fix it" is perfectly acceptable though and if you feel really productive, chances are you are.
> I think the most rudimentary concept that sold me on a proper IDE over an editor was syntax checking. Editors like emacs or vi may have better support for that than Coda or Notepad++ but knowing the script won't compile immediately vs deploying broken code and finding it there has more than paid for the difference. The most powerful feature of PHPStorm for me is setting breakpoints and having the Xdebug integration give me a peek at everything visually.
Emacs has had mechanism (flymake) to call out to a background process to lint code for decades now. Recently (as in since 2012), there's a new package called flycheck that reimplements flymake's functionality. Since then process-based linters have exploded. At least in JS and Python, you can do syntax check and possibly fix your code exactly the same way as most IDEs. Better yet, these linters update so fast, you generally get much better linting on Emacs/VI than IDEs. Updating these linters is just one command line call away, whereas in IDEs, you typically have to wait for months because they are embedded. The speed of improvements is just so much faster in simple text editors. The problem with Emacs and VI are not linting, but something so much more basic such as keybindings and window management.
> 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.
Do you have some examples of things I might not be aware of?
My problem is I consider vim to be the best text editor ever created. That is, when it comes to manipulating text, there is no equal. But it's a lousy (even terrible) "IDE". Between editing text and other dev related tasks (searching, diffing, autocomplete, etc), text editing is slightly more important to me, so I use vim. Using another editor/IDE with a vim emulator doesn't cut it. I've never found one that matches real vim. Neovim could eventually allow me to have my cake and eat it too though.
I quite like the Jetbrains vim emulation (Ideavim). It has a few quirks I run into every once in a while, but I find the combination of Jetbrains + Ideavim worlds better than my highly customized vim install when coding on a non-trivial project.
However, if all I need is a text editor, such as when hacking out a script or two or doing actual writing, then it's terminal vim all day long.
I actually wonder why there aren't more IDEs that just embed vim as their text editor. Ironically, the only one that can do something like that is emacs.
Part of that problem is that a really good IDE isn't editing text: it's editing code. One may retort "but code is stored in text files," and yes, that happens to be the primary serialization format but while it's in RAM the editor is making changes to the AST (for example)[1] and the MPS project[2] even strives to do away with "text file" façade entirely, allowing you to edit the parts that are truly editable, and just graphically render the syntatic sugar for everything else.
That distinction is relevant to the question because merely embedding vim would be problematic since the common language spoken between the IDE's mental model and vim's mental model is text, but I couldn't imagine the pain that would be involved in trying to send down the keystrokes required to update all occurrences of a variable, for example.
IntelliJ does have emacs bindings, and does have a vim plugin, but I've watched people use both of them and they suffer from the uncanny valley effect. Not to mention the fact that, and I can't stress this enough, entering character level keyboard shortcuts to change an AST is optimizing the wrong problem.
that can do something like that is emacs
I've actually spent many, many hours thinking about that very issue, and I am 100% convinced in my soul that a sufficiently determined person could in fact make Emacs as smart as IntelliJ. But the problem isn't making it that smart, it's keeping it up to date with the new bugfixes and rules. It might be possible (heh, or even preferable!) to write the AST manipulation and inspection rules using (e)lisp, but given how many developers know Java versus how many know lisps, I doubt a commercial company would bet the farm on such a thing.
I actually got half way through writing up a substantiating argument that JetBrains could benefit from AST manipulation and inspection written in a lisp-flavor, which would benefit both camps. But I actually don't know of a lisp with static typing, and reasonable people can differ about whether such a thing has merits, but for the purposes of this discussion, I bet trying to wire a dynamically typed language into a statically typed codebase would make everyone unhappy
I use Spacemacs but it isn't always perfect and if Spacemacs doesn't wind up working I end up just using vanilla emacs because MELPA is a dice roll whether it will work or not every single time for me, usually regardless of OS. I just know enough basics of emacs to edit code, but I wish adding packages didn't involve so many hoops such as having to add a repository that everyone already goes out of their way to add to emacs and having said repository fail on you.
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.
I put melpa in my init file and never thought about it again. You don't need to keep adding it every time.
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.
I know what you mean. I started emacs spacemacs, be cause for me it was the better vim. But with time I got fed up with the bloat of spacemacs and so many details which I can't controll for my personal ways. Now I roll my own fork of spacemacs, tweak it the way I want and still have some external help with the occasional merge from spacemacs-repo.
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.
I had similar feelings, but I've actually been using (an admittedly, somwhat tweaked version of) Batsov's Prelude for a couple of years now. It pulls in a lot of exceptional packages with sensible defaults (without trying to make it stop being Emacs, a common fault of such kits) and has very good facilities for customization and managing things like package loading order.
They treated the whole frontmacs as a package and put it on https://elpa.frontside.io/ , I don't know whether it's good idea. Actually I proposaled the same concept for spacema\
cs, doesn't got approved back then. So this is not a starter kit I guess?
Emacs is a programming language with it's own text editor built in. Like every other programming language on the planet, it benefits from dependency management and source code management.
Getting all of our tools into similar management forms ultimately makes all of coding more accessible.
elisp ist the programming language. Emacs is an environment with text-oriented interface. Pretty much like modern browsers, just more mature. One could even say, Emacs is the spiritual ancestor of the electron-framework.
I disagree. I've tried to use Electron editors (VS Code, Atom) and the thing that frustrated me the most is that it is missing the "essence" of Emacs. To me, these things are:
* Self-documenting
* Easy to dynamically inspect and change the editor internals and all packages, from the editor itself
* Emphasis on the editor as an interface into your system (the editor as a way to process and "glue" together text from subprocesses)
Atom in particular seems promising, but from the time that I spent with it, I quickly concluded that it was missing the spirit of Emacs entirely, because it was not straightforward or well-documented how I would go about exploring and changing the internals of the editor and its packages. E.g. a package was throwing an exception...it was quite a process to find the source, set a breakpoint on that error, and fix/work around the bug. That's trivial stuff in Emacs, and IMO is at the spiritual core of Emacs.
I would love to be wrong here, so please correct me if I'm mistaken!
WRT to self-documenting. VS Code and Atom aren't self-documenting like Emacs might have something to do with the language itself. There's just no equivalent of ELISP's powerful introspection mechanism that allows you to fish out the docstring in one simple function call. However, Python does, and it's not even a function call, it's just a property access. Have you tried Sublime?
I assume that is a difference in cultur not ability. But lack of introspection and prototyping is a surprise. After all at the end it's just a browser, which have good tools for such things. Maybe it's just not mature enough for this at the moment.
I'm at the point in my emacs journey where I'm looking for places in my day-to-day editing that can be made more efficient by writing code that writes that code. I have implemented some helpful macros, but I think I would benefit a lot from reading macros written by a more experienced emacs programmer.
I guess I see it as a Spacemacs user or Frontmacs user decided that was the way to make Emacs “their own”, less in an emotional sense and more of a utilitarian “this will do the job nicely for me”.
I got into Linux with Mandrake. A year later I was running Slack.
Not everyone sticks with their first tool when starting out
(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}
Also, maybe this should only happen to buffers that are already backed up in the VCS? Saving unknown changes back to the original file whenever the frame looses focus - which can happen due to external, unpredictable events - seems like an accident waiting to happen.
As a general fileditor, it may be scary, yes. But I have this in IntelliJ and love it. Saving is just a useless keystroke for most of my development time. Things are in VCS, and if not, I can also use local history to roll back.
I don’t agree. I used IntelliJ for work for the past two years and I’ve never had any problems with auto saving (in fact, I find it quite convenient, although muscle memory means I still do :w with my vim bindings) and I’ve never seen ever used the local history feature.
Prelude does this too (I'm guessing that's what inspired them), and I've gotten very used to it. Since emacs maintains a pretty deep edit history, it hasn't caused me issues. But it probably is worth mentioning.
I will (almost certainly) never switch from my current configuration to use any of these all-in-one package bundles, but I do like looking through them for ideas.
I had a configuration that I was nursing along for several years, but after seeing Prelude [0] I realized that it would be much simpler for me to let the community to most of the work for me. Now I have a consistent environment for most languages and I am able to make small tweaks on top.
Yeah, me too. I also love watching people use emacs. There's always something neat that I haven't seen before. Unfortunately that is a very rare pleasure for me. I've only seen emacs in the wild a few times and mostly they were old professors using it with the standard configuration.
Hi forvelin! I'm one of the devs that helped create frontmacs. This is a great idea and something I generally like doing. I do it on my own emacs config: https://github.com/Robdel12/.emacs.d
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.
Agree! I am not a developer or an overly technical person and I recently started using Emacs because of an article here (using ido and org mode). I like it but I'm not fluent enough, or know enough of what it does to switch to it for everyday tasks - but there's a beauty in navigating file systems, creating files, switching windows all with your keyboard.
Does anyone know if you can actually write code on Emacs, like HTML/CSS/Javascript?
Actually this link is all about write front code in Emacs, that's why it's named `frontmacs` I guess. Yeah, currently I am write frontend code inside emacs. Nothing special. I just used few major modes. js2-mode/web-mode/css(sass)-mode, there is typescript mode. Only for syntax highlighting. I don't use auto-complete thing.
If you mean using emacs as your code editor then yes, that's the main purpose of emacs for most users. However there's other hidden eastereggs such as M-x pong, M-x tetris or why not try M-x doctor if you're feeling a bit down.
Yeah. M-x doctor is really helpful, especially when you are depressed. For example, if you say the doctor that "I'm going to suicide", it will guide you the right way.
Reminds me of the evolution of Lua https://www.lua.org/history.html from a configuration language to a full blown programming language.
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.
This is an interesting aspect, but slightly different from what I had in mind.
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:
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.
Then again, while Emacs Lisp is based on Lisp, it's not really the best lisp. Some could say it's not even good, because of how old and crafty and lacking in features it is/was. But thing is, it slowly evolves, and maybe in a decade or two it closed the gap.
What numbers do you require? If there was a metric measuring simplicity then Lisp (or perhaps a modern variant, Scheme) would probably win - it is a local optimum of language design, essentially just lambda calculus exposed via a very simple grammar (which aids meta-programming).
Such studies are very hard to do, it is almost impossible to factor out social preferences.
For me personally, I am most productive in languages like Haskell and OCaml.
I also seem to recall a paper from the 90s or early 2000s which compared speed of development & program execution between Lisp & other languages. Maybe it was somewhere on Ron Garrett's site? IIRC, Lisp programs were developed consistently more quickly than C/C++/Java/SmallTalk, and were normally faster than all but the very fastest C/C++ programs — but I could misremember. I remember that it had some interesting-looking charts.
What programming languages do you use? What numbers made you choose those ones? Maybe if you show me an example of some numbers I could help more.
I don't have the time to write up why I think Lisp is great, but you can find essays by many greater (and more famous) programmers than me such as Richard Stallman, Peter Norvig, Steve Yegge, Paul Graham et al. But really the only way is to learn it for yourself. There is a kind of enlightenment that comes with learning Lisp and I would recommend it to every programmer.
I think what they mean is it's fully set up, so that if you've never used Emacs and you start using it, you won't encounter the situation where something stinks and your friend who's an experienced Emacs user says "oh, you need to customize such and such." So, "awesome by default" rather than "awesome after many hours of learning about and applying configuration changes." (I have no idea whether what they've done would meet that criterion for a large number of potential users.)
This is very similar to what I have configured in my .emacs[1] and custom.el[2]. I like that this project is minimalist. If I were to start using emacs 2 years ago, I'd probably start with this.
A 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.
After years of using other people's configs, I found that they never really fit my way of working completely and they're filled with things I don't understand and/or don't use. I think most people will want to use their own configs after a while, and that's one of emacs's greatest strengths. Nowadays we have multiple package repositories and multiple ways of configuring it to suit your tastes.
I also find the description filled with buzzwords and buzz-phrases to the point where it becomes meaningless.
> I think most people will want to use their own configs after a while
"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.
> We don't want to maintain code, we just want to enter a few keystrokes and download more awesome.
The phrase "download more awesome" makes me very strongly doubt whether the authors are genuinely experienced with the difficulties of software engineering.
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.