Re: [PATCH 3/4] emacs: possibility to customize the rendering of tags

[Tomi Ollila <tomi.ollila@iki.fi>]

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