He's doing this only because Racket has the unusual feature of supporting images as "self-eval" values in the source code.<p>In other languages, all you'd want is the byte string (maybe BASE64-encoded, maybe with byte escape sequences), and you wouldn't need a fancy reader extension: just put a byte string literal.<p>A variation on the byte string literal you might see is when people create a minilanguage out of strings. For example, if you want to represent a 2x pixel map image with a fairly small color map... you might just have a string literal of ASCII characters for each row, where each ASCII character maps to an RGB color (or transparent) that you specify, with a simple function to translate it to binary. Then it looks like ASCII art in your source code.<p>Vector images, OTOH, are more likely to have a textual language already (e.g., SVG), so of course you can just embed that as strings in your source file.
I like these kinds of ideas. I've spent a lot of time thinking about similar ones. Here's my rough translation of this particular concept to Emacs:<p><pre><code> (defun imagify-buffer ()
(interactive)
(font-lock-ensure)
(save-excursion
(goto-char (point-min))
(while
(re-search-forward
(rx "(%image \""
(group (1+ (or alphanumeric "+" "/" "=")))
"\")")
nil t)
(when (equal 'font-lock-comment-face
(get-char-property (match-beginning 0) 'face))
(let* ((replaced-string (match-string 0))
(base64 (match-string 1))
(image (create-image
(base64-decode-string base64)
nil t :scale 4.0)))
(goto-char (match-beginning 0))
(kill-region (match-beginning 0) (match-end 0))
(insert-image image replaced-string))))))
(defun insert-image-thingy (filename)
(interactive "f")
(let* ((s (with-temp-buffer
(set-buffer-multibyte nil)
(insert-file-contents-literally filename)
(buffer-substring-no-properties (point-min) (point-max))))
(base64 (base64-encode-string s t))
(thingy (format ";; (%%image \"%s\")" base64)))
(insert thingy)
(imagify-buffer)))
(add-hook 'emacs-lisp-mode-hook #'imagify-buffer)
(add-hook 'lisp-interaction-mode-hook #'imagify-buffer)
(imagify-buffer)
;; (%image "PHN2ZyBoZWlnaHQ9IjE4IiB2aWV3Qm94PSI0IDQgMTg4IDE4OCIgd2lkdGg9IjE4IiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjxwYXRoIGQ9Im00IDRoMTg4djE4OGgtMTg4eiIgZmlsbD0iI2Y2MCIvPjxwYXRoIGQ9Im03My4yNTIxNzU2IDQ1LjAxIDIyLjc0NzgyNDQgNDcuMzkxMzAwODMgMjIuNzQ3ODI0NC00Ny4zOTEzMDA4M2gxOS41NjU2OTYzMWwtMzQuMzIzNTIwNzEgNjQuNDg2NjE0Njh2NDEuNDkzMzg1MzJoLTE1Ljk4di00MS40OTMzODUzMmwtMzQuMzIzNTIwNzEtNjQuNDg2NjE0Njh6IiBmaWxsPSIjZmZmIi8+PC9zdmc+")
</code></pre>
This adaptation hooks onto an Emacs language mode—Emacs Lisp mode, in this snippet—and searches for, and translates, a regex syntax (%image) appearing in the comments section. This piggybacks on the language mode's own parser (the 'font-lock-comment-face thingy). The image-handling part is core Emacs functionality; like DrRacket it does support these things natively.
I really wish IDEs would support showing images inline in code. I can't count the number of times I've wanted to include a nice diagram in a comment but I instead had to resort to describing the diagram with words, or a shitty ASCII art diagram.<p>There's a very long standing VSCode issue for this.<p><a href="https://github.com/microsoft/vscode/issues/3220">https://github.com/microsoft/vscode/issues/3220</a>
On a related note, one of the features in TempleOS was images embedded in source code along with an image editor within the code editor: <a href="https://www.youtube.com/shorts/196Dv3gFslU" rel="nofollow">https://www.youtube.com/shorts/196Dv3gFslU</a>