I've spent 2 month trying out emacs and I feel like I sort of scratched the surface. It's like the deeper you look the more you realize how much more there is
My biggest revelation was when I realized how to use Emacs to learn about Emacs. Knowing where to look up function, variable definitions etc was an eye opener in my understanding of how things work and are piped together
There was a time when this was the obvious thing to do when making systems. Sadly that's forgotten. Manpages to read on cli tooling is the same thing of course. Yet people rather go to another window, the browser, and go to a ad-driven website and get the same output as the manpage would give.
These days people rather switch to a browser window, open an LLM of their choice in a new tab and in verbose English ask "how do I do X in this popular program Y?".
Then get a hallucinated answer and come to you to complain about a missing cli option, while it's literally there, in their terminal, just one -h away. True story (had to vent out, thanks for listening).
The only 2¢ I can add here is that LLMs are surprisingly good for solving tasks that involve Elisp. There's large corpus of Emacs Lisp in the wild - the amount of it on GitHub alone is shocking.
For comparison - whenever I try using a model to write some Neovim config stuff, LLMs hallucinate badly.
Using Emacs these days is so much fun - you just ask a model and you can immediately try things - not only without restarting - you don't even have to save anything, anywhere.
You can even make Emacs do things that involve tools and languages that have nothing to do with elisp, e.g., "write elisp that would open all nested dirs in a given folder, and then run magit-log for each project, searching for specific pattern... and if found, issue npm or uv pip install with arguments...", etc.
I'm a Spacemacs user, and Claude knows the difference between Spacemacs and stock emacs. It basically wrote tools for itself to hook into the emacs LSP package and look up C++ code (in our codebase, which is, uh, challenging for FOSS language servers) from gptel. I was completely fucking unable to do this via publicly-available MCP servers in the VSCode agent mode. In general I have been able to resolve a bunch of niggling config issues that I had just been ignoring in favor of doing Actual Work.
As you said, I can evaluate the elisp Claude wrote right there in the gptel buffer, try it out, and iterate before actually pasting it into .spacemacs. It it doesn't work, Claude knows a ton of debugging tricks I can try. trace-function, advice to dump a backtrace, etc. It knows how to do everything in org-mode. Super helpful. Way better than the AI Assistant that my employer bundles with our product (which is outperformed by the Google AI Overview).
I think the problem that most beginners try to explore the editor features, instead of focusing on main fundamental truth about Emacs - it's not just an editor, it's a Lisp system with a built-in editor.
I think focusing on understanding how Lisp drives Emacs can remarkably speed up the pace of learning it. Every key press and button click hooks up to a Lisp function. Even complex keyboard macros translate to Lisp command sequences.
1. Figure out structural editing commands to move s-expressions freely - those parens only feel annoying initially, later they become friendly.
2. Understand REPL-driven development - any expression can be evaled in-place.
3. Try the build-in profiler.
4. Learn the debugger.
5. Use the describe- commands. Emacs can "describe" to you every key, function, command, symbol, input methods, themes, fonts, characters, etc.
Emacs is really not about "what it can or cannot do" in general sense. It's all about "what you can do with it". Learn some basic elisp - and you will be able to achieve a lot.
I'm going to give a counterpoint to this (common) take.
I was an Emacs power user for almost a decade before I learned Emacs Lisp. I knew just the bare minimum to populate my .emacs file, and occasionally copied others' config snippets.
> Who's got a decade to spare, when they can wield the power in just a couple of months?
I was a power user within months - a year tops. I didn't say it took me 10 years to become a power user.
Ever since I learned Elisp (it's been many years), I wouldn't say my expertise and abilities has grown exponentially. It is merely an incremental improvement. It definitely is nice that I can now code away annoyances, but it's not the game changer people make it out to be.
> I wouldn't say my expertise and abilities has grown exponentially
Things always look easier only after you solve a problem, don't they?
That is a known as hindsight bias (also called the "knew-it-all-along" effect). Once you've solved a problem or seen the solution, it seems obvious and you tend to overestimate how predictable or easy it was.
There's related phenomena known as the curse of knowledge - difficulty imagining not knowing something once you know it.
"The Mythical Man-Month" - discusses on why we underestimate complexity, it explains the psychology behind it.
There's also "forgetting the beginner's journey" or the "fourth stage" of learning where skills become so automatic you can't easily explain them.
Your psychology lesson is misplaced. I know my usage before and after, and it's a minor delta. The bulk of my Emacs usage today is using features that have been in my config since prior to my learning Elisp.
If we're going to be patronizing here: Most people who learn Elisp early into their Emacs experience are failing at identifying the source of their growing expertise, and are incorrectly attributing it to their knowledge of Elisp, when in reality they are merely becoming better Emacs users due to repetitive practice.
They also have a habit of reinventing solutions that are readily available within Emacs, or as a package.
I'm not trying to snub you nor am I arguing with you - my opinions are just that - I never said they are fundamentally true for everyone. Similarly, your experiences are yours - it would be wrong to generalize based solely on that data. There was no "schooling" here, the phenomenon mentioned fits this case perfectly, I just thought someone might be interested to learn more about it, that's all. Cheers to you, friend.
On the other hand, when we critique, it is for the benefit of everyone who reads the critique and learns from it.
That's why critique has value. To the original author/artist (if they see it), but also to everyone else who sees it. "Oh, I was going to intersperse text slides with a transcript, but I remember how offputting that was once on HN, so let's skip the slides."
The article in question is written by a person who stands to benefit heavily from AI & agents succeeding. They appear to be a true believer so this isn’t a disparaging comment, but a snake oil salesman would display the same behavior.
The biggest stunt Apple pulled was making people think this is Apples new CPU designs that created the performance gap and not just buying all the production capacity for next gen fabs.
We used to get that same performance gain every few years just from regular process improvements, but this time Apple made it seem like it was Apple that made the gain and not the general world.
Hard agree. The first-past-the-post single representative election system that is the foundation of the two party system in the US is breaking the country. It encourages politics where the current winner has no reason nor expectation of compromising on anything; now is their time and they are justified in breaking everything the previous winners did. It encourages politicians to act like babies, not grownups.
And I am grateful for the ends, wish Python had them as well. Python already marks the start of every block with a :, one more keyword and the semantic whitespace madness could end.
Interesting. My very personal opinion is that punctuation like characters should be used to structure/shape code, and words/tokens should be used for expressions.
I accept that others, such as yourself, have different opinions.
I think the reason that I feel the way I do is that I’ve read a lot over the years (like, non fiction), so I’ve been heavily conditioned to look for infix characters to separate and define the shape of code, and strings of words to express things. But that may be self introspective reach too far.
Process groups, some solid performance tweaks to ETS and Mnesia, etc. It all got upstreamed or became redundant eventually. Rick Reed gave a couple talks about it around a decade ago if you can track down recordings.
The number one thing I wish was addressed in future version of Python is the semantically significant whitespace.
Python is absolutely the worst language to work in with respect to code formatters. In any other language I can write my code, pressing enter or skipping enter however I want, and then the auto formatter just fixes it and makes it look like normal code. But in python, a forgotten space or an extra space, and it just gives up.
It wouldn't even take much, just add a "end" keyword and the LSP's could just take care of the rest.
Whitespace is semantically significant in nearly all modern programming languages, the difference is that with Python it is completely significant for both the humans and the tools - it is syntactically significant.
I've actively used Python for a quarter of a century (solo, with small teams, with large teams, and with whole dev orgs) and the number of times that not having redundant block delimiters has caused problems is vanishingly small and, interestingly, is on par with the number of times I've had problems with redundant block delimiters getting out of sync, i.e. some variation of
if (a > b)
i++;
j++;
Anytime I switch from Python to another language for awhile, one of the first annoying things is the need to add braces everywhere, and it really rubs because you are reminded how unnecessary they are.
Anyway, you can always write #end if you'd like. ;-)
The parent’s point was that you don’t have to care about white space when composing code in other languages since the LSP can auto format. So you could theoretically never press return or space more than once, and always have perfectly correctly functioning and formatted code at the end.
Oh, I thoroughly understand the parent's point, I'm just disagreeing that it is a problem that needs to be "addressed".
Most language design decisions involve tradeoffs, and for me this one has been a big positive, and the potential negatives have been - across decades of active usage - almost entirely theoretical.
Also, the real-world use case for importing code and auto formatting it is quite doable with Python - the main thing you can't do is blindly (unintelligently) merge two text buffers and expect it to work every time, but in general it takes only a smidgen of analysis on the incoming text to be able to auto reformat it to match your own. You could go all the way and parse and reformat it as needed, but much simpler/dumber approaches work just as well.
What you can't do is take invalid Python code and expect it to autoformat properly, but that borders on tautological, so... :)
...yes? Sorry, I'm not sure I understand what you're getting at. :)
(funny enough, that particular scenario is actually harder to miss in Python since it often produces an error that prevents the program from running at all)
I am debugging how this function works so I actually only want it to run when some condition is true. C:
if (some_condition) {
some_function();
}
Python:
if some_condition:
some_function()
Oops. That's not indented correctly, so it won't run. To be fair neither actually looks good but that's 1. fine because this is for debugging and 2. for the C code I just format the file and it is instantly fixed. What if I have a loop? C:
for (int i = 0; i < 5; ++i) {
iteratively_optimize();
}
Python:
for i in range(5):
iteratively_optimize()
Unfortunately this breaks something so I want to step it through. In C I comment out the loop as follows:
// for (int i = 0; i < 5; ++i) {
iteratively_optimize();
//}
In Python:
// for i in range(5):
iteratively_optimize()
Nope, that's broken too. I can't just autoformat this code either because the formatter can't look at scope using anything else. I have to manually go and fix the indentation on that line too.
These are actually very small cases. I can even imagine you saying, in C you have to fix two places if you want to comment out a loop or if: the opening brace and the closing one. In Python you need to comment out the control statement and the second thing is fixing the indentation, so what's the big deal? Well, as the number of lines in the block grows larger in C it's still just commenting out the two braces, while in Python you have to select the whole region line-perfectly and fix the indentation. As someone who writes both I always find this to be a lot more fiddly and annoying.
The day your wish is fullfilled is the day I stop working with Python. I can't stand all those useless braces everywhere, why are they there at all since good practice mandates proper indentation anyway?
I am at the point where I prefer single quotes for strings, instead of double quotes, just because they feel cleaner. And unfortunately pep8 sometimes mandates double quotes for reasons unknown.
A while ago, when thinking about syntax design for a new language, I considered this combination (`:` and `end`, as opposed to `do` and `end` as used by Lua etc).
Are there any languages that use it, or is Python unique in using `:` to begin a block?
I don't have this problem, and I've been writing Python for more than twenty years. Sure, I may have the occasional wrong space somewhere, but it's maybe a few times a month, whereas I'd otherwise have to type "end" for every single block.
I dont think this is a problem anymore in todays world of LSPs and auto formatters. I almost never have to type "end" in Elixir for instance, it is always autocompleted for me.
The autoformatter does it based on indentation, but when writing code the editor just inserts it when you open a block (after your cursor), same way } is added when you type { in other languages.
Ahh OK, I see, thanks. I don't really see much difference with whitespace sensitive languages, I've never really had problems with it. Maybe I've been lucky.
Thank you, but I rather not inject a tool that hasn't been updated in 6 years into my build chain. Thats how we do things in the Javascript world and frankly it sucks.
This is a joke that's actually built into Python. The __future__ module is where you can import/enable features that will become the default in future versions. The point it makes by giving "SyntaxError: Not a chance" is that Python will never add braces.
And IMO for good reason. It makes the code so much cleaner and it's not like it particularly takes effort to indent your code correctly, especially since any moderately competent editor will basically do it for you. Tbh I actually find it much less effort than typing braces.
This suggestion gives me chills. I literally never face this issue. Are you using vim? Theres autoindent and smartindent features you can enable to help you.
Neovim + ruff lsp. I have gone through many formatters to try and get this better, but it is always worse than any other language where whitespace is not semantic.
Expecting formatters to fix your broken blocks is a false economy with Python and smart indentation. It takes fewer keystrokes to write Python correctly, than to add delimiters so you could write it incorrectly.
Python’s tradeoffs pay dividends every day, at the expense of few questions a year. Also code is read 10x more than written, where the extra delimiters lower signal to noise.
Maybe it would help to think of "enter" as "semicolon" (since it's the statement terminator) and configure a macro or shortcut in your editor to act as "end" which decreases the indentation level by one step.
Wouldn't that make it behave pretty much as what you expect?
