tl:dr I have finally matured enough to say that I'm in love with (mostly) vanilla emacs. And I can't believe my peers didn't force me to learn this properly sooner.

I've used vim/neovim for about a decade. I have spent countless hours adding/removing/writing plugins, tinkering with the config, etc. I was never fully happy with it, but I was content knowing that my vim motions worked very well in most programs and within my editor, and the way I worked tends to look like wizardry to the rest of my team who are still stuck relying on their VSCode, trackpads/mouse etc.

I tried many times to get into emacs. I used doom emacs, spacemacs, just evil mode etc etc. Every time I tried I got frustrated and quicky quit. I even tried going deep into org mode because that's what everybody ever talks about, but it didn't stick.

However, recently I got fed up with my environment in general. Not just vim, but everything. I got fed up of zellij and struggled relearning tmux. I got fed up with fish and zsh and alacritty and kitty and all of the linux ricing nonsense. In particular, I got fed up with having my work laptop be a crappy version of my personal one because I don't have the discipline to commit, push and pull my dotfiles over 10 different apps so that it works in all my machines (I've tried stow, chezmoi and others - I'm just too lazy or too stupid - or both).

I'm also fed up of browsers. I know we can't live without them, and V8 and co are probably engineering marvels, but the fact that the browser is neither a document renderer nor a distributed application runtime, but a mishmash of both just hurts my soul (and let's not talk about privacy and security).

And then I got fed up of my languages. Nothing much wrong with Go, but nothing much exciting about it either, but lord help me if I have to compile a Rust program. Let's not talk about npm crap show that's now even infected pypi. And finally there's lua. Lua is a great language. But it just never clicked with me when writing plugins for neovim.

And then there was lisp. I love lisp. And for years I've kept asking myself, can I replace everything with lisp? And for whatever reason it never occurred to me that this was the main reason to go with emacs. I just needed to learn how to use emacs better. And it turns out, every single thing I got fed up with... emacs solves, and it solves it beautifully. I guess only now am I mature enough to realise that.

All this massive rant just to say, I bought Mastering Emacs by Mickey Petersen and I've been sticking with emacs from vanilla. I wrote every single line in my emacs init.el and it's only about 252 lines long at the time of writing. No evil mode, no spacemacs or doom, just as vanilla as I possibly can (emacs 30 anyway). It's week 2, and as I was writing some code and running some eshell commands I kept feeling more comfortable with remembering the motions and commands and keybindings, and it felt great. I don't think I'll ever leave emacs anymore. I've just touched the tip of the iceberg, and I'm now addicted. (p.s. I'm writing this in my browser , I know - the horror. I haven't had time to set everything up in emacs yet, but I look forward to writing these, and more, in my emacs client)

Guidelines used to populate this list:

• No packages, stock Emacs only.

• No steep learning curves. Learn each feature in under two minutes or bust.

• No gimmicks. No doctor, tetris, snake, dunnet, zone or butterfly.

• Just the deltas. No commonly mentioned packages like flymake, doc-view, outline-minor-mode or eww/w3m. Nothing that Emacs brings up automatically or a nonspecific Google search gets you.

• Assume a modern Emacs, 26.3+.

While working on some projects involving things like (sometimes unknown) binary protocols via a TTY, or dealing with small binary protocol chunks in other protocol streams I realised that once I can pretty print decoded protocol frames I have half of the emacs implementation ready - and the other way round.

I built a debug framework around that, noticed how useful it'd be to use the same code to sniff and pretty-print communication between the device and the closed client - and added the option to run helpers that forward packets at linespeed, and make them available to emacs at its own pace. At that point I realised that this could be useful as a standalone package, and started ripping it out of that codebase to form lempo as a standalone package.

The screenshot is a pcap bridge helper I've added as simple demonstration of the concept - it's pretty easy to have that as self contained module. The setup in the scratch buffer is because the interactive path for doing that broke a bit when ripping the code out - I should be able to fix that over the next few days, though.

While this currently heavily focuses on binary protocols (and with that, mostly nicely printed hex dumps) doing helper bridges decoding higher level protocols should be easily doable as well.

The current code (with the "I'm still fixing the bits I broke by making it standalone" warning) is at https://github.com/aardsoft/lempo/

cross-posted from: https://programming.dev/post/48790323

I'd like to announce ghostel, a terminal emulator for Emacs that uses libghostty-vt - the same VT parsing engine behind the Ghostty terminal - as a native Zig module.

It's inspired by vterm and follows the same general approach (native module does terminal emulation, Elisp handles the Emacs integration), but uses a more modern engine that supports newer terminal protocols. Ghostel is a superset of vterm's feature set - everything vterm can do, ghostel can too, plus a lot more on top.

Feature comparison with vterm

Feature	ghostel	vterm
True color (24-bit)	Yes	Yes
OSC 4/10/11 color queries	Yes	No
Bold / italic / faint	Yes	Yes
Underline styles (5 types)	Yes	No
Underline color	Yes	No
Strikethrough	Yes	Yes
Cursor styles	4 types	3 types
OSC 8 hyperlinks	Yes	No
Plain-text URL/file detection	Yes	No
Kitty keyboard protocol	Yes	No
Mouse passthrough (SGR)	Yes	No
Bracketed paste	Yes	Yes
Alternate screen	Yes	Yes
Shell integration auto-inject	Yes	No
Prompt navigation (OSC 133)	Yes	Yes
Elisp eval from shell	Yes	Yes
TRAMP remote terminals	Yes	Yes
OSC 52 clipboard	Yes	Yes
Copy mode	Yes	Yes
Drag-and-drop	Yes	No
Auto module download	Yes	No
Scrollback default	~5,000	1,000
PTY throughput (plain ASCII)	65 MB/s	29 MB/s
Default redraw rate	~30 fps	~10 fps

Key differences

Terminal engine. libghostty-vt comes from Ghostty, a modern GPU-accelerated terminal, and supports Kitty keyboard/mouse protocols, rich underline styles, and OSC 8 hyperlinks. libvterm targets VT220/xterm emulation and is more conservative in protocol support.

Mouse handling. Ghostel encodes mouse events (press, release, drag) and passes them through to the terminal via SGR mouse protocol. TUI apps like htop or lazygit receive full mouse input. vterm intercepts mouse clicks for Emacs point movement and does not forward them to the terminal.

Rendering. Both use text properties (not overlays) and batch consecutive cells with identical styles. Ghostel's engine provides three-level dirty tracking (none / partial / full) with per-row granularity. vterm uses damage-rectangle callbacks and redraws entire invalidated rows. Ghostel defaults to ~30 fps redraw; vterm defaults to ~10 fps.

Shell integration. Ghostel auto-injects shell integration scripts for bash, zsh, and fish - no shell RC changes needed. vterm requires manually sourcing scripts in your shell configuration. Both support Elisp eval from the shell and TRAMP-aware remote directory tracking.

Performance. In PTY throughput benchmarks (5 MB streamed through cat, both backends configured with ~1,000 lines of scrollback), ghostel is roughly 2x faster than vterm on plain ASCII data (65 vs 29 MB/s). On URL-heavy output ghostel still comes out ahead (42 vs 24 MB/s); with link detection disabled ghostel reaches 65 MB/s regardless of input.

Color auto-detection. Thanks to OSC 4/10/11 support, TUI programs like duf, btop, and delta can query Emacs for its foreground/background colors and automatically adapt to your light or dark theme - no COLORFGBG hacks needed.

Installation. Ghostel can automatically download a pre-built native module or compile from source with Zig. vterm uses CMake with a single C dependency (libvterm) and can auto-compile on first load from Elisp.

Installation

ghostel is available on MELPA:

(use-package ghostel :ensure t)

Or with Emacs 30+ built-in vc-use-package:

(use-package ghostel :vc (:url "https://github.com/dakra/ghostel" :rev :newest))

The native module is downloaded automatically on first use. If you prefer to build from source, you'll need Zig 0.15.2+.

Requires Emacs 27.1+ with dynamic module support on macOS or Linux.

Feedback, bug reports, and contributions very welcome.

Lsp errors that shows when cursor on line that has the error?

I would like to have a keybind for this

We are awaiting the decision by the GNU Project on these matters, which will define the policy for all the GNU packages, and in the meantime we don't accept LLM-generated code, as a precaution.

https://www.fsf.org/blogs/licensing/2026-anthropic-settlement

simple package for running npm scripts (specially in mono-repos)

Totally effortless, but liked the result. Logo was created by Chatgpt and theme by Claude.

I've been reading through their docs[0] and FAQs[1] but cannot for the life of me understand how they can use SPC as a chord prefix, and also just type normal sentences on a keyboard.

I don't want to try it, but I do want to know.

0: https://www.spacemacs.org/doc/QUICK_START.html
1: https://www.spacemacs.org/doc/FAQ.html#how-do-i

No explanation given. Just a whimsical little image for our beloved emacs, I made a while ago, in response to something, I forget what. Is just fun.

One are ELPA tarballs....

...and the other 'elps 'er tar balls!

(Nailed it. Flawless setup!)

cross-posted from: https://hexbear.net/post/6891969

If you write for a living, for studies, or even as a hobby, you should consider Emacs. It could be just what you need in an environment of enshittifying word processors and AI garbage.

als kruis­bericht geplaatst vanaf: https://lemmy.ml/post/38966704

A minimal, declarative setup for productive Rust hacking on Emacs + Guix

I noticed there was a blatant lack of resources and documentation on this particular setup. So I rolled up my sleeves and wrote this article, which hopefully you find useful.

https://jointhefreeworld.org/blog/articles/rust/simple-guix-emacs-rust-development-environment/index.html

See image here of my Emacs with rust-analyzer and clippy working: https://ibb.co/whxq8dX1

I think one of my package is interacting wrongly with TRAMP and it is too often freezing. It is difficult to debug as it freezes totally and quite annoying as I cannot interrupt with C-g. Are there options to run tramp in a way it does not collapse the whole emacs? I could then try to guess which package interact with it by deactivating/activating them...

It seems to work properly if I open emacs with emacs -Q