You can do practically anything to text or other objects. If you can think of it, I'm pretty sure that Emacs can accomplish that for you. Any transform, file action, font changes, etc etc.

Example, this auto-saves a given file. In this case, whenever I archive an org-mode subtree, the archive file is auto-saved:

  435   │   ;; The `save-some-buffers` function can run silently, and it also accepts a
  436   │   ;; function argument to predicate whether a buffer is saved or not.
  437   │   ;; This predicate simply says "save the buffer's file if it's the notes archive
  438   │   ;; file"
  439   │   (defun redacted/save-notes-archive-file ()
  440   │     (interactive)
  441   │     (save-some-buffers 'no-confirm (lambda ()
  442   │                                    (equal buffer-file-name
  443   │                                           (expand-file-name redacted/notes-archive-file)))))
  444   │ 
  445   │   ;; Finally, the newly-defined function can advise the archive function. So,
  446   │   ;; after a subtree in org is archived, the archive file will be automatically saved.
  447   │   (advice-add 'org-archive-subtree :after #'redacted/save-notes-archive-file)

After I learned enough Common Lisp to build a few small projects, I realized how powerful it is to write small, bespoke functions for odd text editing jobs. You can write and save functions that do something very specific but powerful to any project you're working on, regardless of the language or tooling used, because everything uses text. I'm so glad I learned it.

[0]: https://news.ycombinator.com/item?id=29256103

But the way that I actually got competent enough to do anything interesting with it was to learn Common Lisp, because they are similar in that learning to solve problems in Common Lisp lets you do the same in Elisp. I learned Common Lisp by reading Practical Common Lisp by Peter Seibel and writing small programs.

I would really recommend spending a little time learning both dialects because it's easy to learn "just enough" elisp to configure your setup but not enough to appreciate what you can do with it.

  > I made a big push to switch from vim to spacemacs so that I could use
  > org-mode for note taking and reduce my dependence on paper notebooks

If anybody is looking for a good notes platform, seriously, learn org-mode. I only wish that I started earlier.

Signed, a two-decades VIM user.

it was spc-g-g for me on spacemacs but i am not sure what they moved to in spacemacs. on doom it is that.

How crude are you willing to go? Check out M-x artist-mode, which comes with emacs. https://www.emacswiki.org/emacs/ArtistMode

(this is mostly a joke, I don't think anyone uses that)

You are right: Bit by bit you write tiny macros that do things you need or want. After 1/2/5/10/30 years, your personal macros compound to create real efficiency. I don't use Emacs today, but I do appreciate that the ecosystem is enormous and well-developed.

That said, to emacs' credit, it makes (1) extraordinarily easy. C-h k to see which function is being called by a given key-combination and C-h f to get to the source of that function makes it very easy to look at the internals of the editor and figure what I should setq in order to make the editor behave in the way I want.

  > Learning Lisp is on my "bucket list", I know where to go to learn it but I need the time :) 

For Emacs Lisp: I just looked at the info pages for emacs. There are some books, never touched them so can't comment. But if you know CL, Emacs Lisp is not a stretch to learn as it's about 90% the same (especially since they made some changes in the past decade or so to better support lexical scope by default).

For Scheme: Check out The Little Schemer and the rest of that book series. Unique presentation style, but very approachable if you get past it (some people don't, I liked them).

I am a big fan of the little family of books by Friedman et al.

  - Little schemer

  - Seasoned schemer

There is also Practical common lisp which and land of lisp which are usually recommended by people.

Hope that helps somewhat.

It looks like it's been kept up to date and you could do worse than starting there, especially in an Emacs context.

Here is the online version in case you don't know how to navigate info manuals yet:

https://www.gnu.org/software/emacs/manual/eintr.html

+ Org-mode + SLIME (Common Lisp IDE) + A Lisp as "extension" language (it isn't really extension---Emacs is fundamentally reprogrammable). + Really smooth integration of LaTeX, Dot and Tikz. + Rock, rock, rock solid no matter what I through at it.

Also, I find that for me, Emacs has ergonomically good key-bindings once I accepted that they are different, learned them properly and did the CAPS-Ctrl switch.

The main reason why I don't like Emacs is that it feels very fragile to me. The first time I tried to use Emacs seriously - granted, that was many years ago and probably things have improved - I wanted to change the font because it was using an old X11 pixel font. So I went to the settings, and accidentially deleted the combobox that allows you to choose the font. I tried to configure it with the command line or REPL or what it is called and managed to mess it up even further. Later, as I got more familiar, I regularly managed to get it into a state that required restarting. It seems in Emacs, everything is a mode and everything is an editor, and there is no separation between content and UI (except for things like the menu bar, which uses a different toolkit and is bolted on). I've learned to appriciate less configurable editors because there is less to screw up, and you have the same good experience on any PC without your special config.

But I don't think that the Emacs learning curve should be exaggerated, either. If you start it up and follow the instructions, you very quickly become productive. What gets people into trouble is usually when they expect Emacs to be like software X which they already know, so they don't read what's on the screen and kind of skip the introduction. And then they get frustrated when they find out that Emacs is Emacs. I'm not saying that's you, or that it is stupid, impatient etc. or whatever. I'm just saying that I've seen it quite a few times.

There's nothing you can say to make me believe that.

Emacs is fragile. Any change, even the most simple change, to one's .emacs file can cause unexpected behavior. From fonts, to shell changes, etc. I have really wanted to like Emacs and get into it, but it's fragile from the very start.

> What gets people into trouble is usually when they expect Emacs to be like software X

This is the problem with Emacs. By default and by itself, it's nothing more than a glorified text editor. You have to update and configure it to get things to work as they should, but that's where the fragility comes in.

I've gone through this multiple times. Every time I try Emacs for some new language, I end up in configuration hell. The moment I switch to VSCode, while not perfect things just work, and I get to coding. Maybe I'll eventually bunker down in a hole and get Emacs to work as I'd expect, but that has not been accomplishable yet.

And I generally actually prefer using dedicated IDEs for languages. Otherwise, you're reliant on someone having implemented a usable Emacs mode.

In Emacs you have control over absolutely everything so, of course, you can mess it up. The solution however is very simple, trivial even: just version your entire Emacs config in Git. Screw up something? Checkout the last known working version. There are people even going as far as versioning their entire user directory under Git (not just Emacs but everthing). At the OS level there are people using NixOS: where everything is reproducible.

You make it sound like it's not possible to have a deterministic system. It's not just possible: it's very easy (any dev should know how to use Git to revert back to a working Emacs config).

> And I generally actually prefer using dedicated IDEs for languages.

Then try the JetBrains tools. It's leaps and bounds above anything MS has to offer.

That's not necessarily a feature in my opinion, and I don't like the framing that's it's me messing things up and not Emacs or packages. Look, Emacs is super powerful, but people always respond to things being difficult in Emacs with something along the lines of "just do this and then you get rainbows and the pot of gold". In reality, you're spending hours reading documentation and random forum posts on how to do the simple thing you want. Next thing you know you're having to basically write your own features into Emacs.

The thing I balk at is people acting like Emacs is just some under appreciated tool that just has a learning curve. No, it has a learning curve plus the difficulty of understanding its ad hoc design and the multitudes of packages, the way they're written and interact with Emacs, and the millions of ways various people like to do things. I just wish people were more honest regarding its complexity and the vast multitudes of ways that people use it in very individualized manners.

And yes, I have previously managed my .emacs file in GitHub. Not sure why you commented on a bunch of that. It's still not as easy as VSCode automatically syncing via my GitHub account or working automatically through SSH.

> Then try the JetBrains tools. It's leaps and bounds above anything MS has to offer.

That's actually what I was referring to. I use Dr. Racket for Racket, Visual Studio for F#, VSCode right now for Elixir, but I've considered trying out the Jetbrains stuff for Elixir, and if I was using Clojure, I'd definitely use IntelliJ with Cursive.

And all installed packages.

> You make it sound like it's not possible to have a deterministic system. It's not just possible: it's very easy

If you never update a package or install a new one. The more packages you have installed and use and the more (major and minor) modes you use (simultaneously), the higher the possibility.

Correct. As an undergraduate in the 90s when OOP got in vogue, I puzzled at the bureacratic notion of data hiding and private variables. Emacs set me straight on why those things are important.

Looking through my .emacs I really can't think of anything that would cause the chaotic behavior you describe. And the only revert I see in the last 10 years of git history is a key binding change that I decided I didn't like after all.

The only way I can see this happening is if you copy and paste random stuff from the internet without understanding it. But then what else could you expect.

Emacs is like dating a redhead. You're right: it is more fragile. It takes effort and dedication to figure out what you can do with it (more than you initially thought) and how to not upset it (more easily than you initially thought). But like the redhead, it's worth the effort.

That's the definition of fragile.

The famous "You're holding it wrong", even sounds benign compared to "it's just a learning experience".

With your reasoning, all software that gives you a choice, anything that can be configured, all programming languages etc. etc., become fragile, because as soon as someone says "I did this but I didn't like the result," your case has been proved. In other words, it is a circular definition.

Anyway, I didn't mean learning experience in a condescending way. The user I answered indicated himself that he was learning---and we all are, when it comes to Emacs.

You sound like a zealot for thinking a settings menu breaking when trying to change a setting is acceptable.

I think people are just kidding themselves when they arrive at the conclusion that a program like Emacs---which is super mature, has a huge user base amongst very picky programmers and has survived in fierce competition for 45 years---is somehow fundamentally flawed, fragile etc. Of course it isn't. But it might not be your thing, and that's fine.

You see every few years a project to modernize emacs and get wider mindshare among developer community, and they always fail due to some stubborn choices due to stalwarts not admitting when they are wrong.

I have more faith in VSCode sticking around for the next 10 years than I do Emacs.

I mean, almost everyone is confident about that too. And rightfully so because, VSCode actually has real corporate backing. People are being actually paid to develop it and sometimes plugins for it, so it would be a surprise if it didn't pan out. Nobody is getting paid to work on Emacs, or third party elisp libraries. It has always been individual hackers doing the bits that interests them. I don't want to come across like anybody owes Emacs anything. But I think in forums people sometimes take the reverse for granted, like Emacs owes anyone anything. Or that the people who actually bother to do voluntary work share the same vision of modernity as them, so it's a failure of some sort when that isn't exactly delivered.

> You see every few years a project to modernize emacs and get wider mindshare among developer community, and they always fail due to some stubborn choices due to stalwarts not admitting when they are wrong.

I think this is a mischaracterisation. Because, firstly you don't actually need the approval of the "stalwarts" to modernise it. Doom Emacs is making a name of its own just fine. The other thing is, Emacs is old. Most of the old vanguards aren't actively involved in Emacs development any more. Most of the "stalwarts" now weren't even around for most of the mistakes, why would you attribute things to vanity when it was not current stalwarts personally who were responsible for most of the design goals?

Browsing emacs-devel, it's clear that the real problem is acute lack of manpower. Only a fraction of Emacs users do bug reports, and then only a tiny fraction of them do actually get involved in fixing things. Which means the maintainers are always facing an uphill battle, who by the way don't have domain expertise or historical understanding of why things are the way they are, any more than you or I do, in many of the situations. Compared to that, VSCode is only a few years old, there are probably engineers who are familiar with the entire codebase, from conception to now.

That said, it has always been more or less like this. Emacs will be fine in its own way, because it will always attract certain sort of hackers. So sure, in terms of "mindshare" and "percentage of users", Emacs will keep free falling, specially now that software development itself has become way more pervasive. It might continue to get more out of touch with "modernity". However, as someone who has been in Emacs community for 7 years now, I believe the ecosystem is only getting more and more vibrant each year than the one before, in absolute terms (more mailing list or other forum activities, more landmark features, more new and high quality third party libraries etc.).

I don't even know how that makes any logical sense. The maintainers aren't what they are by virtue of nepotism. Rather they are only one who shows up, voluntarily. That doesn't mean they owe anyone shit, nor does it mean they are preventing others like you to show up and do what needs to be done. So no, if there is anyone who can "revive" Emacs' fortunes, it's people like you, that is if they bother to show up instead of complaining which is always easy.

I also don't get your obsession with "name". XEmacs was a fork, and for a while it was wildly popular. So if you have fundamental difference with emacs-devel, then go fork it? If your fork becomes worthy and solves many people's problems, then all linux distributions will package yours too.

The entire Guile Emacs thing was a product of a GSoC project, the moment it ended so did the project. None volunteered to take up the mantle, even though to this day people lament in forums about how it never became a thing. Turns out that solutions don't magically manifest without people putting the work, what a surprise. But I suppose this is to be expected, when people become too spoiled by other people's labour.

If you believe that there is a fundamental flaw in the GNU Emacs maintainership and you cannot join them to influence it yourself and you care enough, fork it. Build your own community. Give it its own name (Valmer Emacs, vemacs for short) and get on with it.

It's not that emacs users "live in another world entirely", it's that some things a very difficult to explain to folks who don't have first-hand experience of those things. Try describing what minus 20 degrees Celsius feels like to someone who's spent their entire life in Florida, or Brazil. You can't really, it has to be experienced to be understood.

It's no different with emacs. Emacs doesn't really make any sense until you use it for a while, then all of sudden you "get it" and don't want to use anything else.

No, I'm pretty sure everyone knows what fragile software feels like. Disclaimer: I've been using fragile emacs as long as most HN users have been alive.

But the point remains. You can't really understand emacs (or a lot of other things for that matter) in the abstract, you have to use it. So use it or don't, but you can't really offer meaningful criticism without have it used it a fair amount. There are plenty of warts on emacs, any emacs veteran (which I'm certainly not) will freely acknowledge that. But it does seem that most criticisms of emacs come from folks who haven't used it much.

That's not at all true. It's called "validation" and "error handling". What kind of farce are you getting at? You unironically think a text editor that lets you break its settings panel by trying to use the settings panel normally isn't fragile?

Edited to remove cheapshot at parent comment

I'm genuinely curious how you did this, and how you did it in a way that was permanent. The customization screens are read-only by default (except for those boxes you type text in to specify the customization) and they're programmatically generated, not fixed.

I've recently got Python working well. It can be done. The deeper problem - and this is admittedly ubiquitous in emacs - is that the defaults are awful, and there is not even good discoverable official documentation about what configuration you should use because everyone's just a wee bit too content to allow, "We have a very welcoming community on IRC!" to stand in for a proper new user experience.

Both Eclipse and NetBeans are outstanding (and free) Java IDEs. To be clear: I write this as someone who does not make extensive use of plug-ins with IntelliJ. I am almost exclusively using the default plug-ins provided by JetBrains. For many, many years, NetBeans was (enviably) considered the Gold Standard for Java Swing GUI design that was drag-and-drop. I knew developers who used NetBeans only for GUI design, then IntelliJ or Eclipse for other work!

Finallly, I have never used Visual Studio Code, but I also assume -- at this point -- that it is very good with Java. The speed at which their community has grown is simply breathtaking.

I am interested to hear from other people if this agree or disagree with me.

Unfortunately, that's not the case. I tried using VSCode with its Java development extension pack last week and I found that it was nowhere near as polished as, for example, its Python or Typescript extensions, both of which are gold standard. I ended up switching back to IntelliJ.

I can't complain about Python except I didn't succeed in using the projects local pipenv automatically.

I have struggled with a similar thing (poetry not pipenv, but should be applicable) and came to this working solution: https://github.com/bananaoomarang/dotfiles/blob/master/emacs...

Basically: if poetry project file exists in project root, get the path for the active venv with poetry and activate with the emacs pyvenv package. This adds a little jank when switching projects I haven't looked into ironing out yet but it is functional.

I should note that I don't work on large codebases. My codebases have ~20 files and <20,000 lines of code total. I know some folks prefer LSP and that might be the reason.

BTW, all software that changes will have a bug from time to time, but Emacs and things related to Common Lisp are like at the very bottom of the trouble-frequency charts. I can't think of any software that I use regularly that gives me fewer problems. For the record I never encountered a bug in either (which doesn't mean they don't exist).

But aside from that Emacs, like most programs, has a UX philosophy that I can't stand. And while Emacs lets me change that I don't want to manually redefine things for every single filetype and mode I'm using. Vim just does it right unless I make the mistake of writing JS in HTML files.

But you can always revert a configuration choice you made without restarting Emacs. Either use the built in configuration interface, or evaluate a form with the change. For example, if you set something to t you can reset it to nil and just C-x-e that form.

That's not something you shouldn't do and you also shouldn't need to restart Slime. Just break using `C-c C-c` and do a 'retry'.

Try opening a large file. Or a small one. With emacs it's always a wait-and-see.

This is definitely not my experience. I regularly see emacs lock up indefinitely when asked to handle large buffers, especially when also using TRAMP. Even when it doesn't lock up indefinitely, it can easily stall for minutes(!) when doing something like moving point to the end of a large minified JS file (C-E).

There are many reasons to love Emacs, and I use it as my main development OS almost, but stability and performance are not among those reasons.

Note: mostly used it in console mode on Linux (Ubuntu WSL 2).

The OS could matter, I guess. I didn't even think about that. I used Debian Stable and have been since the last century. Always a version or two behind, at least, so I guess bugs could be resolved before I get a chance to encounter them.

It must be said that large file handling is an area that could do with some improvement - vlf-mode is okay as a workaround but it would be nice if I could deal with a large file in much the same way as a regular sized files. Few environments will provide this either though.

I used vim for ~12 years and then emacs for ~12 years, and this emacs has never been able to handle large files well. vim meanwhile has zero trouble with files of any size that I've ever tried.

"Vim can do it" doesn't counter you saying "few environments" though. I haven't needed to look much farther than vim/emacs.

Now that I’m talking about it I do remember a couple of times where vi (rather than vim) choked on some very very large files but she always got there.

This is the main reason I keep using Emacs for my everyday use. I never thought it was simply the best editor you could imagine. But it’s an editor I could always rely on.

There have been so many editors and IDEs in the past with their shiny features, great UIs and everybody screaming of excitement — until they were replaced by the next new shiny editor after a couple of years.

VSCode is surely a nice editor. (Although I don’t think its pixel dust UI is particularly great. And don’t get me started on its memory consumption.) Microsoft’s LSP, however, is a great idea. Emacs absorbed this feature already and will make it available even long after everybody stopped using VSCode within a couple of years.

Editors fall out of fashion. People die. Emacs remains Emacs.

I watched a video on JetBrains [1] and the keyboard shortcuts and navigation look genuinely well thought out, so I’ll be giving that a try (with a vim emulation plugin, naturally)

[0] https://github.com/microsoft/vscode/issues/126310

[1] https://youtu.be/x8y_6Gg28GI

It covers everything (code, inspections, docker, database layer, seamless multilanguage support).

This might be my number two reason. I learned Emacs in 2000. Meanwhile, I've not had to learn, over and over again, all those other editors and IDE's. To be sure, I've honed my Emacs skills, installed and learned new tools in it (hello flycheck, elpy, SLIME, org-mode, TRAMP, CEDET), and just generally get on with whatever I'm working on ATM.

My number one reason has been the power though, especially after reading things like this: https://blog.vivekhaldar.com/post/3996068979/the-levels-of-e...

I use a mix of editors on a day-to-day basis because they each solve a particular problem in a way I like. I imagine everyone else has a similar thought process. If you like the way it works, then it's the editor for you.

http://web.mit.edu/Emacs/source/emacs/lisp/emulation/ws-mode...

> Emacs is not really an editor either! I believe that Emacs is the ultimate editor building material. The out-of-the-box experience is kind of basic and somewhat weird, but I don’t think that anyone should be using Emacs like this. You take this simple foundation, you shape and mold it to your taste and preferences and you end up with the best possible editor for you and you alone. That’s the reason why you should consider using Emacs. … For me, personally, the ability to extend Emacs easily with Emacs Lisp remains its number one advantage over vim. There’s also the fact that you can re-create much of the vim experience with Emacs, but you’ll be hard pressed to re-create the Emacs experience in vim.

For me, this is really the key attraction of Emacs. It’s not an editor; it’s a library for me to build my own ideal editor. And, in the long term, there are very few editors which can compete with this.

Are there other ways to get modal editing in emacs?

I’m surprised to hear this. I’d personally assess Evil highly — in some areas, it’s even better than Vim. What problem(s) did you have with it?

You can edit vim macros but it's not nearly as seamless

I'm happy faffing around with Sublime, VSC, even Nano, but when I'm doing anything substantial over an extended period of time I'll always use Emacs, not only that but in the world of Atom Emacs has to be one of the fastest loading/running editors.

That quote reminds me of this quote:

> Lisp isn't a language, it's a building material. -- Alan Kay

Funny, Emacs seems to be written in Lisp . . .

This is the first video:

https://www.youtube.com/watch?v=74zOY-vgkyw

If you are a fan of vim style modal editing, Spacemacs [2] and Doom [3] are two popular emacs "distributions".

[1] https://github.com/bbatsov/prelude

[2] https://github.com/syl20bnr/spacemacs

[3] https://github.com/hlissner/doom-emacs

There is, for example, mine:

https://github.com/Release-Candidate/Emacs

Setting up Emacs reasonably for Go development just isn't even close to being straightforward. And with Go, go tooling and Emacs continually being changed, any setup that works will eventually stop working and you have to try to figure out how to rewrite your configuration. This happens often enough that even someone like me, who really, really didn't want to ditch emacs, eventually may do so.

I appreciate all the work that has gone into Emacs, but the feeling I get is that the project lacks enough active developers and/or the focus misses the mark. I see version numbers going up - I don't see visible improvement.

The goalposts moved. They are farther afield. Expectations of what an environment has to offer have gone up. If a decent developer experience isn't an understood priority, then Emacs isn't going to be very attractive for new developers. And it may have problems both attracting new users and developers and retaining new developers.

(That being said: VS Code is apparently going through a rough patch where things have gotten really buggy if you use it for Go development. So it isn't like VS Code is a magic bullet)

Vim has more users than Emacs and lately neovim gained a lot of traction; they managed to coordinate the community on a direction, ask for money, fund a new generation of programmers to learn the codebase and update it to be async and use a different script engine.

Emacs has had several efforts at replacing elisp or rewriting the core in rust or what have you... But they've never been able to budge the local maximum nor coordinate the community on the new direction. Actually, I believe guix is the new emacs because..

Neovim has succeeded in retiring vimscript for lua and from there a community is emerging around fennel (a powerful lisp that compiles to lua). This is the beginning of a very interesting answer to emacs which is growing fresh from old roots and there seems to be a lot of people eager to build tools with these tools.

Although I tend to think the brand value of vim and Emacs is worth a lot I'm starting to see a lot of new editor projects that look somewhat appealing but until the packaging and configuration management gets at least an order of magnitude easier I'm reluctant to spend time with these things.

The fate of VS code seems to be really closely tied to TypeScript at the moment. If it turns out that Types really are the way forward, then these will eventually be included in the JS core. What then for TypeScript? Who even decides?

The nice thing about Emacs is that it is firmly rooted in standards and consensus. It will never be the best editor for most people at any one moment in time, but it has been a _good_ editor for decades and will continue to be so for decades to come.

That's like saying the the fate of Emacs would be closely tied to Common Lisp (or Coq with Proof General). That's some languages Emacs where still beats anything else.

That typo is actually the problem. If they don't decide to make TypeScript a Visual Studio feature.

But my point is that VS Code would not be an alternative to Emacs if you could only use it for TS and Emacs wouldn't exist any more, if all that you could do with it was programming (Common) Lisp.

Any obvious reasons this would be a good/bad idea?

Webassembly is the same as being able to call C libs (which don't have to be written in C) from Python. It's there to speed up bottlenecks.

Not necessarily? TypeScript could easily continue being its own thing as it is now, and ECMAScript have shown absolutely 0 interest in adding types to the core language a-la TypeScript. Infact, the amount of work needed to enable types (supporting new syntax) would result in so much backwards compatibility breaking that it wouldn't even be feasible.

TypeScript is way more likely to remain its own thing.

It shouldn't be a controversial position to say that perhaps something cobbled together by an inexperienced language designer in a matter of weeks, five or six internet lifetimes ago may not be a good long term bet.

I wish browsers would set an EOL for JS support and just get on with WASM. Of course, that's never going to happen.

Emacs is really short on core developers, and core development is hampered by the de-facto requirement that no aspects of user experience should change by default for longtime users with no out-of-core customization.

That said, the improvements in Emacs 28 are tremendous. The biggest is the native compiler, which will AOT compile Emacs Lisp code to native code, so lots of things that used to be slow are now very fast. Native JSON parser (maybe was added in 27?) means that LSP support is very fast. Pure GTK frontend didn't make it into 28, but will probably make it for 29, and means that Emacs on Wayland doesn't use X11 anymore.

What I'd like to see is a "standard distribution": something not as opinionated as Spacemacs or Doom Emacs, but which will apply more modern defaults, and have something similar to the Spacemacs "layers" feature, where there's a standard, supported way to enable the needed packages for a language or common workflow.

go-mode with godef, goimports and oracle was great during the early years. I remember telling people how the simplicity and quality of tooling and the great Emacs support around them was one of the reasons I enjoyed working with Go.

The transition to module support was a bit of a pain but that was a question of updates to the tooling, not Emacs itself. And then LSP came along just around the right time to deal with that and everything else.

Other than Elisp itself and Common Lisp (SLIME) I'd say Go is my favorite language to work with using Emacs.

Edit, looking at the timeline Go 1.0 was March 2012 and it took a year before we had go-mode with godef support. I guess I managed until then, it was simpler times in the Go world.

I used to have a highly customized Emacs setup with a lot of code that would automate lots of tasks for different programming languages and environments. I essentially ended up using an email reader that I found somewhere and then rewrote to include a lot of automation of the way I did my email.

Of course, things changed over time. My customizations started breaking - more and faster each year. I went from having my email delivered on a traditional mailbox file, to using IMAP. Along the way I had to use POP (because I could emulate having a mailbox file) the client needed a major rewrite to deal with IMAP and in the middle of the rewrite I gave up because something else broke. I have always worked on multiple machines, so I had to synchronize setups - sometimes between machines with different emacs versions.

I used Emacs for fewer and fewer things until it was only used for writing code and markdown files.

Heavily customizing anything is risky because at some point you become the sole maintainer of a lot of code. At one point I'd spend perhaps 2-3 days per month programming Emacs Lisp - which, at the time, was not all that great.

I don't customize software I depend on that much anymore. Including keybindings. It is cheaper to try to learn defaults, and if you put your ego aside, usually not that big of a deal. This doesn't mean you can't add functionality or customize it - it just means you shouldn't have to rewire the innards to accomplish it.

Sadly, in Emacs, "extensions" are, to put it mildly, a rough ride. And more so the more you customize. Things are a bit too "freeform". You end up saying no to a lot of things you could have had for free because things start to clash with your customizations. "You broke it, now you own it".

I have a very clear benchmark for what might bring me back to Emacs: be able to set up Emacs from scratch in 10 minutes so that I can program in Go, have good language server support, easy access to documentation, and a lot of the things I used to have before, but which simply rotted away over the past few years.

....and then not have it break in a way that requires more than a couple of minutes of my attention for a year.

That's because you (and each extension) has access to 'the' editor itself, whereas with for example Code, the plugin API is limited. Yes, you cannot change everything, but you also cannot break everything.

I stopped using Emacs like 10 years ago after realising that if one needs over 1000 lines of init.el then I am not the target user of the editor. I tried to reduce that via using external packages, but that has not helped much.

And for hobby projects I am happy with Geany on Linux.

And it works across all major OSes. Just copy your .spacemacs file to a new laptop, and wait for everything to install itself.

To be fair, I use VS Code pretty regularly as well. But more of a nicer alternative to TextEdit/Gedit/etc. to capture notes as I work in Spacemacs (of course, there's also the helpful scratch buffer).

[0] https://www.spacemacs.org

  git clone myemacs
  mv myemacs ~/.emacs.d
  emacs

Some people enjoy hacking their configs, but for me the changes were due to Emacs defaults not to my taste. So I got no pleasure in writing the thing.

It was more fiddly when I started because gopls was new, but now it’s just rock solid (and fast).

Any specific example of Emacs being changed to break your workflow?

I can't remember what specific functionality had just died, but I was in the process of re-doing my Go setup from scratch for the third time or so when I figured I'd give VS Code another spin.

In my own experience, emacs developers generally have the exact opposite approach and strongly resist any changes that may break existing user workflow. Of course, externally maintained packages might take a different approach because they are developed independently of emacs.

Even if you are not yourself interested in emacs development, you can contribute by just making bug reports for these missing features or breaking changes in the packages that you use. That's just being a conscientious open source citizen.

Go has had excellent tooling from early on. Standard code formatting with gofmt from day 1 was HUGE. godoc, godef, goimports and oracle were also available from early on. And then when LSP came along we got multiple LSP server implementations fairly quickly.

I don't have a link around but I am fairly certain that getting the basic tooling into shape was one of the priorities before the 1.0 release.

It's mainly about how powerful plaintext is and how Emacs and it's community acknowledged that. Org and org-roam are extensions of my brain by now, I've even installed Emacs in my smartphone because of that. Ledger-mode is the most ideal finance management I could conceive, and I've set-up Emacs (CUA-mode with just a ledger hydra) for two family members so they could use it too. I have absolutely no idea how I could make Ledger tolerable to non-technical people without Emacs. I also create beautiful presentations in a couple of minutes using org-reveal.

Besides, it's hack-ability certainly inspires inumerable beautiful creations. Some packages like Magit, Hydra, Helm and avy are just that, beautiful. When I don't feel like programming, I change some config and write programs as an excuse to test it, because Emacs is fun. It's no wonder people who act like understanding your editor is a chore have a bad experience, they're missing the point.

On OpenBSD there is one nit, and googling only suggested 1 fix. I am a heavy RCS user, but Emacs RCS package fails on OpenBSD due to its Base RCS. The only fix I can find is to install GNU RCS and disable OpenBSD Base RCS. I tried to find and fix the Lisp package, but it is way beyond my skill level.

OpenBSD people seems unconcerned about correcting their RCS to work with Emacs (maybe a security thing). I believe the same seems to be the case Emacs RCS people, I think they would prefer the use of GNU RCS (understandable).

I would prefer to use OpenBSD Base RCS but I am caught between two projects. So on OpenBSD I stick with vim until I can find a workable solution.

I agree with that wholeheartedly. Don’t get me wrong—I love emacs and I’ll be the first to talk your ear off about it.

But it’s a hobby, and not necessarily worth the time investment compared with other editors, if you’re looking for something that “just works” and has all the modern features.

I even got syntax highlighting for patches and wrote some lisp to link up notmuch search results to gnus- so I can search for an e-mail and find the whole thread easily.

Of course, I could have just started evolution and been done, but this stuff is fun!

At my last job, I was forced to use PyCharm. Fine an IDE it probably is, I hated every second of it. Within 3 days I ditched it for Emacs.

Come on. „CUA mode“ exists since the 90s. ;)

Jokes aside, Emacs UX is just completely different to anything modern. Computer users not enlightened by Emacsen try to press Esc to get out of trouble, assume scrolling doesn't move the cursor, etc. Chorded keybindings are a mind-blow, and they have their own further pitfalls too.

I either got used to Emacs behaviours, or find them superior (can't tell which one) but frankly I think they might be a big deterrent. For new users, it must be like getting into a car where all the controls are different. Brake and accelerator swapped, clutch is hand-operated (and woe to you if you've only driven automatic), stems are swapped, and some vital controls are operated by pressing buttons with the top of your head. Computer programs of the past 20 years have some basic common behaviours that are almost synonymous with basic IT skills, and Emacs diverges in many of them.

I adopted Emacs in the relative modernity of 2012, when I joined a mostly-airgapped Linux environment and needed a power editor. I persevered and grew to love Emacs, but frankly if I could have downloaded VS Code or Pycharm, I probably would have done.

It’s in the menu bar, under “Options” → “Use CUA Keys (Cut/Paste with C-x/C-c/C-v)”, beside an on/off checkbox. How could it possibly be made to be any easier to find and understand (except to make it enabled by default)?

There shouldn't be any goddamn high places!

You have to meet your users where they are, otherwise you won't have users. For desktop applications, that means using the standard interface conventions and shortcuts for common operations.

That actually does work, if you press ESC three times. It’s a special case in Emacs, added just to make it easier for people who hammer the ESC key to abort.

True, though, that it gets me out of the mini-buffer, same as C-g. I didn't know that works - nice.

Btw, here's another thing. How many times as a beginner was I stuck in the mini-buffer and had no idea what's going on? The new editors have some kind of command palette, which is vaguely similar, but I don't think you can get stuck in it.

Why Emacs? - https://news.ycombinator.com/item?id=3256721 - Nov 2011 (128 comments)

I don't use emacs because I did some cost-benefit analysis on my editor. I tried emacs and found that it's a whole lot of fun, which of course is why I got into programming in the first place - I found it, and still find it, fun.

If you view programming as a job in the same way something like being a tax account is a job, then learning emacs is probably not for you, you're better off with something like VS Code that asks very little of its users and gives you a nice working environment right out of the box.

Emacs is great if, as the author notes, you're an intellectually curious person who genuinely enjoys tinkering. If that's the case, you'll most likely have a lot of fun with emacs. It's very hard to describe how much fun it is to edit and modify your development environment in real time while you're working in that very same development environment.

Two of those editors are Mac-only, and only one editor is open source. I suspect if Sublime had become open (and cross-platform), it would be significant "player" in the editor wars. Atom has mostly died on the vine, thanks to VS Code. That doesn't negate any of the author's points about Emacs, but, aside from VS Code (and, I guess, Atom), there have been few efforts to create a performant[0] cross-platform, IDE-like editor.

[0] Insert comments about VS Code's performance here.

Btw, I think TextMate is open-source these days as well.

Emacs is not rock solid.

It's easy to bring Emacs to a standstill with something as simple as a long string. This is especially apparent outside Linux, e.g. on Mac OS (Windows is a whole other story). It's a fundamental flaw in the text editor, and I don't know if there is any solution on the horizon.

Text editing can also become noticeably slower once many of the must-have Emacs packages are in use.

At the same time, becoming somewhat proficient at Emacs and knowing a thing or two about Emacs Lisp has made me a better programmer, and certainly more productive in the use of my editor.

If Emacs can solve some of its performance issues, and perhaps make things like the Debug Adapter Protocol easier to set up, it will continue to be in a league of its own and an essential editor to many for the foreseeable future.

I have been using Emacs on Windows for a couple of years, but I have been transitioning to using Linux full-time at work, and by the end of the year I won't have to deal with the slowness of Magit (and git in general) under Windows.

As passionate in your love for Emacs as Kyle Machulis is? ;)

https://news.ycombinator.com/item?id=29207607

https://github.com/qdot/deldo

https://www.youtube.com/watch?v=D1sXuHnf_lo

Sometimes I do use VSCode as an alternative, but VSCode only has a rudimentary implementation of org-mode, and the so-called org-mode alternative - markdown - is not nearly as powerful as org-mode.

[1] http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/pixel-s...

The third-party package "good-scroll" improves on pixel-scroll-mode by adding variable speed. IME, it's necessary in order to prevent flickering from pixel-scroll-mode. The defaults are somewhat conservative, and might not look like "scrolling pixel by pixel" to you, but you can definitely customize it to get what you want.

Has anybody written a patch for Emacs to implement this behavior?

The "Emacs Way" here is to use a command that takes you back to where you were before. If you used tags navigation to get to what you wanted to look at, you could use `pop-tag-mark`, which is on M-, (other modes for getting around, like xref and LSP use the same binding). Or failing that, if you know you're staying in the same buffer, you can `set-mark-command`, scroll to where you want to look, and `exchange-point-and-mark` (and then deactivate the mark with C-g if you were in transient-mark-mode, which most people are these days).

There's also a package `dogears' (https://github.com/alphapapa/dogears.el) for saving your place to go back to automatically even if you're just scrolling.

I recognize that all these solutions are not intuitive to someone who expects the cursor position to stay in the same place even if it scrolls offscreen.

I used to live inside Emacs -- not just for coding but for mail and news too. But nowadays I use Jetbrains IDEs for development and a reasonably clean vim for editing random files.

I'd really appreciate it.

Currently, I've only mustered enough courage and time to understand enough of vim to not feel scared of it anymore (vimtutor was the silver bullet for me there, learning enough vim in an hour to feel fine with it).

JetBrains makes great IDEs, and you should use them if you're working on a large project that one of those IDEs is geared towards. It'd take a lot of work to get any other editor to have the same feature-set and organization of workspace.

Emacs is a general-purpose environment for writing, and you should use it if you want a specific flow for writing code, or anything else. You can setup plugins so that it's like a mini IDE for most of the languages you write in, and you can setup plugins to modify the organization of your workspace. You want tabs? Add them. You want a tree view of your current project folder? Add one. You want Vim-style editing? Enable it. Etc.

Right now it seems everyone is looking for a code editor that is extensible and fast - Emacs fits that bill better than VS Code (also Neovim might end up being even better!), but it's more difficult to get it right. That's why there are projects like Spacemacs and Doom Emacs to make adding/removing plugins easier, and also have a good setup out of the box.

The main advantage of IntelliJ or any other IDE by JetBrains over Emacs, is that the out of box experience IDE provided, especially from a new programmer's perspective. All they need to do to click a button, check few checkbox, then IDE will resolve it for you and tell you what happened.

But to make Emacs do any complex behaviors, you usually have to write additional codes or configurations to glue different features together. Not to mention you need to read documents and debug it when there is an error. In JetBrains IDEs those are integrated already. A context-aware error detection and code inspection is available the second you open the IDE first time. That is something default Emacs can never do.

The main advantage on Emacs over IDEs, is that you can ask Emacs to do whatever you want as long as you know how to implement it. Practically speaking, you most likely will accumulate many little functions over time that is specific designed for your workflows. That kind of customizability is something IDEs cannot provide. I do not consider myself an Emacs power user, but I still benefit form it.

Emacs is also have better text editing features in general. You can use the same features no matter what text file you are editing. That's why people want to use Emacs for everything.

In short, they are different tools, use it where it is suitable for you.

For me, I whine about how bad the editor is when I use IDE, then I complain about how bad the integration my Emacs has between multiple tools (mainly my inability to make it work).

Hope this give you some ideas.

For example, I made a lot of scripts in Python to refactor codebases by automatically splitting files (including imports). Could I do that with emacs? Probably yes. But why?

For most intents and purposes it doesn't matter if your "automated editing" environment is integrated in your editor.

(disclaimer: happy vim user but always looking :) )

shift semicolon w enter

ctrl x s

(Flaming in jest and good heartedness)

Back then I was also using vim in mswin mode where Ctrl-S would save the file, just like in Windows.

Interestingly, though, I still find :w<Enter> easier. Maybe it's muscle memory now, maybe because I don't need to hold a second key for two key strokes, maybe colon is easier for me, maybe...

I guess I need to check my habits more closely :)

I guess it's the modality, I know ':' indicates the start of an ex command, and "w"rite saves the file, while I only see C-x C-c as a "single token".

I supposed it's just C-x for "execute command" and ... I'm not sure why it's control c, instead of just c, or s, or w...

C-x enters a keymap called the `ctl-x-map`, lots of file-related commands live in there but also half a million other things. It's very similar to `:` to enter an ex command or, more accurately, `g` as a prefix to a million different vim commands.

If you ever find yourself in emacs again, try typing C-x (to enter the `ctl-x-map`) and then hit C-h. This shows the help for the Ctrl-x keymap, and you'll see it's somewhat well-organized, if completely arbitrary. For instance, if you hit `C-x 5` you'll be in a sub-keymap (the ctl-x-5-map) which has a lot of frame-specific management mappings. Why is it under `5`? Historical reasons, no doubt, but it's inscrutable to normies like me.

with emacs i have this mindset, that emacs can do literally anything and be perfect for my brain with enough tuning. with vscode i know it's limited and don't bother fixing it, just muscle-memory the workarounds.

i do miss magit.

As a concrete example, for the main project I work on, we usually configure via CMake and then build through Ninja. A simple `cmake` command followed by a `ninja -j4` was all I needed to get everything built. However, I could never get vscode to just do that. I saw that it had its own internal version of CMake (that could never find my shared libaries) and it had its own build system, but they usually failed to build (despite the code still building just fine on the command line). Every guide I found on vscode was about starting a new project from scratch and didn't touch on working with existing code.

I know that the issue has to be how I'm thinking about vscode. That I'm not understanding its philosophy on how to work with code. What that philosophy is, though, I can't seem to find a good understanding of.

There’s way less philosophy to vscode than to emacs, i would suggest using it as dumb editor for a while and explore how various extensions make your life easier. If they don’t - maybe you just got your eMacs config right and should stick to it :)