gptel icon indicating copy to clipboard operation
gptel copied to clipboard

Fix attachment link resolution with org-attach ID-based storage

Open jwiegley opened this issue 1 month ago • 2 comments

Summary

Fixes #1073

This PR fixes an issue where gptel does not correctly locate media files referenced by org-mode "attachment" links when using org-attach's ID-based storage support.

Changes

1. gptel-org.el (gptel--parse-media-links)

  • Use org-attach-expand to properly resolve attachment-type links to their actual file paths
  • This is necessary when org-attach uses ID-based storage where attachment directories are not relative to the current file
  • Added declare-function for org-attach-expand

2. gptel-request.el (gptel--realize-query)

  • Call gptel--parse-buffer in the original buffer context rather than the temp buffer
  • This ensures org-attach-expand has access to Org properties (ID, ATTACH_DIR) needed to resolve attachment paths
  • These properties are not copied to the temp buffer, so the context switch is necessary

Testing

  • Backward compatible: file-type links continue to work as before
  • Attachment-type links now properly expand to absolute paths when using ID-based storage
  • Existing test suite validates media link parsing functionality

Test plan

  1. Customize org-attach-id-dir to a location outside the working directory
  2. Create an Org file with a heading that has an ID property
  3. Attach an image file to the heading using org-attach
  4. Link to the attachment using [[attachment:filename.png]]
  5. Enable media tracking in gptel
  6. Send a query asking about the image
  7. Verify the image is correctly encoded and sent to the LLM

Without this fix, the LLM would not receive the image. With the fix, the image is properly encoded and included in the request.

🤖 Generated with Claude Code

jwiegley avatar Oct 04 '25 20:10 jwiegley