From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/23448 Path: main.gmane.org!not-for-mail From: Karl Kleinpaste Newsgroups: gmane.emacs.gnus.general Subject: Re: some mail annoyances [renumbering] Date: 22 Jun 1999 14:20:50 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035161179 2060 80.91.224.250 (21 Oct 2002 00:46:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:46:19 +0000 (UTC) Keywords: mail,gnus,messages,news,transport,smtp,nntp,renumber,group,articles,view,user Return-Path: Original-Received: from farabi.math.uh.edu (farabi.math.uh.edu [129.7.128.57]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id OAA07634 for ; Tue, 22 Jun 1999 14:23:34 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by farabi.math.uh.edu (8.9.1/8.9.1) with ESMTP id NAB07203; Tue, 22 Jun 1999 13:21:55 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 22 Jun 1999 13:22:41 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id NAA13442 for ; Tue, 22 Jun 1999 13:22:27 -0500 (CDT) Original-Received: from beaver.jprc.com (BEAVER.JPRC.COM [207.86.147.217]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id OAA07563 for ; Tue, 22 Jun 1999 14:21:20 -0400 (EDT) Original-Received: (from karl@localhost) by beaver.jprc.com (8.8.7/8.8.7) id OAA17336; Tue, 22 Jun 1999 14:20:50 -0400 Original-To: ding@gnus.org X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu In-Reply-To: Per Bothner's message of "22 Jun 1999 10:48:02 -0700" Original-Lines: 113 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2 (Chiyoda) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:23448 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:23448 Per Abrahamsen writes: >> You can't renumber the usenet messages, why should you be able to >> renumber mail messages? Makes no sense from the Gnus point of view. Per Bothner writes: > But it makes sense from *my* point of view. Saying you can't > renumber news does not imply that should should not be able to > renumber mail. News and mail *are* different. (This is something of a rant of mine from years past, but I feel a need to dust it off one more time.) The difference between mail and news is the size of the receiving audience. Privately-addressed, SMTP-transported articles are mail. But ding@gnus.org arrives as mail (SMTP) while being news nonetheless. A fair number of apparent ding subscribers see it as emacs.ding via some server in .dk, as a matter of fact. Local to myself, there's a newsgroup (being, in precise terms, a forum present on a local machine which serves up text via NNTP) which has precisely two readers, myself and one other. It's effectively mail, considering that no one but the two of us sees this stuff -- it *could* be sent between us via SMTP with no loss, or even change, of semantic value. The bottom line is that you, and many other people, distinguish content type from transport class. And that's neither necessary nor appropriate nor exactly the point any more. Are messages shared in a Micro$quish Exchange server environment news or mail? I dunno -- I can't tell the difference any more, and I like it that way. You tell me that news and mail are different. And I wonder exactly how, considering that I can truly get at either transport class with an identical user interface. *I don't care about transport class*. Transport doesn't matter; presentation does. Gnus gives me a great presentation while satisfyingly hiding transport from view. Certainly, I can go hunting down to the transport level for those types of bits, if I really need. I seldom do, and see no reason for such low-level issues to govern the high-level items that concern me. E.g. the concept of a "followup" has a uniform conceptual organization, which is defined appropriately in the different transport classes. > It is useful for them to share user interfaces to a large extent, > but that should not be an excuse to provide the minimal shared > functionality. I'm at the edge of being vaguely offended by the idea that Gnus represents any concept of "minimal functionality." It is no stretch of the truth to say that Gnus represents a proper superset of nearly every other news/mail interface's capabilities. You have managed to identify a couple of things that Gnus doesn't yet do. Whether those are things which we ought to make it do is an interesting question; perhaps they've been left out because they are peculiar to a transport-centric environment, or have some other attribute which just plain doesn't fit with the model Gnus provides. Gnus' model is much more one of "message management" than "news reading". There are a number of transport-specific capabilities that do in fact have to be available, such as moving around messages over which one has complete control (those which arrived via SMTP). But these are the wild exception to the general model presented. > If there was a command to renumber a mail group, it would also > renumber the remembered read messages. That is part of a correct > implementation. It may be tedious, but it is obviously doable. Certainly. What do you wish to accomplish by re-numbering? That is, certainly you're correct, some amount of hackery could be undertaken so as to coerce Gnus into re-ordering SMTP-transport messages. What is the goal of having done so? If you're just looking to group a set of messages close to one another numerically, then Gnus already provides that: Mark the set of articles in which you're interested with `#', and move them (`B m') to the same group in which they currently sit. New articles comprised of those original articles will come into existence, and the old ones will disappear. Voilą, you now have numerically-clumped articles, which may be of some benefit to you. (I don't know what, offhand; for myself, I use `B m' almost exclusively for archival purposes.) I will observe that, from your original discussion of wanting to move messages, I got the distinct impression that you simply had a long- standing workaround for a known MH limitation, in that MH doesn't cope with message numbers above 10,000 *at all*. If that's the goal being accomplished -- keeping the user interface operating sanely in the face of an erroneous and arbitrary internal representation -- then you don't need the function in the first place, because Gnus does not have that bug. > You can (reliably) move messages *within* a group? I guess I should > read up on that. `C-h i' -> Gnus -> The Summary Buffer -> Mail Group Commands There you will find `B m' and all its relatives. >> Rat has already explained why re-using low numbers is not a good >> idea at all. > Not to my satisfaction. There is necessarily a trade-off between programming difficulty and usefulness to the users. What you're asking for strikes (many of) us as being of extremely limited value, while surely being a major pain in the ass to implement. Whether you perceive the trade-off similarly is the definition of whether the explanation is "to your satisfaction" or not. --karl