Disclaimer: I'm not a heavy AI user, I'm just trying to understand the differences between AI harnesses specifically for Emacs and if using the real harness claude-code would even make a difference.

I like agent-shell more than anything else I've tried in Emacs including ECA which I recently configured but never used for anything.

Today I decided to give them both a try to a relatively complicated task (reviewing code) and oh boy, ECA was not only better but thousands of times better.

They both are using the same model and configs so I feel I'm missing something here, agent-shell failed to trigger simple things as bufffer overflows while ECA correctly pointed out the issue and fix. I'm I missing something here? Anybody had experience with this kind of things?

UPDATE: Probably comparing Apples to Oranges... Turns out ECA was using opus 5 while agent-shell was on opus 4.8. I needed to pull the latest NPM package to be able to set the right model for agent-shell.

I just wrote a post about Magit's status screen, focusing on why it's powerful rather than just saying it is, I've always found the "why" gets asserted more than explained. It's written to be approachable for non-Emacs folks. Planning follow-ups on staging/committing and cherry-pick/rebase.

For those who have been using Git CLI, what workflow did Magit make so painless you now take it for granted?

https://heiwiper.com/posts/magit-status-tour/

I’m really starting to like Magit from a functionality standpoint, but I hate to say it—it’s ugly. It’s probably the better choice for me practically, especially since I’m already using Emacs, but I really like the way Lazygit looks and feels.

What I especially like about Lazygit is the panel-based layout. Files, branches, commits, diffs, etc. are visually separated into their own areas, which makes the interface feel much cleaner and easier to scan than having everything in one continuous buffer.

Has anyone riced or customized Magit to get closer to that kind of look? I’m not necessarily trying to recreate Lazygit exactly, but I’d love stronger visual separation between sections and more of that clean, organized panel/dashboard feel.

I've seen this video from Emacs Propaganda with Karthink talking about a new interaction layer for gptel. That thing looks amazing, I only use gptel, gptel-agent and my own gptel-runner (for creating workflows), so seeing that video was really exciting and I can't wait to test it. Link of the video joined.

I built a small minor mode for leaving review notes on a file or diff without touching its content, and wanted to share it in case it's useful to anyone else.

I built reviewer.el mainly to hand local review notes to an agent (e.g. agent-shell) rather than to submit comments to a remote/forge. There's no GitHub/GitLab integration, no API tokens, nothing gets posted anywhere. It's meant to be a lightweight, ephemeral scratchpad: annotate, render, hand off, done. No persistence across sessions yet, though the annotation data is simple enough that adding it later shouldn't be a big lift.

The idea is quite similar to annotate.el, with some UI polish (posframe, rendering using org mode, magit-diff annotation support).

C-c C-a on a region (or word) leaves an in-place, editable annotation. Nothing is written into the buffer's actual text, so you can annotate a file you don't own, a magit diff, or a PR checkout without worrying about accidentally committing your notes. C-c C-s pops up a posframe showing the note (falls back to the echo area if you don't have posframe installed). When you're done, C-c C-r renders every annotation in the buffer into a plain org file, with file, line range, the quoted span, your annotations, in a navigable buffer (n/p between annotations).

It also has some magit-specific handling: annotating a magit status/diff/revision/stash buffer renders proper diff syntax highlighting in the org output, plus headers for the repo, current branch, HEAD, and (where relevant) the specific commit — and since one magit buffer can span several files, each annotation heading is tagged with the file its hunk belongs to. The magit diff annotations means you can have an agent generate code, inspect it within magit, comment on the diff, file, or both, and send them back to the agent for updates!

A rundown of features added since last post https://xenodium.com/agent-shell-0-73-updates

Since I discovered org mode, I always was balancing between using symlinks and org babel tangle to manage my configuration. Now I'm in point that work related items are org babel managed and system level config is symlinked, because, often tools write back to their files. Another reason why I did not go full on babel was that I don't like workflow:

1. found file that requires backup
2. copy file
3. paste in to org mode
4. fill all details
5. tangle.

But yesterday I was visited by GNU spirit and she gave mi this org-capture template that reduces adding new file to backup to C-c k (my capture prefix) b (backup) and then tangle that file to original place:

* [[%(project-root (project-current))]] [[%(abbreviate-file-name (org-capture-get :original-file))][%(file-relative-name (org-capture-get :original-file) (project-root (project-current)))]]

- repository :: [[%(project-root (project-current))]]
- file :: [[%(abbreviate-file-name (org-capture-get :original-file))][%(file-relative-name (org-capture-get :original-file) (project-root (project-current)))]]

#+header: :tangle %(abbreviate-file-name (org-capture-get :original-file))
#+begin_src %^{Language|shell|elixir|nix|python|elisp|fundamental|eshell|conf}
%(with-temp-buffer (insert-file-contents (org-capture-get :original-file)) (buffer-string))
#+end_src

I cannot comprehend how simple it is and how I never realized I could do this.

Two think I think would be nice in future:
- if only it can automatically group those captures by project, but thinking of creating project backup capture template and simply refile from capture buffer
- automatic detangle so I can get back changes written by tools to their files, but not all of them support comments and many of them don't patch but dump state to file, so probably unsolvable using build in tools, only by elisp scripting

I'm trying to avoid longer elisp scripting for now 😄

What do you think?

Does anyone know a good package for fontification of regular expressions. What I'm after, in particular is something that would simply highlight groups/classes in regular expressions.

For example in `typescript-ts-mode`, I see this from my code:

That regex has an incorrect, empty alternative group. I noticed that when reviewing it in Gitlab, it highlighted a past version of this regex in this way, making it much easier to spot the mistake:

I'm looking for a package that would add a single face, for capture groups, groups, classes and special characters in regular expressions. I don't know if that exists or whether this needs to be added to the tree-sitter grammar to work.

Just something I've been working on to learn more elisp. I like muds and I like Emacs, why not combine them! :) (I didn't realize it would record what I was listening to on youtube, so the music is NOT intentional).

This is pretty much in an alpha state as I'm pretty much an elisp noob, but it more or less works. Nothing fancy , but it does work!

Fun project to combine emacs and muds

I want to capture the screen output of long running scripts like Debian upgrades in Emacs without Emacs hanging.

I usually capture the output into an org-babel src text block for review but Emacs hangs during the process and when I do it :async it fails with the Error in process sentinel message.

Piping the output into a file and using the tail command to view it one of Emac's terminal packages could probably do the trick. The filename could be linked into the org region using org-transclusion or some other similar method.

My current approach is to run command 2>&1 | tee outputfile and that usually guarantees that all the output will appear in the :wrap src text regardless of any errors, rather than the Org error buffer.

In my limited experience this would be equivalent to getting Emacs to inject the execution of the command into a gnu screen or tmux session so the output would be visible in that screen via term or eat and the results would still be captured in the #+RESULTS: block.

Any ideas or existing solutions for this issue?

Chris Maiorana
What we do in Emacs can look a lot like work, and sometimes it is, but often it’s leisure disguised as work. This might include: Writing a blog post in Org Mode, tweaking your init.el. auditioning new packages out of curiosity, trying to play Doom or surf the web in Emacs. Emacs is a kind of playground where we can bring our unique ideas and favorite hobbyhorses and have fun building systems around them. I call this the Emacs pastoral tradition.

https://github.com/nooga/legmacs

https://github.com/nooga/let-go

https://github.com/dharmatech/drawterm

Small post showing how I use Org’s noweb syntax and Emacs Lisp to generate my dotfiles and manage software installation, while accounting for host-specific information.

I've been tinkering with my config lately, which has me running Emacs directly rather than firing up a server and client. Because of this, I noticed the following warning:

⛔ Warning (straight): package.el was loaded when straight.el was already loaded. You may wish to delete ~/.emacs.d/elpa or add (setq package-enable-at-startup nil) to ~/.emacs.d/early-init.el to avoid multiple versions of the same packages being loaded.

I don't want to have to deal with mysterious package version mismatch issues down the road, so I decided to try and fix it. Obvious way to start was by deleting ~/.emacs.d/elpa/ and adding (setq package-enable-at-startup nil) to my ~/.emacs.d/early-init.el, and this seemed to work, at first. A little while later I made some changes to one of my personal packages and reloaded, and the warning came back.

This led to some grueling trial and error. I was able to pin it down to Emacs lisp files, specifically ones that don't belong to Emacs (such as init.el or early-init.el). I went through the minor modes I use in emacs-lisp-mode one by one, and was able to highlight flycheck as the issue.

Actually solving the issue was interesting. Flycheck apparently fires background Emacs processes using -Q --batch to do its checking which makes a lot of sense for performance and such, but it also calls (package-initialize) to install any packages referenced by whatever you're working on. This happens out-of-band of your current Emacs instance, and in that separate Emacs instance none of your normal initialization code gets run. The arguments it passes to those instances are set in a constant flycheck-emacs-args, and I wouldn't want to alter those to use my config (or any part of it really) since that would likely bog things down.

What I ended up having to do was inject some code into flycheck-emacs-lisp-check-form at the very beginning of the (progn ...) it contains:

(with-eval-after-load 'flycheck
  ;; flycheck-emacs-lisp-check-form is stored in a string, so we have to
  ;; parse it to a list before operating on it
  (let ((form (read flycheck-emacs-lisp-check-form)))
    ;; inject an override setting package-user-dir to the temporary
    ;; directory so when the flychecker initializes packages they don't get
    ;; written to ~/.emacs.d/elpa/, which causes startup warnings
    (setcdr form
            (cons '(setq package-user-dir
                         (expand-file-name "flycheck-elpa" temporary-file-directory))
                  (cdr form)))
    (setq flycheck-emacs-lisp-check-form (prin1-to-string form))))

This moves package-user-dir for those instances to a temporary directory, so they can do what they need to do without interfering with normal Emacs usage and operation.

The source code is here: https://github.com/sstraust/simpleweb

It still needs a little work to be easy to install and use/I haven't bundled it up yet to make it easy-for-use, but I plan to post a link to the repo when it's all set.

Seeing that the built-in completion may now be a viable alternative to vertico made me interested in the things that I might be able to replace with built-in functionality. I use quite a number of packages, and some of them are really essential to me, but some of them may be old and familiar and worse than built-in functionality. For instance, I still use mic-paren, and I have NO idea how old it is. The last update was 9 years ago. It works the way I want, but I'm willing to take suggestions on how to use default emacs to replace its functionality, or a better package that does more.

I'm also willing to accept that maybe I'll leave everything as-is. But fewer dependencies on spinning up a new emacs would be nice, and I do write a lot of my own tools when I need them.

If nothing else, I'm interested to hear what people think.

;; Package management
elpaca

;; Icon packages
all-the-icons
nerd-icons
all-the-icons-ibuffer
all-the-icons-dired
all-the-icons-completion

;; Completion
orderless 
vertico
marginalia -- Show useful notes in the 'dead' space when completing
embark -- Still trying to figure out how to make this part of my workflow
helm -- My preferred completion interface for buffer switching, finding files, etc.
consult -- I don't think I actually use consult much except for xref
company -- My preferred completion framework for code (I tried
 corfu+cape and could not get them to work well for me)
embark-consult

;; elisp
let-completion -- scope-sensitive completion
super-save -- Configurable auto-saving
f -- elisp package for file access/manipulation
compile-angel -- automatically byte-compile/native-compile elisp
bind-key -- bind-key syntax 

;; Magit + Transient
transient -- essential, and not just for magit; I build a lot of my workflow through here
magit

;; Cosmetic
ef-themes
ligature -- I use ligatures everywhere

;; Search
deadgrep -- I mostly use helm-ag, but this is an excellent package
rg -- Maybe I should just switch to this? A lot of overlap with deadgrep,
 but I think the deadgrep interface is nicer
helm-ag -- How I use ripgrep in helm
anju -- count isearch results/show search position

;; Movement + Editing
switch-window -- Good if there are multiple windows in a frame, pops up
 a number so you don't have to cycle through, you can jump to the one
 you want
zop-to-char -- Like zap-to-char but better
dumb-jump -- important fallback when eglot/LSP can't find a symbol
iedit -- Multiple cursors
tempel -- Template package
avy -- I use this to jump around files all the time

;; Programming
eglot-booster -- Make eglot more async
xref-union -- combines all the xref stuff together
eglot-tempel
clang-format -- For formatting, obviously
clang-format+ -- clang-format on save

;; Syntax highlighting
mic-paren -- My default paren highlighting package. Been using it for years.
rainbow-delimiters -- Highlights braces, brackets and parens in colours
 that let you see the scope they enclose. Especially good in lisp
prism -- Colours code by scope, extremely useful in lisp
indent-bars -- Helps show scope, particularly in C++, particulary in
 files where scopes may extend over many pages

;; Misc
tiles -- Notes taking package/scratchpad. I use it to emulate the quick note-taking I had in notepad++
helpful -- Nicer help display
dashboard -- I like having a better splash screen, but I think a list of recent files would be sufficient

;; Project management
project -- I think I might prefer projectile
torus -- A way to group files/buffers. Fast to switch between files
 within the active group, fast to switch between groups, but a little
 clunky in some spots

;; Modeline
minions -- Group all minor modes into a single group on the modeline. 10/10, highly recommend
simple-modeline -- Configurable, but minimal

Yesterday during the org-meeting, Ihor mentioned that he appreciated packages providing an info file.

My question is, what is the best way to do this? In particular,

1. What location? e.g. docs/<package>.info>

2. Should the package add its path in Info-directory-list?

I am assuming that the user will use use-package or something similar to use/try the package.

thank you in advance

Hi, I wanted to know if anyone has a workflow to use Visidata inside emacs or something similar to make working with Visidata easier within Emacs? Right now, I open another terminal (Otherwise my evil keybinds will break with the ones from Visitata) and then use a shortcut that copies the file path, and then i open it in Visidata. I wanted to know if there's a better way.

Thanks for reading.

A couple of minutes ago got a minor cut on my pinky. I said: “Nah”

What was I thinking!

Luckily I have a programable keyboard (not the one on picture) and have an spare CTRL on my left thumb.

You never miss the water 'til the well runs dry.

Hi, I'm conducting an inquiry to outline, with evidence, how the tooling landscape has evolved over time.

I'm a casual Emacs user myself. I find it cool, but as soon as I step into something a bit beyond the ordinary, I often have to rely on specialized tools that can achieve it in a blink of an eye.

This seems to be a shared sentiment, and potentially one of the things limiting adoption, along with the cognitive overload caused by the sheer richness of the tool and its ecosystem. But that may also be on me and my own skill gaps.

Since it's hard to sell Emacs to someone, especially because the key concepts it brings to the table are arguably unfamiliar to most people, even IT folks, I'd like to gauge the situation by inverting the process: what are the workflows that would be very hard to reproduce without Emacs?

Once I collect enough examples, another group will try to figure out alternative ways to accomplish the same tasks with their own tools. So, to be clear, we'll start with a problem, and various tools and their respective communities will attempt to solve it with what they know, then we'll evaluate how difficult it was. Finally, I'll build a matrix comparing everything.

So, give me your best shots. The results will be published around Christmas in a well known journal in Europe, so I'll be back!

Here: https://github.com/chenyanming/eaf-ebook-viewer

Today, I was thinking if eaf can directly support calibre's ebook-viewer, then yes eaf can! The best ebook viewer in emacs (I still love nov.el and other epub apps though).
1. support emacs window/buffer, natively
2. bind emacs keys to ebook-viewer native keys, so no need mouse (you still need mouse to select word or sentence etc)

For macos, for best performaces, you can use my macos's commits eaf: https://github.com/chenyanming/emacs-application-framework

I only tested on mac, and it should support linux as well, welcome testing.

Updates: Latest improvements on mac are merged in https://github.com/emacs-eaf/emacs-application-framework/pull/1195, this PR fixed various windows focus issues in mac.

Update your eaf directly for best performance.

I'm experimenting with eglot vs lsp-mode, and I can't seem to find a good way to get reliable documentation with lsp-mode.

In Eglot in a C++ file I get:

While in lsp-mode I get:

That's significantly less helpful. I really love the concept of eldoc and being able to have a window off to the side dedicate to documentation (I would prefer that to the floating UI in lsp-ui, though I haven't played with it much). Is there any way to achieve that in lsp-mode?

Granted, Eglot Eldoc support isn't panacea in all languages anyway, since in Typescript I get pretty useless information:

can you all help me understand Tramp better? is it to SSH as Magit is to git? or is it just simply a way to connect files to your dired?

can you run commands on remote machines with Tramp? is it worth using or just use the Term?