Re: some mail annoyances [renumbering]

[Karl Kleinpaste <karl@justresearch.com>]

Per Abrahamsen <abraham@dina.kvl.dk> 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 <per@bothner.com> 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