I use Lem. It's an "emacs" but not a clone of GNU Emacs. It's written in Common Lisp, extensible in Common Lisp and it's way more performant than GNU Emacs. Obviously less features and plugins but for my needs (writing Lisp code mostly) it's great.
Dunno, I've been trying it off and on since it was first released in like 2018. I don't theres any particularly noticeable changes from 6 months ago specifically.
I also used Emacs way back in the day but have been Vim/Neovim for the last 5 years or so. But I recently started a new Lisp project so revisited Lem, actually set it up the way I want (with LazyVim-like bindings), and found with my changes and comfort hacking on it (it's all Common Lisp top to bottom so it's easy to change) that it can replace LazyVim for me now. Just using the ncurses front end BTW.
I don't like keyboard-centric text editing. Yes GNU Emacs supports the mouse, but just like Vim the experience is miserable. You can spend a lot of time configuring it, but at some point you're just writing extensions of extensions just to get a basic GUI flow that isn't painful, and no matter what it'll never feel quite "right". The program just wasn't built with the idea of a mouse in mind, and bolting it on really wasn't sufficient.
Add onto that pretty nasty performance issues, internals that aren't exactly well thought-out, and the experience in general having a high background noise of jank, where it's not uncommon for simple things like rainbow parens to randomly break.
I understand why other people like it, but it's really just not for me. I'll stick with Lite-XL.
No. Even most keyboard-centric text editors implement mouse inputs, with only a few exceptions coming to mind, almost none of which anybody uses today, for example ed. In fact, most editors don't even restrict text insertion and deletion to keyboard input, which is what you might be confusing with "text editing", which might be more clearly expanded to "operating a text editor".
The only reason why I was taught vim is that a coworker wanted someone to know it so they can explain why emacs is better. It didn't work and I've transitioned to neovim.
I'm a die-hard vimmer. I use vim-motions everywhere - they permeate my editors/IDEs, browsers, terminal, I use them system wide (e.g. to change volume or control media or my WM). One day I woke up with the realization of the fundamental truth - Emacs simply vims better. Much better than even Neovim. I just had to master Vim and grok some Lisp to arrive to that conclusion.
People fighting Vim vs. Emacs are materially wrong - they focus on superficial (albeit substantial) angle, instead of considering the core ideas behind them. Vim's augmentation of modality is an incredible, beautiful, practical concept. Lisp - yet another grandest idea in all history of computer science. And these ideas are not overlapping. Lisp-powered vimming grants you genuinely joyful experience - surprisingly empowering and enormously liberating.
Emacs' Lisp interpreter is so capable - accurately simulating vim in it is not impossible, while pretty much every other editor/IDE has failed - not a single VSCode plugin, not Sublime, not IntelliJ with IdeaVim have ever fully implemented vim motions to the degree where it doesn't feel foreign, while Evil-mode in Emacs feels like a built-in feature. Until recently, bolting Lisp into Vim seemed impossible, today you can get a pseudo-Lisp engine with Fennel. Even though it unlikely ever feel like Emacs.
If you're sticking to one thing only due to some muscle memory, sure you're not a savage, you're just a bit ignorant.
I suppose that you mean via some third party cloud. I personally sync my Org mode notes via adb when I backup the phone occasionally. I read on the phone using Orgro.
So? Emacs has built-in solar and lunar calendars, has world-clock command, format-time-string accepts ZONE argument. Why don't you build a minor mode that calculates the offsets and shows you stuff in different timezones? This can be done in less than 15 minutes. With AI maybe in 20.
You're not dealing with an app you paid for, and your complaint not even an accurate one: Org's timestamp format doesn't encode timezone by default. Emacs absolutely supports the feature you want, you just didn't know about it.
Oh, you can't imagine how I'd like to be proven wrong.
Last time I checked, proper timezone support wasn't there. One could specify single timezone for entire org engine, but not per timestamp. I found some nearly official mailing list thread where participants couldn't settle on a single solution, and so the conclusion was that proper TZ is not coming to org.
> Org's timestamp format doesn't encode timezone by default
> format-time-string accepts ZONE argument
Isn't format-time-string just a visual decoration? Last time I checked, agenda and all other plumbing always treated every timestamp as local (to the TZ configured globally). And so if I recorded that I have a meeting at 1PM London time, my org-agend would show it to me 1PM even if my TZ is set to New York.
> Why don't you build a minor mode that calculates the offsets and shows you stuff in different timezones?
Can you elaborate? My understanding was that I'd need to rewrite entire org in order to support time stamps with mixed time zones embedded in them.
> You're not dealing with an app you paid for
Actually, I'd be willing to pay above the competitor _subscritpion_ price for an org-based organizer with
- proper TZ support
- conflict-free sync between devices
- (cherry on top) touch UI friendly Android client. But honestly, orgzly would do, as long as it supports the above
a) you need to see the timestamp in different timezone(s)
A minor mode with home-zone/visiting-zone vars showing dual times via overlays answers: e.g. "It's 1PM here, what's that in London?" That's the world-clock problem. Useful, easy to solve in ~15 min.
b) anchor an event to a foreign zone permanently - you want to record a fact about an event that is intrinsically tied to a zone
For that, yes, you'd have to either change a bunch of things about Org-mode - every consumer of timestamps (agenda, clock, deadlines, repeaters) would need to become zone-aware.
Pragmatically, you can store the zone without rewriting Org, by piggybacking on a property/tag and a conversion step.
1. Author in foreign zone, but store normalized to one canonical zone (e.g. UTC) in the timestamp, and keep the original zone in a property:
* Meeting
:PROPERTIES:
:TZ: Europe/London
:END:
<2025-06-01 12:00> ; UTC
2. A small minor mode renders the display via overlay in either the stored :TZ: or your current zone, computed with `format-time-string … zone`.
The limitation is that all the timestamps within a single heading can only be of a single timezone.
---
There's yet another alternative - you can codify the TZ on each timestamp as a propertized text. The problem? Text properties don't get persisted, so you'd have to add custom logic that mangles the timestamps in the file on save (essentially breaking them for all dowstream consumers), and then restores them to normal shape with propertized timezone info. I guess this begets another problem - many Org operations reconstruct the timestamp string from a parsed org-element struct.
I guess, I do stand corrected - if the problem you want to solve is "b" - there isn't a straightforward solution to it.
Aren't Org mode dates ISO 8601? ISO 8601 has an optional timezone, is that not supported in Org mode? You could then use format-time-string to configure how it is displayed.
Another possible solution. Often - but not always - a datetime and timezone pair can alternatively be represented as a UNIX timestamp. Depending on the use case there are tons of ways to manipulate UNIX timestamps, and Org mode might support that naively (I'm not sure, try it).
If emacs is not installed on a system, I use sed. In addition to not getting stuck inside it when you don't remember the magic exit incantation, you can immediately reuse the command on a different file. And it doesn't play sounds while you do it. Plus when you're typing the sed command, you can use emacs key bindings to move around!
"If emacs is not installed on a system, I use sed."
Bill Joy (creator of vi) once said that if he sits down on a foreign system, he reaches for ed [1].
To be fair, both emacs and vi have "magic exit incantations", though if you have emacs perhaps you have a menu in GUI mode. If not, C-x C-c is really not any more memorable than :wq! The vi one at least has an obvious mnemonic ("write quit") but either way, you need to know an arbitrary sequence of keystrokes.
NeoVim because it's fun!! So many plugins and colorschemes!
So customizable- these days Claude will just change it for you, no need to learn the APIs if you're just interested in the result. Yes you're AI-slopping your config, but the drawbacks to that are super low (it's a personal editor, not something I'm inflicting on others)
AI slopping my config is what allowed me to learn vim without going through the pain of setting it up. I can ask AI to teach me about some motions or set up some configs for m in lua without ever know lua. This is the biggest impact of AI in my professional life.
Vi is fine. It's superior and to bare ed - The Standard Editor*, when you don't have anything else available. I made much of my living coding vi 7 years in -80's. And I still use vi, when emacs is not there or system has so little memory that emacs is too much. Which is usually with a embedded systems or some old Unix on single mode fixing unbootable system.
