This is impressive, but (and probably because I'm not the intended audience for this post) I don't get it, I kind of want to get it though. With "it" I mean making Emacs do X, where X is something far from editing text files. It always seems to me like playing Doom on a pregnancy test. Sure you can do it, sure it's impressive, but should you?
n.b. I'm a C# developer that has accepted my fate and use Visual Studio to earn a living, though I've made sure I know my tool, flaws and merits, better than most developers I've met/worked with. My first job as a programmer was writing C++ code in Emacs and can't remember anything negative about that experience (other than getting used to ctrl+x, ctrl+s for saving and, by reflex, doing the same in Excel, and losing a big part of the document that I had just selected to move, because Excel couldn't undo past last save).
Reading the (at the time I'm writing this) 13 comments on this post I see mentions of at least three lightweight programs that does this. What other than "the mountain is there" makes someone think Emacs would be the tool for this? As a Resolve user I know what tool I'd reach for even if using a multi GB, Hollywood grade, non linear editor, compositor and color grader for trimming a short video clip is about as ridiculously overpowered as using a sledge hammer to press a key (and I did exactly that just a few days ago).
Like I said, I'm most likely not "getting it", on multiple levels. Please educate me, why would I use Emacs for this or any of the page upon page of "strange" use cases you find if you search for "Emacs" here on HN. I know Emacs is a powerful editor but I can't for the life of me understand why I would use it to trim video clips.
Emacs is weird. I think it changed something in my brain. Before Emacs, I never thought I would ever try controlling video playback from my editor. "Just why?" I probably would've said. I never thought I'd be trying to get the text from the active tab in my browser. Or search through my browser history. Or OCR the content of my clipboard, or control my WM. Dang, before Emacs, it didn't even occur to me to try to type just about any text in my text editor - which now makes absolute sense - why would I ever bother typing in my browser window, Slack, Zoom, or email client?
In Emacs, I have all the tools I need for dealing with text - thesaurus, spell-checking, definition and etymology lookup, search engines, translation, LLMs, etc. Why, oh why, wouldn't I ever try typing anything longer than two words in anything else?
Like, for example, while typing this very comment, I may come across a thought: "I think I already made a similar comment some time ago, let me find it..." What would a regular user do? They'd switch to the browser, navigate to HN, scroll to the bottom, type search query, lookup on the page, jump to the next, keep paging until they find it, copy, switch back, paste... What would an experienced Emacs user do? They'd search for it without ever leaving their editor, grab the stuff from the buffer and paste it - all within just a few keystrokes. Or if I need to find a url in my browser history - I'd just search for it and insert in-place - two keystrokes+search query.
It's not just faster - it is profoundly satisfying and liberating. It gives you the feeling of being in control. You don't have to deal with the quirks of specialized apps; you don't need to memorize tons of their specific keybindings; it gives you a straight path to extracting or injecting plain text.
That's why those who never made a wholehearted attempt to use Emacs just never get it. And those who have, never can understand why others don't even try to recognize the value.
I hear stories like this and I can kind of see the proposition. But I’d be more eager to, somehow, see a long-running example of it all at work. I think I’m not so skeptical about what it can do, but somewhat skeptical that it’s actually as much of a paradigm shift as some describe it to be. I wonder if oftentimes it falls in the enjoyable hobby category of, “I just really enjoy upgrading my workshop.”
It is indisputably not a hobby, at least for me, personally it ain't. I've been coding long enough to see a difference between "oh, what a nice gimmick" and "how the fuck would I even do that, if I didn't know this way existed...". Long. My first programming language was Sinclair BASIC. The second PL I learned was Pascal. I picked up a few more over the years. I'm not trying to show off, nor am I claiming to be an outstanding programmer - I'm neither great nor terrible. I'm just saying I've been doing this shit for a long time, that's all.
It isn't a hobby, because Vim and Emacs allow me to perform in a way that I consider far more enjoyable, productive and satisfactory than I ever had before them. That is of course on a personal empirical basis - I cannot promise them having the same effect on anyone else.
In my opinion, after many years using many different tools, techniques, ideas and methodologies, frameworks, approaches, systems, platforms, workflows, philosophies, paradigms, strategies, practices, concepts, models, theories, and experiments, I personally find these two to be exactly the paradigm shift — in comparison to my prior experience when I didn't have them.
But let me be more specific - the paradigm shift I see is not in Emacs or Neovim as tools themselves. The paradigm shift I sense is in the grand ideas behind these tools - modal navigation and Lisp.
I honestly don't know why more people don't gravitate towards these ideas. Perhaps, because these ideas are kind of like 'meditation' - people say one can only experience the mind shift after practicing it for some time. I wouldn't know - I never practiced mediation for long. And that time required to see the shift can differ for every person - some may grok it quickly, for some, it may take decades without ever even clicking.
Also, you're wrong about "upgrading one's workshop" - it's a misconception that longtime Emacs users constantly have to tweak their configs. My config for example is pretty stable; I often make changes to it not because I have no choice, but because the task at hand calls for it. I write a lot of Lisp because it's an instrument for achieving specific goals and solving specific puzzles - work for which I get paid real amounts of real money. I get paid to use Emacs, not the opposite. So, no: definitely not a hobby.
> It isn't a hobby, because Vim and Emacs allow me to perform in a way that I consider far more enjoyable, productive and satisfactory than I ever had before them. That is of course on a personal empirical basis - I cannot promise them having the same effect on anyone else.
> I honestly don't know why more people don't gravitate towards these ideas. Perhaps, because these ideas are kind of like 'meditation' - people say one can only experience the mind shift after practicing it for some time.
It doesn't make sense to define something as a "hobby" just because there's some enjoyable or, in the quote you made, "meditation" and "mind shift" parts in it.
What's a "hobby" anyway? As the one you commented on, I have also been programming for a very long time. And why do I continue to do that, instead of changing to some management role? The answer to that is that I enjoy programming. I enjoy making tools to make the tools to create the thing I want to create, and to have enough stuff I want to create, I have a job which provides that in abundance. There are no hard borders between "hobby" and "job". It's a useless distinction in this case.
You know what really makes Emacs different than other editors and IDEs? Consider many ways one can transform selected text in VSCode. Let's say there are maybe 3-4 ways, with some extensions it can get to, I dunno a dozen?
Now consider that Emacs allows you virtually unlimited ways of doing the same thing. Because there are virtually unlimited ways to program that behavior.
In VSCode, you'd be clicking buttons and using shortcuts. Imagine if you had virtually unlimited number of buttons there? For different ways of running a command. That would be insane, right?
Well, here comes the argument if VSCode's (default) way maybe actually better? Some may argue about cognitive overhead - flexibility isn't free after all. Some programmers prefer tools to be tools rather than clay, yeah?
That's totally okay, I'm fine with all that. I'm just seriously baffled as to why Emacs is such an underrated and misunderstood tool. Why don't more programmers even attempt to try it? If you are a programmer, for sure, you should be, at least to a certain degree, curious about the ultimate programmable environment, no?
And don't bring the argument that non-emacs things are also "extendable". In virtually none of them can I open a buffer and add yet another way to transform selected text. Right there, without even saving that code in a file.
Well, sure, to a certain degree it is a hobby. Here, let me quickly run (define-it-at-point) command while I'm typing this comment, because of course I can do that in Emacs.
First definition says "it's a horse", then there's another:
> Any favorite object, pursuit, or topic; that which a person persistently pursues or dwells upon with zeal or delight, as if riding a horse.
Sure, in that sense it can be characterized as a hobby. What's the opposite of a hobby? Well, it's either "work", "chore" or "obligation"— all three kind of fit for my example. I use Emacs at work, for work, to do stuff I get paid for - check! It sometimes feels like a chore - well, what tool you use everyday doesn't? Sometimes you need to update it, delete stale cache files, reinstall, fix dependencies, etc, so can feel like a chore - check! Whenever I open-source some piece of code that extends Emacs, I have an obligation not to break it, etc. So the third one fits too. So, like I said - not a fucking hobby.
Shall we continue quibbling over words, how what reads to you is not what I meant and maybe even discuss how semantic meaning of words may change due to interlocutors' backgrounds, age, mood or the current lunar phase, or do you have some other kind of nitpicking in mind?
I do like having access to stuff while doing similar stuff. Perhaps I'm just a little too lazy to learn that stuff while still getting paid to know other stuff. And I do have just about every tool/feature you mentioned, just not in a single user interface.
I guess the path to Emacs was more of a possibility/probability earlier in my career and I might find it later but for now I'll alt+tab to the browser and/or open a new tab when I need to look up any etymology and stick to navigating around Visual Studio like a pro while they still pay me to do it.
The nice thing with emacs is that you can do as much or as little as you want with it. For me it started with basic text editing, then doing some git stuff with magit, then realizing emacs has wonderful capabilities around notetaking and to-do management in org-mode.
Like you, though, I work in orgs that are very Windows heavy, so I tend to use it more for my personal stuff rather than in my day job
Yeah I know some folks who only really use it for basic text editing and org-mode notetaking. I know writers who only use it to write. I know coders who only use it to code. etc.
> I do have just about every tool/feature you mentioned, just not in a single user interface.
Well, just like I said - you're not getting it, we're talking past each other. It isn't about a "single interface" - not about cramming everything into one window, it's rather about seamless workflow integration. It's like having a command center that orchestrates your existing tools, rather than replacing them. The power isn't in the interface - it's in the programmable glue between your tools.
You say: "I'd open a new tab if I need etymology..." Sure, on the surface it feels like a fair point. However, when you have the ability to request something from any tool or service "at-point", right in the middle of typing a sentence or solving a specific task - it simplifes so many things, and you tend to use those tools more. It's basic psychological phenomenon called 'convenience effect'.
But that's the only half story of it. Here's the practical example I often use as an evidence. I use Google Translate, alright? On its own there's nothing special about it - other editors and IDEs, also probably have integrations like that if not even nicer with GTranslate or some other translating service, right? Yet check this out. I'm learning Spanish, and when I want to translate something like "Colonel was born in 1968", what would GTranslate do? It would translate the text leaving the numbers intact, and that's totally expected. But guess what? I am trying to gain better familiarity with numbers in Spanish, I really do need to see them in their written form.
How long do you think it took me to solve that little personal discomfort? No longer than fifteen minutes. First, I needed to find out what actually was sending the payload to GTtranslate endpoints. I launched Emacs' built-in profiler and performed a task of translation. I found the function. Then I advised it. Advising is an Emacs Lisp mechanism to prepend, append or override the behavior of any given function - built-in or third-party. So, I figured that if I convert the numbers to text first, then send the payload with that text instead of numbers, it will work exactly as I wanted.
I couldn't even find an implementation of numbers-to-word in Elisp, and I didn't want to spend any time trying to write one. So I delegated the task to an npm package. Now, my advising function adjusts the behavior of 'translate' function (that sends the payload) by detecting the numbers in the text and then runs nodejs, changing the payload, so GTranslate spits out: "Coronel nació en mil novecientos sesenta y ocho"
Did I have to write my own browser extension for that? Nope. Did I have to figure out how GTranslate endpoints work? Nope - I didn't even have to open their documentation page. Did I have to re-implement the entire command that sends the payload? Nope - I just needed to tweak one, specific aspect of it, with extreme granularity - the body of the function is ten lines long. If that's not some blackmagickfuckery, I don't know what that is. Maaaan, I wish someone has showed me some shit like that when I was much younger.
> Perhaps I'm just a little too lazy to learn that stuff
Here's a thing about ideas - and don't consider Emacs as a concrete tool, a mere editor, but think of the fundamental idea behind it. You don't need to "learn" ideas. You just have to cultivate some level of curiosity about them. Sure, you may later have to spend considerable time learning the concrete tools behind those ideas, but absorbing the idea is the first step.
And grokking basic fundamentals about the idea of Lisp is pretty trivial - one just needs to learn mainly two things - structural editing and REPL-driven development. Some may argue that even those are not specifically necessary to begin the journey.
You know how the "do" in Taekwondo, Judo, Aikido, Karate-do stands for "path" or "way"? There's no truly "learning" Aikido, you either practice it or you don't. It's a lifelong practice rather than something you "master" or "complete." The idea of Lisp is similar - it's not really something you "learn" in the traditional sense and then move on from. You practice thinking in Lisp.
The fundamental principles of Lisp - code as data, the power of the REPL, recursive thinking, functional approaches - these aren't just techniques you acquire. They become a way of approaching problems, a mindset you cultivate through practice. The practice never really ends - it just deepens.
I haven't done any martial arts, so I'm just spitting words here, but I bet, if I ask anyone who practiced Aikido for a long time if it makes their lives any better, I bet they'd tell me some koans about zen master pouring tea or some other shit that I'd immediately dismiss as complete bullshit, so I wouldn't blame you if you take my words the same way.
> I guess the path to Emacs was more of a possibility/probability earlier in my career
Just like Aikido welcomes practitioners at any age or stage of life, Lisp is always ready for new practitioners. The fundamental principles align here in more ways than one could imagine - "the journey is the destination", "wisdom over athleticism", etc. Many people discover their deepest appreciation for Lisp (or Aikido) later in life, when they have the patience and perspective to appreciate the subtleties. The best time to start is always now.
FWIW, Org Mode is what a native Emacs user might reach for as alternative to Jupyter notebooks: https://michaelneuper.com/posts/replace-jupyter-notebook-wit... That doesn’t imply that you should both try Emacs and replace Jupyter! Just be aware that if either you are using Jupyter for your own reasons or working with like-minded team there is an alternative which may be preferable for your use-case.
Jupyter support in Emacs is pretty bad, tbh. I keep trying every once in a while (as lots of companies prefer notebooks) and it basically never works.
You could probably get it working locally for yourself but in corporate environments it can be annoyingly hard.
org-mode is a better choice, but note that it's not specialised for Python (which is good and bad) so you may need to wire up some stuff (I mostly use R for personal stuff and that works very well).
Pfft, you call that an emacs-HN integration? Something tells me you had
to bring in the browser at some point, either when reading this message,
or writing your reply. I am using nnhackernews. Now that's a real
emacs-HN integration.
Sure, that's just another package I forgot existed. Guess what? You can still use all of them together in the same instance of Emacs and they probably wouldn't even complain about it.
this is inspiring, I am slowly getting to that same conclusion but in neovim... if I write text I want all my nvim fancyness... because oh boy is it fancy!
Yup, Neovim is very awesome, I use it myself pretty much every day whenever I need to ssh to a remote host. There are many reasons though for why it is unlikely to dethrone Emacs as my main driver. Just like Emacs could never fully replace my photo-editing app.
It saddens me how people of Emacs often reject vim navigation outright, just as the broader programming community tends to dismiss the fundamental ideas that drive Emacs.
Neither represents a dogmatic religion, nor do they embody fundamental, conflicting truths about computing. No one needs to choose one and commit to it exclusively - they are simply tools, built upon some brilliant foundational concepts. Understanding and utilizing the ideas behind them may literally transform your life in mind-blowingly positive ways. I wish more people contemplated this profound truth, instead of thinking they have to stick with one, particular way of things.
I used Vim for 5 years before I eventually made the switch to Emacs. The reason I switched was because I needed an alternative to stop my hands from hurting all the time. Because having to slam every key at full force (because a missed input can wreak absolute havoc) was really taking its toll on both my hands. The combination of using standard Emacs bindings and the Dvorak keyboard layout have improved things significantly.
Evil mode is fantastic. Not only am I fascinated by how nicely it works, I'm just impressed that it's never been a built-in feature of Emacs. It definitely doesn't feel that way. It feels like a baked-in, first-class thing.
Here's one thing about vim-navigation. Gary Bernhardt (the WAT talk guy) once said: "There's no vim-mode there's only Vim" and he was right - to a certain degree. All the different extensions and attempts to bring vim-navigation to non-vim editors have glaring deficiencies - all of them - VSCode doesn't fully vim, IntelliJ doesn't do it comprehensively, Sublime can't properly vim, etc. With one notable exception. Emacs actually vims better than vim/gvim/neovim. I'm saying this with the full-blown confidence of a die-hard vimmer.
The way Emacs implements Evil-mode and its extensions is the ultimate compliment to its design. If there's a model of a plane that can perform a vertical landing, yet never actually needs to use it, I would still love that model over any other planes, even if the feature is purely accidental. The fact that it can do so alone would be great evidence of amazing engineering. Evil-mode is absolutely one of the most celebrated achievements of Emacs, complementing other remarkable packages like Org, Magit and many others.
As an Emacs users who often tries to do as many things as possible in Emacs, I would say that the more stuff you can do in Emacs, the more the various features in Emacs compound with each other, giving you more utility.
For example, I use the Verb package for making HTTP requests. So with Emacs as my HTTP client, I can do bulk HTTP request calls with keyboard macros. The HTTP requests can be stored in org-mode. I can write custom Elisp for special authentication scenarios. I can create new commands if I need them.
For this example, I can imagine (haven't used this myself) scenarios like creating a keyboard macro to shave off the first X seconds of a video usable with dired.
Some non-text-editing things in Emacs that are actually extremely useful:
- Git via Magit
- Managing files with Dired
- Media player with Emms
- RSS feeds with elfeed
and the list goes on and on...
Using a well thought-out Emacs interface for anything is one of the biggest sources of joy in my technical life.
Using well thought out interfaces is a joy wherever we find them.
Something in your comment made me remember a DOS based file "explorer". Screen split down the middle with a folder-tree and file list on both sides. I remember hardly ever turning on the computer without starting that for one task or another. That was some serious UI pleasure, at least for the time. Ha, found it:
Getting deep enough into it, it basically becomes your shell, complete with the ability shells have to orchestrate multiple programs into a meta-program.
An Emacs tool to trim video most likely has a conventional Emacs API, conventional Emacs documentation, and was developed using conventional Emacs user personas. Modulo the skill of the tool’s developer, this means it won’t require a lot of unnecessary brain cycles to learn or use or automate.
It won’t require switching to a browser. It won’t require creating an account. No going to the app store. No license consent. No dangerous program warning. No turn on notifications. No unlock premium features. No an update is available. No marketing emails. No cookies.
It’s just gonna STFU and do what it says it does in a way that makes sense. And if it is good enough, it’s good enough. It won’t add bullshit to your day.
While I'm not an Emacs aficionado and I find some of the stuff that people squeeze into Emacs weird [0], I have to vouch for OP here. It's a front end for ffmpeg. ffmpeg is a text-based utility and Emacs is a text editor. That actually makes sense. And judging by the screengrab it's a lot more ergonomic than plain ffmpeg. If I were an Emacs user I'd definitely consider using this, and it makes me kind of jealous.
[0] recent example from here: a proto social network that runs via org-files-over-http (as if we didn't have a markup language designed for http already) https://news.ycombinator.com/item?id=44889354
> if we didn't have a markup language designed for http already
Org-mode is far more than just a markup. It is executable - you can have executable code-blocks (in different languages) that interact with one another. It is interactive - there are TODO items, agendas, and scheduling that integrate with your workflow. It has built-in calendar, deadlines, and habit tracking. It has spreadsheets with calculations, like in Excel. It is insanely programmable. I use it for various things, even some unexpected like managing my dotfiles - simpler and more predictable than Nix or Stowed, org-mode creates an 'immutable' version of my system.
Sure, it is also a markup, but the markup is just the interface to a much richer computational document model.
So, what you're finding to be weird is only because you are unfamiliar with it. It is in fact highly pragmatic, and there's nothing weird about it; you just have not experienced that firsthand, and that's alright.
I get that Org-mode is extremely powerful, but I was talking about Org-social specifically. Take a look at the spec, does it use much programmability? To me it looks like just annotating a bunch of metadata plus a unique ID (which is actually just a timestamp, which seems problematic to me for a number of reasons, eg tracking edits, not being necessarily unique,...).
I don't understand what you're saying. If everyone on the team uses Excel to manipulate data and they share it around in .xlsx files, you wouldn't tell them "why not .csv?", right?
I'd say it's more like they're sending around csv tables in the body of emails and then writing VBA scripts to copy them into Excel. In that case, yeah, I might mention that there are better ways to do it.
There's some truth to the aphorism, "Emacs is a great operating system... if only it had a decent text editor."
I think Emacs is basically an elisp runtime that happens to have primitives like buffers, windows, etc upon which a text editor happened to be implemented.
It's more like a programming environment than a text editor. Sort of like Pharo Smalltalk, for example.
You can implement an HTTP server in elisp. You can render SVG, HTML, PDF. All kinds of things.
Emacs isn't an editor. It has an editor. And a bunch of other stuff. The core is written in C, but that's mostly a Lisp runtime and a display system. Everything else is written in elisp. If the runtime doesn't give you what you need, you can load dynamic libraries to extend its functionality.
I found for me that the epiphany came when I realised three things:
1. Key bindings are just calling Emacs functions in the current runtime, which you yourself can call from Elisp
2. Holy shit, you mean every keystroke is ALSO just a function that you can call yourself meaning you can automate everything with Elisp?!!
3. Wait. Emacs is just an Elisp runtime where some of the functions can edit text buffers!!!!
Why is this cool? Because it means that Emacs is NOT an editor - it’s a virtual machine holding libraries of functions that do useful things, which YOU then customise into YOUR editor.
In other words - Emacs is a toolkit that allows you creator your own editor/environment, customised to your specific workflow. And if you don’t like it, you have the power to fix it yourself, which is in contrast to every other editor I know of which was built by the editor developers with their own idea of how you should edit text
To go along with (2), "C-h k <KEY SEQUENCE>" and "M-x view-lossage" are excellent starting points for investigating what any key stroke means. From there, one can follow links in function and variable help all the way to the relevant elisp definitions.
If only that ease of hood-popping were more common.
The flaw in that metaphor is that elisp is a pretty suboptimal programming language for general-purpose programming. The standard library (in my limited experience) seems to use buffers as the base primitive and doesn’t help you very much if you want to do anything complicated without touching the current buffer.
This is a common misunderstanding about buffers. Buffers are the base primitive for text manipulation for a good reason; it’s a deliberate design decision not a handicap or a straitjacket. Think of a buffer as a string with a cursor in it, where it is always easy to manipulate the text at the cursor. (It’s implemented using a gap buffer <https://en.wikipedia.org/wiki/Gap_buffer>, but you don’t need to know that.)
The operations you can do on a buffer include not just the usual string primitives like insertion and deletion of text, but _any_ editing command that you could use as a user as well. For example, if you want to move the cursor to the beginning of the line, call `beginning-of-line`. This is exactly the same function that is bound to `C-a`. Want to move to the next line? That’s `next-line`, which is bound to the `down` key by default. Want to drop the mark at the cursor position? Call `set-mark`. Want to search for something? `re-search-forward`. Now that you’ve found what you were looking for, you want to remove it from the buffer? Call `kill-region`, same as if you had typed `C-w`.
And commands build on other, more primitive, commands to give you complex behaviors. There are commands for creating, parsing, and sending emails, making HTTP requests and parsing HTTP responses, creating and parsing JSON, XML or HTML, etc, etc. You can create some JSON in the current buffer, send it off to the server via HTTP, and when the response comes back it swaps you over to a new buffer with the response. Or you can ask it to parse the response and just give you the body, etc. Basically any command you could interactively use as an Emacs user will work as part of a new Elisp program simply by virtue of the fact that it works on the current buffer. And the new Elisp programs you write can be used as commands by the user, and as parts of the user’s next Elisp program.
And switching buffers it not slow; all the buffers are in memory at the same time and the “current” buffer is just a pointer. The only quirk is that the pointer is stored in a variable instead of being passed as an argument to every single command you run. And that’s a good thing, because you would soon get tired of passing the current buffer to every single function you call!
Lego is a "programming environment," so avoid the obvious contrarian nit
of "must be more general," and accept there's no better
language-environment combo for constructing workflows than elisp and
emacs -- yes, it's leaps better than bash and term.
Don't really see how the string (and other usual container types) or filesystem APIs are lacking in any significant way compared to stdlibs of other scripting languages.
I also believe that buffer as an abstraction strictly makes many harder things easier, to the point I often wonder about creating a native library based on elisp buffer manipulation APIs alone that could be embedded in other runtimes instead. So the without touching buffer is a premise/constraint I don't quite understand to begin with.
In this case, I'd view it more as an interactive mode to use ffmpeg?
That is, it isn't like emacs is the thing that is doing the trimming. It is just providing convenient access to ffmpeg to do that. That it is able to do this using roughly 300 lines of code is quite impressive and largely speaks to why people love doing things in emacs.
It would be one thing if this was code golfed to get to a working state. Reading the code, it is remarkably straight forward interactions with ffmpeg.
Emacs more like a platform like DOS or the Terminal/Shell/TUI combination than an editor like Vim/Micro. The wealth of libraries, all centered around the concept of buffers and windows, make it easy to integrate pretty much any other tools.
Is it an REPL? use comint.
Is it a tool that act on text files (lint, test,...)? Use compile
Do you need input with completion? Use the minibuffer.
Do you need multichoice selection? Use a buffer and mark stuff (there's a mode that you can extend from if you need to display tabulated data).
Do you need to define flags on the fly? Use transient.
Network request? Calling shell command? A combination of all the above? Emacs got your back.
And because it's a live programming environment, you can start quickly with a prototype (or just altering stuff) and then tweak things until you have a proper package.
To me the point is that Emacs is a customizable environment that allows you to whip up stuff like that fairly easily, and have it integrate with arbitrary other Emacs stuff. Standalone desktop programs are each their own separate little worlds. Emacs is a more integrated environment in that sense, compared to mainstream operating systems.
> It always seems to me like playing Doom on a pregnancy test
you can't do it >:( that reddit post is so annoying to me, the only bit of that which was "pregnancy test" was the plastic shell, everything else was replaced, but everyone keeps going "hey did you know they ran doom on a pregnancy test?"
I'm not really the type of person to do video editing or web browsing in Emacs, but I can still see the appeal.
A well-tuned emacs install is comfortable. I have my keybindings that do what I want them to do. I can visually organize my emacs frame (what is now called a GUI window) exactly how I want, with files taking up the parts of the screen that I want. I can be reading the README of some project I checked out and be curious about some terms, then just select it and send it off to my LLM. It's trivial to switch between Claude, OpenAI/ChatGPT, and Gemini depending on how much context I need to give.
It's like having personal space organized to your tastes. For some, their personal space can seem on the outside as a warzone of stuff, for others it's meticulously organized and labelled, but the key commonality is that it's personal space and that the owner of the space is comfortable in it. That's what emacs is. I don't need to learn a new set of keybindings or mouse clicks to unlock new functionality, I can just bring it into emacs.
Great comment, although I use emacs for everything code, writing, finanaces, task management still all these things are text so I don't get using emacs for non text things
What do you mean by "non-text things"? You are dealing with the computer, it's all about text and mostly text. Sure, it might be encoded and digitized, but even structured binary - is all just text. Even when you give a computer voice commands - they are just synthesized audio form of fucking text. Even with "turtles all the way down" - it's all turtles made of text.
Have you seen the gif in the blogpost? With the transient that has "Move Forward/Backward", "Increase", etc. commands? The commands that you'd have to send to the specialized app anyway - Emacs or not. In what form? Fucking text, of course.
Everything can be reduced to text. Sure, I'm of course pushing it here with my "all digital information reduces to bits, and thus could be text", but the meaningful processing requires understanding the inherent structure and relationships within that data.
It's like arguing that "all books are just sequences of letters". That's technically true, but meaningless without understanding grammar, semantics, and context.
What I'm saying is akin to: "First step to understanding all the books starts with understanding letters..."
Anyway, emojis are of course text - even though they are stored as encodings. For example, LLMs process them exactly like any other text characters - they're tokenized, embedded, and handled through the same mechanisms as words. I should've use a different analogy to make my point clear, but you know what I meant.
Well, in the context of the discussion, you can "teach" Emacs to play Pacman. Imagine sending left/right/up/down commands to a Pac-Man emulator or whatever. The emulator itself may not "understand" these commands in pure text, accepting some digital form of them, but whatever format it accepts, it probably can be reduced to sequences of alphanumerical characters.
Similarly, when the emulator broadcasts current coordinates for pieces, or sprites of them - they still can be reduced to plain text.
I'm sorry. I'll try not doing it again :)
I just caught a cold, lost sleep and overall have been feeling pretty lame. I don't typically lurk around the orange site, eagerly waiting for someone to mention Emacs.
I use exwm as my windows manager [1], so for me, everything is emacs-first. Therefore, trimming a video in emacs is more natural than using another program to do it. I love the experience of using exwm and emacs for everything whenever possible.
I did not "get it" from the post itself, but it linked to a post that mentioned "subed", subtitle editing for emacs with syncing with/control of video playback in mpv. I could see myself doing that and then would be happy if I could also trim the video while I am at it.
Modern emacs is surprisingly powerful, far from "Doom on a pregnancy test" (image display and UI widgets are just features).
Looking at the code for this solution (https://github.com/xenodium/dotsies/blob/main/emacs/ar/video...), it's under 400 lines (excluding the require of three very common libraries and an ffmpeg dependency). I'm not actually sure I could pull off this feature in 400 lines of JavaScript (and the binding logic for going from node to ffmpeg isn't going to come to my fingertips nearly as fast as the logic for emacs LISP, although I know that varies from person-to-person).
Plus, once it's in emacs it can glue to other things. If I want to grab video from an email and trim it, I have tools in emacs to fetch particular emails, etc.
I think the most reasonable way to think about emacs hacks like this is "I could do this in a shell script... But why would I when emacs gives me interactivity, a REPL, and the advantages of buffer manipulation as a metaphor?"
hmmm, I'll try. Think of these things like you think about using cli tools. If you ONLY had ffmpeg or imagemagick in isolation, there would be no benefit to using them on the command line. You are working with images and video after all. That's what GUI is for! Even if you end up using them, you use them through a GUI wrapper. I bet Resolve uses ffmpeg somewhere under the hood.
They don't work in isolation, though, and I bet you can easily think up a bunch of usecases for either. They're scriptable and they compose well, after all, so the tradeoff is worth it. You put up with the headache to automate that batch job of changing the intro sequence of the thousand video files and generate new thumbnails and put the new subtitles in one go.
In emacs, everything tends to be composable and scriptable. You are in GUI land but things feel powerful like in CLI land, except discoverable. It's the "vim is the text editor of the unix IDE" idea, except they put the whole unix into your editor. When people jokingly claim it's an OS they're only half joking. It's malleable. You are already running it. You are already familiar with the way it works, with the way you discover features, get help etc. Why start another program for a task like this?
Pretty neat. I use Emacs a lot, and also do quite a bit of video trimming. For people wondering "why Emacs?", here’s the use case: trimming video is mostly about writing down start/end times, sometimes with a note. That’s all text.
If you can turn that text directly into clips without switching to a separate video editor, it’s surprisingly efficient. Of course, this only makes sense if you already live in Emacs, then it reduces context switching, helps to keep the flow. If you don’t, it just looks odd. But it’s not about making a meme out of "doing everything in Emacs" - it is just a small tool that fits the workflow of people who are already in that environment.
This supports the meme of Emacs as an operating system. It would actually be nice if graphical integrations like that could be implemented as easily on our actual OSs.
This is pretty interesting; I had never thought of using Emacs as a video trimming thing, but why not? I've trimmed videos manually with FFmpeg and I've thought about building my own GUI to do it, so Emacs is as good a choice as any.
I don't really use Emacs but I love that people use it for everything; next step is a non-linear video editor.
I've been using emacs for light video editing too, but I took a different approach. Instead of having emacs deal with video directly, I use emacs as a JSON IPC client of mpv, over a unix socket, which handles the video. Over that IPC link I can control mpv playback (optional) and get timestamps/etc to add into an Edit Decision List (EDL) file.
Having been an Emacs user for 25+ years, I have a bunch of muscle memory.
So I created Emacs shortcuts for Davinci Resolve. (I create a lot of videos, and every time I've attempted to outsource editing, it has always been more work to review and give feedback than to just do it myself. I have a routine using the AI transcription features of Resolve that lets me edit video very fast. Editing a one-hour video might take 2-3 hours).
I'm also interested in hearing more about your process. I get bogged down going through my footage either comparing similar options, or trimming to the best action (best focus, least shake). I find the default Resolve keyboard shortcuts to be fast, and trim in the Edit mode (whatever #4 is called), but I'd love an AI augment that colour-coded clips based on which segments might be best (e.g., eyes/face in focus, or require least stabilisation, etc).
I have a Resolve Speed Editor panel but just found that to be far slower than the keyboard.
Very cool tool, and always amazing what Emacs can do...
If this isn’t your _daily_ use case and you only need to edit video from time to time, just ask your preferred LLM to give you the FFmpeg commands to cut, speed up, mute, flip, add text, etc.
This has worked quite well for me with simple use cases, and well no need to learn Emacs.
That’d be an awful way to cut video, because it wouldn’t help with the most important part: visualising and extracting the exact initial and final time stamps.
Especially if you don’t do this regularly, a GUI makes much more sense and saves you the frustration of having to sift through potentially wrong commands and figuring out what exactly to edit to fix the mistakes.
I’m not saying this is better than a GUI, but instead let me give you an example.
Sometimes I have movie clips A, B, and C. I want to trim part of A at the beginning and end, then stitch clip B to it while speeding it up by 2x, and finally add clip C at the end, also trimmed a bit. After that, I want to add some text at specific times for a specific duration. In the end, I’ll export everything in 1080p.
I know all of this can be done with Final Cut or any other video editing app using a GUI, or the cool Emacs tool above...
But for me this would mean (GUI example) downloading the app and watching YouTube tutorials just to learn what to click.
For simple video editing (and other tasks), I sometimes need to get the job done quickly without wanting to learn a whole new tool.
I found out that I can achieve sufficiently advanced video edits with FFmpeg commands produced step by step from a LLM.
If you think this is awful, ok. I thought it was neat and wanted to share the idea.
If you ever needed to do that more than once, using a basic video editor (of which there are many, free and open-source, no need for a commercial behemoth like Final Cut), playing with it for ten minutes once would give you all the knowledge you need forever, even when you are without access to your LLM. And you can keep the app installed, you don’t need to download it every time. There’s also no need to watch YouTube videos, most of these basic editors have evident interfaces that anyone could figure out on their own for simple tasks. People did figure out things before YouTube tutorials. Or hey, if you’re that keen on LLMs, ask them where the option you want is.
Furthermore, you have not addressed at all the crux of the point. How are you even getting the exact time stamps to give to the LLM of FFmpeg for the cut? Or how do you decide that 2x is the exact speedup you need? Or how do you know what size and position and text font and colour even make sense?
All of those are visual decisions which need confirmation because video is visual. It doesn’t make sense to blindly run lengthy FFmpeg commands over and over to see if the result is any good.
Again, totally fair points, and for many people a (simple) GUI is the right tool. I am not against GUIs or particularly pro LLMs; I just want to show an alternative way to solve video editing problems without judging any specifc technology.
Not all video work is visual-first storytelling. In engineering/lab contexts you often just need “good enough” trims, concatenation, speedups, and a few labels to document an experiment. As I said in another comment, I usually get the timestamps by noting them down while watching the video, or in rarer cases from timestamped sensor data.
Not the OP, but ffmpeg's documentation is pretty awful to navigate if you aren't an expert in it. It is very technical and exact, but fails to provide examples for most options.
For example, the fpsmax option says you can set the maximum frame rate using "Hz value, fraction or abbreviation." So now the user has to search for how any of these things are to be specified (does a bare 60 mean 60hz? Do you need to include Hz? Is it case sensitive? What are the abbreviations? What is the fraction a fraction of?). And that's a random option I found in the pile of documentation it has.
Maybe it's useful if you use it every day, but I completely understand why people use GUIs whose purpose is to construct the command. Or even LLMs to do the same thing.
In my common use case, I note down the timestamps of the cuts. No LLM needed here.
I know there are options for everything in FFmpeg, and I’m thankful to the community and maintainers for providing such a powerful and well-documented tool. I sometimes just want a quick video edit that doesn’t involve reading the man pages for minutes or hours.
Hey, thanks for reporting. I had a couple of links that went haywire. Please lemme know if you run into other issues. First link to https://xenodium.com/seek-and-you-shall-find was broken. Should work fine now.
i love this but dont use emacs. i wish that existing tools were lighter weight at video trimming. Screenflow is the lightest i know of but fails badly at some video formats and sometimes OoMs. if it had a better architecture streaming bytes i feel like it might not have that problem.
I find my approach lightweight, but it’s still around 80 lines of code so a tad big to share as an HN comment. It also requires a bit of explanation to set up (though once done, it’s incredibly simple to use) and the output is custom to my needs.
Essentially, I already use mpv as my video player, which in addition to being very fast also allows seeking frame-by-frame, saving and returning to positions, and running Lua scripts. So I wrote some Lua which reacts to a specific key press by saving the current video timestamp. Press it again and it records a second timestamp, then it fires off Handbrake CLI (FFmpeg could also work) to do the cutting and save the trimmed file.
If you search online for “mpv cut video” you should find some plugins with that same idea. I have never used them so I can’t attest to how good or bad they are. All the ones I found are larger than my approach, but then again I just made mine do exactly what I want without customisation so that’s to be expected.
One specific advice I’ll give, if you go this approach and are on the Apple ecosystem: Use the Handbrake CLI instead of FFmpeg to do the cutting. FFmpeg was super frustrating and I was unable to get a result where the output video worked properly in Quick Look and sending through iMessage; after too long trying to get it to work and messing with a myriad flags, I switched to Handbrake with no weird settings and it’s been working flawlessly ever since.
> Screenflow is the lightest i know of but fails badly at some video formats and sometimes OoMs
I'm a big fan of ScreenFlow, but light it is not ;) If you just want to trim and assuming you are on macOS, QuickTime's "Edit > Trim..." does the job. It's what I used before doing the Emacs thingy.
Lightweight? I don't mind a bit of weight if its versatile. But when I want to do things fast, I use Shotcut (free, open source) which is much easier to use than e.g. ffmpeg. There exist a number of good tutorials showing how to accomplish tasks.
P.S. What's great about tools like emacs or ffmpeg is their usability via a command line and thus scripting. Which even works on an Android device running inside Termux.
Transient is indeed very nice, even though I wish its programmable API was simpler and made more sense, sometimes it feels annoyingly quirky and unreasonably complex.
Shameless plug for further ideation and discussion: https://news.ycombinator.com/item?id=44025635 - it's a long video - ~1hr, it's unscripted and unedited. I guess I just couldn't fit all my Transient use cases in a smaller one. I have a lot of these bad boys in my Emacs.
Typical reaction from someone who has no clue. Emacs isn’t a “hammer”; it's more like “glue” - you don't have to do everything _with_ Emacs, but it can definitely mediate and delegate specific tasks to more specialized tools - it can give you the sense of doing everything _through_ Emacs.
Why would anyone do that? Because plain text rocks.
> There is no equivalent in any other communication technology for the social, communicative, cognitive and reflective complexity ¹
And there's simply nothing better today than Emacs for dealing with the plain text. Neovim comes close, but still can't match it.
I know that you are a stalwart Emacs supporter — I've seen your posts before, and still remember your airplane awakening — but don't you think that more carrot than stick would be more effective at convincing people to use Emacs?
I may not sound nice at times, but I strive to be kind. Kindness implies honesty. Why is it easier to learn a foreign language around kids? Because kids (with no malice in their hearts) would tell you the truth - when you mispronounce things, they'd laugh at your mistakes. When it comes to spreading truth about Emacs, I'd rather be like a kid.
I don't think the comment above justified characterizing it as a "stick", but I suppose that is something you wanted to say to me long ago, and I appreciate your veracity. If you give me more constructive suggestions for changing my rhetoric, I may even promise to consider changing my narrative, but at this point, I don't even see what's wrong with it, really.
You don’t have to tell me what Emacs is capable of. Been using it for all my computational use-cases for years. But migrated away from it because it is obvious that each use case has better solutions outside Emacs. I am convinced the Unix way (do one thing and do it well, connect them via pipes and text) is the way to go.
> I am convinced the Unix way (do one thing and do it well, connect them via pipes and text) is the way to go.
I was convinced too, but after the amount of work required to convince terminal, tmux and neovim to be friends I thought “It would be nice if all of it would be in one sane configuration language and actually debuggable!”
These days, if I need unix tools (use rg a lot) I plug them into emacs.
The Unix philosophy has limits - text pipes work great for linear data processing, but often break down for interactive stateful workflows. Many modern tasks require rich data structures, not just text streams. Also, context switching between tools loses state and mental flow.
Advocates of "Unix philosophy" often lay it out as if it's the exact opposite of the "Emacs way", which is pretty inaccurate - Emacs can actually be viewed as "Unix philosophy+" - it does do one thing well: text manipulation+extensibility.
You can still use Unix tools from within Emacs - shell commands, compilation, etc. Moreover - you can pipe the result of a command into an Emacs buffer and the content of that buffer into another command, etc. And unlike pure terminal workflows, you gain persistent state, shared buffers and unified keybindings across all operations.
Unix philosophy is brilliant for system administration and data processing, I would never try to convince anyone not to use, e.g. Neovim, I myself reach for it when I see the need. Emacs philosophy is brilliant, for example, for knowledge work and creative tasks, like the example in the OP's blogpost.
These tools - Emacs, Neovim, and Unix - embody some of the greatest ideas in computer science throughout its relatively short history. One would have to be extremely short-sighted not to recognize the immense value in any of them. Frankly, mastering all three of them may make you feel like the Chuck Norris of computing.
This may be a bit pedantic, but Emacs-as-a-hammer metaphor might work better than you intended, since a hammer is definitely useful for more than just hitting nails. This seems pretty neat to me.
lol I did work in the smarwatch space for a good chunk of time. While I totally get the nail thing, this is as quick/lightweight as it gets after the command line, which is a lot more cumbersome for this use case.
It’s obvious that the author wrote the simplest code that could work, rather than spending extra time on complexities that might not be needed. They were quite pragmatic and achieved a useful and usable result. It’s commendable, so you shouldn’t sneer.
It's not "boneheaded". Shit ain't stupid if thy shit works. This HN user is just a troll with condescending traits and arrogant tendencies, don't feed their ego.
I just don't think it's that bad. Even if it spawns a process for each frame when you're scrubbing, it seems to run fast enough on my computer.
If you want to do a lot of advanced video editing then yeah use a real editor, but if you're just doing a quick trim it's really not a big deal to spin up a few dozen very-short-lived processes.
It’s probably be more efficient to convert the video to multiple frames in batches, and then buffer them. Spawning processes is pretty resource intensive.
I mean, "resource intensive"; that's technically true but the processes are pretty short-lived and only one spawns at a time as far as I can tell. It's definitely more overhead than an in-thread thing, but still not that much on modern computers.
I agree that it would be more efficient to do these things in batches but I really don't think its current state is that bad, at least for a V1.
This is impressive, but (and probably because I'm not the intended audience for this post) I don't get it, I kind of want to get it though. With "it" I mean making Emacs do X, where X is something far from editing text files. It always seems to me like playing Doom on a pregnancy test. Sure you can do it, sure it's impressive, but should you?
n.b. I'm a C# developer that has accepted my fate and use Visual Studio to earn a living, though I've made sure I know my tool, flaws and merits, better than most developers I've met/worked with. My first job as a programmer was writing C++ code in Emacs and can't remember anything negative about that experience (other than getting used to ctrl+x, ctrl+s for saving and, by reflex, doing the same in Excel, and losing a big part of the document that I had just selected to move, because Excel couldn't undo past last save).
Reading the (at the time I'm writing this) 13 comments on this post I see mentions of at least three lightweight programs that does this. What other than "the mountain is there" makes someone think Emacs would be the tool for this? As a Resolve user I know what tool I'd reach for even if using a multi GB, Hollywood grade, non linear editor, compositor and color grader for trimming a short video clip is about as ridiculously overpowered as using a sledge hammer to press a key (and I did exactly that just a few days ago).
Like I said, I'm most likely not "getting it", on multiple levels. Please educate me, why would I use Emacs for this or any of the page upon page of "strange" use cases you find if you search for "Emacs" here on HN. I know Emacs is a powerful editor but I can't for the life of me understand why I would use it to trim video clips.
Emacs is weird. I think it changed something in my brain. Before Emacs, I never thought I would ever try controlling video playback from my editor. "Just why?" I probably would've said. I never thought I'd be trying to get the text from the active tab in my browser. Or search through my browser history. Or OCR the content of my clipboard, or control my WM. Dang, before Emacs, it didn't even occur to me to try to type just about any text in my text editor - which now makes absolute sense - why would I ever bother typing in my browser window, Slack, Zoom, or email client?
In Emacs, I have all the tools I need for dealing with text - thesaurus, spell-checking, definition and etymology lookup, search engines, translation, LLMs, etc. Why, oh why, wouldn't I ever try typing anything longer than two words in anything else?
Like, for example, while typing this very comment, I may come across a thought: "I think I already made a similar comment some time ago, let me find it..." What would a regular user do? They'd switch to the browser, navigate to HN, scroll to the bottom, type search query, lookup on the page, jump to the next, keep paging until they find it, copy, switch back, paste... What would an experienced Emacs user do? They'd search for it without ever leaving their editor, grab the stuff from the buffer and paste it - all within just a few keystrokes. Or if I need to find a url in my browser history - I'd just search for it and insert in-place - two keystrokes+search query.
It's not just faster - it is profoundly satisfying and liberating. It gives you the feeling of being in control. You don't have to deal with the quirks of specialized apps; you don't need to memorize tons of their specific keybindings; it gives you a straight path to extracting or injecting plain text.
That's why those who never made a wholehearted attempt to use Emacs just never get it. And those who have, never can understand why others don't even try to recognize the value.
I hear stories like this and I can kind of see the proposition. But I’d be more eager to, somehow, see a long-running example of it all at work. I think I’m not so skeptical about what it can do, but somewhat skeptical that it’s actually as much of a paradigm shift as some describe it to be. I wonder if oftentimes it falls in the enjoyable hobby category of, “I just really enjoy upgrading my workshop.”
It is indisputably not a hobby, at least for me, personally it ain't. I've been coding long enough to see a difference between "oh, what a nice gimmick" and "how the fuck would I even do that, if I didn't know this way existed...". Long. My first programming language was Sinclair BASIC. The second PL I learned was Pascal. I picked up a few more over the years. I'm not trying to show off, nor am I claiming to be an outstanding programmer - I'm neither great nor terrible. I'm just saying I've been doing this shit for a long time, that's all.
It isn't a hobby, because Vim and Emacs allow me to perform in a way that I consider far more enjoyable, productive and satisfactory than I ever had before them. That is of course on a personal empirical basis - I cannot promise them having the same effect on anyone else.
In my opinion, after many years using many different tools, techniques, ideas and methodologies, frameworks, approaches, systems, platforms, workflows, philosophies, paradigms, strategies, practices, concepts, models, theories, and experiments, I personally find these two to be exactly the paradigm shift — in comparison to my prior experience when I didn't have them.
But let me be more specific - the paradigm shift I see is not in Emacs or Neovim as tools themselves. The paradigm shift I sense is in the grand ideas behind these tools - modal navigation and Lisp.
I honestly don't know why more people don't gravitate towards these ideas. Perhaps, because these ideas are kind of like 'meditation' - people say one can only experience the mind shift after practicing it for some time. I wouldn't know - I never practiced mediation for long. And that time required to see the shift can differ for every person - some may grok it quickly, for some, it may take decades without ever even clicking.
Also, you're wrong about "upgrading one's workshop" - it's a misconception that longtime Emacs users constantly have to tweak their configs. My config for example is pretty stable; I often make changes to it not because I have no choice, but because the task at hand calls for it. I write a lot of Lisp because it's an instrument for achieving specific goals and solving specific puzzles - work for which I get paid real amounts of real money. I get paid to use Emacs, not the opposite. So, no: definitely not a hobby.
> It isn't a hobby, because Vim and Emacs allow me to perform in a way that I consider far more enjoyable, productive and satisfactory than I ever had before them. That is of course on a personal empirical basis - I cannot promise them having the same effect on anyone else.
> I honestly don't know why more people don't gravitate towards these ideas. Perhaps, because these ideas are kind of like 'meditation' - people say one can only experience the mind shift after practicing it for some time.
idk this reads a lot like tl;dr: it's a hobby.
It doesn't make sense to define something as a "hobby" just because there's some enjoyable or, in the quote you made, "meditation" and "mind shift" parts in it.
What's a "hobby" anyway? As the one you commented on, I have also been programming for a very long time. And why do I continue to do that, instead of changing to some management role? The answer to that is that I enjoy programming. I enjoy making tools to make the tools to create the thing I want to create, and to have enough stuff I want to create, I have a job which provides that in abundance. There are no hard borders between "hobby" and "job". It's a useless distinction in this case.
YES! Thank you! That's exactly it.
You know what really makes Emacs different than other editors and IDEs? Consider many ways one can transform selected text in VSCode. Let's say there are maybe 3-4 ways, with some extensions it can get to, I dunno a dozen?
Now consider that Emacs allows you virtually unlimited ways of doing the same thing. Because there are virtually unlimited ways to program that behavior.
In VSCode, you'd be clicking buttons and using shortcuts. Imagine if you had virtually unlimited number of buttons there? For different ways of running a command. That would be insane, right?
Well, here comes the argument if VSCode's (default) way maybe actually better? Some may argue about cognitive overhead - flexibility isn't free after all. Some programmers prefer tools to be tools rather than clay, yeah?
That's totally okay, I'm fine with all that. I'm just seriously baffled as to why Emacs is such an underrated and misunderstood tool. Why don't more programmers even attempt to try it? If you are a programmer, for sure, you should be, at least to a certain degree, curious about the ultimate programmable environment, no?
And don't bring the argument that non-emacs things are also "extendable". In virtually none of them can I open a buffer and add yet another way to transform selected text. Right there, without even saving that code in a file.
Well, sure, to a certain degree it is a hobby. Here, let me quickly run (define-it-at-point) command while I'm typing this comment, because of course I can do that in Emacs.
First definition says "it's a horse", then there's another:
> Any favorite object, pursuit, or topic; that which a person persistently pursues or dwells upon with zeal or delight, as if riding a horse.
Sure, in that sense it can be characterized as a hobby. What's the opposite of a hobby? Well, it's either "work", "chore" or "obligation"— all three kind of fit for my example. I use Emacs at work, for work, to do stuff I get paid for - check! It sometimes feels like a chore - well, what tool you use everyday doesn't? Sometimes you need to update it, delete stale cache files, reinstall, fix dependencies, etc, so can feel like a chore - check! Whenever I open-source some piece of code that extends Emacs, I have an obligation not to break it, etc. So the third one fits too. So, like I said - not a fucking hobby.
Shall we continue quibbling over words, how what reads to you is not what I meant and maybe even discuss how semantic meaning of words may change due to interlocutors' backgrounds, age, mood or the current lunar phase, or do you have some other kind of nitpicking in mind?
I do like having access to stuff while doing similar stuff. Perhaps I'm just a little too lazy to learn that stuff while still getting paid to know other stuff. And I do have just about every tool/feature you mentioned, just not in a single user interface.
I guess the path to Emacs was more of a possibility/probability earlier in my career and I might find it later but for now I'll alt+tab to the browser and/or open a new tab when I need to look up any etymology and stick to navigating around Visual Studio like a pro while they still pay me to do it.
The nice thing with emacs is that you can do as much or as little as you want with it. For me it started with basic text editing, then doing some git stuff with magit, then realizing emacs has wonderful capabilities around notetaking and to-do management in org-mode.
Like you, though, I work in orgs that are very Windows heavy, so I tend to use it more for my personal stuff rather than in my day job
Yeah I know some folks who only really use it for basic text editing and org-mode notetaking. I know writers who only use it to write. I know coders who only use it to code. etc.
> I do have just about every tool/feature you mentioned, just not in a single user interface.
Well, just like I said - you're not getting it, we're talking past each other. It isn't about a "single interface" - not about cramming everything into one window, it's rather about seamless workflow integration. It's like having a command center that orchestrates your existing tools, rather than replacing them. The power isn't in the interface - it's in the programmable glue between your tools.
You say: "I'd open a new tab if I need etymology..." Sure, on the surface it feels like a fair point. However, when you have the ability to request something from any tool or service "at-point", right in the middle of typing a sentence or solving a specific task - it simplifes so many things, and you tend to use those tools more. It's basic psychological phenomenon called 'convenience effect'.
But that's the only half story of it. Here's the practical example I often use as an evidence. I use Google Translate, alright? On its own there's nothing special about it - other editors and IDEs, also probably have integrations like that if not even nicer with GTranslate or some other translating service, right? Yet check this out. I'm learning Spanish, and when I want to translate something like "Colonel was born in 1968", what would GTranslate do? It would translate the text leaving the numbers intact, and that's totally expected. But guess what? I am trying to gain better familiarity with numbers in Spanish, I really do need to see them in their written form.
How long do you think it took me to solve that little personal discomfort? No longer than fifteen minutes. First, I needed to find out what actually was sending the payload to GTtranslate endpoints. I launched Emacs' built-in profiler and performed a task of translation. I found the function. Then I advised it. Advising is an Emacs Lisp mechanism to prepend, append or override the behavior of any given function - built-in or third-party. So, I figured that if I convert the numbers to text first, then send the payload with that text instead of numbers, it will work exactly as I wanted.
I couldn't even find an implementation of numbers-to-word in Elisp, and I didn't want to spend any time trying to write one. So I delegated the task to an npm package. Now, my advising function adjusts the behavior of 'translate' function (that sends the payload) by detecting the numbers in the text and then runs nodejs, changing the payload, so GTranslate spits out: "Coronel nació en mil novecientos sesenta y ocho"
Did I have to write my own browser extension for that? Nope. Did I have to figure out how GTranslate endpoints work? Nope - I didn't even have to open their documentation page. Did I have to re-implement the entire command that sends the payload? Nope - I just needed to tweak one, specific aspect of it, with extreme granularity - the body of the function is ten lines long. If that's not some blackmagickfuckery, I don't know what that is. Maaaan, I wish someone has showed me some shit like that when I was much younger.
> Perhaps I'm just a little too lazy to learn that stuff
Here's a thing about ideas - and don't consider Emacs as a concrete tool, a mere editor, but think of the fundamental idea behind it. You don't need to "learn" ideas. You just have to cultivate some level of curiosity about them. Sure, you may later have to spend considerable time learning the concrete tools behind those ideas, but absorbing the idea is the first step.
And grokking basic fundamentals about the idea of Lisp is pretty trivial - one just needs to learn mainly two things - structural editing and REPL-driven development. Some may argue that even those are not specifically necessary to begin the journey.
You know how the "do" in Taekwondo, Judo, Aikido, Karate-do stands for "path" or "way"? There's no truly "learning" Aikido, you either practice it or you don't. It's a lifelong practice rather than something you "master" or "complete." The idea of Lisp is similar - it's not really something you "learn" in the traditional sense and then move on from. You practice thinking in Lisp.
The fundamental principles of Lisp - code as data, the power of the REPL, recursive thinking, functional approaches - these aren't just techniques you acquire. They become a way of approaching problems, a mindset you cultivate through practice. The practice never really ends - it just deepens.
I haven't done any martial arts, so I'm just spitting words here, but I bet, if I ask anyone who practiced Aikido for a long time if it makes their lives any better, I bet they'd tell me some koans about zen master pouring tea or some other shit that I'd immediately dismiss as complete bullshit, so I wouldn't blame you if you take my words the same way.
> I guess the path to Emacs was more of a possibility/probability earlier in my career
Just like Aikido welcomes practitioners at any age or stage of life, Lisp is always ready for new practitioners. The fundamental principles align here in more ways than one could imagine - "the journey is the destination", "wisdom over athleticism", etc. Many people discover their deepest appreciation for Lisp (or Aikido) later in life, when they have the patience and perspective to appreciate the subtleties. The best time to start is always now.
I really want to learn eMacs but most of my work is in Jupiter notebooks in terra.bio - can eMacs interact with that?
https://github.com/emacs-jupyter/jupyter exists. No idea if it’s awesome or terrible.
FWIW, Org Mode is what a native Emacs user might reach for as alternative to Jupyter notebooks: https://michaelneuper.com/posts/replace-jupyter-notebook-wit... That doesn’t imply that you should both try Emacs and replace Jupyter! Just be aware that if either you are using Jupyter for your own reasons or working with like-minded team there is an alternative which may be preferable for your use-case.
Jupyter support in Emacs is pretty bad, tbh. I keep trying every once in a while (as lots of companies prefer notebooks) and it basically never works.
You could probably get it working locally for yourself but in corporate environments it can be annoyingly hard.
org-mode is a better choice, but note that it's not specialised for Python (which is good and bad) so you may need to wire up some stuff (I mostly use R for personal stuff and that works very well).
How are you integrating with things like HN or your browser history?
I'm glad you asked:
https://www.youtube.com/watch?v=ud3Gmxg5UZg - Browsing Reddit and HackerNews In Emacs (7 minutes).
If you don't want to watch it:
https://github.com/thanhvg/emacs-hnreader - for browsing HN.
https://github.com/thanhvg/emacs-reddigg - for browsing Reddit.
https://github.com/agzam/consult-hn - for searching through HN.
https://github.com/agzam/browser-hist.el - for browser history.
Pfft, you call that an emacs-HN integration? Something tells me you had to bring in the browser at some point, either when reading this message, or writing your reply. I am using nnhackernews. Now that's a real emacs-HN integration.
Sure, that's just another package I forgot existed. Guess what? You can still use all of them together in the same instance of Emacs and they probably wouldn't even complain about it.
Ah. I think I vaguely remember now why I chose thanhvg/emacs-hnreader instead of clarete/hackernews, because the former renders buffers in Org-mode.
Per the comment, he doesn’t have to, all prior written text is nicely stored in a file (probably an org file), already open in emacs.
this is inspiring, I am slowly getting to that same conclusion but in neovim... if I write text I want all my nvim fancyness... because oh boy is it fancy!
Yup, Neovim is very awesome, I use it myself pretty much every day whenever I need to ssh to a remote host. There are many reasons though for why it is unlikely to dethrone Emacs as my main driver. Just like Emacs could never fully replace my photo-editing app.
It saddens me how people of Emacs often reject vim navigation outright, just as the broader programming community tends to dismiss the fundamental ideas that drive Emacs.
Neither represents a dogmatic religion, nor do they embody fundamental, conflicting truths about computing. No one needs to choose one and commit to it exclusively - they are simply tools, built upon some brilliant foundational concepts. Understanding and utilizing the ideas behind them may literally transform your life in mind-blowingly positive ways. I wish more people contemplated this profound truth, instead of thinking they have to stick with one, particular way of things.
I used Vim for 5 years before I eventually made the switch to Emacs. The reason I switched was because I needed an alternative to stop my hands from hurting all the time. Because having to slam every key at full force (because a missed input can wreak absolute havoc) was really taking its toll on both my hands. The combination of using standard Emacs bindings and the Dvorak keyboard layout have improved things significantly.
Embracing Evil has been totally worth it. My cursor now teleports around the buffer at the speed of thought.
Evil mode is fantastic. Not only am I fascinated by how nicely it works, I'm just impressed that it's never been a built-in feature of Emacs. It definitely doesn't feel that way. It feels like a baked-in, first-class thing.
Here's one thing about vim-navigation. Gary Bernhardt (the WAT talk guy) once said: "There's no vim-mode there's only Vim" and he was right - to a certain degree. All the different extensions and attempts to bring vim-navigation to non-vim editors have glaring deficiencies - all of them - VSCode doesn't fully vim, IntelliJ doesn't do it comprehensively, Sublime can't properly vim, etc. With one notable exception. Emacs actually vims better than vim/gvim/neovim. I'm saying this with the full-blown confidence of a die-hard vimmer.
The way Emacs implements Evil-mode and its extensions is the ultimate compliment to its design. If there's a model of a plane that can perform a vertical landing, yet never actually needs to use it, I would still love that model over any other planes, even if the feature is purely accidental. The fact that it can do so alone would be great evidence of amazing engineering. Evil-mode is absolutely one of the most celebrated achievements of Emacs, complementing other remarkable packages like Org, Magit and many others.
Emacs is the WeChat of Gnu/Linux.
As an Emacs users who often tries to do as many things as possible in Emacs, I would say that the more stuff you can do in Emacs, the more the various features in Emacs compound with each other, giving you more utility.
For example, I use the Verb package for making HTTP requests. So with Emacs as my HTTP client, I can do bulk HTTP request calls with keyboard macros. The HTTP requests can be stored in org-mode. I can write custom Elisp for special authentication scenarios. I can create new commands if I need them.
For this example, I can imagine (haven't used this myself) scenarios like creating a keyboard macro to shave off the first X seconds of a video usable with dired.
Some non-text-editing things in Emacs that are actually extremely useful:
Using a well thought-out Emacs interface for anything is one of the biggest sources of joy in my technical life.Using well thought out interfaces is a joy wherever we find them.
Something in your comment made me remember a DOS based file "explorer". Screen split down the middle with a folder-tree and file list on both sides. I remember hardly ever turning on the computer without starting that for one task or another. That was some serious UI pleasure, at least for the time. Ha, found it:
https://handwiki.org/wiki/Software:File_Commander
Ah, the nostalgia!
Nostalgia no more! Midnight Commander/4DOS style file management can be achieved with Emacs Dired today and then some.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...
For your consideration, I built a keyboard-driven menu interface for Dired called Casual to help with discovery. https://kickingvegas.github.io/casual/Dired.html
In my opinion Dired is the best way to rename files bar none (wdired-mode)...
Getting deep enough into it, it basically becomes your shell, complete with the ability shells have to orchestrate multiple programs into a meta-program.
An Emacs tool to trim video most likely has a conventional Emacs API, conventional Emacs documentation, and was developed using conventional Emacs user personas. Modulo the skill of the tool’s developer, this means it won’t require a lot of unnecessary brain cycles to learn or use or automate.
It won’t require switching to a browser. It won’t require creating an account. No going to the app store. No license consent. No dangerous program warning. No turn on notifications. No unlock premium features. No an update is available. No marketing emails. No cookies.
It’s just gonna STFU and do what it says it does in a way that makes sense. And if it is good enough, it’s good enough. It won’t add bullshit to your day.
While I'm not an Emacs aficionado and I find some of the stuff that people squeeze into Emacs weird [0], I have to vouch for OP here. It's a front end for ffmpeg. ffmpeg is a text-based utility and Emacs is a text editor. That actually makes sense. And judging by the screengrab it's a lot more ergonomic than plain ffmpeg. If I were an Emacs user I'd definitely consider using this, and it makes me kind of jealous.
[0] recent example from here: a proto social network that runs via org-files-over-http (as if we didn't have a markup language designed for http already) https://news.ycombinator.com/item?id=44889354
> if we didn't have a markup language designed for http already
Org-mode is far more than just a markup. It is executable - you can have executable code-blocks (in different languages) that interact with one another. It is interactive - there are TODO items, agendas, and scheduling that integrate with your workflow. It has built-in calendar, deadlines, and habit tracking. It has spreadsheets with calculations, like in Excel. It is insanely programmable. I use it for various things, even some unexpected like managing my dotfiles - simpler and more predictable than Nix or Stowed, org-mode creates an 'immutable' version of my system.
Sure, it is also a markup, but the markup is just the interface to a much richer computational document model.
So, what you're finding to be weird is only because you are unfamiliar with it. It is in fact highly pragmatic, and there's nothing weird about it; you just have not experienced that firsthand, and that's alright.
I get that Org-mode is extremely powerful, but I was talking about Org-social specifically. Take a look at the spec, does it use much programmability? To me it looks like just annotating a bunch of metadata plus a unique ID (which is actually just a timestamp, which seems problematic to me for a number of reasons, eg tracking edits, not being necessarily unique,...).
I don't understand what you're saying. If everyone on the team uses Excel to manipulate data and they share it around in .xlsx files, you wouldn't tell them "why not .csv?", right?
I'd say it's more like they're sending around csv tables in the body of emails and then writing VBA scripts to copy them into Excel. In that case, yeah, I might mention that there are better ways to do it.
There's some truth to the aphorism, "Emacs is a great operating system... if only it had a decent text editor."
I think Emacs is basically an elisp runtime that happens to have primitives like buffers, windows, etc upon which a text editor happened to be implemented.
It's more like a programming environment than a text editor. Sort of like Pharo Smalltalk, for example.
You can implement an HTTP server in elisp. You can render SVG, HTML, PDF. All kinds of things.
This is the answer.
Emacs isn't an editor. It has an editor. And a bunch of other stuff. The core is written in C, but that's mostly a Lisp runtime and a display system. Everything else is written in elisp. If the runtime doesn't give you what you need, you can load dynamic libraries to extend its functionality.
lol, logged in to say the same thing!
I found for me that the epiphany came when I realised three things:
1. Key bindings are just calling Emacs functions in the current runtime, which you yourself can call from Elisp
2. Holy shit, you mean every keystroke is ALSO just a function that you can call yourself meaning you can automate everything with Elisp?!!
3. Wait. Emacs is just an Elisp runtime where some of the functions can edit text buffers!!!!
Why is this cool? Because it means that Emacs is NOT an editor - it’s a virtual machine holding libraries of functions that do useful things, which YOU then customise into YOUR editor.
In other words - Emacs is a toolkit that allows you creator your own editor/environment, customised to your specific workflow. And if you don’t like it, you have the power to fix it yourself, which is in contrast to every other editor I know of which was built by the editor developers with their own idea of how you should edit text
To go along with (2), "C-h k <KEY SEQUENCE>" and "M-x view-lossage" are excellent starting points for investigating what any key stroke means. From there, one can follow links in function and variable help all the way to the relevant elisp definitions.
If only that ease of hood-popping were more common.
The flaw in that metaphor is that elisp is a pretty suboptimal programming language for general-purpose programming. The standard library (in my limited experience) seems to use buffers as the base primitive and doesn’t help you very much if you want to do anything complicated without touching the current buffer.
This is a common misunderstanding about buffers. Buffers are the base primitive for text manipulation for a good reason; it’s a deliberate design decision not a handicap or a straitjacket. Think of a buffer as a string with a cursor in it, where it is always easy to manipulate the text at the cursor. (It’s implemented using a gap buffer <https://en.wikipedia.org/wiki/Gap_buffer>, but you don’t need to know that.)
The operations you can do on a buffer include not just the usual string primitives like insertion and deletion of text, but _any_ editing command that you could use as a user as well. For example, if you want to move the cursor to the beginning of the line, call `beginning-of-line`. This is exactly the same function that is bound to `C-a`. Want to move to the next line? That’s `next-line`, which is bound to the `down` key by default. Want to drop the mark at the cursor position? Call `set-mark`. Want to search for something? `re-search-forward`. Now that you’ve found what you were looking for, you want to remove it from the buffer? Call `kill-region`, same as if you had typed `C-w`.
And commands build on other, more primitive, commands to give you complex behaviors. There are commands for creating, parsing, and sending emails, making HTTP requests and parsing HTTP responses, creating and parsing JSON, XML or HTML, etc, etc. You can create some JSON in the current buffer, send it off to the server via HTTP, and when the response comes back it swaps you over to a new buffer with the response. Or you can ask it to parse the response and just give you the body, etc. Basically any command you could interactively use as an Emacs user will work as part of a new Elisp program simply by virtue of the fact that it works on the current buffer. And the new Elisp programs you write can be used as commands by the user, and as parts of the user’s next Elisp program.
And switching buffers it not slow; all the buffers are in memory at the same time and the “current” buffer is just a pointer. The only quirk is that the pointer is stored in a variable instead of being passed as an argument to every single command you run. And that’s a good thing, because you would soon get tired of passing the current buffer to every single function you call!
Lego is a "programming environment," so avoid the obvious contrarian nit of "must be more general," and accept there's no better language-environment combo for constructing workflows than elisp and emacs -- yes, it's leaps better than bash and term.
There is: my OS plus Python, Ruby, even JavaScript, or any other modern scripting language. macOS even supports Emacs keys globally!
Don't really see how the string (and other usual container types) or filesystem APIs are lacking in any significant way compared to stdlibs of other scripting languages.
I also believe that buffer as an abstraction strictly makes many harder things easier, to the point I often wonder about creating a native library based on elisp buffer manipulation APIs alone that could be embedded in other runtimes instead. So the without touching buffer is a premise/constraint I don't quite understand to begin with.
> elisp is a pretty suboptimal programming language for general-purpose programming.
Well, because it ain't. it isn't a general-purpose language. It serves a single, specific purpose and excels at that function remarkably well.
> if you want to do anything complicated
Then you'd delegate the task to more specialized tools, possibly written in general-purpose PLs. Which Elisp is not.
Elisp is pretty good at what it allows for: quickly hacking code.
Buffers are quite good as a primitive: almost every kind of information snapshot can fit in a buffer. It’s kind of a blackboard in a math room.
In this case, I'd view it more as an interactive mode to use ffmpeg?
That is, it isn't like emacs is the thing that is doing the trimming. It is just providing convenient access to ffmpeg to do that. That it is able to do this using roughly 300 lines of code is quite impressive and largely speaks to why people love doing things in emacs.
It would be one thing if this was code golfed to get to a working state. Reading the code, it is remarkably straight forward interactions with ffmpeg.
Emacs more like a platform like DOS or the Terminal/Shell/TUI combination than an editor like Vim/Micro. The wealth of libraries, all centered around the concept of buffers and windows, make it easy to integrate pretty much any other tools.
Is it an REPL? use comint.
Is it a tool that act on text files (lint, test,...)? Use compile
Do you need input with completion? Use the minibuffer.
Do you need multichoice selection? Use a buffer and mark stuff (there's a mode that you can extend from if you need to display tabulated data).
Do you need to define flags on the fly? Use transient.
Network request? Calling shell command? A combination of all the above? Emacs got your back.
And because it's a live programming environment, you can start quickly with a prototype (or just altering stuff) and then tweak things until you have a proper package.
To me the point is that Emacs is a customizable environment that allows you to whip up stuff like that fairly easily, and have it integrate with arbitrary other Emacs stuff. Standalone desktop programs are each their own separate little worlds. Emacs is a more integrated environment in that sense, compared to mainstream operating systems.
> It always seems to me like playing Doom on a pregnancy test
you can't do it >:( that reddit post is so annoying to me, the only bit of that which was "pregnancy test" was the plastic shell, everything else was replaced, but everyone keeps going "hey did you know they ran doom on a pregnancy test?"
(and breathe...)
I'm not really the type of person to do video editing or web browsing in Emacs, but I can still see the appeal.
A well-tuned emacs install is comfortable. I have my keybindings that do what I want them to do. I can visually organize my emacs frame (what is now called a GUI window) exactly how I want, with files taking up the parts of the screen that I want. I can be reading the README of some project I checked out and be curious about some terms, then just select it and send it off to my LLM. It's trivial to switch between Claude, OpenAI/ChatGPT, and Gemini depending on how much context I need to give.
It's like having personal space organized to your tastes. For some, their personal space can seem on the outside as a warzone of stuff, for others it's meticulously organized and labelled, but the key commonality is that it's personal space and that the owner of the space is comfortable in it. That's what emacs is. I don't need to learn a new set of keybindings or mouse clicks to unlock new functionality, I can just bring it into emacs.
Great comment, although I use emacs for everything code, writing, finanaces, task management still all these things are text so I don't get using emacs for non text things
> I don't get using emacs for non text things
What do you mean by "non-text things"? You are dealing with the computer, it's all about text and mostly text. Sure, it might be encoded and digitized, but even structured binary - is all just text. Even when you give a computer voice commands - they are just synthesized audio form of fucking text. Even with "turtles all the way down" - it's all turtles made of text.
Have you seen the gif in the blogpost? With the transient that has "Move Forward/Backward", "Increase", etc. commands? The commands that you'd have to send to the specialized app anyway - Emacs or not. In what form? Fucking text, of course.
with the computer, it's all about text.
Boy, are you going to be blown away by Pac-Man.
First Pac-man was written for Zilog Z80 microprocessor in Assembly. What do you think Assembly looks like? Sequence of emojis?
I would call a sequence of emojis a form of text too!
Everything can be reduced to text. Sure, I'm of course pushing it here with my "all digital information reduces to bits, and thus could be text", but the meaningful processing requires understanding the inherent structure and relationships within that data.
It's like arguing that "all books are just sequences of letters". That's technically true, but meaningless without understanding grammar, semantics, and context.
What I'm saying is akin to: "First step to understanding all the books starts with understanding letters..."
Anyway, emojis are of course text - even though they are stored as encodings. For example, LLMs process them exactly like any other text characters - they're tokenized, embedded, and handled through the same mechanisms as words. I should've use a different analogy to make my point clear, but you know what I meant.
But how does playing pac-man make especial sense in text?
Well, in the context of the discussion, you can "teach" Emacs to play Pacman. Imagine sending left/right/up/down commands to a Pac-Man emulator or whatever. The emulator itself may not "understand" these commands in pure text, accepting some digital form of them, but whatever format it accepts, it probably can be reduced to sequences of alphanumerical characters.
Similarly, when the emulator broadcasts current coordinates for pieces, or sprites of them - they still can be reduced to plain text.
As a matter of fact, if you want to play Pacman in Emacs... you can just play Pacman in Emacs: https://github.com/emacsmirror/pacmacs
You beat me to it !
I'm sorry. I'll try not doing it again :) I just caught a cold, lost sleep and overall have been feeling pretty lame. I don't typically lurk around the orange site, eagerly waiting for someone to mention Emacs.
I use exwm as my windows manager [1], so for me, everything is emacs-first. Therefore, trimming a video in emacs is more natural than using another program to do it. I love the experience of using exwm and emacs for everything whenever possible.
[1]: https://github.com/emacs-exwm/exwm
I did not "get it" from the post itself, but it linked to a post that mentioned "subed", subtitle editing for emacs with syncing with/control of video playback in mpv. I could see myself doing that and then would be happy if I could also trim the video while I am at it.
> would be happy if I could also trim the video while I am at it.
You can, see the command subed-crop-media-file.
https://github.com/sachac/subed/blob/main/subed/subed-common...
Modern emacs is surprisingly powerful, far from "Doom on a pregnancy test" (image display and UI widgets are just features).
Looking at the code for this solution (https://github.com/xenodium/dotsies/blob/main/emacs/ar/video...), it's under 400 lines (excluding the require of three very common libraries and an ffmpeg dependency). I'm not actually sure I could pull off this feature in 400 lines of JavaScript (and the binding logic for going from node to ffmpeg isn't going to come to my fingertips nearly as fast as the logic for emacs LISP, although I know that varies from person-to-person).
Plus, once it's in emacs it can glue to other things. If I want to grab video from an email and trim it, I have tools in emacs to fetch particular emails, etc.
I think the most reasonable way to think about emacs hacks like this is "I could do this in a shell script... But why would I when emacs gives me interactivity, a REPL, and the advantages of buffer manipulation as a metaphor?"
hmmm, I'll try. Think of these things like you think about using cli tools. If you ONLY had ffmpeg or imagemagick in isolation, there would be no benefit to using them on the command line. You are working with images and video after all. That's what GUI is for! Even if you end up using them, you use them through a GUI wrapper. I bet Resolve uses ffmpeg somewhere under the hood.
They don't work in isolation, though, and I bet you can easily think up a bunch of usecases for either. They're scriptable and they compose well, after all, so the tradeoff is worth it. You put up with the headache to automate that batch job of changing the intro sequence of the thousand video files and generate new thumbnails and put the new subtitles in one go.
In emacs, everything tends to be composable and scriptable. You are in GUI land but things feel powerful like in CLI land, except discoverable. It's the "vim is the text editor of the unix IDE" idea, except they put the whole unix into your editor. When people jokingly claim it's an OS they're only half joking. It's malleable. You are already running it. You are already familiar with the way it works, with the way you discover features, get help etc. Why start another program for a task like this?
Unity of key bindings is one reason. Consistency of interface. Relative ease of using elisp to write some of these things.
Emacs users typically have a whole pile of customizations, macros, and workflow automations they've written up over the years.
And for things that are text oriented, the ability to work the buffers emacs-style between emacs windows is a joy.
There's a lot of advantages to keeping everything inside emacs.
Author needs money from you but lives in London. Maybe he should move somewhere cheaper
Pretty neat. I use Emacs a lot, and also do quite a bit of video trimming. For people wondering "why Emacs?", here’s the use case: trimming video is mostly about writing down start/end times, sometimes with a note. That’s all text.
If you can turn that text directly into clips without switching to a separate video editor, it’s surprisingly efficient. Of course, this only makes sense if you already live in Emacs, then it reduces context switching, helps to keep the flow. If you don’t, it just looks odd. But it’s not about making a meme out of "doing everything in Emacs" - it is just a small tool that fits the workflow of people who are already in that environment.
This supports the meme of Emacs as an operating system. It would actually be nice if graphical integrations like that could be implemented as easily on our actual OSs.
Emacs is an elisp interpreter.
I love that (and I say this with zero shade intended) you can never really tell which "Use Emacs for x" posts are goofs and which ones are serious.
This is pretty interesting; I had never thought of using Emacs as a video trimming thing, but why not? I've trimmed videos manually with FFmpeg and I've thought about building my own GUI to do it, so Emacs is as good a choice as any.
I don't really use Emacs but I love that people use it for everything; next step is a non-linear video editor.
Other responses were getting at the same ideas, but to put in concisely, an Emacs-based solution is:
1. keyboard driven
2. programmable
3. within an ecosystem they are already within (lightweight, cross-platform, etc).
I had a daydream about a DJ using Emacs once
They exist: https://www.youtube.com/watch?v=l3h773bycP8
We are out here.
I've been using emacs for light video editing too, but I took a different approach. Instead of having emacs deal with video directly, I use emacs as a JSON IPC client of mpv, over a unix socket, which handles the video. Over that IPC link I can control mpv playback (optional) and get timestamps/etc to add into an Edit Decision List (EDL) file.
Having been an Emacs user for 25+ years, I have a bunch of muscle memory.
So I created Emacs shortcuts for Davinci Resolve. (I create a lot of videos, and every time I've attempted to outsource editing, it has always been more work to review and give feedback than to just do it myself. I have a routine using the AI transcription features of Resolve that lets me edit video very fast. Editing a one-hour video might take 2-3 hours).
I'm also interested in hearing more about your process. I get bogged down going through my footage either comparing similar options, or trimming to the best action (best focus, least shake). I find the default Resolve keyboard shortcuts to be fast, and trim in the Edit mode (whatever #4 is called), but I'd love an AI augment that colour-coded clips based on which segments might be best (e.g., eyes/face in focus, or require least stabilisation, etc).
I have a Resolve Speed Editor panel but just found that to be far slower than the keyboard.
Could you explain your workflow in a video?
Years ago, a friend of mine said to me:
This has held for emacs, Microsoft Excel, Microsoft Word, and probably vim as well.Honorable mentions for AutoCAD, Blender, and Eclipse too.
:-)
Massive kudos on this! Could see elevating this to a full blown "ffmpeg-mode" that allows other forms of editing that is common from that tool.
Very cool tool, and always amazing what Emacs can do...
If this isn’t your _daily_ use case and you only need to edit video from time to time, just ask your preferred LLM to give you the FFmpeg commands to cut, speed up, mute, flip, add text, etc. This has worked quite well for me with simple use cases, and well no need to learn Emacs.
That’d be an awful way to cut video, because it wouldn’t help with the most important part: visualising and extracting the exact initial and final time stamps.
Especially if you don’t do this regularly, a GUI makes much more sense and saves you the frustration of having to sift through potentially wrong commands and figuring out what exactly to edit to fix the mistakes.
I’m not saying this is better than a GUI, but instead let me give you an example.
Sometimes I have movie clips A, B, and C. I want to trim part of A at the beginning and end, then stitch clip B to it while speeding it up by 2x, and finally add clip C at the end, also trimmed a bit. After that, I want to add some text at specific times for a specific duration. In the end, I’ll export everything in 1080p.
I know all of this can be done with Final Cut or any other video editing app using a GUI, or the cool Emacs tool above...
But for me this would mean (GUI example) downloading the app and watching YouTube tutorials just to learn what to click.
For simple video editing (and other tasks), I sometimes need to get the job done quickly without wanting to learn a whole new tool.
I found out that I can achieve sufficiently advanced video edits with FFmpeg commands produced step by step from a LLM.
If you think this is awful, ok. I thought it was neat and wanted to share the idea.
I’m having a hard time believing your example.
If you ever needed to do that more than once, using a basic video editor (of which there are many, free and open-source, no need for a commercial behemoth like Final Cut), playing with it for ten minutes once would give you all the knowledge you need forever, even when you are without access to your LLM. And you can keep the app installed, you don’t need to download it every time. There’s also no need to watch YouTube videos, most of these basic editors have evident interfaces that anyone could figure out on their own for simple tasks. People did figure out things before YouTube tutorials. Or hey, if you’re that keen on LLMs, ask them where the option you want is.
Furthermore, you have not addressed at all the crux of the point. How are you even getting the exact time stamps to give to the LLM of FFmpeg for the cut? Or how do you decide that 2x is the exact speedup you need? Or how do you know what size and position and text font and colour even make sense?
All of those are visual decisions which need confirmation because video is visual. It doesn’t make sense to blindly run lengthy FFmpeg commands over and over to see if the result is any good.
Again, totally fair points, and for many people a (simple) GUI is the right tool. I am not against GUIs or particularly pro LLMs; I just want to show an alternative way to solve video editing problems without judging any specifc technology.
Not all video work is visual-first storytelling. In engineering/lab contexts you often just need “good enough” trims, concatenation, speedups, and a few labels to document an experiment. As I said in another comment, I usually get the timestamps by noting them down while watching the video, or in rarer cases from timestamped sensor data.
Sorry if my explanation wasn't good enough...
If the LLM is not seeing the video, what does this add for you over just looking up the relevant options?
> just looking up the relevant options
Not the OP, but ffmpeg's documentation is pretty awful to navigate if you aren't an expert in it. It is very technical and exact, but fails to provide examples for most options.
For example, the fpsmax option says you can set the maximum frame rate using "Hz value, fraction or abbreviation." So now the user has to search for how any of these things are to be specified (does a bare 60 mean 60hz? Do you need to include Hz? Is it case sensitive? What are the abbreviations? What is the fraction a fraction of?). And that's a random option I found in the pile of documentation it has.
Maybe it's useful if you use it every day, but I completely understand why people use GUIs whose purpose is to construct the command. Or even LLMs to do the same thing.
In my common use case, I note down the timestamps of the cuts. No LLM needed here.
I know there are options for everything in FFmpeg, and I’m thankful to the community and maintainers for providing such a powerful and well-documented tool. I sometimes just want a quick video edit that doesn’t involve reading the man pages for minutes or hours.
Nice, I was just about to do something like that as I didn't find anything ready last week when I got annoyed yet again when trimming a video.
All of your links to your own posts in your blog seem to be broken -- relative links need a "/" at the beginning, I think?
Hey, thanks for reporting. I had a couple of links that went haywire. Please lemme know if you run into other issues. First link to https://xenodium.com/seek-and-you-shall-find was broken. Should work fine now.
It's odd. There multiples problems on that blog.
https://xenodium.com/emacs-as-your-video-trimming-tool/
Is fixed and also fix various typo in the blog post. Bbut has other bugs, for example, the title link redirect to the bugged URL.
But (the bugged URL):
https://xenodium.com/emacs-as-your-video-trimming-tool Have the problems with relative links you talked about.
i love this but dont use emacs. i wish that existing tools were lighter weight at video trimming. Screenflow is the lightest i know of but fails badly at some video formats and sometimes OoMs. if it had a better architecture streaming bytes i feel like it might not have that problem.
any other light weight trimming people have?
I find my approach lightweight, but it’s still around 80 lines of code so a tad big to share as an HN comment. It also requires a bit of explanation to set up (though once done, it’s incredibly simple to use) and the output is custom to my needs.
Essentially, I already use mpv as my video player, which in addition to being very fast also allows seeking frame-by-frame, saving and returning to positions, and running Lua scripts. So I wrote some Lua which reacts to a specific key press by saving the current video timestamp. Press it again and it records a second timestamp, then it fires off Handbrake CLI (FFmpeg could also work) to do the cutting and save the trimmed file.
If you search online for “mpv cut video” you should find some plugins with that same idea. I have never used them so I can’t attest to how good or bad they are. All the ones I found are larger than my approach, but then again I just made mine do exactly what I want without customisation so that’s to be expected.
One specific advice I’ll give, if you go this approach and are on the Apple ecosystem: Use the Handbrake CLI instead of FFmpeg to do the cutting. FFmpeg was super frustrating and I was unable to get a result where the output video worked properly in Quick Look and sending through iMessage; after too long trying to get it to work and messing with a myriad flags, I switched to Handbrake with no weird settings and it’s been working flawlessly ever since.
> Screenflow is the lightest i know of but fails badly at some video formats and sometimes OoMs
I'm a big fan of ScreenFlow, but light it is not ;) If you just want to trim and assuming you are on macOS, QuickTime's "Edit > Trim..." does the job. It's what I used before doing the Emacs thingy.
I made a video trimmer for the terminal: https://github.com/wong-justin/vic
But haven't worked on it in months. Usable for now if you don't need audio
Lightweight? I don't mind a bit of weight if its versatile. But when I want to do things fast, I use Shotcut (free, open source) which is much easier to use than e.g. ffmpeg. There exist a number of good tutorials showing how to accomplish tasks.
https://en.wikipedia.org/wiki/Shotcut
P.S. What's great about tools like emacs or ffmpeg is their usability via a command line and thus scripting. Which even works on an Android device running inside Termux.
I consider Handbrake lightweight. It never fails at any video formats I care to test and it also transcodes them to modern video codecs.
Lossless Cut is free, open source, and very simple to use. Highly recommend. Wayyyyy lighter than screen flow.
Lossless Cut is a 300 Mb Electron app, not exactly light. But it does its job.
Avidemux is ok for what it is. I use it for snipping and stitching stuff together because you can avoid full reencodes when exporting.
Impressive, but I'll stick with LosslessCut (https://github.com/mifi/lossless-cut)
Great tool! I'm always impressed by how versatile a tool Transient is. I use it extensively as well and there's nothing like it anywhere else.
Transient is indeed very nice, even though I wish its programmable API was simpler and made more sense, sometimes it feels annoyingly quirky and unreasonably complex.
Shameless plug for further ideation and discussion: https://news.ycombinator.com/item?id=44025635 - it's a long video - ~1hr, it's unscripted and unedited. I guess I just couldn't fit all my Transient use cases in a smaller one. I have a lot of these bad boys in my Emacs.
When you have a hammer in your hand and try to use it for more than nails.
Typical reaction from someone who has no clue. Emacs isn’t a “hammer”; it's more like “glue” - you don't have to do everything _with_ Emacs, but it can definitely mediate and delegate specific tasks to more specialized tools - it can give you the sense of doing everything _through_ Emacs.
Why would anyone do that? Because plain text rocks.
> There is no equivalent in any other communication technology for the social, communicative, cognitive and reflective complexity ¹
And there's simply nothing better today than Emacs for dealing with the plain text. Neovim comes close, but still can't match it.
__
¹ Graydon Hoare: Always bet on text https://graydon2.dreamwidth.org/193447.html
I know that you are a stalwart Emacs supporter — I've seen your posts before, and still remember your airplane awakening — but don't you think that more carrot than stick would be more effective at convincing people to use Emacs?
I may not sound nice at times, but I strive to be kind. Kindness implies honesty. Why is it easier to learn a foreign language around kids? Because kids (with no malice in their hearts) would tell you the truth - when you mispronounce things, they'd laugh at your mistakes. When it comes to spreading truth about Emacs, I'd rather be like a kid.
I don't think the comment above justified characterizing it as a "stick", but I suppose that is something you wanted to say to me long ago, and I appreciate your veracity. If you give me more constructive suggestions for changing my rhetoric, I may even promise to consider changing my narrative, but at this point, I don't even see what's wrong with it, really.
You don’t have to tell me what Emacs is capable of. Been using it for all my computational use-cases for years. But migrated away from it because it is obvious that each use case has better solutions outside Emacs. I am convinced the Unix way (do one thing and do it well, connect them via pipes and text) is the way to go.
> I am convinced the Unix way (do one thing and do it well, connect them via pipes and text) is the way to go.
I was convinced too, but after the amount of work required to convince terminal, tmux and neovim to be friends I thought “It would be nice if all of it would be in one sane configuration language and actually debuggable!”
These days, if I need unix tools (use rg a lot) I plug them into emacs.
Yup, exactly this.
The Unix philosophy has limits - text pipes work great for linear data processing, but often break down for interactive stateful workflows. Many modern tasks require rich data structures, not just text streams. Also, context switching between tools loses state and mental flow.
Advocates of "Unix philosophy" often lay it out as if it's the exact opposite of the "Emacs way", which is pretty inaccurate - Emacs can actually be viewed as "Unix philosophy+" - it does do one thing well: text manipulation+extensibility.
You can still use Unix tools from within Emacs - shell commands, compilation, etc. Moreover - you can pipe the result of a command into an Emacs buffer and the content of that buffer into another command, etc. And unlike pure terminal workflows, you gain persistent state, shared buffers and unified keybindings across all operations.
Unix philosophy is brilliant for system administration and data processing, I would never try to convince anyone not to use, e.g. Neovim, I myself reach for it when I see the need. Emacs philosophy is brilliant, for example, for knowledge work and creative tasks, like the example in the OP's blogpost.
These tools - Emacs, Neovim, and Unix - embody some of the greatest ideas in computer science throughout its relatively short history. One would have to be extremely short-sighted not to recognize the immense value in any of them. Frankly, mastering all three of them may make you feel like the Chuck Norris of computing.
This may be a bit pedantic, but Emacs-as-a-hammer metaphor might work better than you intended, since a hammer is definitely useful for more than just hitting nails. This seems pretty neat to me.
Hey, has your favorite IDE been used to run German air traffic control?
Everything seems like a nail these days. Probably uses his smartwatch to spread butter, too.
lol I did work in the smarwatch space for a good chunk of time. While I totally get the nail thing, this is as quick/lightweight as it gets after the command line, which is a lot more cumbersome for this use case.
You what is even easier than using Emacs to operare ffmpeg? Just use claude-code (or one of the other CLI code-agents)...
Emacs can do that too. Plug gptel and voila.
Yeesh, OP merely respawns a new ffmpeg process to extract the next frame -- a very emacsy, and thus boneheaded, way of emulating a proper GUI.
It’s obvious that the author wrote the simplest code that could work, rather than spending extra time on complexities that might not be needed. They were quite pragmatic and achieved a useful and usable result. It’s commendable, so you shouldn’t sneer.
I'm not sure how you'd do it "properly" with libavcodec while still doing a regular Emacs plugin.
It's 300 lines and in pure Emacs lisp, it doesn't seem boneheaded to me.
> it doesn't seem boneheaded to me
It's not "boneheaded". Shit ain't stupid if thy shit works. This HN user is just a troll with condescending traits and arrogant tendencies, don't feed their ego.
I'm not sure how to libavcodec while still doing Emacs
I'm glad you see my point.
I just don't think it's that bad. Even if it spawns a process for each frame when you're scrubbing, it seems to run fast enough on my computer.
If you want to do a lot of advanced video editing then yeah use a real editor, but if you're just doing a quick trim it's really not a big deal to spin up a few dozen very-short-lived processes.
It’s probably be more efficient to convert the video to multiple frames in batches, and then buffer them. Spawning processes is pretty resource intensive.
I mean, "resource intensive"; that's technically true but the processes are pretty short-lived and only one spawns at a time as far as I can tell. It's definitely more overhead than an in-thread thing, but still not that much on modern computers.
I agree that it would be more efficient to do these things in batches but I really don't think its current state is that bad, at least for a V1.
The implementation actually uses a single ffmpeg process with pipes for efficient frame extraction, not separate processes per frame as you suggested.