A few weeks ago I wrote about how I remapped yank to my command which allows to transform the yanked text. The whole setup – where I press C-y twice to trigger the transformation transient – has one drawback: I sometimes legitimately want to call yank twice in a row. This happens when I need to copy the current line and modify the copy so that I have two similar lines in a row. (I often need this when editing Ledger transactions, for example.) What I sometimes do in such a situation is basically a dance of C-a C-1 C-k C-y C-y.
It turns out I don’t need to. There is a duplicate-line command which does exactly what is says on the tin. The only issue is that it is not bound to any key by default. There is, however, one key which is ideally suited for it - C-x C-d. It is normally bound to list-directory, which I find completely useless given that Dired (C-x d) exists.
Before binding duplicate-line to C-x C-d, let’s poke around a bit. This command is almost completely superseded by its cousin duplicate-dwim, which duplicates the current line if the region is inactive and the current region otherwise. Also, there are two options which allow to tweak both commands’ behavior. If you set duplicate-line-final-position to 0 (the default), duplicating the line leaves the point where it was. Setting it to +1 or -1 moves it to the first and last duplicated line, respectively (of course duplicate-line and duplicate-dwim accept a prefix argument!). The duplicate-region-final-position option works in a similar way.
(setq duplicate-line-final-position 1) (setq duplicate-region-final-position 1) (bind-key "C-x C-d" #'duplicate-dwim)
That’s not the end of the story, though. While looking around in the file where these commands are defined (lisp/misc.el), I found a few more interesting ones. One of them is copy-from-above-command. I’m not sure how useful it is (and what to bind it to in case I find a use for it), but it’s there if you need it. As its docstring says, it copies characters from the line above, starting above point and until the end of that line. (A prefix argument limits the maximum number of characters copied.) There is zap-up-to-char which works like zap-to-char but does not delete the character it zaps to. There are forward-to-word and backward-to-word, which work very similarly to forward-word and backward-word, but leave the point at the opposite end of the words they move to (so for example forward-to-word moves the point forward until it gets at the beginning of a word). There are a few more, but these I find the most interesting. Maybe I’ll bind them some day – but even if not, they might come in handy with M-x or in Elisp code one day.
That’s it for this time, see you next week!
A few years ago I wrote about a setup I coded for myself for when I want to make paying my bills a tiny bit less painful. One thing I mentioned then was the primary selection. For those of you who don’t know it: under X.org, you can select a portion of text (for example by dragging the mouse over it) and then paste it in the same or another application with clicking the middle button. It is extremely useful for quick copy-and-paste operations where you do not have to issue a separate “copy” command (usually C-c, but often also found on mouse context menu). And by the way, Wayland also supports this.
Sometimes I find it useful to use it even without the mouse. Everybody knows how to select text using keyboard – one common way is by using movement keys with shift, but the Emacs way is to activate the mark with C-SPC and move the point using any of multiple ways Emacs gives us. The question is, however, how to paste the selected text without touching the mouse?
Well, it’s Emacs, so it’s enough to press C-h c and click the middle button to find out. It turns out that the command is mouse-yank-primary. Despite its name, it can be invoked without a mouse, either via M-x or by binding it to some key.
One important thing to mention here is that there is an option called mouse-yank-at-point. If it is nil (the default), the primary selection will be pasted in the place you clicked the mouse. I have it set to t, which means I can click anywhere in the Emacs frame and the primary selection will be pasted at point.
Of course, this is not going to be useful a lot of the time since the usual workflow with the primary selection is to both select and paste the text with the mouse, but if you need to do using your keyboard or from Elisp code, you know now how. (In fact, if you need to use the primary selection in Elisp code, you might want to check out the gui-get-primary-selection function, too.)
That’s it for today, see you next week!
As I’ve mentioned some time ago, I’ve been using Claude Code for some time now.
Now, a disclaimer is in place. I’m still a bit skeptical about the current “AI” hype – in particular, I really avoid using the term “AI”. I consider it a very misleading marketing gimmick. When non-technical people hear the phrase “artificial intelligence”, a computational model capable of generating more or less random sequence of letters which sometimes create a semblance of “understanding” or “intelligence” is probably not what they think. Well, I am really a layman, too – I have some extremely vague understanding what happens inside these “chatbots”, but other than that they seem a bit magical to me as well – but my point is, they are really closer to a giant spreadsheet with billions (or even more) of cells than to Skynet.
Anyway – even I have to admit that what Claude Code is able to do is pretty impressive. However, I quickly discovered that the OOTB experience is less than ideal. One of the easier ways to enhance Claude (and other LLMs, apparently) is by writing skills, which are basically reusable prompts or procedures for performing some tasks, written in natural language.
Compared to classic programming, writing skills is, well, a slightly different skill. Unlike hooks, they are not deterministic, and even though Claude has a way to “invoke” a skill directly, by typing a slash followed by the skill’s name, they can be invoked by a prompt which Claude interprets as suggesting using a skill, which is cool but much less certain.
From what I have learned so far, one of the biggest challenges when using LLMs in general and agentic coding in particular is “context management”. LLMs have very limited “attention span”, and giving them too much data makes them work worse. From skills perspective, this means that they should be as concise as possible. Two nice tricks that can help with that are: skill descriptions and dividing skills into several files. First of all, every skill file has a “description” field. All installed skills’ descriptions are preloaded at the beginning of the session, so providing concise descriptions clearly describing when Claude should use a skill is a crucial step. Besides, if a skill is really large – or has substantial parts which are needed really seldom – it may make sense to move these parts to separate files, and link to them from the main skill file. (Apparently, it is enough to tell Claude something along the lines of “When the user requests …, read the … file”.)
One problem with guidelines like this is that it is very difficult to know whether they are genuinely useful tips or just superstitions. The fact they are officially recommended gives some hope. Interestingly, Anthropic released a tool which helps with developing and evaluating skills. Reading through the files in its repo is a mind-blowing experience: the tool is itself a skill, and I have to say that the fact that it works (and I tried it out!) seems magical.
After all that intro, let me share one of the first skills I created (with help from Claude itself, of course). It is very simple in the sense that it only consists of one SKILL.md file, but it already proved itself to be very useful a few times on the first day I installed it!
It is often said that LLMs are generally very agreeable – they tend to flatter the user more than criticize them. Connected with the fact that the normal workflow is to tell the “agent” what you want done and expect obedience, there is a real danger that the only thing your coding agent will help you achieve is writing bad code faster. On the other hand, since LLMs were trained on a lot of written material, in particular describing good and bad practices, gotchas and pitfalls, it seems worthwhile to ask them if your idea is any good before implementing it and learning that it’s not the hard way.
So, here is the complete SKILL.md file for my assess skill.
--- name: assess description: > Assesses pros and cons of a user's idea, with a focus on weaknesses. Use when user asks to assess an idea. --- # Idea Critique Skill Before applying this framework, say: "Applying /assess framework". When asked to assess, evaluate, or critique an idea, apply this framework: ## Stance Default to skeptical. Assume the idea may have a fatal flaw and actively hunt for it before concluding it doesn't exist. This is not about being negative — it's about stress-testing so weak points surface early. ## Process 1. **Steelman first** — articulate the idea's best possible form before critiquing it 2. **Pros** — list genuine strengths with brief reasoning 3. **Cons** — list weaknesses; spend more effort here than on pros 4. **Weak points deep-dive** — pick the 1–3 most dangerous weaknesses and stress-test them hard. Ask: what would have to be true for this to fail? 5. **Verdict** — a honest one-line summary of where the idea stands 6. **Suggested pivots** — if flaws exist, propose concrete ways to address them ## Weighting Score each pro/con 1–3 for significance. Call out any single con scored 3 as a potential deal-breaker. Mark the scores as `[★☆☆]`, `[★★☆]` and `[★★★]`. ## Tone Direct and honest. Avoid hedging language that softens real concerns. The user wants signal, not comfort. --- Now apply this framework to the following idea: $ARGUMENTS
Note the use of $ARGUMENTS at the end – this ensures that I can tell Claude to invoke this explicitly, by saying /assess <my idea>.
I think the most astonishing thing about this skill is that it works really well despite being so short. At 220 words it takes up about 300 tokens, which is way smaller than, say, the aforementioned skill-creator (roughly 20k tokens!) – but is really useful.
Also, this is just the beginning. As of now, I have quite a few custom skills, and this one is one of the smallest (in terms of the word count). And despite the problems with the fact that they are, well, more what you’d call “guidelines” than actual rules, they are genuinely useful.