I often see downvotes when people criticise ST's pricing, but I mostly agree with the detractors - the price always seems to be just a few bucks over the magical limit I'd be willing to pay.
Tech workers often spend $100 or more on a fancy meal with friends in a single night—I've definitely done that more than once. So paying $100 for a software license that I’ll be using almost every hour of the workday, and even more when working on personal projects, feels like a bargain.
I do wonder why it is that way though, because you're right, I've balked at the cost of software before, but had no issue in spending an order of magnitude more money on a flight to SF to meet up with other developers.
probably because there's a free OSS equivalent to most software.
The free equivalent to meeting up with friends/developers is a zoom call, and those suck.
Many of the non-sarcastic responses here are subjective changes (scripting language, core plugins, alternative control schemes) that will change what Emacs is for other people.
But I think we can find a lot of agreement around launch speeds, latency, typography and similar.
"Sakishi is based on Emacs key bindings. There is a very deep and logical reason for this, but for the purposes of this document, I will just state it as my preference."
I once set out to learn Emacs, but the stupidly multi-key bindings for very basic things (Ctrl-X Ctrl-C to copy, etc) turned me off. Deep and logical my ass.
I once set out to learn Vi, but the absurd modal editing and convoluted key combinations for basic tasks made it a nightmare. Efficient and logical, my ass!
I find it hard to believe you encountered a single key combination when starting to use vi. Maybe you got far enough to see "ctrl-v"? There are 108 unmodified choices before you'd ever need a combination.
: is shifted on almost every keyboard layout, so saving or quitting would require at least one key combination (OK, arguably you can quit with caps lock, Z, Z, caps lock).
But I suspect he meant "sequence of keys" by "key combination" in what was clearly intended to be a humorous parody of the previous comment.
I don't mean this to be a striking criticism of Emacs, however, I had the exact same experience. To be fair I've been using Vim for many years so that may have influenced how difficult it was for me to understand the Emacs key bindings. I didn't even have enough time to check out all the cool extensions
Emacs has a very long tail indeed of elisp extensions which Neovim has yet to fully catch up with. Neovim is well on its way however, and uses a programming language which many people already know and which is in any case familiar and easy to pick up. Lua has its quirks, elisp is pretty weird even for a Lisp (credit where credit is due, the elisp documentation is fantastic).
I've used Emacs off and on for years, and lately have settled on Neovim. The Spacemacs / Doom style configuration gives Emacs a fairly nice user interface, but I've never managed to hit a sweet spot of running all the fancy stuff I want to run, and not having the editor randomly pause / stutter.
With Neovim I've found that I can load it up and it still starts in under half a second, keeps up with typing/scrolling under all circumstances, and so on. For me that's the right tradeoff, ymmv.
I’m under the impression emacs performance will improve but agree it’s an issue, particularly on very long lines - my understanding is that any modes must recalculate things (font colors, etc) on every change and recalculate major parts of the file. Iirc emacs 30 implements treesitter and a few other things which should improve performance, but some issues still undoubtedly remain.
All I want is a cheatsheet between "how you would do it in vim" and "how you would do it on Emacs"
When a long time then use up and I want to give emacs a proper go, but I really can't live without some conveniences like "change inner string" or what have you.
How the hell do you do that in emacs, I cannot find out
I agree with this. I suspect it's part of a more general Godot philosophy that involves full in-editor workflows with highly detailed scenes, many nodes, and with small scripts attached to all of them.
I'm a commercial dev, previously used Unity, now using Godot. This comment rings true of GD Script and signals. I get around this by using C# and its event handling.
Working with nodes and editor bugs (or features? Hard to know really) is probably the most frustrating - you can really feel that this was initially built for 'smaller' projects.
For this reason, I rarely use the editor outside of setting up the scenes and a general hierarchy.
Daily tools: Emacs (with C# LSP) most of the time. VS Code for debugging. Godot editor for tweaking the scene tree.
Perhaps this perspective is useful for other devs thinking about Godot.
Copilot. I suspect a lot of us will (or already do) use it at some level, even if it's just autocompleting logging statements, writing boiler plate/comments, suggesting improvements etc.
Yeah, fundamentally it helps you manage records of documents. Of course you can also attach PDFs and full text (if you have them), but it's the record that's important.
A common use case is in academia - it helps you track your citations and then output standardised reference lists, which is a pain to do by hand.
Other tools in this space are Mendeley and Endnote.
reply