u/AsleepSurround6814

Image 1 — `flex-x: built-in flex completion with AND filtering, history-aware sorting, and migemo/pyim support`
Image 2 — `flex-x: built-in flex completion with AND filtering, history-aware sorting, and migemo/pyim support`
Image 3 — `flex-x: built-in flex completion with AND filtering, history-aware sorting, and migemo/pyim support`
▲ 21 r/emacs

`flex-x: built-in flex completion with AND filtering, history-aware sorting, and migemo/pyim support`

Hi r/emacs,

I made a small completion-style package called flex-x. It extends Emacs's built-in flex style rather than replacing it with a new matching engine.

For me, orderless is still the gold standard among completion styles. In particular, I like how space-separated components make it easy to narrow a large candidate set, and how leaving sorting to the completion table or frontend often produces a very natural order—for example, preserving the useful order of find-file candidates. Its matching-style dispatch also makes integrations such as migemo and pyim possible.

At the same time, I also like one property of built-in flex: it scores matches, so candidates that are more closely related to the input can rise to the top. The downside is that loose flex matching can leave many candidates in the list, and those weaker matches can become noise.

flex-x is my attempt to combine the parts of those experiences that I find useful:

  • space-separated AND filtering: every input term must match;
  • history-aware sorting: minibuffer history first, then flex match quality;
  • optional Corfu history sorting outside the minibuffer;
  • customizable extra matchers or regexp expanders for non-ASCII candidates, including migemo and pyim;
  • standard match highlighting, plus whole-candidate highlighting for strong literal or consecutive word-prefix matches.

That last point is meant to make a noisy flex result set easier to scan. A loose subsequence match keeps the normal per-character highlighting, while a stronger match—such as a contiguous term or a sequence of word prefixes—is emphasized as a whole.

The package is frontend-agnostic: it uses normal completion metadata and is intended to work with the completion UI you already use. It does not require Vertico, Corfu, migemo, or pyim. Optional non-ASCII matching is also bounded by default so that it does not perform an unlimited scan of very large completion tables.

Basic setup:

(use-package flex-x
  :ensure t
  :config
  (setopt completion-styles '(flex-x basic)))

Migemo integration can be as small as:

(with-eval-after-load 'migemo
  (setq flex-x-extra-pattern-function #'migemo-get-pattern))

For Chinese candidates, pyim can provide pinyin-based regexp expansion:

(with-eval-after-load 'pyim
  (require 'pyim-cregexp-utils nil t)
  (setq flex-x-extra-pattern-function #'pyim-cregexp-build))

flex-x requires Emacs 30.1 or newer and is available from MELPA:

I would especially appreciate feedback on the matching and sorting behavior: whether history-first ranking feels natural, whether the stronger highlighting helps when flex produces many candidates, and whether the extra-matcher API works well for other non-ASCII search tools.

u/AsleepSurround6814 — 4 days ago

smith.hx: an early declarative plugin manager for Helix, inspired by Emacs use-package

Hi! I've been working on smith.hx, a declarative plugin manager for Helix built with Steel and backed by Forge.

The idea is to declare plugins in init.scm and let Smith handle installation, loading, configuration, keybindings, updates, and removal. A declaration can have separate init, config, and bind phases, with Smith running them in the appropriate order.

The screenshot shows:

  • Left: packages installed and managed through Smith
  • Center: the corresponding declarations in init.scm
  • Right: the output of :smith-list in a *smith-list* scratch buffer

Current features include:

  • installing Git repositories through Steel's Forge
  • automatic package-name and entry-file detection
  • init, config, and bind declaration phases
  • enabling, disabling, updating, and removing packages
  • pruning manager-owned packages that are no longer declared
  • lock and restore support
  • Helix commands such as :smith-list, :smith-update, and :smith-prune

This is still an early preview, so the API may change. It currently requires a Helix build with Steel support. I would especially appreciate feedback on the declaration syntax, package lifecycle, and the overall approach.

Repository and installation instructions:

https://github.com/kn66/smith.hx

The README also contains a short GIF showing the workflow.

u/AsleepSurround6814 — 13 days ago

I tried Helix’s experimental Scheme plugin system as an Emacs user

I saw this post in the Emacs community about Helix potentially getting a plugin system based on Scheme:

https://www.reddit.com/r/emacs/comments/1ulcjxr/helix_is_getting_a_plugin_system_that_uses_scheme/

I usually use Emacs, but the idea of using Scheme for editor plugins caught my interest, so I built the relevant Helix branch and tried writing a few Scheme plugins myself.

I made two small experimental plugins:

https://preview.redd.it/vvkap2y9a8bh1.png?width=435&format=png&auto=webp&s=b575d6a25a8c93e40cba57f729c4e572a1267fd3

https://preview.redd.it/6r4l58wfa8bh1.png?width=921&format=png&auto=webp&s=07902a4c69fe3a1ebfdbaba01311803c5a2c7075

https://preview.redd.it/5lwj7n9ha8bh1.png?width=358&format=png&auto=webp&s=a3b1d8c2e19b048208ecfb3e8799a8c425dd1e4d

https://preview.redd.it/quq5nhzna8bh1.png?width=810&format=png&auto=webp&s=98537ebf2eb67749c2c6503a22c898d0b088d3f3

These are just prototypes, so the quality and completeness of the plugins themselves are still rough. But after actually building Helix and writing plugins in Scheme, my impression was very positive.

What I liked most was that it felt possible to extend the editor while still keeping Helix’s design relatively simple and lightweight. Scheme feels a little unusual at first, but for small editor extensions it actually seems like a good fit.

Of course, this still seems experimental, and there are many things that would need to be figured out: API stability, documentation, plugin distribution, security, and so on. But as an Emacs user, I found this direction genuinely promising.

For transparency, I used Codex GPT-5.5 to help develop the plugins. Still, this impression comes from actually compiling Helix, writing Scheme plugins, and trying them locally.

reddit.com
u/AsleepSurround6814 — 21 days ago
▲ 55 r/emacs

commonmark-gfm.el: a pure Emacs Lisp CommonMark/GFM renderer

Hi everyone,

I’ve been working on commonmark-gfm.el, a pure Emacs Lisp Markdown renderer focused on CommonMark and GitHub Flavored Markdown compatibility.

Repository: https://github.com/kn66/commonmark-gfm.el

The project started from a simple preference: I wanted Markdown rendering that could stay entirely inside Emacs Lisp instead of shelling out to an external tool. There are already excellent Markdown renderers, of course, but having one implemented in Elisp makes it easier to inspect, customize, and integrate directly with Emacs workflows.

It can be used as a markdown-command replacement, for example with markdown-live-preview-mode, without requiring an external Markdown executable.

Current highlights:

  • Pure Emacs Lisp implementation
  • CommonMark block/inline parsing
  • GFM extensions such as tables, task lists, strikethrough, autolinks, and tagfilter
  • HTML rendering
  • Optional default CSS for browser HTML output
  • Optional Mermaid.js support for browser-side diagram rendering
  • Source position tracking for parsed nodes
  • Local cmark-gfm spec.txt check currently reaches 672/672 with the project’s GFM spec options

Example setup:

(add-to-list 'load-path "/path/to/commonmark-gfm.el")
(require 'commonmark-gfm)

(setq markdown-command #'commonmark-gfm-markdown-command)
(setq markdown-command-needs-filename nil)

Or:

(commonmark-gfm-use-as-markdown-command)

One clarification: the EWW preview path does not evaluate the optional CSS or Mermaid.js. Those are intended for generated browser HTML output.

The API is still intentionally small while the parser continues to evolve, but I’d be interested in feedback from people who use Markdown heavily inside Emacs.

u/AsleepSurround6814 — 27 days ago
▲ 56 r/emacs

dired-clipboard.el: Copy and paste files in Dired with M-w / C-y

I made a small Emacs package called dired-clipboard.el.

It lets Dired use familiar clipboard keys for file operations:

  • M-w copies marked files/directories, or the file at point
  • C-y pastes copied files/directories into the current Dired directory
  • M-w still behaves normally when the region is active
  • M-w and C-y keep their normal editing behavior in WDired

It also tries to interoperate with desktop file managers where possible. It supports plain file path lists, text/uri-list, GNOME/Nautilus and MATE/Caja copied-files MIME formats, Windows Explorer FileDrop via PowerShell/.NET, and macOS

Finder file URLs via osascript.

I also added conflict handling for paste: if the destination already contains the same file name, it can paste as file copy.txt, file copy 2.txt, etc.

https://github.com/kn66/dired-clipboard.el

u/AsleepSurround6814 — 29 days ago
▲ 77 r/emacs

halo.el: an experimental minor mode for keeping point centered and dimming distant lines

I made a small experimental Emacs package called halo.el.

The starting idea was a personal hypothesis: maybe it would be easier to maintain attention on the current editing area if point stayed near the vertical center of the window, reducing vertical eye movement, while lines farther away from point were shown with lower contrast.

So I made a minor mode that can keep point near the center line and gradually dim visible lines as they get farther away from point. The current line and nearby lines stay at normal contrast.

At first, the effect felt a little strange and it took some time to get used to. After using it for a while, it started to feel natural enough for me in some buffers. I do not want to claim that this improves focus in general, but for my own use it has been an interesting experiment, and it may be useful for certain workflows.

This is different from just using centered-cursor-mode: halo.el combines cursor centering with gradual contrast falloff away from point. It also uses a display-only virtual top margin, so point can still appear near the center even at the beginning of the buffer.

The package is still experimental. I would be interested in feedback, including critical feedback, especially about readability, theme compatibility, performance, or cases where this kind of interface is simply a bad fit.

I know this kind of visual effect is probably not for everyone, so I am mostly posting it as an experiment rather than a recommendation.

Repo:

https://github.com/kn66/halo.el

u/AsleepSurround6814 — 1 month ago
▲ 31 r/emacs

Inspired by nano-emacs: vertico-buffer-frame with nano-vertico

Hi r/emacs,

I recently watched Nicolas Rougier's talk, "The Art of Text", which was shared here:

https://www.reddit.com/r/emacs/comments/1txnsrr/nicolas_rougiers_talk_at_39c3_the_art_of_text/

That made me try `nano-emacs`. At first it took me some time to get used to the lower-contrast visual style, but after using it for a while I started to really appreciate the concept.

While exploring related packages, I found `nano-vertico`.

I originally made `vertico-buffer-frame` as a child-frame frontend for Vertico's built-in `vertico-buffer-mode`, rather than replacing it with a separate posframe-based UI. A nice side effect of that design is that packages which customize `vertico-buffer` can still work naturally.

So I tried combining:

- `nano-emacs`

- `nano-vertico`

- `vertico-buffer-frame`

and I liked the result enough to share it.

Screenshot:

https://preview.redd.it/0s0crgrwtn6h1.png?width=1920&format=png&auto=webp&s=c2af6f73b4a4f0f2e7b704c31a380245c2525fea

https://preview.redd.it/p0eiujtttn6h1.png?width=1920&format=png&auto=webp&s=d68094a58a8bb796a9071813fd301d4897e28ef9

https://preview.redd.it/c5j46382un6h1.png?width=1920&format=png&auto=webp&s=4d97cecf5091b66e705c827beb94b76a32653398

This is not meant as a replacement for the normal Vertico UI, and I know the low-contrast style is a matter of taste. But I thought it was interesting that the nano-emacs visual approach can also work nicely with a centered Vertico

child frame.

Thanks to Nicolas Rougier and the nano-emacs/nano-vertico work for the inspiration.

Links:

https://github.com/rougier/nano-emacs

https://github.com/rougier/nano-vertico

https://github.com/kn66/vertico-buffer-frame

reddit.com
u/AsleepSurround6814 — 1 month ago
▲ 79 r/emacs

vertico-carousel: keep the selected Vertico candidate on the first visible row

Hi, I made a small Vertico display extension called vertico-carousel.

It keeps the selected candidate on the first visible row of the Vertico candidate list. The following candidates are shown below it, wrapping from the end of the list back to the beginning.

Repository:

https://github.com/kn66/vertico-carousel

The behavior is similar to icomplete-vertical-mode: as you move through candidates, the list rotates while the selected candidate stays in the same visible position.

My original motivation was fairly specific. I use vertico-buffer-frame, and when the selected candidate was near the bottom of the candidate list, it could overlap with the preview area, making it hard to tell which candidate was being previewed. Keeping the selected candidate at the top solved that issue for my setup.

It currently supports:

  • vertico-count
  • wrapping near the end of the candidate list
  • optional session-local vertico-cycle
  • group headings, with the heading before the current candidate omitted
  • vertico-indexed-mode, including wrapped rows

I searched the Vertico issue tracker and found related discussions such as minad/vertico#86, #26, and #63, but I did not find an existing proposal for a vertical display mode that keeps the current candidate on the first visible row.

This package uses Vertico internal APIs, so it may need adjustments if Vertico changes internally.

Feedback is welcome. I’m especially interested in whether this behavior seems useful outside of my own setup, or whether it is too specific to be worth keeping as a separate package.

u/AsleepSurround6814 — 2 months ago
▲ 0 r/emacs

I made elisp-quality-ai: AI-friendly quality reports for Emacs Lisp projects

Hi r/emacs,

I’ve been working on elisp-quality-ai, a small Emacs Lisp package that provides a single entry point for generating AI-friendly quality reports for Emacs Lisp projects.

The motivation was that Emacs Lisp already has useful quality tools, but they are spread across different packages and interfaces: checkdoc, byte compilation, package-lint, relint, complexity tools, Elsa, etc. When using these from CI or from AI coding agents, I wanted a consistent CLI and stable JSON/JSONL/Markdown output instead of having each workflow assemble custom Emacs Lisp snippets.

The built-in collectors work out of the box with Emacs:

  • checkdoc: documentation and style checks
  • byte compilation: compiler warnings and errors

Optional collectors are used automatically when available:

  • package-lint: package metadata, headers, autoloads, MELPA-style packaging checks
  • relint: suspicious or mechanically improvable regular expressions
  • cognitive-complexity: maintainability signals for complex definitions
  • Elsa: deeper static analysis around symbols, values, and type-like flow

It also generates ranked AI-oriented tasks from the collected diagnostics, so an agent can ask for the next useful maintenance task instead of parsing raw tool output.

Example CLI usage:

bin/elisp-quality-ai report --root . --format markdown
bin/elisp-quality-ai tasks --root . --format json --limit 5
bin/elisp-quality-ai next-task --root . --format json

If the optional tools are installed through package.el, the bundled CLI initializes package.el and can use them directly. For straight.el, elpaca, or other package managers, you can pass their build directories with repeated --load-path arguments, or load a setup file with --load.

The goal is not to replace the existing tools, but to normalize their output into one report that is useful for maintainers, CI, and AI-assisted maintenance.

It requires Emacs 29.1+.

I’d appreciate feedback on the report schema, collector model, and whether the generated tasks match real Emacs Lisp maintenance workflows.

GitHub: https://github.com/kn66/elisp-quality-ai

u/AsleepSurround6814 — 3 months ago
▲ 49 r/emacs

Hi r/emacs,

A few days ago I posted vertico-posframe-preview, a small package which adds a preview sidecar to vertico-posframe:

https://www.reddit.com/r/emacs/comments/1t0vmko/verticoposframepreview_a_preview_sidecar_for/

After that, I learned that a normal buffer can be displayed directly in a child frame. Since vertico-buffer-mode is one of Vertico's built-in extension modes, I wanted to try a lighter approach: use vertico-buffer itself, and make Emacs display that buffer in a child frame.

So I made a follow-up experiment called vertico-buffer-frame.

It shows vertico-buffer-mode in an Emacs child frame using the built-in display-buffer-in-child-frame, without depending on posframe or vertico-posframe. It can also show an optional preview child frame for the current candidate.

Main differences from vertico-posframe-preview:

  • depends only on Emacs and Vertico
  • uses Vertico's built-in vertico-buffer-mode instead of vertico-posframe
  • uses Emacs' built-in child frame display action
  • keeps the minibuffer prompt width intact by overlaying the preview on the lower-right side of the candidate frame
  • also supports a side-by-side preview layout
  • includes previews for files, directories, buffers, bookmarks, commands, functions, variables, faces, packages, Consult locations, grep results, imenu, org headings, xref, etc.

Basic setup:

(require 'vertico-buffer-frame)
(vertico-buffer-frame-mode 1)

To toggle the preview during completion:

(with-eval-after-load 'vertico
  (define-key vertico-map (kbd "C-t")
              #'vertico-buffer-frame-toggle-preview))

This is still experimental. The package no longer depends on posframe or vertico-posframe internals, but it still hooks into some Vertico internals in order to update the preview while candidates change. So I would especially appreciate feedback from people using different window managers, themes, frame setups, or Emacs versions.

Repository: https://github.com/kn66/vertico-buffer-frame

Feedback, bug reports, and suggestions are welcome.

u/AsleepSurround6814 — 3 months ago
▲ 95 r/emacs

Hi r/emacs,

I made a small package called vertico-posframe-preview.

It adds a second posframe next to vertico-posframe and shows preview content for the currently selected Vertico candidate. The goal is to make completion workflows feel closer to “select on the left, preview on the right” without leaving the minibuffer.

It currently supports previews for common candidates such as:

  • files and directories
  • buffers
  • bookmarks
  • locations, grep results, imenu, and xref candidates
  • Consult previews, when Consult is loaded

Basic setup:

(require 'vertico-posframe-preview)

(vertico-mode 1)
(vertico-posframe-mode 1)
(vertico-posframe-preview-mode 1)

You can also toggle the preview during a Vertico session:

(keymap-set vertico-map "C-t" #'vertico-posframe-preview-toggle)

Repository:

https://github.com/kn66/vertico-posframe-preview

A note: this package currently advises some internal APIs from vertico-posframe and Consult, so it may need updates if those internals change. The tested baseline is listed in the package header / README.

Feedback, bug reports, and suggestions are welcome.

u/AsleepSurround6814 — 3 months ago