On Wed, Jan 23 2013, Austin Clements <amdragon@MIT.EDU> wrote: > On Fri, 18 Jan 2013, Damien Cassou <damien.cassou@gmail.com> wrote: > >> + `(("unread" >> + (:propertize "unread" face >> + (:Foreground "red"))) >> + ("flagged" >> + (:propertize "flagged" display >> + (image :type svg :file >> + ,(expand-file-name >> + "resources/star.svg" >> + (file-name-directory >> + (or >> + (locate-library "notmuch-tagger") >> + (buffer-file-name)))) > > Interesting. Is this a standard way to locate resources? (I've never > had need to.) > > Since there are other icons here as well, perhaps the resources > directory should be bound to a global variable so it's easy to construct > other standard notmuch icon names? You capture this in a function in > patch 4, but that function doesn't obviously accomplish anything a > simple variable wouldn't. I was thinking this too. M-x apropos RET -path RET (apropos "-path") outputs (at least) 2 symbols that are relevant here: image-load-path Variable: List of locations in which to search for image files. Properties: standard-value custom-type custom-requests variable-documentation and image-load-path-for-library Function: Return a suitable search path for images used by LIBRARY. (if the second were used I'd suggest to use 'notmuch' instead of 'notmuch-tagger' -- just to support me who just installs notmuch.elc which is done by concatenating all notmuch .el files together to one notmuch.el file which is then byte-compiled :D) > Another possibility is that these icons could be included directly in > the Elisp source, probably as simplified SVGs (your SVGs look like they > could be cut down to 3 or 4 lines of XML easily) or as XPMs. Besides > skirting issues with resource location, this would make it trivial to > alter their colors based on user preferences. I also had the same 2 things in mind, simplify SVGs and possibly include that directly in the source... Tomi