Re: Tag based dired?

[Xiao-Yong Jin]

Bill Wohler <wohler@newt.com> writes:

> Leon <sdl.web@gmail.com> writes:
>
>> Could you give an example of using tag?
>
> I'll guess.
>
> Take mh-e.el for example. Right now, for me, it is in one specific
> place on my hard drive, namely, /usr/local/src/emacs/lisp/mh-e/mh-e.el.
>
> I could tag this file with "mail", "emacs", "lisp", "source", "MH-E".
> In addition, the lisp files already have a Keywords pseudo-header
> field which could be used to automatically tag the files as well.
>
> I could then find this file by specifying any of those tags. I could
> limit the number of files I see by specifying more tags.
>
Yes, that's exactly what I meant.

> If you were to use a normal file system, you'd create a directory for
> each tag in the system, and create hard links between the directories
> for files that share tags.
>
I see this as a disadvantage of the conventional way to store files.

> The major advantage of this system is that it would be easier to
> classify and find stuff since you wouldn't have to create--and
> remember--a possible arcane path to a file. The disadvantage with this
> implementation is that the directories would be huge and unwieldy.
>
It's like that you have two ways of labeling or classifying an
ordinary file.  One is the physical path of a file in the file system
it resides.  The other is a logical way, that is, you can specify a
certain file or a group of files by giving some tags.  It's a much
easier way to grouping files, I guess.  But, I don't see why the
directories would be huge and unwieldy?  I think a good hierarchy of
arcane paths of files should be still well maintained.

> An Emacs interface to this would make it easy to enter tags and to
> limit the output to files tagged with those tags.
>
It's pretty much like a keyword database for files such that you can
search files by their keywords.  But an Emacs interface should provide
the end user a friendly interface like dired with a comprehensive and
powerful but yet easy way to manage the tags.  I think implement this
feature on top of dired would be ideal.  Actually it's like emblems in
nautilus -- personally I believe emblems in nautilus are just an extra
useless thing, not easy to use at all -- but with a powerful editing
and searching ability.

> In the meantime, you might look at locate and locate-with-filter. Why
> these functions don't put their output in a dired buffer is beyond me.
>
An easy and quick implementation like locate is fine.  At least the
output buffer of locate has similar interface with dired.  Many basic
editing can be done with it, like rename, copy, and even byte
compile.  I'll definitely look at that to see if I can get some
where.

One thing that still bothering me is how and where to store the tag
informations.  It should be easily accessed and edited, and searching
within it should be quick.  However, for a small group of file, plain
text should be sufficient.  And due to my personal interest, I tend to
use the org-mode.  Because I've been using org-mode to maintain links
to files and to web pages as well.  But this also pulls in the
incorporation with org-mode, which makes it harder to implement, at
least for me, now.  Nevertheless since searching through tags has
already been mature in org-mode, it could be the basis of tag
searching for files.

> -- 
> Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
>
>
>

More inputs from you are appreciated.

-- 
Xiao-Yong