* Re: new backend? [not found] <m28yz4xu8u.fsf@tnuctip.rychter.com> @ 2002-12-05 18:55 ` Ted Zlatanov [not found] ` <m2smxcvyzo.fsf@tnuctip.rychter.com> 0 siblings, 1 reply; 5+ messages in thread From: Ted Zlatanov @ 2002-12-05 18:55 UTC (permalink / raw) Cc: ding On Thu, 05 Dec 2002, jan@rychter.com wrote: > I would like to write some code that allows me to access messages in > my nnml spool. I will need to combine multiple messages from > multiple groups together and operate on them (set marks, move > between groups, etc). I still want to use nnml for storing messages, > but I'd like to be able to access them in two ways: via standard > nnml groups and via my new interface. > > What would be The Right Way to implement that kind of functionality? > > I have identified some starting points: > > -- nnvirtual.el. Very complex code. I probably don't need most of > it. I'm not sure what you're trying to do, but combining multiple groups so they look like one group is *very* easy with nnvirtual. Perhaps if you explained your goals better, you'd get more information. Why do you want combined groups and marks? Ted ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <m2smxcvyzo.fsf@tnuctip.rychter.com>]
* Re: new backend? [not found] ` <m2smxcvyzo.fsf@tnuctip.rychter.com> @ 2002-12-06 13:33 ` Kai Großjohann 2002-12-06 19:21 ` Ted Zlatanov 1 sibling, 0 replies; 5+ messages in thread From: Kai Großjohann @ 2002-12-06 13:33 UTC (permalink / raw) Jan Rychter <jan@rychter.com> writes: > But let's say I get another message from that person, related to the > same problem, but without a References header and with a different > Subject. I want to (manually) add it to the "bundle" and in the future > view and process (such as mark as expirable) the whole bundle > together. I would also like to store information related to the whole > bundle (such as date of last activity in this thread/bundle). From what > I know, there is no easy way to do that in Gnus. My kludgy workaround for these things has been that I consider the new message to be part of the old thread. I then use `T ^' to `attach' it to the thread. I think it works like this: you select a message which is to be the parent, hit `#' on it. Then you select the new message and hit `T ^' on that, and Lo! The message is part of the thread, with the #-marked message as parent. -- ~/.signature is: umop ap!sdn (Frank Nobis) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: new backend? [not found] ` <m2smxcvyzo.fsf@tnuctip.rychter.com> 2002-12-06 13:33 ` Kai Großjohann @ 2002-12-06 19:21 ` Ted Zlatanov 2002-12-06 19:55 ` Kai Großjohann 1 sibling, 1 reply; 5+ messages in thread From: Ted Zlatanov @ 2002-12-06 19:21 UTC (permalink / raw) Cc: ding On Fri, 06 Dec 2002, jan@rychter.com wrote: > Let's say I'd like to look at my mail differently -- I'd like to > look at it as bundles of messages. A bundle would be several threads > combined together, possibly from several groups. [example snipped] OK, so essentially you want to explicitly attach an article to a thread. Kai's example showed how to do it, I think. Information such as the last activity date about a thread can be deduced from the contents of the thread. If you need more parameters than can be deduced from the thread contents, you may need to use a new group per "bundle" with the current Gnus, or somehow store the thread meta-data in the group parameters. > It's not really a replacement for mail groups, it's just another way > of looking at your mail. Think for example "trouble ticketing > systems". I've described a simple use above, but there are many > others. > > Does that explain it? If yes, what's the best way to go about > implementing it? I don't know the best way, but perhaps I can help you figure out if a new backend is the answer. Backends deal with article storage and retrieval. I don't think you want a new backend. It's a lot of work, and may not be necessary. Ideally, your functionality should work with any backend that allows threading and group parameters. I think you want to hook into the thread generation code (gnus-sum.el is a good starting point, I think). Given a thread, perhaps you want to add your thread meta-data to it, and make it visible through summary line formats. I can imagine a thread about "ticket 985" the way you describe. A useful functionality for you, if I understand your needs, is to move/copy an article from any group to the tickets_group:bundle_985 thread in one shot. So perhaps the key thread meta-data you want is a thread name, for article copy/move operations? Then you can associate almost any data with that thread name. I hope that helps... Ted ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: new backend? 2002-12-06 19:21 ` Ted Zlatanov @ 2002-12-06 19:55 ` Kai Großjohann 2002-12-06 20:21 ` Ted Zlatanov 0 siblings, 1 reply; 5+ messages in thread From: Kai Großjohann @ 2002-12-06 19:55 UTC (permalink / raw) Ted Zlatanov <tzz@lifelogs.com> writes: > I can imagine a thread about "ticket 985" the way you describe. A > useful functionality for you, if I understand your needs, is to > move/copy an article from any group to the tickets_group:bundle_985 > thread in one shot. So perhaps the key thread meta-data you want is > a thread name, for article copy/move operations? Then you can > associate almost any data with that thread name. I've been thinking that it might be nice to allow for dynamic creation of digests in a group. You process-mark some articles, hit a button, and lo! you get a new article which is a digest of the process-marked ones which are then deleted. Later on, you add an article to such a digest. Digests can easily be viewed with C-d, so I think that would be a nifty thing to have. Not that it solves Jan's problems, of course. -- ~/.signature is: umop ap!sdn (Frank Nobis) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: new backend? 2002-12-06 19:55 ` Kai Großjohann @ 2002-12-06 20:21 ` Ted Zlatanov 0 siblings, 0 replies; 5+ messages in thread From: Ted Zlatanov @ 2002-12-06 20:21 UTC (permalink / raw) Cc: ding On Fri, 06 Dec 2002, kai.grossjohann@uni-duisburg.de wrote: > I've been thinking that it might be nice to allow for dynamic > creation of digests in a group. You process-mark some articles, hit > a button, and lo! you get a new article which is a digest of the > process-marked ones which are then deleted. > > Later on, you add an article to such a digest. > > Digests can easily be viewed with C-d, so I think that would be a > nifty thing to have. Definitely. > Not that it solves Jan's problems, of course. I'll let Jan tell us, but I think that digest messages would be exactly the right solution in this case. Baing able to access these digests by name as external move/copy targets would pretty much do the "bundle" functionality. I like it. Ted ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-12-06 20:21 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <m28yz4xu8u.fsf@tnuctip.rychter.com> 2002-12-05 18:55 ` new backend? Ted Zlatanov [not found] ` <m2smxcvyzo.fsf@tnuctip.rychter.com> 2002-12-06 13:33 ` Kai Großjohann 2002-12-06 19:21 ` Ted Zlatanov 2002-12-06 19:55 ` Kai Großjohann 2002-12-06 20:21 ` Ted Zlatanov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).