> Partly because I wanted my config to survive without breakage across Emacs releases. Partly because I was tired of dealing with package repositories, mirrors going down in the middle of the workday, native compilation hiccups, and the inevitable downtime when something changed somewhere upstream and my job suddenly became debugging my very long (at the time) config instead of doing actual work.
Picking on this detail, what I've found works nicely is that when a new major Emacs version flows into my Debian, I also update all packages to their latest versions and then freeze those versions until the next major Emacs release. And those versions are locked in my emacs.d git repo, so I have a reproducible Emacs at home and work both. There's a little iteration to adapt to changes in Emacs and packages, but after that, it's stable and reliable for a year or two.
Trying out vibe-coding (so mostly not even reading the code) a note-taking web app that's essentially a simplified and dirt-cheap to host Workflowy clone. That seems to me like an easily disruptible SaaS in the sense that note-taking is a very generic app, I only use a small part of the feature set of Workflowy and find the price far too high given that. A lot of other vibe-coding around me I see is throw-away junk, but my intention is to actually use this. The frontend is mostly done and working quite nicely already. Sync is then more crucial to get right to avoid data loss and I think I'll review and rewrite myself more of that.
Is the frontend component from scratch? Must be quite hard to get that right. I wish Dyanlist (from the same talented people who are doing super well with Obsidian...) was open-sourced so we had a good model for outliners.
Yeah, the frontend is from scratch. Each bullet is just a div contenteditable. The DOM is the state (Claude Code suggested the usual frontend pattern of separate state and rerenders, but I rejected that). Apart from the DOM, content is dumped to local storage. Bullet folding and zooming work mostly just by showing and hiding the bullet divs i.e. the whole note tree is all the time in the DOM. It's conceptually quite simple and Claude Code is good at writing code that traverses the DOM. There's of course a lot of operations like indent/dedent, copy-paste, undo/redo etc. but they've been quite painless to add.
I recently revised my script to rely on (1) no commits in the last 30 days and (2) branch not found on origin. This is obviously not perfect, but it's good enough for me and just in case, my script prompts to confirm before deleting each branch, although most of the time I just blindly hit yes.
I've been experimenting with using LLMs for a content recommender system. Specifically I've built a news reader app that fetches news articles from multiple RSS feeds, uses an LLM to first deduplicate and then score them. The user can then rate the articles and those ratings are used as few-shot examples in the LLM scoring prompt. Any resulting low score articles (uninteresting to the user) are hidden by default and visible ones scaled by their score on a dynamic CSS grid like on a traditional newspaper front page. Looking good so far, but still testing and tweaking.
One thing I’ve always disliked about RSS (and this could actually fix it) is duplicates. When a new LLM model drops for example there are like ~5 blogs about it in my RSS feed saying basically the same thing, and I really only need to read one. Maybe you could collapse similar articles by topic?
Also, would be nice to let users provide a list of feed URLs as a variable instead of hardcoding them.
Looking at the console messages with the LLM reasoning, it does seem to work quite nicely for deduplication. Your example is probably even a lot easier than news articles, where you can have many articles from different viewpoints about the same event.
I don't actually plan to run this as a service so there's some things hard-coded and the setup is a bit difficult as you need an API key and a proxy. Currently it's just experimentation, although if it works well, I'll probably use it personally.
Ive been working on something similar, have you had any issues with the LLM not giving you back a full response for all the input? Ive been using Chat gpt but even on the same request sometimes id give it 20 things to rank, and Id just get back 3 results
No, it's been working without problems so far. I'm using Anthropic for what it's worth. I ask the LLM to first do some reasoning and then return a JSON array on the final line. Sometimes I've seen some Markdown backticks there, but no irregularities more than that.
My favorite of the year would be Maxim Gorky's three-part autobiography: I read "Childhood" and "In the World" (a.k.a. "Amid Attendants") and just started the last part "My Universities". Gorky drifted as an orphan from house and job to another and describes an interesting array of characters he came across, mostly poor and misfortunate, but many of them good as well.
"He took me under the arms, lifted me up, kissed me, and placed me firmly on the jetty. I was sorry for him and for myself. I could hardly keep from crying when I saw him returning to the steamer, pushing aside the porters, looking so large, heavy, solitary. So many times since then I have met people like him, kind, lonely, cut off from the lives of other people."
It's unfortunate that Python and R don't really have any out-of-the-box means of opening data files from arguments, but if you do this kind of stuff on a daily basis it's something that you can set up. My not directly usable examples below.
Agreed! It's easy understand "LLM with tools in a loop" at a high-level, but once you actually design the architecture and implement the code in full, you'll have proper understanding of how it all fits and works together.
I did the same exercise. My implementation is at around 300 lines with two tools: web search and web page fetch with a command line chat interface and Python package. And it could have been a lot less lines if I didn't want to write a usable, extensible package interface.
As the agent setup itself is simple, majority of the work to make this useful would in the tools themselves and context management for the tools.
Picking on this detail, what I've found works nicely is that when a new major Emacs version flows into my Debian, I also update all packages to their latest versions and then freeze those versions until the next major Emacs release. And those versions are locked in my emacs.d git repo, so I have a reproducible Emacs at home and work both. There's a little iteration to adapt to changes in Emacs and packages, but after that, it's stable and reliable for a year or two.
https://github.com/radian-software/straight.el