<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with vertico]]></title><description><![CDATA[A list of topics that have been tagged with vertico]]></description><link>https://board.circlewithadot.net/tags/vertico</link><generator>RSS for Node</generator><lastBuildDate>Thu, 14 May 2026 23:09:04 GMT</lastBuildDate><atom:link href="https://board.circlewithadot.net/tags/vertico.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[&quot;The history of #Emacs completion frameworks is a progression from monolithic solutions toward composable ones.&quot;]]></title><description><![CDATA[@jameshowell Composability, where each module does one thing well and has a clean interface to the others, is a worthy goal. But from the user perspective, completion _is_ one thing, so why should we need to coordinate and configure seven or eight packages to get it working? Yes, as the article says, there are many _potentially_ orthogonal concerns in completion, but when you separate them into different user packages, you've pushed too much of the complexity of their interaction onto the user.The solution, apparently, is to add another layer of abstraction: emacs configuration kits. It all seems a bit much.]]></description><link>https://board.circlewithadot.net/topic/82b9daa3-a305-40e4-876f-572a6c69e560/the-history-of-emacs-completion-frameworks-is-a-progression-from-monolithic-solutions-toward-composable-ones.</link><guid isPermaLink="true">https://board.circlewithadot.net/topic/82b9daa3-a305-40e4-876f-572a6c69e560/the-history-of-emacs-completion-frameworks-is-a-progression-from-monolithic-solutions-toward-composable-ones.</guid><dc:creator><![CDATA[wirthy@functional.cafe]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>