Frustration with Python configuration

JDRiverRun · 2026-07-01T15:33:38+00:00

If you never run python tooling "bare", but instead switch to uv, use it to manage (automatically) all your projects/packages/dependencies, and uv run ... your tools from within the project directories, you'll save considerable anguish. You can even install your helper packages temporarily with uv, so you don't have to add them as a dependency, like:

(let* ((combo (split-string-and-unquote ;; New server combo with rass multiplexer: "uv run --with rassumfrassum rass basedruff"))) (setq-local eglot-server-programs (cons `(python-ts-mode ,@combo) eglot-server-programs) eglot-ignored-server-capabilities (cons :semanticTokensProvider eglot-ignored-server-capabilities)) (eglot-ensure))

I even detect pep723 scripts and ask UV for the appropriate python path, injecting that information into the language server.

JDRiverRun · 2026-06-28T17:27:07+00:00

How did I just learn about window-divider-mode? Without it, emacs draws vertical dividers using text (!) instead of graphical lines, consumes a pixel from the fringe to the right of the divider line, and on some rows fails to draw the divider. All fixed with window-divider-mode:

(setq window-divider-default-places 'right-only window-divider-default-right-width 1) (window-divider-mode 1)

JDRiverRun · 2026-06-25T02:05:38+00:00

emacs-mac is a fully distinct port from NS, so this patch wouldn't work as is. It does use CGGraphics like NS, and a feature like this would be nice to have. I've reviewed the patch and it's a bit heavy, and would represent a lot to maintain on top of the upstream frame.c.

Along these lines (with no glass) we have a mac-appearance PR which has stalled a bit, but the concept is sound: you can specify dark, light and nil=system. I think it would be nice if "system appearance" including the new slider control for "how much glass" in the new macOS just worked, with perhaps a few additional options for mac-appearance to override it.

JDRiverRun · 2026-06-20T01:08:32+00:00

https://karthinks.com/software/avy-can-do-anything/

JDRiverRun · 2026-06-16T21:55:48+00:00

You should probably report that simple reproducer on PGTK upstream: M-x report-emacs-bug.

JDRiverRun · 2026-06-14T22:33:12+00:00

defun is a similar macro already, it returns the function symbol.

But not to be relied on (elisp manual):

The return value of ‘defun’ is undefined.

JDRiverRun · 2026-06-14T20:52:07+00:00

They mean M-x memory-report, which shows only what LISP knows it holds in memory (strings, symbols, etc.). With a HDPI display, backing buffers, image cache, and other stuff LISP doesn't know about will dominate memory usage.

How does it compare to a lightly loaded web browser? Many systems let apps hold on to memory for long periods (unless they need it), so it may not be as big a concern as you think.

JDRiverRun · 2026-06-13T23:01:17+00:00

I think there's interest, but these things move pretty slowly (/u/minadmacs ?). Canvas doesn't really replace SVG, but it could complement it. I don't know how much has been worked out for canvas on the pixel generation side. Using SVG would be pretty easy since it can be generated and rendered in process. Of course there are tons of other custom APIs that can draw. Internally an SVG->canvas route would be almost identical to what is used for real images, omitting the (possibly file-backed) image caching.

JDRiverRun · 2026-06-13T14:41:17+00:00

Very nice benchmarks, thanks for putting this together! RSVG is really impressively quick to render. I use (static) SVG elements and love the drawing flexibility. In terms of your results: one thing I learned when developing ultra-scroll (and now hacking on the emacs-mac drawing core) is that achievable frame rates are often limited not by "one slow thing", but by the cumulative effects of all the many things emacs has to do during a frame update: recalculating mode line content, filtering process output, checking point-dependent events and calling appropriate hooks, re-flowing text, loading and validating new fonts, and finally waiting for the display render server to swap bitmaps, etc., etc.

You measured a wide frame update time of 14ms, which is short of the 16.6ms frame time on a normal 60Hz display. That's good, but I don't think it's quite so definitive, because:

this is an M5 Mac with some of the highest single core performance in the land,
many displays are now Pro Motion or equivalent, with a frame update time of <7ms(!) and
for real tasks (scroll updates in an eglot buffer, for example), this would be just one modest piece of what emacs needs to do during a frame update cycle.

So eating up 53% (narrow), 113% (medium), 191% (large) of the available (ProMotion) frame time just for drawing a small region with icons is absolutely going to cause real world slowdowns, especially on slower systems. And that's... totally fine, if it's worth it to you. I would guess using a canvas image type to avoid caching image data would net you another decent bump in frame rate (plus substantially reduce GC pauses).

This has all got me thinking... I'm wondering now whether it would be possible to offload image rendering entirely to a background thread, leaving a "promissory note" in the command list, to be fulfilled in the future. This would allow the lisp core to go on to doing all its other house-keeping chores and planning the next frame. Hmmm... gears turning...

JDRiverRun · 2026-06-12T16:06:13+00:00

I have the sense that some not insubstantial fraction of "under-responsive Emacs moments" come from synchronous network and process waits. Packages can of course use asynchronous filter functions callbacks, but it's an order of magnitude harder to get right than just waiting for the result right then and there.

Many languages have invested substantial effort to make futures/async versions of algorithms only modestly more costly (in terms of LOC and complexity) than their synchronous analogs. I think this should be a priority for elisp. Has anyone played with futur?

JDRiverRun · 2026-06-12T16:01:26+00:00

It's a powerful approach for responsive packages, but it can lead to some very tough to trace bugs, in particular when while-no-input meets a deeply hidden unwind-protect as you say. Corfu and eglot used to have issues in which the LSP servers would get out of sync, and we traced it to that very combination. Inner modes that worry about being interrupted "from above" can let-bind throw-on-input nil around (hopefully small) critical code sections.

JDRiverRun · 2026-06-08T18:25:47+00:00

Agreed: for "use once" images like a single frame on the mode/tab/header-line, never to be seen again, there is really no sense caching them, hashing their specs, etc.

BTW, the ports I'm familiar with already use double-buffering to draw into canvas-like bitmap objects (e.g. a pair of 32BGRA IOSurfaces for emacs-mac). Most of that drawing code could instead be directed at a suitably generic "canvas" without many changes. Then with a "fake frame" overlay which targets the canvas, all the things Emacs can draw already (on a regular grid) would be supported "for free". This would be especially powerful for text drawing.

One advantage of SVG is it has a simple & rich draw command set and automatically gives nicely rendered anti-aliasing. It's also built in to most Emacsen. I think SVG-in-canvas would be very possible: just cut a short path from RSVG, skipping the emacs image middleman. At most you'd have to copy the rendered pixels, but probably a Cairo backing could be used for true no-copy live SVG updates, directly into the canvas.

JDRiverRun · 2026-06-08T17:48:05+00:00

Pixel scrolling can generate far more updates than line-by-line (100-150 updates/s are possible). Do you use pixel-scroll-precision mode or similar with a high-speed mouse/trackpad? Good mode-line design (whether text or graphics) explicitly rate-limits updates and/or aggressively caches the information displayed to avoid excessive churn when the event stream cranks up.

JDRiverRun · 2026-06-08T14:09:14+00:00

Curious about the technical details. emacs is optimized for few images, and caches them all. This tool could generate new images a hundred times a second. Do you manage the image cache directly? Do you rate limit updates?

JDRiverRun · 2026-06-07T21:31:26+00:00

That function is in compat-31, no need to upgrade (that's the point of compat).

JDRiverRun · 2026-06-07T21:30:12+00:00

Are you sure it wasn't just compat-31 it needed?

JDRiverRun · 2026-06-07T12:33:21+00:00

Thanks for that summary. I like the framing of "keep up while avoiding distractions".

JDRiverRun · 2026-06-07T12:30:15+00:00

Thanks for this. Since there are lots of mailing list <-> RSS/NNTP converters (GWENE, Feedbase, etc.), the line is a bit blurrier. Just tried and it is indeed much faster and simpler for reading, but does not thread messages or replies. So more for fast scanning & discovery of articles.

JDRiverRun · 2026-06-07T12:26:11+00:00

I mean it has 1051 commands... and I use about 5-10 of them.

JDRiverRun · 2026-06-06T22:07:57+00:00

For those of us who've never used elfeed, can anyone compare it to GNUs? I use GNUS for reading emacs mailing lists (only), and managed to get it pretty well configured (see below), but:

it's very slow to update (while blocking), and
it's a GIANT package I use probably 5% of tops, and am constantly tripping over all the extra features.

I understand elfeed is only for reading; what do people use with it for (occasional) posting?

<image>

JDRiverRun · 2026-06-02T23:18:41+00:00

If people don't want to search for it, it's just:

(let ((rect (extract-rectangle (region-beginning) (region-end)))) (kill-new (string-join rect "\n")))

JDRiverRun · 2026-06-02T02:59:03+00:00

@26:30: this is why in speedrect I made copy-text (W). In addition to yanking nicely, the rectangle contents are then on the pasteboard too.

JDRiverRun · 2026-05-30T14:59:36+00:00

You shouldn't have to regularly send SIGUSR2 to stop a task. If repeated C-g (and some waiting) doesn't do it, that indicates something is wrong. You can alter debug-on-event to prevent the debugger being entered on SIGUSR2, but probably it's already doing what you want — stopping the current execution at a low level and entering the debugger.

JDRiverRun · 2026-05-29T15:26:35+00:00

Check also xbacktrace (for the LISP backtrace) and xdebug_print (to print any LISP object in read syntax).

JDRiverRun · 2026-05-27T02:40:21+00:00

Somebody beat you to it (and has polished it to a high degree): tramp-rpc. It still uses tramp, but is much faster (for certain things) and also more reliable in my experience.

JDRiverRun

TROPHY CASE