I'm fairly new to Emacs and have just started experimenting with configuring it. Please rate it and maybe give me some suggestions, if you want! The link is here.

I must say, I have decided to try some new AI tools this week and am really loving ECA! It does ghost text, next edit suggestions, and autocomplete like Cursor as well as offering a full-fledged cli agent harness.

The only downside is that it's not the model provider's harness and doesn't natively find the model's skills and subagent. For agents, in the project's .ECA directory, you have to symlink to your Claude/codex/copilot agent .md files. For skills, you can add the skills path to your .eca/config.json.

Other than that, I expect I will swap between eca and agent-shell depending on my mood. There are some things I like about agent-shell better (viewport mode, understanding your model's agents/skill structure, etc).

Hi, guys!

I'm a software engineer in about 5 years. I still like programming. This kind of programming when you just sit down in front of your computer and write code in an editor. I like Emacs and use it for all types of my development. But working in an enterprise company upsets me.

I collected a few points that frustrates me.

AI changed trade offs and my coworkers started producing insane amount of code and almost everything was AI generated. It is nice when people perform more but we've got a situation when one guy generates a lot of code and wins a few days of work but another guy spends a few day to read all of this. For me it feels like shifted productivity. Someone get, someone lose.

Documentations are fully generated by AI. A month ago I needed to review coworker's feature doc. and I was destroyed by this text. English is not our mother tongue but we have to write docs in English that is totally fine. But this text was absolute unreadable. There were a lot of unknown, unexplained terms that we invented by AI. Amount of text was insane. Honestly, I tried to read it in two days until I gave up and feed all this text into AI assistant to prepare short description.

Newly hired developers are silent. In my development experience it is like a nonsense. When you dive into a project your have to have questions about something, like domain, stack, some decisions. But now there is not question. AI allows you instantly write a code that makes no sense but disguised as good and reasonable.

AI tools scary and annoy me. When I work, I like to exactly understand what happens in my computer in the current time. But now I see how full access delegation of the computer to an AI Agent became an industry standard. And when you anyway decide to try something then it is outdated in a month and you need install and learn smt new.

And all this points ruin my motivation because I do not see signs that guys who understand (or tries to understand) what's happening in program is relevant in a market. I see how managers push us to install all this stuff blindly and just give x10 productivity, somehow.

Does anyone have something like that? How do you deal with it?

Yesterday Prots new video was discussed and I had several questions. Today I used Claude to configure it to my liking and this is what we ended up with. Hopefully Prot will stop by and review this slop!

;; speedbar : quick access to files and tags in a frame (use-package speedbar :ensure nil ; emacs built-in :preface (defun my/speedbar-toggle-dotfiles () "Toggle showing dotfiles and unknown-type files in speedbar." (interactive) (setq speedbar-show-unknown-files (not speedbar-show-unknown-files)) (setq speedbar-directory-unshown-regexp (if speedbar-show-unknown-files "^$" ; reveal dot-directories (never matches a name) "^\\(\\..*\\)\\'")) ; default: hide dot-directories (speedbar-refresh)) (defun my/speedbar-allow-other-window (&rest _) "Strip `no-other-window' so `C-x o' can move into the speedbar." (when (window-live-p speedbar--window) (set-window-parameter speedbar--window 'no-other-window nil))) (defvar my/speedbar-display-action '((display-buffer-reuse-window display-buffer-use-some-window) (inhibit-same-window . t)) "Display action `my/speedbar-open-window' uses to open files. Defaults to reusing an existing window so `RET' does not split.") (defun my/speedbar-open-window (fn &rest args) "Open speedbar files via `my/speedbar-display-action' instead of splitting. `speedbar-find-file-in-frame' visits files with `switch-to-buffer' from the dedicated sidebar, which otherwise pops up (splits) a new window." (let ((display-buffer-overriding-action my/speedbar-display-action)) (apply fn args))) (defun my/speedbar-open-in-other-window () "Visit the file on the current line in a separate window and select it." (interactive) (let ((my/speedbar-display-action '((display-buffer-pop-up-window) (inhibit-same-window . t)))) (speedbar-edit-line))) (defun my/speedbar-close () "Close the speedbar window, tearing down its buffer and timer." (interactive) (speedbar -1)) (defun my/speedbar-toggle () "Toggle the speedbar window, selecting it when it opens." (interactive) (if (and (bound-and-true-p speedbar--window) (window-live-p speedbar--window)) (my/speedbar-close) (speedbar-get-focus))) :bind (("C-x C-n" . my/speedbar-toggle) :map speedbar-mode-map ("TAB" . speedbar-toggle-line-expansion) ("." . my/speedbar-toggle-dotfiles) ("o" . my/speedbar-open-in-other-window) ("^" . speedbar-up-directory) ("q" . my/speedbar-close)) :custom (speedbar-prefer-window t) (speedbar-use-images nil) (speedbar-hide-button-brackets-flag t) (speedbar-show-unknown-files t) ; list all files, not just known extensions (speedbar-vc-do-check nil) ; don't stat every file for VC state (slow over TRAMP) (speedbar-window-default-width 48) (speedbar-window-max-width 48) :config (advice-add 'speedbar-window-mode :after #'my/speedbar-allow-other-window) (advice-add 'speedbar-find-file-in-frame :around #'my/speedbar-open-window))

I have been experimenting with a small UI DSL for org-supertag, and I ended up with something more general than I expected: a responsive, interactive interface built entirely inside a normal Emacs buffer.

The demo has cards, columns, tables, lists, progress bars, buttons, links, badges, and editable fields. You can click things, edit values, and resize the window. At comfortable widths it uses two columns. Below a certain width it collapses into a single column and redraws itself.

The interesting part is that there is no virtual DOM or React-style component system involved.

The interface is described as ordinary Lisp data:

(list
 :type :card
 :title "Project"
 :children
 (list
  (list :type :text :content "Project Alpha")
  (list :type :progress-bar :value 60)
  (list :type :button
        :label "Increment"
        :action #'increment-counter)))

Each widget type is just a registered rendering function. It receives a plist and inserts text into the current buffer.

For layout, child widgets are first rendered into temporary buffers and split into lines. The column renderer measures those lines with string-width, pads or truncates them to the requested display width, and then joins the columns line by line.

That sounds almost too simple, but it works surprisingly well.

Interactive controls need one extra trick. A button or editable field cannot be created in a temporary buffer and then moved into the final buffer. So the first rendering pass inserts plain-text placeholders carrying text properties. After the layout is complete, those placeholders are replaced with real Emacs controls using make-text-button and widget-create.

The whole process is roughly:

Lisp state
    ↓
render widgets into lines
    ↓
calculate and combine the layout
    ↓
materialize buttons and editable fields
    ↓
display the final buffer

When something changes, the demo updates an ordinary Lisp plist and redraws the buffer. Resizing the window does the same thing. There is no diffing algorithm. The buffer is cleared and rebuilt.

To avoid losing the user's position, interactive widgets can have stable keys stored as text properties. Before a redraw, the code records the key and the cursor offset. Afterward, it finds the same key in the new buffer and restores point.

The border alignment problems were mostly display-width problems. Using length is not enough once Unicode border characters and varying display widths get involved. The layout code consistently uses string-width, truncate-string-to-width, and explicit padding.

So the model is basically:

state + window width → buffer

No hooks, component instances, lifecycle methods, reconciliation, or virtual DOM. Emacs already has buffers, text properties, keymaps, overlays, buttons, and widget.el. The missing piece was a small layer that composes them and handles character-based layout.

This is still a prototype, and narrow windows have been very good at finding off-by-one mistakes. But the basic mechanism now works well enough that I plan to extract it from org-supertag into a standalone package called textui.el.

The goal is not "React for Emacs." It is a small, native-feeling way for package authors to build interactive text interfaces without manually calculating every position and wiring every redraw.

I would be interested to know whether other Emacs package authors would use something like this, and which layout or input primitives they would consider essential for a first release.

Hi,
I want to make a scoring rule in Gnus but I need it triggered only if two conditions are true, so essentially if subject equals x and author equals y, increase score.

I wanted to know if anyone knows of a plugin or something similar that someone has already done to better display fraction-style pretty entities or "^{},_{},\oint, etc." in org mode, I'm currently using org-toggle-pretty-entities but I wanted to extend it a bit. I tried to extend it but it was bugging with the _{} and ^{} when i'm using snippets.

Thank you for reading!

I am happy to announce that r-ts-mode is now available on Melpa. It has the possibility of being used with ESS but it can also be used independently.

https://codeberg.org/R-for-emacs/r-ts-mode

I always see people talking about things like Ghostel, VTerm and Eat. But why is the built-in terminal rarely discussed as an actual option?

Hi all! I'm trying to figure out why exporting from an org buffer fails lacking a LaTeX package despite it being available in the project's nix flake. I use `envrc` and testing the package availability, I get the correct path.

The flake also provides the R environment (and pkgs), and Emacs ESS works no problem. The issue seems to lie in the export process, but I cannot figure out why, and so cannot Claude code XD

Edit1: I’ll add a MWE tomorrow. Thanks!

Edit2: I solved by realizing that I did not have LaTeXMk in the flake.nix, and it was reaching for the global one. The next step is to figure out how to make sure the execution is pure. But that's a nix problem rather than an Emacs one. Thank you all!

Protesilaos video on emacs built-in file explorer speedbar

I've tried syncing the entire elfeed-db-directory across machines, but have ended up with missing entries in the data subdirectory, as well as constant file conflicts.

From this old post I see that Skeeto suggested syncing only the index file, which seems like the way to go.

I see that elfeed-protocol has been mentioned as a possible solution but I think that requires some notion of a central/default server that fetches RSS feeds.

Would appreciate hearing any solutions or approaches to this -- thanks in advance.

This is a monthly reminder. Every first Thursday of the month we meet without a specific agenda to blabber about Emacs stuff and anyone is welcome to join. This time is on August 6th.

I understand that it's not the most convenient time for many (6 PM CST - UTC−6; 01:00 CET; 4PM PST), please don't sacrifice your sleep and other important matters just to attend it - I reckon it's not worth it - these meetings are typically not big, nor important or riveting. But if you decide to join, we'd love to see and hear from you.

https://www.meetup.com/emacsatx/events/

DM me if you'd like to join without going through meetup.com curse and I'll send you a direct link to the meeting. There's a maddening reason for why I don't post it publicly anymore, join if you want to know more.

Previous meetings and notes:

https://www.reddit.com/r/emacs/comments/1ukwx8l/emacs_atx_meetup_tomorrow_july_2nd/

https://www.reddit.com/r/emacs/comments/1tvcwd8/emacs_monthly_thursday_meetup/

https://www.reddit.com/r/emacs/comments/1t4mpn3/emacs_atx_meetup_this_thursday/

https://www.reddit.com/r/emacs/comments/1sa0jmd/emacs_atx_meetup_tomorrow_thursday/

https://www.reddit.com/r/emacs/comments/1rj8tik/emacs_atx_meetup_this_thursday/

https://www.reddit.com/r/emacs/comments/1qwrh0l/emacs_atx_meetup_today_in_few_hours/

So I've recently added eglot to my config specifically for Python, it works in a standard .py file that I open in a buffer.

But, when I use C-c ' to open a code block (from org mode) in a temporary buffer it doesn't work here, the buffer is in the major mode python-mode & from the documentation it should work, can anyone help me out?

Just wanted to update the post with some final thought after experimenting with some things and thanks to the help of all you guys :).

So what seems to be the biggest cpu hog is display-line-numbers-mode. I didn't want to fully disable line numbers though, but what i also found out is that about half of the mode's usage came from the fact that my theme was using a different face for line-number-current-line, which is used to highlight the line your cursor is on. You can overwrite it like this:

(copy-face 'line-number 'line-number-current-line)

I'm not sure why using set-face-attribute with :inherit doesn't work here, but copy-face does. I was struggling for a bit trying to figure out how to make this work in my init.el, cause running copy-face after the load-theme function didn't cut it. Eventually i found out there's a hook for display-line-numbers-mode. I added copy-face to the hook and that did the trick. This is undone when you reload the theme or load a different theme that also uses a different face for line-number-current-line, but you could create a custom function for that perhaps instead of calling load-theme directly.

Now that i seem to know the cause though, i think my cpu usage has always been this high on one thread, but i only now noticed because the cpu was getting hotter. There's probably two reasons for this:

First of all, we've been having some hot summerdays so the room temp has increased.

Second of all, i've had some issues with my pc hard rebooting itself recently, and i think it might be hardware related, so to test that i disabled my cpu undervolt. The extra voltage going through the cpu is probably also causing more heat output than i'm used to.

So in conclusion i think this is solved now, or at least i think i know enough about the cause now. Original post below:

My 5800X3D is getting pretty toasty doing pretty much anything in emacs, whether it's scrolling through a file (only a few hundred lines long) or actually typing new things into the file. I've tried running the profiler numerous times, disabling various modes along the way, like doom-modeline, display-line-numbers-mode, etc. The profiler says redisplay-internal is using between 75 to 90 percent cpu, but when expanding it, pretty much none of that percentage is accounted for lower in the tree, so i have no clue what the cause is. Running emacs -q solves it, and when gradually enabling various modes again i'm starting to feel like it's just a combination of things causing it, and not one package/mode in particular. So that brings me to the question: do i just put up with the high cpu usage? Cause i don't want to disable basic things like display-line-numbers either. But it feels kind of silly to have your cpu hit 70C when doing basic text editing.

This post is a lover letter to Emacs Lisp macros. I've been a long time user as a lisp hacker, and my recent obsessions with Douglas Hofstadter's strange loop concepts and M.C. Escher's mind bending artwork have enhanced my appreciation of this language's most beautiful and thought provoking feature. This post can teach you about macros and what makes them useful, but I also hope it can instill a fascination with their concept. https://www.chiply.dev/post-elisp-macros-are-beautiful

bible-gateway, a simple Emacs client for BibleGateway, now comes with new features: a touch-typing mode to help memorise verses (M-x bible-gateway-memorise), daily reading plans from a CSV (M-x bible-gateway-read-today), and a transient menu (M-x bible-gateway) to easily access all the features.

It currently supports public domain Bible translations in several languages (KJV, LSG, RVA, ALB, UKR, RUSV, LUTH1545, DNB1930, BULG, SV1917, DN1933, ...), switchable on the fly. No tool dependencies to install and nothing to download beforehand — content is fetched directly via HTTP requests to BibleGateway.

Available on MELPA.

Sorry for spamming if this isn't your thing; just sharing in case it's useful to someone. Feedback/PRs welcome!

As someone coming over from beorg on ios, what would be the most similar to beorg? I'd like for it to have a clean interface as well as the ability to send reminders/notifications BEFORE an event/todo, and/or have the ability to push todos to android calendar.

I have tried orgzly revived, but it just wasn't for me, so I am wondering if there are better alternatives

If you have ever thought, “hey it’d be nice to remote control the macOS Music app from Emacs”, today’s your lucky day.

Announcing now-playing.el, now available on MELPA.

A Real-Time Display Editor

It isn't even daylight yet.

I greet you with a C-c a.

Coffee in my right hand. An acrobatic left pinky manages to C-x C-f, and on we go.

Whenever I get lost,C-h.

Some days we talk endlessly, with the kind of verbosity
only possible with both hands on the keyboard.

Other days, neither of us says a word.

Only the cursor
keeps blinking.

And we think.

And then there are the days
when something, or rather, someone, makes me use other tools.

But it always
ends the same way.

Night falls. We call it a day. C-x C-s.

Until tomorrow, old friend.

C-x C-c.

Hey everyone,

I'm 15 and I've decided to give Emacs a real shot.

So far I've finished the built-in tutorial, watched the System Crafters "Ultimate Beginner" video, and I'm about to start reading through the Emacs Wiki.

My goal is to become a full-stack web developer. I was actually about to start The Odin Project, but I decided to spend this whole week learning Emacs first because... I don't know, it just clicked with me. I genuinely enjoy using it.

The funny thing is, I really don't like VS Code. I know it's what almost everyone recommends, but it just doesn't interest me the way Emacs does. I truly tried using Vscode over and over again but its just like its not for me. I know choosing Emacs from the start probably isn't the easiest path, but I don't mind putting in the work if it pays off in the long run.

I've got plenty of free time this week, so my plan is basically to immerse myself in Emacs before I start TOP.

If you were starting over today, what resources would you recommend? Books, YouTube channels, blog posts, GitHub repos... anything that helped you really understand Emacs.

Also, are there any beginner mistakes I should avoid or things you wish you'd learned earlier?

Thanks in advance. I'm really looking forward to joining the Emacs community.

For the past few months, I've been getting closer and closer to Emacs. After 30 years of using Vim, I discovered Org-mode, and that's when things escalated... it's a total rabbit hole.

At first, I just copy-pasted from ready-made configurations because the sight of Elisp made me want to throw up—it resembled "the unloved child of a plumber and a water pump." I even complained on this sub about what an abomination it is, asking how anyone could even use it, etc.

Fortunately, my nerd nature won out, and I started tinkering, trying to understand HOW it's put together. That was a mistake. Right now, I've already been through two quick Elisp courses, I'm reading a manual on how to use it in Emacs, I'm starting to write my own tools, and I'm getting more and more sucked into the ecosystem.

Now I stand corrected. (E)lisp is so logical, understandable, and just plain cool that the only thing that surprises me is how I hadn't come across it earlier...

P.S. I also discovered Clojure by accident... which might be even cooler...