That's not what this is about. The bill explicitly defines "sexually oriented material" to include anything that "involves gender dysphoria or transgenderism".
I don't mean to tear down your project at all. If you want to make an editor, I think that's great. I'm actually working on a text editor of my own. But I think that you've fundamentally misunderstood the appeal of Emacs. It has little to do with the key-bindings, or even any particular part of the user interface. Many people don't even use them. Doom, a very popular Emacs distribution, enables Vim-like bindings by default. It's an old joke that Emacs is a great operating system in need of a good text editor.
The appeal of Emacs is that I can, at any time, with only a few keystrokes, dig in to how it does something and then modify it. The self-documenting and customizable behavior is extremely pervasive. Emacs Lisp is not just there for extensions. Every single layer of the application--save for core primitives--is implemented in it. All of it can be inspected, modified, swapped out, wrapped, hooked into, and basically do anything you want. There's absolutely nothing else like it.
> But I think that you've fundamentally misunderstood the appeal of Emacs. It has little to do with the key-bindings, or even any particular part of the user interface.
You mean the default keybindings for readline and macos? I think you're greatly overestimating the extent to which you can speak for other emacs users. I love the default keybindings and never even thought to change them, and I very much understand being leery of the lisp runtime. The modal editing of vim, doom etc always struck me as pointless typing and too much like issuing commands rather than making typing an extension of your fingers.
This isn't for me (electron—blah; I have microemacs etc), but I 100% get it.
Yeah! For typing, you could use cat and be done with it. But you think about editing, then ed(1) start to make sense. You think about it a little more and ex(1) makes sense. You want better visual feedback and vi(1) is born. And then you want more programming features and you’ll get vim.
Emacs is what you get when you sidestep the whole process with something as versatile as lisp. Instead of being economical with commands, you just create the specific actions you want
I've found that it's not any better than emacs at this and you end up spending more brainpower and time issuing commands than editing, but of course YMMV. Plus it gives you cred with people who never learned to exit vi, which I suppose counts for something.
"Making typing an extension of your fingers" is exactly what I was aiming for. I personally love the default Emacs keybindings and the "muscle memory" they provide, so I wanted to create a tool that focuses purely on that physical experience.
Thank you for the incredibly insightful comment. I completely agree with your definition of Emacs, and I have the utmost respect for its true nature as a fully programmable Lisp environment. You are absolutely right—that infinite extensibility is what makes Emacs unparalleled.
When I call my project "Emacs-like," I certainly don't mean to deny or replace that beautiful philosophy. I am simply a software engineer who deeply loves the UI, UX, and keybindings that Emacs pioneered.
My goal was just to recreate that specific physical experience as a standalone application. I truly love the sensation of operating an editor entirely by muscle memory and pure reflex—allowing the words in my head to flow seamlessly onto the screen without consciously thinking about the tool itself. I just wanted to package that exact typing experience into a zero-setup app.
By the way, I am very curious about the project you mentioned! What kind of text editor are you working on? I would love to hear about it.
Oh, I don't have much at all, yet. I decided to use a piece tree, which is what VS Code calls the data structure they used. I implemented part of that, then realized that VS Code does it that way partly because of limitations with V8. So now I don't even know if I want to go forward with using it or switch to something simpler.
I actually went through the same VS Code articles and ended up implementing a minimal Piece Table for this project. I focused on adding just enough functionality to handle Undo/Redo according to my specific needs.
So far, it has been working well for my use case. Since the codebase is compact, it is straightforward to test and maintain. For a solo project, I've found that using a data structure I can fully grasp is an advantage.
I’m interested to see where your project goes, whether you stick with Piece Tree or pivot. Building an editor from scratch is a unique experience, isn't it?
I have to agree, if only because when I hear "the emacs keybindings" I wonder, does that mean the defaults that nobody uses, or the ones I've carried around for 20+ years?
As a quick example "M-g" ("Esc" [pause] "g") has been bound to "goto-line" in my emacs startup file for at least 20 years, and is something I press without even really thinking about.
There are many default keys (such as C-x C-f for finding a file), but even core functionality gets rebound to suit my preferences.
I agree that extensibility is one of the core charms of Emacs!
That said, when it comes to keybindings, I’ve actually stuck with about 95% of the defaults. The only exception I can’t live without is exactly what you mentioned:
(global-set-key "\M-g" 'goto-line)
I've used that for so long that my fingers just do it automatically. It’s funny how even a "minimal" user like me has that one specific rule that feels essential.
Using overall life expectancy here is misleading, as it includes the risk of childhood mortality. You have to look at life expectancy at a given age. According to the SSA's life tables[0], life expectancy for men at 65 in 1930 and 1940 was about 12 years. In 2020, it was about 17. A significant increase, but not nearly as extreme as you're saying.
In 1930, if a person starts paying into the pension at 30, at that point they have a life expectancy of 37 years, ie they will benefit from the pension for 2 years. Life expectancy at age 30 goes up to 48 in 2020, which gives them 13 years after retirement, 6.5 times higher. Assuming linearity, the average life expectancy after retirement during the time you are paying into your pension between 30 and 65 would be 7 years in 1930, and 17 in 2020.
"The 160 MFLOPS Cray-1 was succeeded in 1982 by the 800 MFLOPS Cray X-MP, the first Cray multi-processing computer. In 1985, the very advanced Cray-2, capable of 1.9 GFLOPS peak performance
...
By comparison, the processor in a typical 2013 smart device, such as a Google Nexus 10 or HTC One, performs at roughly 1 GFLOPS,[6] while the A13 processor in a 2019 iPhone 11 performs at 154.9 GFLOPS,[7] a mark supercomputers succeeding the Cray-1 would not reach until 1994."
These flops are not the same. The 2013 phone flops are fp32, the A13 flops look to be fp32 as well (not entirely sure), while the Cray numbers (like the rest of the HPC industry) are fp64 (Cray 1 predates what would become IEEE 754 binary64 though, so not same exact arithmetic but similar in dynamic range and precision).
A modern Nvidia GB200 only does about 40 tflop/s in fp64 for instance. You can emulate higher precision/dynamic range arithmetic with multiple passes and manipulations of lower precision/dynamic range arithmetic but without an insane number of instructions it won't meet all the IEEE 754 guarantees for instance.
Certainly if Nvidia wanted to dedicate much more chip area to fp64 they could get a lot higher, but fp64 FMA units alone would be likely >30 times larger than their fp16 cousins and probably 100s of times larger than fp4 versions.
Years ago, I installed the Facebook app on my phone. I immediately uninstalled it when I saw, horrified, that it had hoovered up all my photos and uploaded them to Facebook (there was no fine-grained storage permission at the time) "for my convenience". I never ran their app on my phone, again.
Location: Seattle, WA
Remote: Yes
Willing to relocate: Maybe to the SF Bay Area
Technologies: Java, Spring, TypeScript, React, Node, SQL, Rust, Python, Clojure, Solid-JS, Nix
Résumé/CV: https://drive.google.com/file/d/1NzYmjFItbxdlewYL_Lz--ZnE24_CqXvH/view?usp=drive_link
Email: mail@requirenathan.com
I'm a mathematician-turned-programmer looking for my next software engineering role after being laid off. I have professional experience as a full-stack developer working on a Java/Spring backend with a React/Next.js frontend. My background has given me lots of practice working away at difficult abstract problems. I'm an information sponge and a ferocious, self-directed learner. My portfolio can be found at requirenathan.com.
I briefly worked on a product related to this. It was a chatbot meant to replace the human phonecall in just this situation. The user would get a text from the bank with a link to the chatbot. They ended up not being able to sell; the common complaint from the banks was that they'd been training their users to never click links like that.
I've just started with jujutsu, as well. Jjui fills a little bit of the gap. Among other things, it allows for quick selecting and splitting of changes. But it's no Magit. I'm thinking of having a go at making an emacs interface for jj myself.
