Re: Icons of program

[Martin Pool <mbp meesha humbug org au>]

Toshio wrote:
>In another part of the discussion (forgive me, I thought I included some of
>that here, but didn't.  Must of fallen aslepp first :-) I stated reasons for
>this.  People who only use the shell shouldn't be forced to look at
>all the clunky info files sitting around in directories.  This is very
>intrusive.  A single-user machine's admin may decide to delte all the .info
>files (takes some time since they're spread all over the machine [well machine
>intensive, anyways... `find` can do it.]) but will then find that when someone
>releases a new package that installs .info files, he'll have to go through and
>delete files again.  

Might I suggest people have a look at fast-lock-mode in emacs-20?

Summary: emacs wants to create dot-files that cache information about
the way to fontify other files: this is vaguely similar to a desktop
that wants to cache information about (say) where icons for files are
located.

The user may specify a list of directories
(fast-lock-cache-directories) in which emacs may store the .flc files.
The default is ("." "~/.emacs-flc"), and emacs uses the first
*writable* directory to store the cache file.

So, if I open /usr/include/bfd.h (not writable by me on this machine),
emacs caches the information in
'$HOME/.emacs-flc/#usr#include#bfd.h.flc'.  The file includes various
checks to maintain integrity: the modification time, real filename,
fontification settings, and so on.  (For example, imagine loading a
file from a cdrom.)

If I open ~/gtksql/guimain.c, emacs stores the font cache in that
(writable) directory, emacs stores the font cache as a dot file in
that directory.

emacs refrains from creating the dot files unless they are necessary.
(In this case, that means that the file is large enough to make
creating a cache worthwhile.)

The point is that by allowing the user to specify a list, one can
accomodate shell users who dislike seeing dot files all over the
place.

One can imagine variations on this theme for:

 - files which are required, rather than just accelerating caches
 - files which can cope with changes to their 'parent' file
 - files which care if, say, the parent's inode changes
 - a cron mechanism to harvest orphaned files every so often
 - files which can be shared between users of a machine

Food for thought.

--
Martin Pool