From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xiao-Yong Jin Newsgroups: gmane.emacs.help Subject: Re: Tag based dired? Date: Fri, 23 Jun 2006 23:20:13 -0400 Organization: Columbia University Message-ID: <874pybjl3m.fsf@photon.homelinux.org> References: <87sllwvhft.fsf@photon.homelinux.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1151120438 27389 80.91.229.2 (24 Jun 2006 03:40:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 24 Jun 2006 03:40:38 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jun 24 05:40:35 2006 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ftz0Y-0006Wm-G4 for geh-help-gnu-emacs@m.gmane.org; Sat, 24 Jun 2006 05:40:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ftz0Y-000579-0o for geh-help-gnu-emacs@m.gmane.org; Fri, 23 Jun 2006 23:40:30 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newscon06.news.prodigy.com!prodigy.net!newsfeed.nyu.edu!newsmaster.cc.columbia.edu!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 81 Original-NNTP-Posting-Host: dyn-carl-201-40.dyn.columbia.edu Original-X-Trace: newsmaster.cc.columbia.edu 1151119213 21383 160.39.201.40 (24 Jun 2006 03:20:13 GMT) Original-X-Complaints-To: postmaster@columbia.edu Original-NNTP-Posting-Date: 24 Jun 2006 03:20:13 GMT User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.0 (gnu/linux) Cancel-Lock: sha1:qCog0l0m2nUWRnSRspyeu6EzG60= Original-Xref: shelby.stanford.edu gnu.emacs.help:140005 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:35629 Archived-At: Bill Wohler writes: > Leon 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 http://www.newt.com/wohler/ GnuPG ID:610BD9AD > > > More inputs from you are appreciated. -- Xiao-Yong