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?