Emacs

So, I started to use orgmode for writing the documentation for my latest software project. This means, that I have code blocks and lots of special characters in my document. I will have to export this whole file to LaTex/pdf, so my colleague can bind it into his project documentation and this is exactly where my problems are. First of all: how can I turn of the need to manually stop the code execution for code blocks when exporting? I have the single line src_bash{} blocks but also the multiline versions:

#+begin_src bash :
#code
#+ends_src

The next thing is, that my function names include underscores, which in orgmode translates to making the following text lowercase. I tried using \ to escape it, but that only breaks it in a new way and I seriously cant comprehend how this so called zero width space is supposed to be used.

So I have the following problem. I use emacs (specifically orgmode, but my problem applies to emacs in general) quite a lot for writing longer texts (In the long term I even plan on writing scientific papers with emacs). However, one of the problems I have is line formatting. As you probably all know, emacs does not really have default "automatic line breaks" as you know them from rich text editors like LibreOffice. Instead emacs then just moves the entire window you see to the right, if a single line gets too long. Since this is awful for editing I started to add line breaks manually, however the problem is, that you then have to manually re-do the entire formatting if you decide to change the structure of one ore more sentences/lines, which is kind of annoying. The next problem is, that it may look good on your screen with the manual linebreaks, but the formatting then often looks bad when viewed on smaller screens.

One solution I saw is, that if a line gets to long, that emacs then just puts the rest of the line into a new line on the screen, without inserting a line break. How can I enable this behaviour in my emacs config?

I also found out about Auto Fill mode, however I kind of dont like, that it inserts a new linebreak relatively fast (my screen is wide, so I want to use it) and the problem with exporting still stands.

Anyone got any good workarounds that might be helpful?

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

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.

reka lets emacs' logic just flow into river. It is a window manager inside of Emacs for the Wayland world.

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)

My next novel, a science fiction story set 500 years in the future, features a sentient artificial being---imagine a HAL 9000 with a functioning moral compass, or Skynet without the genocidal nihilism.

Users interact with this sentient AI being in a variety of ways: non-tech users interact via voice commands and touch, but more tech-savvy users interact through a Brain-computer Interface (BCI) that enables tactile and vision control. A smaller portion of users still use keyboards, but they are viewed in the same way our current age views typewriters: a quaint artifact of a bygone era.

The idea for this post started today when I saw in #emacs-til on libera.chat:

• [2026-01-17 22:30:19] TIL emacs is just not for old boomers lol
• [2026-01-17 22:31:53] also for younger boomers
• [2026-01-17 22:33:10] haha that's me!
• [2026-01-17 22:33:17] lil baby baby boomer
• [2026-01-17 23:25:18] the Youth of Today love Emacs
• [2026-01-17 23:25:29] I asked one of them back in... uh...
• [2026-01-17 23:25:31] 1991?

So I did a websearch for the youngest emacs user, and, the websearch results couldn't help but all be about how old emacs users are.

So I ask Lemmy...

Who is the youngest emacs user?

[And no, before anyone thinks otherwise, that image is not real. I just put that together for whimsical illustration, from an image search or 3, with a relevant comment, an image from an article about a 2 year old who self-taught the alphabet, and an image of an emacs welcome screen pasted together with the help of the GIMP.]

Who is the youngest emacs user?

Anyone younger than 40? In 20s? Teens?? Younger??!

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.

OC by @Digit@lemmy.wtf

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.

Emacs Reader, talk, code, emacsconf page This talk described a fast new document reader that leverages dynamic modules. This made it work faster than docview or pdftools.

LLM & Emacs talk, talk, emacsconf page This talk explores what is "editing" and how different classes of emacs LLM tools goes with, or against editing. A quick tour of many tools + an easy going philosophical discussion.

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.

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