My Emacs configuration https://git.cjennings.net/dotemacs/atom?h=main 2026-05-18T06:24:30+00:00 2026-05-18T06:24:30+00:00 Craig Jennings c@cjennings.net 2026-05-18T06:24:30+00:00 urn:sha1:78d03e66fd5ccc37b464967e96213ad858cda1c9 I switched the gptel use-package form to `:load-path "~/code/gptel"` with `:ensure nil` so Emacs loads from the fork instead of the MELPA release. The fork now carries the narrow `tab-width' copy in `gptel-org--create-prompt' that karthink redirected the upstream PR to, which replaces the local `:around' advice on `gptel--with-buffer-copy-internal' I'd been carrying. I also dropped the stale test file `tests/test-ai-config-gptel-prompt-tab-width.el' and the matching stub in `tests/testutil-ai-config.el'. Both existed only to test the advice I removed. 2026-05-16T05:31:58+00:00 Craig Jennings c@cjennings.net 2026-05-16T05:31:58+00:00 urn:sha1:03d7c6738835e985319d84b67f582c5a75223a2d gptel's `gptel--with-buffer-copy-internal` copies the source buffer's `major-mode` symbol but doesn't run mode hooks. An inherited-org-mode prompt buffer keeps `tab-width` at this config's global default of 4 instead of the 8 that `org-mode-hook` would set. When gptel later parses the prompt buffer with `org-element`, Org's `tab-width=8` guard raises "Tab width in Org files must be 8, not 4." I was hitting this on every second `gptel-magit-generate-message` from COMMIT_EDITMSG. `vc-config.el` sets `git-commit-major-mode 'org-mode'`, and the diffs contained list-shaped content that `org-element--list-struct` parsed. The advice forces `tab-width=8` in the prompt buffer when its inherited mode is org-mode. It's a local workaround for an upstream gap. An upstream patch to run `(delay-mode-hooks (funcall major-mode))` in the buffer-copy is the real fix. I'll send it next.