Show HN: Enjoy Your Vibe Coding

Maybe it is time to settle this discurse once and for all, and move on.

Recently I asked Deepseek (otherwise amazing), Grok (a meme) and Gemini about idiomatic way of enabling syntax highlighting in blocks of code, which may appear in an eww or nov modes.

What they all give me is some stylized pasta from StackOverflow and Github about polymode and mmm-mode and how to use regexps to find particular blocks and to apply some low-level function on a range.

This is, of course, an utter bullshit, and it was eagerly and obviously expected – all the models are building sentences similar (at the level of “tokens”) to ones they have seen before, no more, no less.

Here is the kind of answer I would like.

The unique feature of Emacs is that it has been designed as a set of layerr of function-based DSLs embedded in Rmacs Lisp, which reflect the inherent structure within either a plain text (characters, words, sentences, paragraphs) or [more] structured texts, such as Org, Info, HTML and the derived formats, and some others, like Markdown. Every programming language has its own, even more elaborate structure. This is precisely why there is a notion of a buffer and a major mode associated with it. This design reflects What Is.

Of all the structured texte modes, the org-mode the most general and less cluttered, (because it is based on the “natural” notion of plain text – sentences, paragraphs and embedded blocks of code). It is indeed very general and lightweight, compared, to, say, LaTeX or even Markdown, and it supports all the fundamental notions of a structure, including links.

Other specialized modes, which predate org-mode, notably the Info-mode (the texinfo format),has most of these same “universal” notions but less uniformly. Other wonderful modern modes, like Helpful went even further in generality.

This (and only this) is the only proper way to do everything in Emacs – use the most general and the most high-level modes, like org, and then convert and interact with specialized modes, like LaTeX, Markdown, Info, and particular modes of various programming languages. The blocks of code has to be easily nested . The org-mode got it almost right (aside form the “technical debt” or early idiotic decisions) which is why it is a “killer app” for Emacs itself.

What we, as Emacs users, want (from dear members of the Emacs team) is to have uniform, familiar, unintrusive, minimalist experience across all structured text modes, including gptel and google-tranlate.

It begins with a uniform colortheme, consistent font settings across all buffers, and proper syntax highlighting (are we asking for too much?). Notice that, at least in theory, an embedded code block can appear almost anywhere – in a help or Info as an example (Helpful handles this, Info isn’t), as well as in any html-derived mode, which is a bit tricky. The variable-pitch-mode and mixed-pitch-mode are tried to address this.

Suppose I am reading some epub , writing notes into org-roam and occasionally at look some web pages in eww (which was my original motivation and annoyance). It should have be a smooth, uniform experience, to the point that you cannot tell /which particular buffer you are currently looking at. In the modern Emacs world you can easily tell by how even the simplest markup and rendering is broken in different ways.

This, however, should not be that way. When you are reading a book, it is usually (90%) of the time that all the examples would be in the same programming language. Same, well, lets say 75%, would be true for a web-page. So have a variable associated with a general markup buffer, which hints at the programming language in the code blocks.

HTML and the derived modes do not describe what is in their code blocks, there is even no notion of a code block, just something formatted with a fixed-width fonts, if at all, so we have to have more “hints”. Nevertheless, partial solutions exists, for shr and other specialized modes.

It is not that difficult to generalize this functionality across all structured modes, provided almost everything has already been done right within the built-in org-mode. Make sure the org-mode properly respects the colortheme, that variable-pitch-modes pick up fonts correctly and then use the org-src-font-* consistently everywhere.

This sketch of a solution has one distinct feature which no LLM can have in principle – it systematically walks through the levels (and corresponding layers) of abstraction within a vastly complex system, and tries to select an appropriate level – the highest and the most general one (and that will be the org-mode!) . No LLM, current or further, is capable of such reasoning in principle.

So, the “hack” would be to apply org-mode’s facilities for handing blocks of code uniformly everywhere. org-mode also does variable- and mixed pitch modes right.

With the classic “hooks” and “advices” mechanisms, one can apply simple wrapper functions to buffers with particular modes. Notice that the polymode and mmm-mode are solving a differnt problem. LLMs picked them all because retards on Stackoverflow confused “specialized versus general”.

And no, we don’t need an OO (or, god forbid, Typescript) framework which handles structured text with links, (but we has to be aware of an underlying uniform structure), and no, Treesitter is too low-level to even talk about. The most wonderful feature of Emacs (and org-mode) is that they properly support structured text at the right level of abstraction (when paragraphs are naturally separated by empty lines, not special tags!).

Very few old-school Emacs devs understand this, however. As long as we stick to the layers of embedded DSLs (which maps to the natural structures via simple ADTs) Emacs will rock, and no Electron-based crap would ever come close.

Last but not least, the sages of the ancient past, who did the very first inspiring UI designs (of Smalltalk, Lisp Machine, NextStep, Xv and even Motif) have realized that we don’t need too much. Just distinct fonts for text and code (variable-width and fixed-width) and the proper support of blocks, indentation and highlighting. Emacs could easily do it just right by itself, by incorporating the code form packages like Org and Helpful and generalize it across all major modes based on some additional hits and cues.

Notice, that nether LLMs came up with a working solution, not even with a proper code example. It is murderously hard to change perspective from the overall design to prticulars of the function calls. While this is difficult for a human, who is trained to thing at a higher levels of abstraction, it is impossible for the current LLMs, because there are no such “pathways through the levels of abstractions” – from general to specific, and back, many times per “session” – which is what serious non bullshit programming is all about.

Enjoy your vibe-coding, retards!