Add caveman as a gptel directive:

(setq gptel-directives
      (cons '(caveman . "CAVEMAN MODE: Drop articles/filler/pleasantries/hedging. Fragments OK. Short synonyms. Pattern: [thing] [action] [reason]. [next step]. Keep full technical accuracy. Code unchanged.")
            gptel-directives))

Select with C-c C-d in gptel buffer.

A developer created "Caveman," a Claude Code skill that forces the AI to respond in simplified, caveman-like language to reduce token usage by approximately 75%. The author clarifies this is mostly a joke and targets visible output (removing preambles and filler text), not the hidden "thinking" tokens that improve performance. They acknowledge the ~75% claim needs proper benchmarking and note that the skill doesn't affect code quality itself.

The Hacker News community is highly skeptical, with many arguing that tokens are "units of thinking" for LLMs—reducing them could make the model dumber by limiting its reasoning capacity. Critics point out that chain-of-thought reasoning requires verbose output, and forcing concise responses may degrade performance. However, some find the concept useful for cutting through verbose AI responses, comparing it to telegram-style communication or noting that similar concise prompting can work without harming quality for simple tasks. The debate centers on whether this actually saves meaningful costs versus potentially sacrificing accuracy.

Okay, almost immediately I wanted something like this - (elpa-find-file "agent-shell.el:4616"), which is essentially what visit-source.el does. But, it turned out better not integrate visit-source, but implement parsing of line directly in the function.

So, version 2:

(defun elpa-find-file (pattern)
  "Open file matching PATTERN in the elpa directory.
PATTERN may include a trailing :LINE or :LINE:COL.
Error if multiple versions of the same package match."
  (interactive "sFile: ")
  (let* ((parts (split-string pattern ":"))
         (name (car parts))
         (line (and (nth 1 parts) (string-to-number (nth 1 parts))))
         (col (and (nth 2 parts) (string-to-number (nth 2 parts))))
         (elpa-dir (expand-file-name "elpa" user-emacs-directory))
         (files (thread-first
                  "rg --files %s | grep -F \"%s\" | grep -v '\\.elc$'"
                  (format (shell-quote-argument elpa-dir) name)
                  shell-command-to-string
                  split-string))
         (pkgs (mapcar (lambda (f)
                         (let ((dir (cadr (split-string f "/elpa/"))))
                           (replace-regexp-in-string
                            "-[0-9].*?/.*\\'" "" dir)))
                       files))
         (dups (seq-filter (lambda (p)
                             (> (cl-count p pkgs :test #'string=) 1))
                           (seq-uniq pkgs))))
    (when dups
      (user-error "Multiple versions found for: %s — clean up %s"
                  (string-join dups ", ") elpa-dir))
    (unless files
      (user-error "file %s not found" name))
    (find-file (cl-first files))
    (when line
      (goto-char (point-min))
      (forward-line (1- line))
      (when col (forward-char (1- col))))))

grab a file visit-source.el, put it somewhere on load-path, bind to a key – I have it within ffap package:

(use-package ffap :ensure nil
  :config
  (require 'visit-source)
  ;;(setq ffap-file-finder #'visit-source)
  (setq ffap-file-finder #'find-file)
  :bind (("H-<return>" . visit-source)))

In any buffer put a point on a file-looking string and call {M-x visit-source RET} (or {H-<return>} for me).

File-looking string can be:

• a filename
• a filename with lines (as in exception or log output)

When I first find it on r/emacs comment, it was much simpler version and was intended as drop-in replacement for find-file. Then I added project awareness, so you can visit-source on a file Pavels-Emacs-Configuration-v3.org by filename, from anywhere in the project.

Initially I adopted visit-source instead of find-file {C-x C-f} but then switched to find-file-at-point that has a bit different semantics and kept visit-source at {H-RET} separately.

visit-source worked in most cases, but still had some rough edges, like didn't parse when path at point ends with dots, so text like ../Pavels-Emacs-Configuration-v3.org. didn't parse, so I had to manually end sentences with "../Pavels-Emacs-Configuration-v3.org file." or "../nv directory." Yesterday I bumped into the need to visit arbitrary Org Mode link. {C-c C-o} runs OS open on it, so log files were opening with TextEdit.app for me. Surely I can reconfigure it in macOS level to associate Emacs with log files (via UI?); but visit-source looks the way for it.

Given personal tooling reneissance, with Claude Code on <2026-05-06 Wed> I asked it to refactor the code - extract helper pure functions, implement fixes, support Org Mode links, get rid of trailing punctuation, add tests.

So meet visit-source v0.3.0 – visit-source.el!

Markdown can't handle lists properly.

This Org Mode block:

- github :: [[https://github.com/inanimate-tech/mist][inanimate-tech/mist]]
- posts ::
  - [[https://interconnected.org/home/2026/02/12/mist][mist: Share and edit Markdown together, quickly (Interconnected)]]
  - [[https://interconnected.org/home/2026/04/10/open-mist][mist is now open source and looking for interop (Interconnected)]]

: curl https://mist.inanimate.tech/new -T file.md

is exported as this Markdown block:

-   **github:** [inanimate-tech/mist](https://github.com/inanimate-tech/mist)
-   **posts:** -   [mist: Share and edit Markdown together, quickly (Interconnected)](https://interconnected.org/home/2026/02/12/mist)
    -   [mist is now open source and looking for interop (Interconnected)](https://interconnected.org/home/2026/04/10/open-mist)

    curl https://mist.inanimate.tech/new -T file.md

which is then converted to this HTML block:

• github: inanimate-tech/mist

• posts: - mist: Share and edit Markdown together, quickly (Interconnected)

  • mist is now open source and looking for interop (Interconnected)

  curl https://mist.inanimate.tech/new -T file.md

The list was rendered completely wrong.

When exporting from Org directly to HTML, it's correct - dl/dt/dd tags are used, comment rendered as verbatim text:

github

inanimate-tech/mist

posts

• mist: Share and edit Markdown together, quickly (Interconnected)
• mist is now open source and looking for interop (Interconnected)

curl https://mist.inanimate.tech/new -T file.md

Luckily, the change in texptpod.el is this:

-   (org-export-string-as org-text 'md t)
+   (org-export-string-as org-text 'html t)

I also changed backend to preprocess internal links, they look like this:

../markdown.md // for Markdown export
../markdown.html#5B98C220-A8F4-4202-9708-82B0D000A4E9 // for HTML export

Preprocessing changes both to ?q=markdown., so search starts to /markdown. which matches both md and html extensions.

• textpod.el v0.3.1
• Export from Org Mode into HTML instead of Markdown · velppa/textpod@487fc00