some mail annoyances

some mail annoyances

[Per Bothner]

I switched to pgnus not too long ago, and it works fairly well for me.
However, there are some user interface issues that ae rather
annoying.  (I'm currently using gnus 0.84.)

* If in the Summary group, I do M-g in my mail group to check for new
mail, after new mail is read, point does to the *following* group.
That's silly default; point should stay at the group I just got
more mail for.

* As far as I can tell, there is no command to get new mail/news
from the summary buffer.  This means I have to quit the Summary
buffer, type M-g, then back up, and *then* type space.  As
well as being inconvenient, it inefficient for Gnus to re-load
the existing messages.

* If I enter a group, point normally goes to the first unread message.
But if (say) there is only a single new message, that message becomes
the last line in the window, while point goes to the *middle* of the
window.  When the list of ticked messages is long, it starts showing
the first old message, rather than the first new message.

* In general, the Gnus defaults for mail are quite clumsy.
For example, there should be a single command to delete (make
expirable) messages and move to the next.  I ended up doing:

(add-hook 'gnus-summary-mode-hook 'my-alter-summary-map)
(defun my-alter-summary-map ()
  (local-set-key "d" 'gnus-summary-put-mark-as-expirable-next))

More generally, for mail the natural classification is old messages,
new messages, and deleted messages.  Once I have deleted a
message, I normally don't want to see it.  However, I would like
to be able to see old messages.  If I do plain space in the Group
buffer, I only see new and ticked messages.  But if I do ^U-space
I get *all* the messages, including the expired ones.  This means
that to get what I consider normal behavior (as in most other MUAs)
I must take one of two acrtions for each new message:  Either tick it
if I want to save it, or delete it (make expireable) otherwise.
Sometimes I forget.  This is not very friendly.

* Bottom line:  Gnus is not usable as a mail reader for non-hacker
types.  There are just too many options, there is no introductory
manual, and the defaults are non-intuitive.  Even setting it up
so it suitable for non-hackers is difficult.  I ended up setting
up my boyfriend to use VM.  He is not 100% happy with VM, but
I don't see how gnus could be an option.  That is a shame.

* In there any commend to re-number the messages in a mail folder?
I'm used to mhe, which would re-use numbers on expired messages,
and when teh numbers approaches 10000, I would run an mh command
to renumber the entire folder.  Yes, this is an esthetic issue,
not really important ...
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: some mail annoyances

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Per Bothner <per@bothner.com>  on Mon, 21 Jun 1999
| * As far as I can tell, there is no command to get new mail/news
| from the summary buffer.

M-g

| * If I enter a group, point normally goes to the first unread message.
| But if (say) there is only a single new message, that message becomes
| the last line in the window, while point goes to the *middle* of the
| window.  When the list of ticked messages is long, it starts showing
| the first old message, rather than the first new message.

Ummm... I don't understand what you are describing.  At least I have never
seen the behaviour you describe.

| * In general, the Gnus defaults for mail are quite clumsy.
| For example, there should be a single command to delete (make
| expirable) messages and move to the next.  I ended up doing:

Read messages are automatically marked as read.  Unread messages I can mark 
deletable with 'd', which moves point to the next message.  total-expire
takes care of the rest for me.

[...]
| * In there any commend to re-number the messages in a mail folder?

This is a Bad Idea for something that works from a news reader's
perspective which remembers read messages by number.  If you give a new
message a number that has already been used, it will appear to have been
read, and well, that is just plain wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3bu8pgl+vIlSVSNkRAuQdAJ94lqMCXVmdl08qCAQsPv1cwOgavgCeIGQz
13z8ztdTWRWpf9f4rc9nFbM=
=+jwr
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.

Re: some mail annoyances

[Kai.Grossjohann]

Per Bothner <per@bothner.com> writes:

  > * In general, the Gnus defaults for mail are quite clumsy.
  > For example, there should be a single command to delete (make
  > expirable) messages and move to the next.  I ended up doing:

Some time ago, I tried to start a discussion to make the marking
commands more orthogonal, but I think nothing much became of it.

I suggested that it should be possible to combine the application of
any mark with any movement (no movement, backwards, forwards).
Currently, for example, marking as expirable always moves forward.
Why is there no command that marks as expirable but doesn't move?
Even more, there should be a way to specify the kind of movement: move
to next/previous message, or move to next/previous _unread_ message.

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Kai.Grossjohann]

Per Bothner <per@bothner.com> writes:

  > * Bottom line:  Gnus is not usable as a mail reader for non-hacker
  > types.  There are just too many options, there is no introductory
  > manual, and the defaults are non-intuitive.  Even setting it up
  > so it suitable for non-hackers is difficult.  I ended up setting
  > up my boyfriend to use VM.  He is not 100% happy with VM, but
  > I don't see how gnus could be an option.  That is a shame.

Hm.  In the past, I have set up Gnus for a couple of people as
follows: when a mail is selected, it is automatically ticked, and
total-expire is turned on.  This makes Gnus behave more or less like a
normal mail reader: already-read messages can be distinguished from
new ones, and they are always shown, and deleted messages are normally
not shown.

What do you think about this?

  > * In there any commend to re-number the messages in a mail folder?
  > I'm used to mhe, which would re-use numbers on expired messages,
  > and when teh numbers approaches 10000, I would run an mh command
  > to renumber the entire folder.  Yes, this is an esthetic issue,
  > not really important ...

You can make them have consecutive numbers by moving all messages from
a group to the same group.  Rat has already explained why re-using low
numbers is not a good idea at all.

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Per Bothner <per@bothner.com> writes:
> 
>   > * Bottom line:  Gnus is not usable as a mail reader for non-hacker
>   > types.  There are just too many options, there is no introductory
>   > manual, and the defaults are non-intuitive.  Even setting it up
>   > so it suitable for non-hackers is difficult.  I ended up setting
>   > up my boyfriend to use VM.  He is not 100% happy with VM, but
>   > I don't see how gnus could be an option.  That is a shame.
> 
> Hm.  In the past, I have set up Gnus for a couple of people as
> follows: when a mail is selected, it is automatically ticked, and
> total-expire is turned on.

Kai, Is the auto ticking done by some existing functionality in gnus?

Re: some mail annoyances

[Karl Kleinpaste]

Harry Putnam <reader@newsguy.com> writes:
> Kai, Is the auto ticking done by some existing functionality in gnus?

(add-to-hook 'gnus-article-display-hook 'gnus-summary-tick-article-forward),
presumably.

Re: some mail annoyances

[Kai.Grossjohann]

Harry Putnam <reader@newsguy.com> writes:

  > Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
  > 
  > > Hm.  In the past, I have set up Gnus for a couple of people as
  > > follows: when a mail is selected, it is automatically ticked, and
  > > total-expire is turned on.
  > 
  > Kai, Is the auto ticking done by some existing functionality in gnus?

Well...  There is a variable gnus-mark-article-hook which is normally
set to (gnus-summary-mark-unread-as-read).  I defined my own function
for this:

(defun kai-gnus-mark-article-hook ()
  (if (and (not (or (memq gnus-current-article gnus-newsgroup-marked)
		    (memq gnus-current-article gnus-newsgroup-dormant)
		    (memq gnus-current-article gnus-newsgroup-expirable)
		    (memq gnus-current-article gnus-newsgroup-ancient)
                    (memq gnus-current-article gnus-newsgroup-reads))))
      (if (kai-gnus-newsgroup-style-group gnus-newsgroup-name)
	  (gnus-summary-mark-unread-as-read)
	(gnus-summary-mark-as-dormant 1))))

I enabled this function with:

(setq gnus-mark-article-hook (list 'kai-gnus-mark-article-hook))

Now, what does kai-gnus-mark-article-hook do?  Well, it does not do
anything if the article is alread ticked or dormant or expirable or
ancient or read.  But if the article is fresh, it sees whether the
current group is a `newsgroup style group'.  If so, the article is
marked as read (as is normal in a newsgroup).  Else, the article is
marked as dormant.  (Of course, you can replace
gnus-summary-mark-as-dormant with gnus-summary-mark-as-unread-forward
to tick the message.)

What's missing?  Well, the function kai-gnus-newsgroup-style-group
which checks whether a group is a newsgroup style group.  Here's a
simple version:

(defun kai-gnus-newsgroup-style-group (groupname)
  (if (string-match "^nnml:" groupname)
      nil
    t))

It considers all nnml groups to be mail style, all others to be
newsgroup style.  Suppose you wish to treat mailing lists like
newsgroups, and further suppose your mailing list groups are called
"nnml:list.foo", then you could use the following definition:

(defun kai-gnus-newsgroup-style-group (groupname)
  (cond ((string-match "^nnml:list" groupname) t)
        ((string-match "^nnml:" groupname) nil)
        (t t)))

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Wes Hardaker]

>>>>> On 22 Jun 1999 10:23:13 +0200, Kai.Grossjohann@CS.Uni-Dortmund.DE said:

Kai> Hm.  In the past, I have set up Gnus for a couple of people as
Kai> follows: when a mail is selected, it is automatically ticked, and
Kai> total-expire is turned on.  This makes Gnus behave more or less
Kai> like a normal mail reader: already-read messages can be
Kai> distinguished from new ones, and they are always shown, and
Kai> deleted messages are normally not shown.

Kai> What do you think about this?

Colors are wrong...  Red (default ticked) is not an appropriate color
for old messages...

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

Re: some mail annoyances

[Per Abrahamsen]

Per Bothner <per@bothner.com> writes:

> * If in the Summary group, I do M-g in my mail group to check for new
> mail, after new mail is read, point does to the *following* group.
> That's silly default; point should stay at the group I just got
> more mail for.

Not if you want to fetch new messages for several groups, I do that
often for foreign nntp groups.

> * As far as I can tell, there is no command to get new mail/news
> from the summary buffer.  This means I have to quit the Summary
> buffer, type M-g, then back up, and *then* type space.  As
> well as being inconvenient, it inefficient for Gnus to re-load
> the existing messages.

M-g works in the summary buffer.

> * If I enter a group, point normally goes to the first unread message.
> But if (say) there is only a single new message, that message becomes
> the last line in the window, while point goes to the *middle* of the
> window.  When the list of ticked messages is long, it starts showing
> the first old message, rather than the first new message.

I haven't noticed that.

> * In general, the Gnus defaults for mail are quite clumsy.
> For example, there should be a single command to delete (make
> expirable) messages and move to the next.  I ended up doing:
> 
> (add-hook 'gnus-summary-mode-hook 'my-alter-summary-map)
> (defun my-alter-summary-map ()
>   (local-set-key "d" 'gnus-summary-put-mark-as-expirable-next))

Use `E' for that.

> More generally, for mail the natural classification is old messages,
> new messages, and deleted messages.  Once I have deleted a
> message, I normally don't want to see it.  However, I would like
> to be able to see old messages.  If I do plain space in the Group
> buffer, I only see new and ticked messages.  But if I do ^U-space
> I get *all* the messages, including the expired ones.  This means
> that to get what I consider normal behavior (as in most other MUAs)
> I must take one of two acrtions for each new message:  Either tick it
> if I want to save it, or delete it (make expireable) otherwise.
> Sometimes I forget.  This is not very friendly.

You can set `Expiry Wait' to `immidiate' and `Display' to `all' in the
group properties (G c).  

However, more important: Gnus is not mail reader.  It is a news
reader, which happens to handle mail as well.  As long as you keep
thinking in the news paradigm, Gnus is very friendly.

> * Bottom line:  Gnus is not usable as a mail reader for non-hacker
> types.  There are just too many options, there is no introductory
> manual, and the defaults are non-intuitive.  Even setting it up
> so it suitable for non-hackers is difficult.  I ended up setting
> up my boyfriend to use VM.  He is not 100% happy with VM, but
> I don't see how gnus could be an option.  That is a shame.

VM is an excellent mail reader, and in itself a good reason why Gnus
should keep working like a news reader.  If you want a mail reader
that works according to normal mail reader conventions, VM is there.
However, if you really want to treat your mailbox as a newsspool, Gnus
is the answer.  

> * In there any commend to re-number the messages in a mail folder?
> I'm used to mhe, which would re-use numbers on expired messages,
> and when teh numbers approaches 10000, I would run an mh command
> to renumber the entire folder.  Yes, this is an esthetic issue,
> not really important ...

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.

Re: some mail annoyances [renumbering]

[Per Bothner]

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.

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.  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.

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> This is a Bad Idea for something that works from a news reader's
> perspective which remembers read messages by number.  If you give a new
> message a number that has already been used, it will appear to have been
> read, and well, that is just plain wrong.

Huh?  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.

I suppose message number may also be appear in messages sent
to others, thus threading may get confused if messages are
renumbed and then a new mesages arrives which references a
message using the old number.  But in no case should unread mail
"appear to have been read", assuming a correctly-implemented
re-number command.  I do not see that there can be any fundamental
difficulty writing such a command.  A pain, that I can see, if
there are a lot of files that have to be modified.

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> You can make them have consecutive numbers by moving all messages from
> a group to the same group.

You can (reliably) move messages *within* a group?  I guess I should
read up on that.

> Rat has already explained why re-using low numbers is not a good
> idea at all.

Not to my satisfaction.

Perhaps this would make a good FAQ entry when we are done?
--
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: some mail annoyances [renumbering]

[Karl Kleinpaste]

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

Re: some mail annoyances [renumbering]

[Jaap-Henk Hoepman]

On 22 Jun 1999 14:20:50 -0400 Karl Kleinpaste <karl@justresearch.com> writes:
> (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.
> 
> [snip]
> 
> 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.

Actually there is another quite fundamental difference between mail and news 
(which makes using gnus - by origin a news reader- harder to configure
to read mail ):
        news is stored somewhere else: it's volatile; if you want to keep it
                you have to do something
        mail is stored locally by you: it's permanent; if you want to delete it
                you have to do something
This is how most newsreaders and mail programs work; this is also what people
expect them to do. Therefore transport class (or at least `storage class') does
matter.

Jaap-Henk

--
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: some mail annoyances [renumbering]

[Kai.Grossjohann]

Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

  > Actually there is another quite fundamental difference between
  > mail and news (which makes using gnus - by origin a news reader-
  > harder to configure to read mail ):
  >         news is stored somewhere else: it's volatile; if you want
  >         to keep it you have to do something
  >         mail is stored locally by you: it's permanent; if you want
  >         to delete it you have to do something
  > This is how most newsreaders and mail programs work; this is also
  > what people expect them to do. Therefore transport class (or at
  > least `storage class') does matter.

This fundamental difference is quite blurred with Gnus.  You can even
set it up such that the "in news, you have to do something to keep it,
in mail, you have to do something to delete it" is reversed!

And with IMAP, mail isn't stored locally.

kai
-- 
Life is hard and then you die.

Re: some mail annoyances [renumbering]

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> And with IMAP, mail isn't stored locally.

No, but it is still controlled by the user.  I think the local/remote
distinction Jaap-Henk Hoepman gave is more exactly described as a
user-controled/administrator-controled distinction.

Re: some mail annoyances [renumbering]

[Jaap-Henk Hoepman]

On 23 Jun 1999 09:44:56 +0200 Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:
> 
>   > Actually there is another quite fundamental difference between
>   > mail and news (which makes using gnus - by origin a news reader-
>   > harder to configure to read mail ):
>   >         news is stored somewhere else: it's volatile; if you want
>   >         to keep it you have to do something
>   >         mail is stored locally by you: it's permanent; if you want
>   >         to delete it you have to do something
>   > This is how most newsreaders and mail programs work; this is also
>   > what people expect them to do. Therefore transport class (or at
>   > least `storage class') does matter.
> 
> This fundamental difference is quite blurred with Gnus.  You can even
> set it up such that the "in news, you have to do something to keep it,
> in mail, you have to do something to delete it" is reversed!

Right. And that's exactly why gnus is hard to set up to handle mail with.
By default, it does `the right thing' for news, but not for mail.

Just a thought: how difficult would it be to introduce group parameters
this-is-a-mail-group and this-is-a-news-group, and to let gnus do it
`the news way' for newsgroups and do it `the mail way' for mail groups.
This way, installing gnus to read both news and mail becomes easy; and once
people get the hang of it maybe they will expirment to do it `the gnus way'.

> And with IMAP, mail isn't stored locally.

Well, maybe Per's suggestion to distinguish user-controlled
vs. admin-controlled information better captures the situation.

> kai
> -- 
> Life is hard and then you die.

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: some mail annoyances [renumbering]

[Per Abrahamsen]

Per Bothner <per@bothner.com> writes:

> 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.
> 
> But it makes sense from *my* point of view.

Then your point of view is wrong for Gnus.  The point of my message
was that if can't think of your mail as news which has arrived on a
slightly different route, then Gnus isn't the right tool for you.

Re: some mail annoyances [renumbering]

[Sam Falkner]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Then your point of view is wrong for Gnus.  The point of my message
> was that if can't think of your mail as news which has arrived on a
> slightly different route, then Gnus isn't the right tool for you.

When I first switched to Gnus, I too worried quite a bit about message
numbers and compacting them.  I guess it came from my mh background,
where such things were easy to do.  Also, I would never have dreamed
of turning on total-expire.  Yikes!

Now I couldn't care less about the filenames of the mail messages that
I'm reading (using nnml).  I'm also much happier with total-expire
turned on.  I understand why the manual says `use with caution', but
in reality, I think most people would be happier with it, if they took 
the time to understand it.

My only current gripe is with the cached article numbers, especially
when moving to a new NNTP server.  In that case, I *do* move the
article numbers around to occupy the lowest numbers, and rebuild the
cache.  I wish this were automatic.

- Sam

Finding a given in an nnml group (was: Re: some mail annoyances [renumbering])

[Laura Conrad]

Sam Falkner <samf@central.sun.com> writes:


> Now I couldn't care less about the filenames of the mail messages that
> I'm reading (using nnml).

I don't care what the names are, but there are times I wish it were
easier to connect the filename with the message in gnus.  I do a fair
amount of using grep to find the message which has a given piece of
information in it, and then I look at the headers and then I go to the
group and find that subject and author.  I'm sure there's a more
straightforward way to do this.  What do other people do?

-- 
Laura (mailto:lconrad@world.std.com , http://www.world.std.com/~lconrad/ )
(617) 661-8097 , fax: (801) 365-6574
233 Broadway, Cambridge, MA 02139, USA

Re: Finding a given in an nnml group (was: Re: some mail annoyances [renumbering])

[Jack Twilley]

>>>>> "Laura" == Laura Conrad <lconrad@concord.com> writes:

    Laura> I don't care what the names are, but there are times I wish
    Laura> it were easier to connect the filename with the message in
    Laura> gnus.  I do a fair amount of using grep to find the message
    Laura> which has a given piece of information in it, and then I
    Laura> look at the headers and then I go to the group and find
    Laura> that subject and author.  I'm sure there's a more
    Laura> straightforward way to do this.  What do other people do?

I forget who put it up, but there's a file called nnir.el that does
this wonderfully.  You have to install something like glimpse to index
the mail, but once that's done, you just type G G, and it does its
thing.  Here's the nnir-ish parts of my .gnus:

(setq nnir-search-engine 'glimpse)
(require 'nnir)

Obviously you have to put nnir.el in your load-path, etc etc.

Good luck!

    Laura> -- Laura (mailto:lconrad@world.std.com ,
    Laura> http://www.world.std.com/~lconrad/ ) (617) 661-8097 , fax:
    Laura> (801) 365-6574 233 Broadway, Cambridge, MA 02139, USA

Jack.
(used to be jmt@world.std.com -- still am, I think.)
-- 
Jack Twilley
jmt at nycap dot rr dot com
http colon slash slash jmt dot dhs dot org slash tilde jmt slash

Re: Finding a given in an nnml group (was: Re: some mail annoyances [renumbering])

[Per Abrahamsen]

Laura Conrad <lconrad@concord.com> writes:

> What do other people do?

I press `j' and enter the file name/number of the message.

[ Well, actually I just use less. ]

Re: Finding a given in an nnml group (was: Re: some mail annoyances [renumbering])

[Kai.Grossjohann]

Laura Conrad <lconrad@concord.com> writes:

  > I don't care what the names are, but there are times I wish it were
  > easier to connect the filename with the message in gnus.

Gnus shows the article number in the mode line of the summary buffer
(or was it the article buffer?).  For nnml and nnmh, the article
number is equal to the file name.

  > I do a fair amount of using grep to find the message which has a
  > given piece of information in it, and then I look at the headers
  > and then I go to the group and find that subject and author.

There is a command for jumping to an article.  It allows you to enter
the article number.

  > I'm sure there's a more straightforward way to do this.  What do
  > other people do?

Others have pointed out nnir.el.  It is available from
    ftp://ls6-ftp.cs.uni-dortmund.de/pub/src/emacs/nnir.el
Let me know if I can help in setting it up.

kai
-- 
Life is hard and then you die.

Re: Finding a given in an nnml group (was: Re: some mail annoyances [renumbering])

[Laura Conrad]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:


> Gnus shows the article number in the mode line of the summary buffer
> (or was it the article buffer?).  For nnml and nnmh, the article
> number is equal to the file name.

There is a number in the summary buffer, but it isn't the same as the
file name.  I don't know where that number comes from, or what you can
do with it.

-- 
Laura (mailto:lconrad@world.std.com , http://www.world.std.com/~lconrad/ )
(617) 661-8097 , fax: (801) 365-6574
233 Broadway, Cambridge, MA 02139, USA

Re: Finding a given in an nnml group (was: Re: some mail annoyances [renumbering])

[Per Abrahamsen]

Laura Conrad <lconrad@concord.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> 
> 
> > Gnus shows the article number in the mode line of the summary buffer
> > (or was it the article buffer?).  For nnml and nnmh, the article
> > number is equal to the file name.
> 
> There is a number in the summary buffer, but it isn't the same as the
> file name.  I don't know where that number comes from, or what you can
> do with it.

The numbers in the summary buffer are the number of lines in the
messages.  The number in the *mode line* of the summary buffer is the
article number (file name) of the last displayed article.

Re: Finding a given in an nnml group (was: Re: some mail annoyances [renumbering])

[Kai.Grossjohann]

Laura Conrad <lconrad@concord.com> writes:

  > Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
  > 
  > 
  > > Gnus shows the article number in the mode line of the summary buffer
  > > (or was it the article buffer?).  For nnml and nnmh, the article
  > > number is equal to the file name.
  > 
  > There is a number in the summary buffer, but it isn't the same as the
  > file name.  I don't know where that number comes from, or what you can
  > do with it.

I said mode line, not summary buffer.  My mode line looks like this
when looking at your message:

-1:-- Gnus:nnimap.I.auto.gnus [778] {10 more}  (Summary Plugged)--L9--Bot--

The article number (and file name if using nnml) is 778.

The number in the summary buffer itself is the number of lines in the
message.  I think.

kai
-- 
Life is hard and then you die.

Re: Finding a given in an nnml group (was: Re: some mail annoyances [renumbering])

[Justin Sheehy]

Laura Conrad <lconrad@concord.com> writes:

> I don't care what the names are, but there are times I wish it were
> easier to connect the filename with the message in gnus. 

Using nnml, I assume?  It's easy.

> I do a fair amount of using grep to find the message which has a
> given piece of information in it, and then I look at the headers and
> then I go to the group and find that subject and author.  I'm sure
> there's a more straightforward way to do this.  What do other people
> do?

The name of the file is the article number.  So, if you find a file
named '1783', you can 'j' to article number 1783 to access it in
Gnus.  The easiest way to reverse this process is to read the Xref
header.

-- 
Justin Sheehy

In a cloud bones of steel.
  

Re: some mail annoyances [renumbering]

[Tony Lam]

* "Sam" == Sam Falkner <samf@central.sun.com> writes:

Sam> Per Abrahamsen <abraham@dina.kvl.dk> writes:

Sam> My only current gripe is with the cached article numbers,
Sam> especially when moving to a new NNTP server.  In that case, I
Sam> *do* move the article numbers around to occupy the lowest
Sam> numbers, and rebuild the cache.  I wish this were automatic.

As far as I can tell, moving/copying/respooling don't seem to touch
cached articles at all, so they won't renumber cached articles.  Do I
miss something? I don't know any working solution to this problem.

Tony

Re: some mail annoyances [renumbering]

[Steinar Bang]

>>>>> Sam Falkner <samf@central.sun.com>:

> When I first switched to Gnus, I too worried quite a bit about
> message numbers and compacting them.  I guess it came from my mh
> background, where such things were easy to do.  Also, I would never
> have dreamed of turning on total-expire.  Yikes!

> Now I couldn't care less about the filenames of the mail messages
> that I'm reading (using nnml).  I'm also much happier with
> total-expire turned on.

This mirrors my own experience almost exactly.  Same background, same
scepticism, same desires, and the same conclusions.

Re: some mail annoyances [renumbering]

[David Hedbor]

Sam Falkner <samf@central.sun.com> writes:
> 
> When I first switched to Gnus, I too worried quite a bit about message
> numbers and compacting them.  I guess it came from my mh background,
> where such things were easy to do.  Also, I would never have dreamed
> of turning on total-expire.  Yikes!

I could also care elss about the article file names (numbers), but I
really hate how gnus calculates the number of articles in an nnml
group. If I have 100 messages in a group, I want gnus to say I have
100 messages, not 1029 messages. This has of course been discussed
many times before but I have yet to understand why gnus can't check
how many messages there REALLY are in a mail group. How hard can that
really be?


-- 
[ Below is a random fortune, which is unrelated to the above message. ]
A gleekzorp without a tornpee is like a quop without a fertsneet (sort of).

Re: some mail annoyances [renumbering]

[Kai.Grossjohann]

David Hedbor <david@hedbor.org> writes:

  > [...] This has of course been discussed many times before but I
  > have yet to understand why gnus can't check how many messages
  > there REALLY are in a mail group. How hard can that really be?
  > [...]

It is not hard, but slow.  Use nnmh as your mail backend and you will
see just *how* slow.  (With nnmh, Gnus looks for the exact number of
messages in a group because nnmh does not have these nifty .overview
files.  I think.)

kai
-- 
Life is hard and then you die.

Re: some mail annoyances [renumbering]

[David Hedbor]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> David Hedbor <david@hedbor.org> writes:
> 
>   > [...] This has of course been discussed many times before but I
>   > have yet to understand why gnus can't check how many messages
>   > there REALLY are in a mail group. How hard can that really be?
>   > [...]
> 
> It is not hard, but slow.  Use nnmh as your mail backend and you will
> see just *how* slow.  (With nnmh, Gnus looks for the exact number of
> messages in a group because nnmh does not have these nifty .overview
> files.  I think.)

Why not simply check the number of entries in the overview files? Or
add a second file that keeps the number of articles cached. I can't
possibly see how this can be slow for nnml. If you don't want to count 
lines, isn't there a getdir function? I mean, in Pike I could do
[ sizeof(get_dir(".")) ]. That takes 10-20 ms on a dir with 3000 files 
in it. wc -l on the .overview file in that directory takes 0.006
seconds. Another option would be to add a first line with num articles 
to the .overview files.

In any case, I still can't see how it would be either hard or slow,
unless emacs is very bad at the above operations (I don't know enough
elisp to try). It would of course be an nnml specific solution (well,
should work with nnmh too possibly). 

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
I didn't believe in reincarnation in any of my other lives.  I don't see why
I should have to believe in it in this one.
		-- Strange de Jim

Re: some mail annoyances [renumbering]

[Karl Kleinpaste]

David Hedbor <david@hedbor.org> writes:
> Why not simply check the number of entries in the overview files? 

When evaluating overall state to make a *Group* display, or to offer
#-of-articles-on-entry query when beyond the gnus-large-newsgroup
limit, Gnus has not yet seen overviews.  Overviews are seen only as a
group is being entered, when the *Summary* display is being created.

> In any case, I still can't see how it would be either hard or slow,

It is not slow.  It is hard.  You are asking that Gnus begin to
examine _individual group content_ at a time when it is supposed to be
evaluating only _overall groups' content_.

It is possible that Gnus could be convinced to do this for non-NNTP
groups, at least for nnml groups in particular -- peek into the dir
during *Group* display creation, count real articles, update the count 
seen.  But it is surely a bizarre thing, given the context in which
the *Group* display creation is being conducted.

Re: some mail annoyances [renumbering]

[Kai.Grossjohann]

Per Bothner <per@bothner.com> writes:

  > Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
  > > You can make them have consecutive numbers by moving all messages from
  > > a group to the same group.
  > 
  > You can (reliably) move messages *within* a group?  I guess I should
  > read up on that.

Yes, you can.  And you can rename a group twice: from foo to foo1,
from foo1 back to foo.  After this, you'll have article numbers
starting from 1.

I still don't see why you would want this, but the possibility is
there.

kai
-- 
Life is hard and then you die.

Being forced to deal with message numbers and frustrated

[Tony Lam]

Hi,

As long as people are talking about message number related problem and
solution, I'll throw in my problem :-)

I switched to Gnus from mailers that do not use message numbers,
naturally with Gnus I couldn't care less about message numbers. The
only place that I have to deal with message numbers is when I enter a
large group that I have to decide how many messages to read. (I don't
want to set gnus-large-newsgroup to nil because there are just too
many to read). In the following situations that I'm very frustrated by
the message numbers:

  * Number gap in cached messages can not be removed. When a messages
    group (I use nnfolder) has cached articles, I find
    respooling/moving/copying messages in the group do not touch
    cached articles, also cache groups do not support moving/copy
    themselves, thus there is no way to get rid of those huge gaps in
    message numbers within Gnus. Some people has reported moving
    articles does get rid of the number gaps in cached messages but I
    can't get it working for me. Is this intended behavior or a bug? I
    almost have to write a script to renumber cached messages outside
    Gnus and have Gnus rebuild the cache, but Gnus ought to handle
    this nicely.

  * Number in virtual group is frustrating. I have procmail to
    prioritize one of my high volume mailing lists into three folders,
    say foo.a, foo.b, foo.c. The reason is being that I only want to
    be notified of new messages in foo.a, so I can have xbuffy to only
    watch the spool file for foo.a. Sometimes I need to read all
    messages in foo.a, foo.b and foo.c, so I have a virtual group
    foo.v that consists of the above three. Now how does the number I
    give Gnus to read when entering the virtual group gets distributed
    within the component groups? Here is an example:

	group		message number range
	-----		--------------------
	foo.a		[1000-1200]
	foo.b		[1100-2500]
	foo.c		[3000-4000]

    When I tell Gnus to read read 300 messages from foo.v, does Gnus
    read 100 from each component group or just read the 300 messages
    with highest number from the virtual group? 

How does other people handle these problem? Any suggestion will be
appreciated. 

Tony

Re: Being forced to deal with message numbers and frustrated

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Tony Lam <Tony.Lam+ding@eng.sun.com>  on Wed, 23 Jun 1999
|   * Number gap in cached messages can not be removed. When a messages
|     group (I use nnfolder) has cached articles, I find
|     respooling/moving/copying messages in the group do not touch
|     cached articles,

Why are you caching mail messages?  There is no sane reason to do more than
'tick' with `u' so as to prevent articles from being expired.

|     also cache groups do not support moving/copy themselves,

There is no "cache" backend.  The only ways to read cache areas is to use
nndir or nneething backends, both of which are read-only backends.

If you wish to reseqence a group, process mark all messages in that group
and move them to the same group (B m).

|   * Number in virtual group is frustrating.

Virtual groups are frustrating :).

[...]
|     When I tell Gnus to read read 300 messages from foo.v, does Gnus
|     read 100 from each component group or just read the 300 messages
|     with highest number from the virtual group?

Gnus reads 100 articles.  Where the backend gets them is a separate issue
(which is the entire point, really).

| How does other people handle these problem? Any suggestion will be
| appreciated.

I've never experienced these "problems", mainly becuase I never bother
thinking about things like article numbers.  They are irrelevant to me;
they only mean something to the Gnus backend that maintains them.  Ignore
messages numbers and your "problems" will go away.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3cTwBgl+vIlSVSNkRAuNAAJsGlMogh3cKALkyKHNonecNQKVsFgCfS8Za
CKOdr8nS6KuOZUmV6te9YXU=
=kOfb
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.

Re: Being forced to deal with message numbers and frustrated

[Tony Lam]

* "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

* Tony Lam <Tony.Lam+ding@eng.sun.com>  on Wed, 23 Jun 1999

Tony> * Number gap in cached messages can not be removed. When a messages
Tony> group (I use nnfolder) has cached articles, I find
Tony> respooling/moving/copying messages in the group do not touch
Tony> cached articles,

Rat> Why are you caching mail messages?  There is no sane reason to do
Rat> more than 'tick' with `u' so as to prevent articles from being
Rat> expired.

I use passive cache to archive messages in the same group in mail and
news because ticked messages can be expired, at least in newsgroups,
and I want one consistent operation for both mail and groups. Besides,
I use tick to mark messages that need to be replied later.

>From Gnus's info:

`!'
     Marked as ticked (`gnus-ticked-mark').

     "Ticked articles" are articles that will remain visible always.  If
     you see an article that you find interesting, or you want to put
     off reading it, or replying to it, until sometime later, you'd
     typically tick it.  However, articles can be expired, so if you
     want to keep an article forever, you'll have to make it persistent
     (*Note Persistent Articles::).

Maybe the problem can be better stated as article number reseqencing
is not possible for mail groups with cached articles.

Tony> also cache groups do not support moving/copy themselves,

Rat> There is no "cache" backend.  The only ways to read cache areas
Rat> is to use nndir or nneething backends, both of which are
Rat> read-only backends.

Rat> If you wish to reseqence a group, process mark all messages in
Rat> that group and move them to the same group (B m).

You're right, there is no "nncache" backend. My cache groups are using
nnspool backends (Gnus's default?) I was referring the groups that I
setup to read cached only articles. My point was that those groups do
not support copying/moving, so I can't copy or move them to remove
number gaps.

Rat> Virtual groups are frustrating :).

Rat> Gnus reads 100 articles. 

Good to know. Still they are not the last 300 articles that are
arrived most recently from the point of virtual group, as I would get
from a non-virtual group (assuming no article number gap off course).

Rat> I've never experienced these "problems", mainly becuase I never
Rat> bother thinking about things like article numbers.  They are
Rat> irrelevant to me; they only mean something to the Gnus backend
Rat> that maintains them.  Ignore messages numbers and your "problems"
Rat> will go away.

I never want to care about article numbers in the first place. Gnus
could have transparently hide those numbers from user completely, or
at least provide some satisfactory working solution that can be
automated to deal with these situations, and there would be no
problems from user regarding article numbers.

Regards,

Tony

Re: Being forced to deal with message numbers and frustrated

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Tony Lam <Tony.Lam+ding@eng.sun.com>  on Wed, 23 Jun 1999
| I never want to care about article numbers in the first place. Gnus
| could have transparently hide those numbers from user completely, or
| at least provide some satisfactory working solution that can be
| automated to deal with these situations, and there would be no
| problems from user regarding article numbers.

Point: Gnus *DOES* hide those numbers completely (if you tell it not to
display article numbers in the summary buffers).  In the ~5 years I have
been using Gnus, I have never looked at article numbers outside of writing
code that deals with messages on an article number basis, that being my
grafting of Gnus' early expiry code to GNUS and FSF Emacs 18, making early
versions of Gnus play nicely with jka-compr and compressed nnml files, and
some procmail support (the nnmail-keep-last-article stuff).

Admittedly, you are using cache and tick in a fashion that is more complex
than it needs to be (read: wrong :).  I think you would be happier doing
this:

* Use ticks (! or u) to mark articles that you wish to reply to later.

* Use mark dormant (?) to mark articles that you want to keep around
  forever.

* Set gnus-use-cache based on group name (I use a cond form in
  gnus-select-group-hook to set certain variables based on group name).
  Set it true for remote groups, nil or passive as you would for local
  (mail) groups.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3cXm6gl+vIlSVSNkRAp9BAJ9bCNiCcVKZnBUZo57Mly+wS9opHgCdFJqN
aNr21OGH/FnMUvTWFv6VroQ=
=Cx0K
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.

Re: Being forced to deal with message numbers and frustrated

[Tony Lam]

* "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

Rat> Point: Gnus *DOES* hide those numbers completely (if you tell it
Rat> not to display article numbers in the summary buffers).

People are forced to be concern with, deal with article numbers
because they have been kept prompting to make decision (how many
messages to fetch), for which they have first to be aware there is an
article number associate with each article and secondly, they have to
somehow keep reseqencing these numbers in order for that decision to
make sense. And for the situations I mentioned, Gnus does not provide
a satisfactory solution.

Rat> Admittedly, you are using cache and tick in a fashion that is
Rat> more complex than it needs to be (read: wrong :).  I think you
Rat> would be happier doing this:

Rat> * Use ticks (! or u) to mark articles that you wish to reply to later.

Rat> * Use mark dormant (?) to mark articles that you want to keep around
Rat>   forever.

Rat> * Set gnus-use-cache based on group name (I use a cond form in
Rat>   gnus-select-group-hook to set certain variables based on group name).
Rat>   Set it true for remote groups, nil or passive as you would for local
Rat>   (mail) groups.

I'm one of those people who prefer 5 marks for messages:

  unmarked - new message
  O - old, read message (with total-expire)
  ! - message needs attention
  * - message archived in place
  ? - interesting message that I would like to see followup

Anyway, the problem remains as long as any kind of cache is used for
mail groups (gnus-use-cache is anything other than nil) and I don't
see how using cache is too complex.

Regards,

Tony

Re: Being forced to deal with message numbers and frustrated

[Kai.Grossjohann]

Tony Lam <Tony.Lam+ding@eng.sun.com> writes:

  > * "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
  > 
  > Rat> Point: Gnus *DOES* hide those numbers completely (if you tell it
  > Rat> not to display article numbers in the summary buffers).
  > 
  > People are forced to be concern with, deal with article numbers
  > because they have been kept prompting to make decision (how many
  > messages to fetch), for which they have first to be aware there is an
  > article number associate with each article and secondly, they have to
  > somehow keep reseqencing these numbers in order for that decision to
  > make sense. And for the situations I mentioned, Gnus does not provide
  > a satisfactory solution.

I don't recall having any problems with the gaps in my nnml groups.  I
do not use total-expire, I mark as read those messages which I want to
keep and I tick those messages which I need to work on.

kai
-- 
Life is hard and then you die.

Re: Being forced to deal with message numbers and frustrated

[Kai.Grossjohann]

Tony Lam <Tony.Lam+ding@eng.sun.com> writes:

  > I'm one of those people who prefer 5 marks for messages:
  > 
  >   unmarked - new message
  >   O - old, read message (with total-expire)
  >   ! - message needs attention
  >   * - message archived in place
  >   ? - interesting message that I would like to see followup

If you turn off total-expire, you can use:

unmarked -- new message
E        -- old msg, delete it soon
!        -- msg needs attention
R/O      -- msg archived
?        -- msg archived and interesting

kai
-- 
Life is hard and then you die.

Re: Being forced to deal with message numbers and frustrated

[Peter von der Ahé - at home]

>>>>> "TL" == Tony Lam <Tony.Lam+ding@eng.sun.com> writes:

 TL> I never want to care about article numbers in the first
 TL> place. Gnus could have transparently hide those numbers from user
 TL> completely, or at least provide some satisfactory working
 TL> solution that can be automated to deal with these situations, and
 TL> there would be no problems from user regarding article numbers.

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

 Rat> Point: Gnus *DOES* hide those numbers completely (if you tell it
 Rat> not to display article numbers in the summary buffers).

I will not argue that Gnus cannot hide the article numbers completely
from plain sight, but that is not the problem here is it?

To illustrate what the problem, please try doing the following:

(setq gnus-large-newsgroup 2)

in .gnus.el

Create a new nnml group with G m, copy 3 messages to this group.
Mark them all as read.  Delete the article with number 2.  Exit the
group.  Enter the group.  You will now be asked how many articles you
want to see, even though there only is 2 articles in the group.  This
can be very annoying when you have larges mail groups with gaps.

Further more, AFAIK[1], Gnus will consider all messages from the
lowest available number to the highest.  So if you have a group with a
article numbered 1 and the next is numbered 1002, Gnus will have to do
something for 1000 article in between, this may not be much, but will
amount to a hill of beans in the long run.  So for efficiency it would
be perfectly sane to provide some kind of renumbering function.

[1] Once I had problems entering large mailgroups with gaps, because
gnus insisted on stat'ing all nonexistent files from 2 to 1001.  I
think this problem has gone away, and maybe only the numbers from
.overview is used.

Cheers,
Peter

Re: Being forced to deal with message numbers and frustrated

[Norbert Koch]

In message <yc0hfnxprwg.fsf@whitestar.daimi.au.dk>,
nospam2159+ding@daimi.au.dk (Peter von der Ahé - at home) wrote:

> To illustrate what the problem, please try doing the following:
> 
> (setq gnus-large-newsgroup 2)
> 
> in .gnus.el
> 
> Create a new nnml group with G m, copy 3 messages to this group.
> Mark them all as read.  Delete the article with number 2.  Exit the
> group.  Enter the group.  You will now be asked how many articles you
> want to see, even though there only is 2 articles in the group.  This
> can be very annoying when you have larges mail groups with gaps.

Well, after recognising this problem, you could mark all articles and
respool them (B r). This should ease the trouble, shouldn't it?

Re: Being forced to deal with message numbers and frustrated

[Tony Lam]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

* "Norbert" == Norbert Koch <n.koch@eai-delta.de> writes:

Norbert> In message <yc0hfnxprwg.fsf@whitestar.daimi.au.dk>,
Norbert> nospam2159+ding@daimi.au.dk (Peter von der Ahé - at home) wrote:

>> To illustrate what the problem, please try doing the following:
>> 
>> (setq gnus-large-newsgroup 2)
>> 
>> in .gnus.el
>> 
>> Create a new nnml group with G m, copy 3 messages to this group.
>> Mark them all as read.  Delete the article with number 2.  Exit the
>> group.  Enter the group.  You will now be asked how many articles you
>> want to see, even though there only is 2 articles in the group.  This
>> can be very annoying when you have larges mail groups with gaps.

Norbert> Well, after recognising this problem, you could mark all
Norbert> articles and respool them (B r). This should ease the
Norbert> trouble, shouldn't it?

Not if the group has cached articles.

Tony

Re: Being forced to deal with message numbers and frustrated

[David Hedbor]

Norbert Koch <n.koch@eai-delta.de> writes:

> In message <yc0hfnxprwg.fsf@whitestar.daimi.au.dk>,
> nospam2159+ding@daimi.au.dk (Peter von der Ahé - at home) wrote:
> 
> > To illustrate what the problem, please try doing the following:
> > 
> > (setq gnus-large-newsgroup 2)
> > 
> > in .gnus.el
> > 
> > Create a new nnml group with G m, copy 3 messages to this group.
> > Mark them all as read.  Delete the article with number 2.  Exit the
> > group.  Enter the group.  You will now be asked how many articles you
> > want to see, even though there only is 2 articles in the group.  This
> > can be very annoying when you have larges mail groups with gaps.
> 
> Well, after recognising this problem, you could mark all articles and
> respool them (B r). This should ease the trouble, shouldn't it?

It's rather a large and slow job when you have 40 MB of saved mails in 
some 70 different nnml groups. 

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
What if everything is an illusion and nothing exists?  In that case, I
definitely overpaid for my carpet.
		-- Woody Allen, "Without Feathers"

Re: Being forced to deal with message numbers and frustrated

[Matt Pharr]

David Hedbor <david@hedbor.org> writes:
> Norbert Koch <n.koch@eai-delta.de> writes:
> > Well, after recognising this problem, you could mark all articles and
> > respool them (B r). This should ease the trouble, shouldn't it?
> 
> It's rather a large and slow job when you have 40 MB of saved mails in 
> some 70 different nnml groups. 

Here is some code that automatically goes through all nnml:mail.* groups
and do this.  (Based on code I use to move old mail from nnml to nnfolder
groups.  Bits of this could probably be written in a more properly gnus-y
way, but it seems to work well as is.  elisp coding style feedback happily
received.)

(defun mmp:crunch-nnml-article-ranges ()
  (interactive)
  (let ((newsrc (cdr gnus-newsrc-alist))
	group)
    (while newsrc
      (setq group (gnus-info-group (car newsrc)))
      (if (and (string-match "^nnml:mail.*" group)
	       (gnus-group-read-group 9999999 t group))
	  (gnus-atomic-progn
	    (gnus-uu-mark-buffer)
	    (if (> (- (point-max) (point-min)) 0)
                (gnus-summary-move-article nil group))
	    (gnus-summary-exit)))
      (setq newsrc (cdr newsrc)))))

-matt
-- 
Matt Pharr                                   mmp@graphics.stanford.edu
<URL:http://graphics.stanford.edu/~mmp>

Re: Being forced to deal with message numbers and frustrated

[Tony Lam]

* "Matt" == Matt Pharr <mmp@Graphics.Stanford.EDU> writes:

Matt> Here is some code that automatically goes through all
Matt> nnml:mail.* groups and do this.

This is very handy!

One minor thing I noticed is that if you do any re-ordering of
messages in summary buffer, i.e. threading, sort by score,
etc, you may want turn them off before moving the messages. This is to
make sure when you tell Gnus to fetch last N messages, it gets the
last N most recently arrived messages, not the last N messages in
summary display.

To achieve this, I'll set gnus-show-threads, gnus-select-group-hook to
nil before calling gnus-group-read-group.

Regards,

Tony

Re: Being forced to deal with message numbers and frustrated

[Lee Willis]

nospam2159+ding@daimi.au.dk (Peter von der Ahé - at home) writes:

> Create a new nnml group with G m, copy 3 messages to this group.
> Mark them all as read.  Delete the article with number 2.  Exit the
> group.  Enter the group.  You will now be asked how many articles you
> want to see, even though there only is 2 articles in the group.  This
> can be very annoying when you have larges mail groups with gaps.

Why is it *very* annoying. So you have to hit C-u RET RET.  I'd hardly
call that vastly inconvenient ...

> Further more, AFAIK[1], Gnus will consider all messages from the
> lowest available number to the highest.  So if you have a group with a
> article numbered 1 and the next is numbered 1002, Gnus will have to do
> something for 1000 article in between, this may not be much, but will
> amount to a hill of beans in the long run.  So for efficiency it would
> be perfectly sane to provide some kind of renumbering function.

Hmm, I agree with this, and I can see your point but Gnus *does have* a
renumbering function. Enter the group you wish to renumber with C-u RET
(And a further RET if you're prompted). The do the following

M P b
B m name-of-group RET  and all your problems should be solved (Unless of
course you have cached articles which you shouldn't in mail groups
anyway ...)

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

Re: Being forced to deal with message numbers and frustrated

[Tony Lam]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

* "Lee" == Lee Willis <lee@gbdirect.co.uk> writes:

Lee> nospam2159+ding@daimi.au.dk (Peter von der Ahé - at home) writes:
>> Create a new nnml group with G m, copy 3 messages to this group.
>> Mark them all as read.  Delete the article with number 2.  Exit the
>> group.  Enter the group.  You will now be asked how many articles you
>> want to see, even though there only is 2 articles in the group.  This
>> can be very annoying when you have larges mail groups with gaps.

Lee> Why is it *very* annoying. So you have to hit C-u RET RET.  I'd hardly
Lee> call that vastly inconvenient ...

The problem is also being that the number of articles fetched could be
far off when there are large gaps in numbers. It becomes worse in
virtual group :-<. To me, it *is* very annoying.

>> Further more, AFAIK[1], Gnus will consider all messages from the
>> lowest available number to the highest.  So if you have a group with a
>> article numbered 1 and the next is numbered 1002, Gnus will have to do
>> something for 1000 article in between, this may not be much, but will
>> amount to a hill of beans in the long run.  So for efficiency it would
>> be perfectly sane to provide some kind of renumbering function.

Lee> Hmm, I agree with this, and I can see your point but Gnus *does
Lee> have* a renumbering function. Enter the group you wish to
Lee> renumber with C-u RET (And a further RET if you're prompted). The
Lee> do the following

Lee> M P b
Lee> B m name-of-group RET  and all your problems should be solved (Unless of
Lee> course you have cached articles which you shouldn't in mail groups
Lee> anyway ...)

It does *not* work with groups which have cached articles.

Regards,

Tony

Re: Being forced to deal with message numbers and frustrated

[Per Abrahamsen]

Tony Lam <Tony.Lam+ding@Eng.Sun.COM> writes:

> I use passive cache to archive messages in the same group in mail and
> news because ticked messages can be expired, at least in newsgroups,
> and I want one consistent operation for both mail and groups. Besides,
> I use tick to mark messages that need to be replied later.

Maybe Gnus should interpret the `cache' mark on mail groups as "do not
expire, even if the rules otherwise say expire", instead of making a
copy of the message?

Hmm...  On the other hand, a cache *might* make sense for the imap
backend

Re: Being forced to deal with message numbers and frustrated

[Sam Falkner]

Since I use caching on mail groups, I'll throw in my usage habits just
for the record.  I'm not saying it's the one true way, or the best
way, or even unique, but it's what I currently like to do.

Two reasons I'm doing this: (1) maybe someone else will get an idea
that they like from it, and (2) I'd hate for the semantics to change
such that I couldn't do what I like.  I don't think (2) is likely, but 
it's my fault if I didn't speak up.

                                * * *

I use topics, and occasionally set parameters on both groups and
topics via `G p'.  I set total-expire to be non-nil at the top of my
mail hierarchy.

Under mail I have a `reference' topic, and in this topic, I set
`total-expire' to nil, and set `expiry-wait' to something like a year.
I set `visible' to non-nil, since these groups never get newly
arriving mail, so they almost never have unread messages.  Normally,
the reference topic is unexpanded, except when I want to go looking
for something.

When reading mail, and I see a message I want to keep, I have two ways
I can do it, depending on how I'll try to find it.

If the mail got auto-split into a special group, I use `*' to throw it
into the cache.  This is just like I do for NNTP news, and these are
the mail groups that I don't distinguish at all from news.  Yes, there
are initially two copies of the same message, but one will eventually
expire and the other won't.

If the message to be kept landed in my `misc' folder, I move it (via
`B m') into one of the groups in my `reference' topic.  For example,
our cafeteria at work announces their holiday schedule for the rest of
the year.  So I throw it into my `work.policy' folder (or whatever).
Since it has a limited lifespan, I can also mark it `E' before I move
it there, and it'll last for a year.

                                * * *

I like this scheme.  My only gripe about caching (I've mentioned
before) is that when I change NNTP servers, I have to deal with my
cached articles manually.  Usually, I move the cache directories aside
and ignore it for a while; then, renumber the files in the cache
directory to be 1-n (compact; unlikely to clash with existing message
numbers), move the directories into place, and rebuild the cache
active and nov files.  Since I don't change NNTP servers very often, I
don't mind too much that this is inconvenient.  But with mail, I have
no complaints at all.

- Sam

Re: Being forced to deal with message numbers and frustrated

[Sam Falkner]

Argh, I've never read the info page for `article caching', the one
that explains `gnus-use-cache'.  I read the first sentence, and since
I don't have a slow NNTP connection, I skipped the rest of the page.

I'll modify my usage habits to use `?' for archiving, and caching only
for NNTP, since `?' won't expire with `gnus-use-cache'.

Thanks everyone!

- Sam

Re: Being forced to deal with message numbers and frustrated

[Kai.Grossjohann]

Tony Lam <Tony.Lam+ding@eng.sun.com> writes:

  > * "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
  > 
  > Rat> Why are you caching mail messages?  There is no sane reason to do
  > Rat> more than 'tick' with `u' so as to prevent articles from being
  > Rat> expired.
  > 
  > I use passive cache to archive messages in the same group in mail and
  > news because ticked messages can be expired, at least in newsgroups,
  > and I want one consistent operation for both mail and groups. Besides,
  > I use tick to mark messages that need to be replied later.

Hm.  With active caching gnus-uncacheable-groups, you can just hit !
or ? on a message, and Gnus will DTRT in both news and mail groups.

You could use ! for messages that you need to work on and ? for
messages that you just want to keep.  (Or, if you don't use
total-expire, you could bite the bullet and acknowledge that news is
different from mail and mark the mails you want to keep as read rather
than dormant ("?").)

kai
-- 
Life is hard and then you die.

Re: Being forced to deal with message numbers and frustrated

[Kai.Grossjohann]

Tony Lam <Tony.Lam+ding@eng.sun.com> writes:

  >   * Number gap in cached messages can not be removed. When a messages
  >     group (I use nnfolder) has cached articles, I find
  >     respooling/moving/copying messages in the group do not touch
  >     cached articles, also cache groups do not support moving/copy
  >     themselves, thus there is no way to get rid of those huge gaps in
  >     message numbers within Gnus.

That's a valid point.  But why do you cache messages in nnfolder
groups?  All you need to do to keep the messages is not to mark them
as expirable (or as read if you use total-expire).

Do you really want these messages on your disk twice?

See the variable gnus-uncacheable-groups to prevent caching for mail
groups. 

kai
-- 
Life is hard and then you die.

Re: Being forced to deal with message numbers and frustrated

[Tony Lam]

* "kai" == Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

kai> That's a valid point.  But why do you cache messages in nnfolder
kai> groups?  All you need to do to keep the messages is not to mark
kai> them as expirable (or as read if you use total-expire).

The only consistent way to archive articles in place with mails and
news is to use "*" to cache them.

kai> Do you really want these messages on your disk twice?

Initially yes, there will be two copies, but one will be soon
expired. To me, consistent interface is more important than disk space
used for a few duplicated messages.

kai> See the variable gnus-uncacheable-groups to prevent caching for
kai> mail groups.

Tapping "*" on the article ignores this variable as well as
gnus-use-cache thus unconditionally stores the article in cache.

The only workaround is to settle down for two interfaces for archiving
in mails and news: '?' for nnfolder group and '*' for nntp group
(passive caching) and keep reminding myself which backend I'm using.

Regards,

Tony

Re: Being forced to deal with message numbers and frustrated

[David S. Goldberg]

> The only consistent way to archive articles in place with mails and
> news is to use "*" to cache them.

Would it not be consistent if you used `?' to archive instead of `*'?

> The only workaround is to settle down for two interfaces for
> archiving in mails and news: '?' for nnfolder group and '*' for nntp
> group (passive caching) and keep reminding myself which backend I'm
> using.

I set gnus-use-cache to t and have gnus-uncacheable-groups set to
"^nnml".  I use then use `?' to archive for both mail and news.  I
barely notice the extra `*' on summary lines for archived nntp
messages.
-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: Being forced to deal with message numbers and frustrated

[Kai.Grossjohann]

Tony Lam <Tony.Lam+ding@Eng.Sun.COM> writes:

  > * "kai" == Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
  > 
  > kai> That's a valid point.  But why do you cache messages in nnfolder
  > kai> groups?  All you need to do to keep the messages is not to mark
  > kai> them as expirable (or as read if you use total-expire).
  > 
  > The only consistent way to archive articles in place with mails and
  > news is to use "*" to cache them.

I don't understand.  Why don't you set gnus-use-cache to t, set
gnus-uncacheable-groups to something matching all mail groups and then
use either "!" or "?" to archive messages ("!" if you always want to
see them, "?" if not)?

kai
-- 
Abort this operation?   [OK]  [Cancel]

Re: Being forced to deal with message numbers and frustrated

[Tony Lam]

* "kai" == Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

kai> I don't understand.  Why don't you set gnus-use-cache to t, set
kai> gnus-uncacheable-groups to something matching all mail groups and
kai> then use either "!" or "?" to archive messages ("!" if you always
kai> want to see them, "?" if not)?

You're right, this is a better solution. I'll change my message
marking habit and use it. Thanks for the help.

Regards,

Tony

Re: Being forced to deal with message numbers and frustrated

[Soeren Laursen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

Tony Lam <Tony.Lam+ding@Eng.Sun.COM> writes:

> * "kai" == Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
> 
> kai> I don't understand.  Why don't you set gnus-use-cache to t, set
> kai> gnus-uncacheable-groups to something matching all mail groups and
> kai> then use either "!" or "?" to archive messages ("!" if you always
> kai> want to see them, "?" if not)?
> 
> You're right, this is a better solution. I'll change my message
> marking habit and use it. Thanks for the help.

I think it would be nice if the manual covered more of this stuff.
There are many, many ways of using Gnus but some ways make a lot more
sense that others.

-- 
Søren Laursen http://www.tele.auc.dk/~slau/

Re: Being forced to deal with message numbers and frustrated

[Lars Magne Ingebrigtsen]

Tony Lam <Tony.Lam+ding@Eng.Sun.COM> writes:

>     When I tell Gnus to read read 300 messages from foo.v, does Gnus
>     read 100 from each component group or just read the 300 messages
>     with highest number from the virtual group? 

There's clever code in nnvirtual.el (by David Moore) that tries to
distribute the component articles uniformly over the, er, virtual
space.  Or something.

To take an example:  If there are 100 articles in group a, 100
articles in group b, and 200 articles in group c, the component
articles are spread kinda like this in the virtual group space:

a.1
c.1
b.1
c.2
a.2
c.3
b.2
c.4
...

So when you request the newest 200 articles from a virtual group, you
will get the 300 last article numbers in this sequence, which will
contain 50 articles from group a, 50 articles from group b, and 100
articles from group c.

I think David must be a matematician or something.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances [deleting mail]

[Per Bothner]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Per Bothner <per@bothner.com> writes:
> > * In general, the Gnus defaults for mail are quite clumsy.
> > For example, there should be a single command to delete (make
> > expirable) messages and move to the next.  I ended up doing:
> 
> Use `E' for that.

'E' does not move to the next message.  It also requires a shift.

The most common command when reading mail is "delete this message
and go to the next one".  This *has* to be a single-key command,
not requiring any key modifiers.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: some mail annoyances [deleting mail]

[Jack Twilley]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

    Per> 'E' does not move to the next message.  It also requires a
    Per> shift.

    Per> The most common command when reading mail is "delete this
    Per> message and go to the next one".  This *has* to be a
    Per> single-key command, not requiring any key modifiers.

I've read maybe six thousand email messages over the past eighteen
months, and not once have I used a command that would delete the
current message and go on to the next message.

Sure, I'll mark the most recent message read and go on.  I could even
set things up such that all read messages get deleted when I exit the
group, which would have the effect you desire.

But I don't.  I like mail.  I save it.  I let it gracefully expire if
necessary and archive it as I desire.

I see no need for this command.  Others may, but I'd never hit it.
Please save my keys for more useful commands.

Jack.
(one with gnus?)
-- 
Jack Twilley
jmt at nycap dot rr dot com
http colon slash slash jmt dot dhs dot org slash tilde jmt slash

Re: some mail annoyances [deleting mail]

[Karl Kleinpaste]

Per Bothner <per@bothner.com> writes:
>> 'E' does not move to the next message.  It also requires a shift.

Personally, I find swapping the binding of `e' and `E' very useful.  I
think these two keys are backward, given likelihood of usage of each.

The only MUA I've ever seen which does "delete and show next message"
is Berkeley Mail's "dp" command.  And even that requires *3*
keystrokes, because (being ttyline-oriented) a RET is also needed.

>> The most common command when reading mail is "delete this
>> message and go to the next one".  This *has* to be a
>> single-key command, not requiring any key modifiers.

I don't understand your definition of "most common."  For example,
what's the standard VM binding for this desired function?

Jack Twilley <jmt+usenet@nycap.rr.com> writes:
> I see no need for this command.  Others may, but I'd never hit it.
> Please save my keys for more useful commands.

I'm with Jack on this.  I understand what Per wants to accomplish, but 
consider it so trivial as to be not worth establishing a new default
keybinding for it.  Per is of course free to define a function of his
own to do so, and to bind it to some preferred key.  Personally, I
don't *want* automatic selection of messages, *ever*.  This is why I
set...
      gnus-auto-select-first nil
      gnus-auto-select-next 'quietly
      gnus-auto-select-same t

--karl

Re: some mail annoyances [deleting mail]

[Per Abrahamsen]

Per Bothner <per@bothner.com> writes:

> 'E' does not move to the next message.  

It does when I type it.

> The most common command when reading mail is "delete this message
> and go to the next one".

Not when using Gnus.  In Gnus, as in any decent newsreader, the most
common command is "show next page of this message, or if at the last
page, show first page of the next message and mark it read, or if we
are at the last message, show the first message of the next group and
mark it read, or if we are at the last group, exit to the group list".
It happens to be bound to the biggest key on the keyboard.  Expiring
messages are handled by the news server, or by Gnus setting one of the
"expire" group parameters.

It is correct that the traditional mail reader usage is different, but
if you are using Gnus as you use traditional mail readers, you aren't
using it as it was designed to be used.

Either you adopt the "mail is news" way of thinking, or you will have
to fight Gnus all the way.

Re: some mail annoyances [deleting mail]

[Jaap-Henk Hoepman]

On 22 Jun 1999 21:15:06 +0200 Per Abrahamsen <abraham@dina.kvl.dk> writes:
> Per Bothner <per@bothner.com> writes:
> 
> > 'E' does not move to the next message.  
> 
> It does when I type it.
> 
> > The most common command when reading mail is "delete this message
> > and go to the next one".
> 
> Not when using Gnus.  In Gnus, as in any decent newsreader, the most
> common command is "show next page of this message, or if at the last
> page, show first page of the next message and mark it read, or if we
> are at the last message, show the first message of the next group and
> mark it read, or if we are at the last group, exit to the group list".
> It happens to be bound to the biggest key on the keyboard.  Expiring
> messages are handled by the news server, or by Gnus setting one of the
> "expire" group parameters.

But if you do not want to auto-expire certain groups (like I do not like to
auto-expire my inbox), then I agree with Per that the most common command when
reading mail is (generalizing slightly :-)
        "do something with this message and go to the next one"
where in gnus, do-something is either a mark of some kind, or moving the
article. Moving does go to the next unread message; marking does not. It would
be nice if all mark commands had a twin that moves to the next or previous
(un)read article (I think Kai mentioned this a few days ago), or a variable
gnus-mark-commands-should-move with possible values 
        nil, forward, forward-unread, backward, backward-unread

Jaap-Henk

P.S.: Did posting styles change? Yesterday I configured it for pgnus 0.84
and it worked fine, then I upgraded to pgnus 0.88 (to fix the X-Face problem)
and now it doesn't work anymore...

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: some mail annoyances [deleting mail]

[Yair Friedman]

Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

> 
> But if you do not want to auto-expire certain groups (like I do not like to
> auto-expire my inbox), then I agree with Per that the most common command when
> reading mail is (generalizing slightly :-)
>         "do something with this message and go to the next one"
> where in gnus, do-something is either a mark of some kind, or moving the
> article.

You can put auto-expire in the Group parameters of high traffic groups.
--
Yair Friedman.

Re: some mail annoyances [deleting mail]

[Kai.Grossjohann]

Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

  > where in gnus, do-something is either a mark of some kind, or moving the
  > article. Moving does go to the next unread message; marking does not.

By default, marking commands go to the next unread message.  Thus,
something in your setup must be hosed.  (Or is this a bug in some
pgnus versions?)

kai
-- 
Life is hard and then you die.

Re: some mail annoyances [deleting mail]

[Randal L. Schwartz]

>>>>> "Jaap-Henk" == Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

Jaap-Henk> But if you do not want to auto-expire certain groups (like
Jaap-Henk> I do not like to auto-expire my inbox), then I agree with
Jaap-Henk> Per that the most common command when reading mail is
Jaap-Henk> (generalizing slightly :-) "do something with this message
Jaap-Henk> and go to the next one" where in gnus, do-something is
Jaap-Henk> either a mark of some kind, or moving the article. Moving
Jaap-Henk> does go to the next unread message; marking does not. It
Jaap-Henk> would be nice if all mark commands had a twin that moves to
Jaap-Henk> the next or previous (un)read article (I think Kai
Jaap-Henk> mentioned this a few days ago), or a variable
Jaap-Henk> gnus-mark-commands-should-move with possible values nil,
Jaap-Henk> forward, forward-unread, backward, backward-unread

Jaap-Henk> Jaap-Henk

Still running qgnus, here's what I do:

(defun MERLYN-gnus-expiry-wait-function (ng)
  "give list.clip a short wait, other lists 7 days, and others marked E 1"
  (cond ((string-match "^list\\.clip" ng) 1)
	((string-match "^list" ng) 7)
	(t 1)))
(setq
 nnmail-expiry-wait-function 'MERLYN-gnus-expiry-wait-function
 gnus-total-expirable-newsgroups "^nnml:list\\."
 )

And I bring all my mailing lists into nnml:list.ding, nnml:list.p5p,
etc, where the default is to toss seen articles after 7 days.  Other
mail groups are expire only when I ask for it.

Then it's very visual to me that I can just page forward like a
newsgroup in anything called "list.", but I need to hit "E" in
anything that isn't.  Occasionally, I get it backwards. It does no
harm to hit E in a list.* group, but I can sometimes lose from view
things in my inbox (not a list.*), so I use ^U = occasionally.

This has worked quite well for the two years I've been doing it.

Hopefully, the names of these functions have not changed in terry gnus.
(Which I'm still threatening to switch to Very Soon Now.)

-- 
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

Re: some mail annoyances [deleting mail]

[Nathan Williams]

Per Bothner <per@bothner.com> writes:

> The most common command when reading mail is "delete this message
> and go to the next one".  This *has* to be a single-key command,
> not requiring any key modifiers.

        Several people have already mentioned the tactic of having
Gnus (1) automatically mark read messages as expired and (2) remove
expired messages quickly or immediately (upon exiting the group). This
is what I do (with values of "quickly" ranging from "immediate" for
certain highly-topical groups to a couple of weeks for personal
mail). It sounds like this satisfies your constraints. Is there
something wrong with it, other than the use of the term "expire"
instead of "delete"?

        - Nathan

Re: some mail annoyances [deleting mail]

[Per Bothner]

Nathan Williams <nwilliams@primeon.com> writes:
>         Several people have already mentioned the tactic of having
> Gnus (1) automatically mark read messages as expired and (2) remove
> expired messages quickly or immediately (upon exiting the group).

This is too extreme.  I want to have to type a "real" key (but
only a single key) to delete a message.  Typing just enter or
space and having that delete/expire the message is too dangerous.

However, "auto-tick" like Kai Grossjohann suggested may be a
reasonable option.  I don't recall seeing this in the manual
or FAQ, but of course being Emacs, I can program it ...  But
if someone has code for it, I'll try it.

[By the way - the name of my "husband" who I set up to
use VM, is also Nathan Williams.]
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com     http://home.pacbell.net/bothner/

Re: some mail annoyances [deleting mail]

[Kai.Grossjohann]

Per Bothner <per@bothner.com> writes:

  > Per Abrahamsen <abraham@dina.kvl.dk> writes:
  > 
  > > Per Bothner <per@bothner.com> writes:
  > > > * In general, the Gnus defaults for mail are quite clumsy.
  > > > For example, there should be a single command to delete (make
  > > > expirable) messages and move to the next.  I ended up doing:
  > > 
  > > Use `E' for that.
  > 
  > 'E' does not move to the next message.  It also requires a shift.

`E' moves to the next message or to the next unread message, depending
on the value of gnus-summary-goto-unread.

  > The most common command when reading mail is "delete this message
  > and go to the next one".  This *has* to be a single-key command,
  > not requiring any key modifiers.

You're right.  I have the following in ~/.gnus:

(define-key gnus-summary-mode-map (kbd "d") 'gnus-summary-mark-as-expirable)

Maybe it is necessary to put (require 'gnus-sum) before this.  Marking
as read is still available as `M r', but marking as expirable also
works in news groups.

FWIW, I also have:

  (define-key gnus-summary-mode-map (kbd "C-d")
    (function (lambda () (interactive)
                (gnus-summary-mark-as-read))))

which clobbers C-d, so I put that somewhere else:

  (define-key gnus-summary-article-map "D" 'gnus-summary-enter-digest-group)

Entering a digest now works with `A D'.

Just my EUR 0.02.

kai
-- 
Life is hard and then you die.

Re: some mail annoyances [deleting mail]

[Yair Friedman]

Per Bothner <per@bothner.com> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> > 
> > Use `E' for that.
> 
> 'E' does not move to the next message.  It also requires a shift.

Use auto-expire then. No keys needed at all.
--
Yair Friedman.

Re: some mail annoyances [deleting mail]

[Lars Magne Ingebrigtsen]

Per Bothner <per@bothner.com> writes:

> 'E' does not move to the next message.

This depends on the setting of `gnus-summary-goto-unread'.  

> The most common command when reading mail is "delete this message
> and go to the next one".  This *has* to be a single-key command,
> not requiring any key modifiers.

The most common command in a mail reader is "delete and go to the next
one", but I do not think that this is what should be the most common
command.  I think the most common command should be "mark message as
read and go to the next article", which is conveniently bound to `d',
and happens with `SPC', `N', `P', `n', `p' and a gazillion other
commands.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[David S. Goldberg]

> Per Bothner <per@bothner.com> writes:
>> * If in the Summary group, I do M-g in my mail group to check for
>> new mail, after new mail is read, point does to the *following*
>> group.  That's silly default; point should stay at the group I just
>> got more mail for.

>>>>> Per Abrahamsen writes:
> Not if you want to fetch new messages for several groups, I do that
> often for foreign nntp groups.

Setting gnus-goto-next-group-when-activating to nil doesn't prevent me
from doing that and I still get the behavior I (and I think Per
Bothner) want when doing M-g on top of a group line.
-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: some mail annoyances

[Dmitry Yaitskov]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:

<snip-snip>
> > * Bottom line:  Gnus is not usable as a mail reader for non-hacker
> > types.  There are just too many options, there is no introductory
> > manual, and the defaults are non-intuitive.  Even setting it up
> > so it suitable for non-hackers is difficult.  I ended up setting
> > up my boyfriend to use VM.  He is not 100% happy with VM, but
> > I don't see how gnus could be an option.  That is a shame.
> 
> VM is an excellent mail reader, and in itself a good reason why Gnus
> should keep working like a news reader.  If you want a mail reader
> that works according to normal mail reader conventions, VM is there.
> However, if you really want to treat your mailbox as a newsspool, Gnus
> is the answer.

I for example want a something that reads both mail and news, does it
well, and is more or less intuitive for both. I do not spend all that
much time reading either, and would much rather learn one good program
than two. Besides, news and mail are very closely related, so using
one prog for both seems natural. Hence I think making gnus as
intuitive as possible for both is "a good thing".

> > * In there any commend to re-number the messages in a mail folder?
> > I'm used to mhe, which would re-use numbers on expired messages,
> > and when teh numbers approaches 10000, I would run an mh command
> > to renumber the entire folder.  Yes, this is an esthetic issue,
> > not really important ...
> 
> 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.

Whereas I do not have a strong opinion about renumbering the messages, 
I honestly don't see how the impossibility of renumbering usenet
messages is relevant to the option of renumbering mail messages in
one's own folder. (And besides, somebody's already posted that it *is* 
possible). E.g. you can't delete (B del) a real news article, whereas
you certainly can do that to a mail message. So what?

-- 
Cheers,
-Dima.

Re: some mail annoyances

[Per Abrahamsen]

Dmitry Yaitskov <dimas@home.com> writes:

> I for example want a something that reads both mail and news, does it
> well, and is more or less intuitive for both. I do not spend all that
> much time reading either, and would much rather learn one good program
> than two. 

I spend much time on both, and Gnus is definitely optimized for the my
kind.  With the amount of mail I get, the traditional news reading
paradigm[1] simply works far better than mail the traditional mail
reading paradigm.

> Besides, news and mail are very closely related, so using one prog
> for both seems natural.

Having different paradigms for mail and news groups removes much of
the benefit from having a single program.

> Hence I think making gnus as intuitive as possible for both is "a
> good thing".

It was never a design goal to implement the traditional mail reading
paradigm in Gnus (which is what people mean by "intuitive").  While
you _can_ set it up to be used that way, it will be a fight.  I
strongly recommend either using a tool that was designed for that
purpose, or even better, start using Gnus as it was designed.  The
news readign paradigm _is_ very powerful, and you will not have to
switch paradigm each time you switch between mail and news groups any
more.

> Whereas I do not have a strong opinion about renumbering the messages, 
> I honestly don't see how the impossibility of renumbering usenet
> messages is relevant to the option of renumbering mail messages in
> one's own folder.

Again, it is about how you think about the messages, not about the
particular feature.  If you think about the numbers as something you
should be concerned about, then you think the wrong way.  Gnus is
designed to make the numbers irrelevant, because it is designed for
news where you can't change them.

Yes, there are backend specific features.  What I'm talking about is
the underlying model.

Footnotes: 
[1]  Sorry for using that word, but I can't find a better word for
"the model of thinking about the messages."

Re: some mail annoyances

[Kai.Grossjohann]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

  > It was never a design goal to implement the traditional mail
  > reading paradigm in Gnus (which is what people mean by
  > "intuitive").  While you _can_ set it up to be used that way, it
  > will be a fight.

It will?  With gnus-mark-article-hook, users can configure exactly
what they want to happen when a message is read.  I don't perceive
this to be a fight.  Maybe some more user experience is needed with
this kind of setup in Gnus.

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Dmitry Yaitskov]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:

<snip>
> Having different paradigms for mail and news groups removes much of
> the benefit from having a single program.

For me at least, there are a lot of benefits even if I do treat mail
and news differently. E.g. I do not have to remember different sets of
keystrokes for getting in and out of folders, etc. This may sound
stupid, but is a big advantage for me. Another example is, I read mail
and news in Russian. I had to customize just one program for this, not
two. Etc. None of this has to do with models, yet are big advantages
for me. I am just trying to make a point that it is not necessary to
treat mail and news in exactly the same way to benefit from having a
single program.

But of course, there are other things that *do* have to do with
paradigms, e.g. message threadig in mailing lists like this one. So
you're probably right, that it is better to treat both the same.

> > Hence I think making gnus as intuitive as possible for both is "a
> > good thing".
> 
> It was never a design goal to implement the traditional mail reading
> paradigm in Gnus (which is what people mean by "intuitive").  While
> you _can_ set it up to be used that way, it will be a fight.  I
> strongly recommend either using a tool that was designed for that
> purpose, or even better, start using Gnus as it was designed.  The
> news readign paradigm _is_ very powerful, and you will not have to
> switch paradigm each time you switch between mail and news groups any
> more.

Would be very interesting (for me at least) to learn how different
people use gnus for mail, how they deal with saving, expiring, etc.

> > Whereas I do not have a strong opinion about renumbering the messages, 
> > I honestly don't see how the impossibility of renumbering usenet
> > messages is relevant to the option of renumbering mail messages in
> > one's own folder.
> 
> Again, it is about how you think about the messages, not about the
> particular feature.  If you think about the numbers as something you
> should be concerned about, then you think the wrong way.  Gnus is
> designed to make the numbers irrelevant, because it is designed for
> news where you can't change them.

BTW. What happens when the article numbers *do* overflow? They are
bound to overflow eventually, aren't they?

-- 
Cheers,
-Dima.

Re: some mail annoyances [article number overflow]

[Karl Kleinpaste]

Dmitry Yaitskov <dimas@home.com> writes:
> BTW. What happens when the article numbers *do* overflow? They are
> bound to overflow eventually, aren't they?

This will become an interesting question if and only if you have a
mail folder which has received at least 10,000,000,000 messages.

That is, the question is not interesting.  Typical news servers, such
as INN, use 10-digit article numbers, which means they won't overflow
until they go past 9,999,999,999.  On my 3-year old INN server, even
the "control.cancel" and "junk" groups are numbered only into the
mid-ten-million range.

Re: some mail annoyances [article number overflow]

[Colin Rafferty]

Karl Kleinpaste writes:
> Dmitry Yaitskov <dimas@home.com> writes:

>> BTW. What happens when the article numbers *do* overflow? They are
>> bound to overflow eventually, aren't they?

> This will become an interesting question if and only if you have a
> mail folder which has received at least 10,000,000,000 messages.

You are being too kind to XEmacs.

most-positive-fixnum
=> 1073741823

Of course, if you move to a 64-bit XEmacs before you hit a Gig, there
shouldn't be a problem.

-- 
Colin

Re: some mail annoyances [article number overflow]

[Karl Kleinpaste]

Colin Rafferty <craffert@ms.com> writes:
> You are being too kind to XEmacs.
> => 1073741823

Fair enough.  But I still contend that the Gnus mail group which has
chewed through a billion messages doesn't exist.

Re: some mail annoyances

[David S. Goldberg]

> I switched to pgnus not too long ago [...]

>From an earlier version of gnus?  If so, you've been living with this
badness for way too long.  Most of the suggestions below have been in
my .emacs since red gnus, maybe even as far back as September.

> * If in the Summary group, I do M-g in my mail group to check for
> new mail, after new mail is read, point does to the *following*
> group.  That's silly default; point should stay at the group I just
> got more mail for.

(setq gnus-goto-next-group-when-activating nil)

fixes this to dtrt.

> * If I enter a group, point normally goes to the first unread
> message.  But if (say) there is only a single new message, that
> message becomes the last line in the window, while point goes to the
> *middle* of the window.  When the list of ticked messages is long,
> it starts showing the first old message, rather than the first new
> message.

I think you want (setq gnus-auto-center-summary nil) though I'm not
sure the (IMHO bad) behavior this setting fixed for me is the same as
what you're seeing.
-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: some mail annoyances

[Steinar Bang]

>>>>> Per Bothner <per@bothner.com>:

[snip!]
> * In general, the Gnus defaults for mail are quite clumsy.
[snip!]
> * In there any commend to re-number the messages in a mail folder?
[snip!]

The major thing to remember with Gnus, is to let old habits from
earlier mail programs go, and just go with the flow and read your mail 
like it was news.

You don't want to renumber messages in a mail folder.  You don't even
want to *know* the number of a message, anymore that you want to know
the message number of a USENET message on a particular server.

What I do is use total-expiry, and set up the expiry time to four weeks 
for the mailgroups that see most traffic.  Then I just either
 - read articles and let them go
 - mark them as read with "d"
 - tick them with "u"
 - mark them dormant with "?"

In the case of the first two, the article will reside in the mail
group for four weeks and then quietly go away.  In the case of the
latter two the articles will never go away.

This lets me process mail more efficiently than earlier, because my
experience is that *if* I will need a message for later, this is most
likely to occur within the next four weeks.

Now all I need is to get Kai's search engine backend (nnir.el) up and
running...:-)

Re: some mail annoyances

[Vin Shelton]

>>>>> On 22 Jun 1999 16:33:35 +0200, Steinar Bang <sb@metis.no> said:

Steinar> What I do is use total-expiry, and set up the expiry time to four weeks 
Steinar> for the mailgroups that see most traffic.  Then I just either
Steinar>  - read articles and let them go
Steinar>  - mark them as read with "d"
Steinar>  - tick them with "u"
Steinar>  - mark them dormant with "?"

Steinar> In the case of the first two, the article will reside in the mail
Steinar> group for four weeks and then quietly go away.  In the case of the
Steinar> latter two the articles will never go away.


OK, based on yesterday's advice, I'm now trying out expiry.  Just to
be absolutely clear: I'm using auto-expiry and when I want to preserve 
an article and keep it from being reaped by the expiry process, I'm
using 'd'.  Does this preserve the article, or will it magically
disappear after the expiry time has lapsed, even though the 'E' mark
has gone away.

(Still trying to get used to this weird new mail-reading paradigm.)

vin shelton
-- 
In a minute there is time
For decisions and revisions which a minute will reverse.         T.S. Eliot

Re: some mail annoyances

[Kai.Grossjohann]

Vin Shelton <acs@xemacs.org> writes:

  > [...] Just to be absolutely clear: I'm using auto-expiry and when
  > I want to preserve an article and keep it from being reaped by the
  > expiry process, I'm using 'd'.  Does this preserve the article, or
  > will it magically disappear after the expiry time has lapsed, even
  > though the 'E' mark has gone away. [...]

This will preserve the article.  No articles will be deleted unless it
fulfills at least one of the following two criteria:

(1) It is marked `E'.
(2) Total-expire is turned on for the group and the article is marked
    as read (`r' or `R' or `O').

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Jaap-Henk Hoepman]

On 22 Jun 1999 12:43:11 -0400 Vin Shelton <acs@xemacs.org> writes:
> OK, based on yesterday's advice, I'm now trying out expiry.  Just to
> be absolutely clear: I'm using auto-expiry and when I want to preserve 
> an article and keep it from being reaped by the expiry process, I'm
> using 'd'.  Does this preserve the article, or will it magically
> disappear after the expiry time has lapsed, even though the 'E' mark
> has gone away.

That's exactly what I did: I've set all expirable mail to expire immediately
when exiting a group
        (setq nnmail-expiry-wait 'immediate)
For some groups (mailinglists like ding for instance), I've set the group
parameters to
        ((auto-expire . t))
such that all articles are marked expirable when I read them. Marking them read 
with `d' unmarks them expirable: when I leave the group and enter again these
articles are still there and marked as old `O'.

To make sure that I do not expire articles that I would like to keep after
reading them, I have made sure that all expirable articles are highlighted
(using the same face as deleted articles) as a clearly visible cue that these
articles will be deleted when I exit the group. For this I added the following
to my .gnus.el
        (load "gnus-sum.elc")
        (setq gnus-summary-highlight
          (cons '((= mark gnus-expirable-mark) . gnus-summary-cancelled-face) 
                gnus-summary-highlight)
        )
Note the loading of gnus-sum.elc before prepending the necessary face
to gnus-summary-highlight. If omitted, gnus complains about 
gnus-summary-highlight not being defined and will not start up.

Jaap-Henk


-- 
Jaap-Henk Hoepman, Computer Scientist     |  Sure! We've eaten off the silver
Email: jhh@xs4all.nl, Tel: +31 50 5255546 |  (when even food was against us)
WWW: http://www.xs4all.nl/~jhh            |         - Nick Cave

Re: some mail annoyances

[Wes Hardaker]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

>>>>> On 21 Jun 1999 17:36:24 -0700, Per Bothner <per@bothner.com> said:

Per> More generally, for mail the natural classification is old
Per> messages, new messages, and deleted messages.  Once I have
Per> deleted a message, I normally don't want to see it.  However, I
Per> would like to be able to see old messages.  If I do plain space
Per> in the Group buffer, I only see new and ticked messages.  But if
Per> I do ^U-space I get *all* the messages, including the expired
Per> ones.  This means that to get what I consider normal behavior (as
Per> in most other MUAs) I must take one of two acrtions for each new
Per> message: Either tick it if I want to save it, or delete it (make
Per> expireable) otherwise.  Sometimes I forget.  This is not very
Per> friendly.

If you want this now, I'll include a patch I've been using for a few
years now that allows you to set the "display" group parameter to
"not-expired", so that it will show you old messages.  This is
essentially what you want.  I've always wanted to be able to make the
display parameter accept a string, something like "O !", which would
be translated into old, new, and ticked, or even better "-E" which
would be the same as not-expired.  However, the hack I put in place
didn't work quickly and I didn't have time to mess with it much more.
Lars didn't want to accept the not-expired patch as is.

...


[-- Attachment #2: pgnus-patch --]
[-- Type: application/x-patch, Size: 3905 bytes --]

[-- Attachment #3: Type: text/plain, Size: 81 bytes --]

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

Re: some mail annoyances

[Per Bothner]

Thanks for the various reponses in this thread.  I have gotten work-arounds
for some of the annoyances, and I will see how they work out.  I think
various people have made many of the points I would make.  However, let
me make one last point (for now): 

Some have made the point that it is wrong to think of Gnus as a mail-reader
- it is a news reader that is also great for reading mail.  Trying to
force Gnus into the mold of a mail reader violates its "philosophy".
That may be the case, but it is wrong philosophy for general users.
For almost everybody, mail is much more important than news.  Everybody
uses mail, but far from everybody uses news.  Also, people *start* out
dealing with email, and then maybe later they get to reading news.
People depend on mail;  almost no-one depends on news.

Thus it is more important to get mail "right" than it is to get news
right.  What is the "right" interface will of course differ from person
to person, which is why it is nice to be able to customize things.
It would be nice if there was a "recommended" mail program, which
is powerful, flexible - *and* easy to learn (including having a good
introductory manual).  Gnus *could* be that recommended mailer for
everybody using Emacs.  It is very close - it just needs a little bit
of usability engineering, some tweaking of the defaults, and some
better documentation  It certainly has the power and flexibility.
However, the defaults are a bit unnatural, the standard keybindings
are optimized for news rather than mail, and there is no good
introduction to using Gnus.  (The latter should *start* by explaining
how to use it for mail, since that is what people need *first*.)
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://home.pacbell.net/bothner/

Re: some mail annoyances

[Christian Nybø]

Per Bothner <per@bothner.com> writes:

[...]
> Gnus *could* be that recommended mailer for everybody using Emacs.
> It is very close - it just needs a little bit of usability
> engineering, some tweaking of the defaults, and some better
> documentation It certainly has the power and flexibility.  However,
> the defaults are a bit unnatural, the standard keybindings are
> optimized for news rather than mail, and there is no good
> introduction to using Gnus.  (The latter should *start* by
> explaining how to use it for mail, since that is what people need
> *first*.)

Where do you see VM in that picture?
-- 
chr

Re: some mail annoyances

[Ken McGlothlen]

s911254@stud.nhh.no (Christian Nybø) writes:

| Per Bothner <per@bothner.com> writes:
| 
| [...]
| > Gnus *could* be that recommended mailer for everybody using Emacs.  It is
| > very close - it just needs a little bit of usability engineering, some
| > tweaking of the defaults, and some better documentation It certainly has
| > the power and flexibility.  However, the defaults are a bit unnatural, the
| > standard keybindings are optimized for news rather than mail, and there is
| > no good introduction to using Gnus.  (The latter should *start* by
| > explaining how to use it for mail, since that is what people need *first*.)
| 
| Where do you see VM in that picture?

Well, this is just one guy's perspective.  Please pardon the narrative form.

When I first started using something besides /usr/bin/mail to read my mail and
/usr/local/bin/rn to read my news, I chose Emacs, my favorite editor (at that
time, somewhere in either late v17 or early v18), and used RMAIL and Masanobu
Umeda's GNUS (which at the time, of course, had no mail-reading capabilities).

The shortcomings of RMAIL have been covered extensively elsewhere.  I hated it,
wanted to get back to using something that respected the mbox format, and
finally discovered VM.  GNUS, on the other hand, I loved, and made a lot of
customizations that made it even cooler for me to use.  Except for that one
sticky point:  Umeda-san had basically walked away from it, guaranteeing no
further development.

You can imagine how relieved and delighted I was when Lars announced he was
going to take over development.  If memory serves, I think I wrote him a
thank-you note when I heard about it.

And then Lars pointed out that he wanted to make GNUS handle email as well.
Zowie, I thought---VM is a nice enough package (and as you can see from the
headers, I still use it, at v6.72), but it has some limitations that rather
annoy me.  The thought of using a package that would thread my email, and one I
didn't have to remember different strokes to, was very, very cool.

It hasn't worked out that way.  I've tried converting to Gnus on several
occasions, but never with any good success.

For example, a few months ago, I unexpectedly wound up being CEO of a small,
troubled ISP.  I was suddenly receiving a LOT of email (this from a guy who's
signed up not only to ding@gnus.org, but questions@freebsd.org) that I
absolutely had to keep organized.  The best way I could think of was to bite
the bullet and use Gnus, but needed some quick guidance.  I wrote Lars, if
memory serves (those first few weeks were a blur), who gave me sound advice,
but I couldn't get it working effectively in a short enough amount of time, and
wound up using PINE.  Ulk.

As I said, I'm still using VM, not GNUS.  Why?

Well, lessee.  I have over 400 mail folders comprising over 100MB of email, all
in mbox format.  I need to conveniently transfer messages between folders (I do
occasionally reorganize folders).  I do use procmail, but only use it to break
out mailing list from personal mail---if I were to use GNUS, I'd like to
shuttle it all into appropriate folders, but don't know how to do it in some
cases.  (For example, mail from userA to me should go in the userA folder, but
mail from userA to me *and* userB, userC, userD and userE should go in the
groupZ folder.)  The deletion/expiration stuff can be a bit confusing; I've
lost mail on occasion when trying to convert over.  And it's not a matter of
just having tried once; I've tried six times to move from VM to Gnus, letting
my incoming mail pile up over a couple of days while I try to figure out how to
get Gnus to work well, but eventually giving up and going back to VM when I run
out of spare time, or when the mail pile gets too huge.

There needs to be a "So you use an mbox-style mail reader, and would like to
use Gnus?" document somewhere, for example.  I'd be happy to write it,
even---I'm articulate, after all (well, I think so, at any rate), but I haven't
been able to get it working smoothly enough to convert myself.

If someone wants to help me work through this process, I'll be more than happy
to write up said document.

							---Ken

Re: some mail annoyances

[Harry Putnam]

-----8< snip

> Well, lessee.  I have over 400 mail folders comprising over 100MB of
> email, all in mbox format.  I need to conveniently transfer messages
> between folders (I do occasionally reorganize folders).  I do use
> procmail, but only use it to break out mailing list from personal
> mail---if I were to use GNUS, I'd like to shuttle it all into
> appropriate folders, but don't know how to do it in some cases.
> (For example, mail from userA to me should go in the userA folder,
> but mail from userA to me *and* userB, userC, userD and userE should
> go in the groupZ folder.)  The deletion/expiration stuff can be a
> bit confusing;

A small point here, about splitting:  I believe gnus "fancy splitting"
can handle that setup, but if you are already familiar with procmail,
then why not use procmail to do the more complicated splitting.
Procamil can easily handle the problem you present because you can
list as many conditions as you like in a  single rule.  Gnus can be
made to slurp from procmail created spools, putting the messages into
similarly named gnus groups.

The deletion expiration stuff is a bit confusing but becomes less so
if you kind of forget deletion as an option, like you would on an nntp
group.  Think of deletion as something taken care of by a "higher
power" and you just guide its hand as to when with your expiry.

Not quite that simple, but as I understand it, if you leave gnus in
default settings then nothing in mail gets expired unless you
explicitly mark it for expiry with an "E"  and then only in about 7
days when the "higher power" kicks in.

Taking a word of advice from Karl K. I've switched the bindings of "E"
(gnus-summary-mark-as-expirabl) and "e"  (gnus-summary-edit-article)
Since expiring is much more common function for me.  That makes it
easier to mark as `expirable', since no <SHIFT> is needed

Re: some mail annoyances

[Ken McGlothlen]

reader@newsguy.com (Harry Putnam) writes (in response to a missive by me):

| > (For example, mail from userA to me should go in the userA folder, but mail
| > from userA to me *and* userB, userC, userD and userE should go in the
| > groupZ folder.)
| 
| A small point here, about splitting:  I believe gnus "fancy splitting" can
| handle that setup, but if you are already familiar with procmail, then why
| not use procmail to do the more complicated splitting.  Procamil can easily
| handle the problem you present because you can list as many conditions as you
| like in a single rule.

Hm.  True.  That wasn't the case when I first started using procmail, and I
rarely have use for that feature, so I'd forgotten.  But yes, okay.

| The deletion expiration stuff is a bit confusing but becomes less so if you
| kind of forget deletion as an option, like you would on an nntp group.  Think
| of deletion as something taken care of by a "higher power" and you just guide
| its hand as to when with your expiry.

Actually, I've noticed that one of the things that confuses people the most is
that messages "disappear" once they've been read.  Which is why I say that some
article needs to be written that addresses it for people new to Gnus.

| Taking a word of advice from Karl K. I've switched the bindings of "E"
| (gnus-summary-mark-as-expirabl) and "e" (gnus-summary-edit-article) Since
| expiring is much more common function for me.  That makes it easier to mark
| as `expirable', since no <SHIFT> is needed

That's an excellent idea; I wonder why that isn't the default.

Re: some mail annoyances

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Ken McGlothlen <mcglk@serv.net>  on Fri, 25 Jun 1999
| That's an excellent idea; I wonder why that isn't the default.

Because for most of us, manually marking articles expirable is the less-
common pastime.  We follow the newsreaderly approach to reading mail, that
messages marked as read will be expunged automatically as if we were
reading from a news server unless we explicitly say otherwise (tick).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3dByNgl+vIlSVSNkRAnQJAKCqwB8dGvZOqI8vIRUY5lzhfyZpagCgqqgB
xldI52sJaO+rw9Kub9uDfmE=
=VABV
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 

Re: some mail annoyances

[Harry Putnam]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Ken McGlothlen <mcglk@serv.net>  on Fri, 25 Jun 1999
> | That's an excellent idea; I wonder why that isn't the default.
> 
> Because for most of us, manually marking articles expirable is the less-
> common pastime.  We follow the newsreaderly approach to reading mail, that
> messages marked as read will be expunged automatically as if we were
> reading from a news server unless we explicitly say otherwise (tick).

Just my own habits, but I find myself wanting to keep more than half
of my mail so ticking would be more time consuming than marking the
ones I don't  want with "E".  But I'll admit I am a little leary of
either auto or total expire.  Heres why:

More than once I've had the experience of loosing lots of saved
messages when using "total expire".  If for one reason or another a
group gets all articles marked as unread (M-c) and you do a catchup to
get back to something more reasonable, with out taking into account
the repercussions, then all ticked or dormant articles (now unticked
and undormanted) that are older than expiry-days are history.

If I stick to defaults and expunge by hand, and something occurs to
mark a group as unread, erasing marks, then nothing is lost to expiry,
when catching up.  

In any event, pretending that reading mail is the same as reading news
has to stop at the fact that no amount of ticking will save an nntp
article from expiry. Hence the persistent mark, so why continue to act
as if mail and news are the same.  Several posters have pointed out
that persistent marks in nnml or "mail" groups makes no sense.  Why?
Because it is not a newsgroup, nor is it news.  It is not handled by
gnus as if it were news either.

Nntp posts will be expunged (expired) regardless of your marks, even
unread. Gnus knows this.  Not so in mail, whatever your settings. Gnus
also knows this, and offers several ways to handle mail.  So while
there may be some confusion amongst gnus users about mail and news
being different, Gnus itself understands a fundamental difference.

Consequently gnus offers quite a wide variety of functions to deal
with the difference between news and mail.

Re: some mail annoyances

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Harry Putnam <reader@newsguy.com>  on Fri, 25 Jun 1999
| Just my own habits, but I find myself wanting to keep more than half
| of my mail so ticking would be more time consuming than marking the
| ones I don't  want with "E".

You are obviously not on moderate to high volume mailing lists :).

Of course, if you unmark all your ticked/dormant articles then catch up,
those articles are ripe for expiry.  About all I can say to that is, "don't 
do that."  Maybe you have a good reason for it, but I generally do not see
the rational behind unmarking an entire group.

Then again, rsync is my friend.  It should be your's, too.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3dDrhgl+vIlSVSNkRAjuLAJ46EneF3Zia9sA1LEblQp0hZLEpmQCeLdUU
yintvdvUqn6wBWZAJ3PCbLc=
=tu1Y
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.

Re: some mail annoyances

[Harry Putnam]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Harry Putnam <reader@newsguy.com>  on Fri, 25 Jun 1999
> | Just my own habits, but I find myself wanting to keep more than half
> | of my mail so ticking would be more time consuming than marking the
> | ones I don't  want with "E".
> 
> You are obviously not on moderate to high volume mailing lists :).

Maybe not, but Redhat lists, or "ding" for that matter, are not
considered "quiet" by most.
> 
> Of course, if you unmark all your ticked/dormant articles then catch up,
> those articles are ripe for expiry.  About all I can say to that is, "don't 
> do that."  Maybe you have a good reason for it, but I generally do not see
> the rational behind unmarking an entire group.

You must have noticed at one time or another that M-c is rather close
to M-x.

> Then again, rsync is my friend.  It should be your's, too.

I did recently start tinkering with rsync, and just in the last few
day have written and implemented an elementary backup script using
"tar" for $HOME and /etc., so may get a little braver with total expire. 

Re: some mail annoyances

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Harry Putnam <reader@newsguy.com>  on Fri, 25 Jun 1999
| Maybe not, but Redhat lists, or "ding" for that matter, are not
| considered "quiet" by most.

*shrug*

Some of the lists I am on average 150 messages a day.  The 10-15 on ding is 
negligible to me.

| You must have noticed at one time or another that M-c is rather close
| to M-x.

In my summary buffer, M-c is bound to capitalize-region-or-word.  Are you
sure you did not change the binding yourself?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3difsgl+vIlSVSNkRAtWqAKDs/8ZX4LxPFFZVRLkq8t8npEUk9wCg1q8z
tqS9DFwcaYO7cGjqpxH67Dw=
=sZK/
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball contains a liquid core,
Minion of Nathan - Nathan says Hi! \ which, if exposed due to rupture, should
PGP Key: at a key server near you!  \ not be touched, inhaled, or looked at.

Re: some mail annoyances

[Harry Putnam]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Harry Putnam <reader@newsguy.com>  on Fri, 25 Jun 1999
> | Maybe not, but Redhat lists, or "ding" for that matter, are not
> | considered "quiet" by most.
> 
> *shrug*
> 
> Some of the lists I am on average 150 messages a day.  The 10-15 on ding is 
> negligible to me.

Is 10-15 really accurate... seems I see as many as 80 or so during
MIME rushes : )


> | You must have noticed at one time or another that M-c is rather close
> | to M-x.
> 
> In my summary buffer, M-c is bound to capitalize-region-or-word.  Are you
> sure you did not change the binding yourself?

How do you go about capitalizing a region or word in the Summary
buffer anyway?  : )  Mine is read only

In my defautl (fsf) setup M(read ALT)-c doesn't seem to be bound to
anything in the summary buffer.  And the summary buffer has never
caused a problem.  Try "group" buffer.  On my keyboard ALT-c is right
next to Alt-x.  And Alt(M)-c removes all marks from a group.  It can
happen other ways too.  One I've posted about in the past is under
certain circumstances when calling the agent `unplugged' marks can be
removed.  Not sure of the exact circumstances, but have had it happen
more than once.

Re: some mail annoyances

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Harry Putnam <reader@newsguy.com>  on Sun, 27 Jun 1999
| Is 10-15 really accurate... seems I see as many as 80 or so during
| MIME rushes : )

I got 30 in the past 24 hours or so, which is only 10% of the ~300 non-work 
messages I just downloaded.

[...]
| How do you go about capitalizing a region or word in the Summary
| buffer anyway?  : )  Mine is read only

Yep, but that is the default binding.

| In my defautl (fsf) setup M(read ALT)-c doesn't seem to be bound to
| anything in the summary buffer.  And the summary buffer has never caused
| a problem.  Try "group" buffer.

Owch!  Okay.  Memo to myself: that is BAD.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.8 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3eAitgl+vIlSVSNkRAnOBAJsG075cRIO4R0nVWoq6/U8LSxbdxgCg3pdh
mJ6vf6PcoZH4F+ooYC0KDPQ=
=drDJ
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Caution: Happy Fun Ball may suddenly
Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds.
PGP Key: at a key server near you!  \ 

Re: some mail annoyances

[Kai.Grossjohann]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

  > * Harry Putnam <reader@newsguy.com>  on Fri, 25 Jun 1999
  > 
  > | You must have noticed at one time or another that M-c is rather close
  > | to M-x.
  > 
  > In my summary buffer, M-c is bound to capitalize-region-or-word.
  > Are you sure you did not change the binding yourself?

I think Harry was talking about `M c' and `M x', both of which are
bound to useful functions in the summary buffer, and it is a bit, err,
surprising, if one hits `M c' when `M x' was intended :-)

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> 
>   > * Harry Putnam <reader@newsguy.com>  on Fri, 25 Jun 1999
>   > 
>   > | You must have noticed at one time or another that M-c is rather close
>   > | to M-x.
>   > 
>   > In my summary buffer, M-c is bound to capitalize-region-or-word.
>   > Are you sure you did not change the binding yourself?
> 
> I think Harry was talking about `M c' and `M x', both of which are
> bound to useful functions in the summary buffer, and it is a bit, err,
> surprising, if one hits `M c' when `M x' was intended :-)

I see where you would think that, given the default binding for `M c'
and `M x' .  I never used those bindings or even knew about them
before.

My comments were about "META-c" and META-x in group buffer.

Imagine you start to say `M-x apropos <RET>' but hit `M-c' first
instead.  Oops all marks are erased from the entire group.

Re: some mail annoyances

[Kai.Grossjohann]

Harry Putnam <reader@newsguy.com> writes:

  > Imagine you start to say `M-x apropos <RET>' but hit `M-c' first
  > instead.  Oops all marks are erased from the entire group.

When I hit M-c, Emacs beeps.

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
>   > Imagine you start to say `M-x apropos <RET>' but hit `M-c' first
>   > instead.  Oops all marks are erased from the entire group.
> 
> When I hit M-c, Emacs beeps.

Must be something peculiar in my term or keyboard settings.
In group buffer look at `C-h w <gnus-group-clear-data><RET>'

Mine shows `M-c'

But when going at it a different way: (In group buffer) C-h m shows
`ESC c'=gnus-group-clear-data

Far as I can tell I have no init or site files that say anything about
a binding for M-c, so am assuming it is default setting.

Re: some mail annoyances

[Kai.Grossjohann]

Harry Putnam <reader@newsguy.com> writes:

  > Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
  > 
  > > Harry Putnam <reader@newsguy.com> writes:
  > > 
  > >   > Imagine you start to say `M-x apropos <RET>' but hit `M-c' first
  > >   > instead.  Oops all marks are erased from the entire group.
  > > 
  > > When I hit M-c, Emacs beeps.
  > 
  > Must be something peculiar in my term or keyboard settings.
  > In group buffer look at `C-h w <gnus-group-clear-data><RET>'

Oh, you are talking about the Group buffer!  Sorry, I was talking
about the Summary buffer.

Right -- M-c is a dangerous key in the Group buffer.  Though I've
never accidentally hit it -- until just now, I didn't even know it
exists.

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Kai.Grossjohann]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

  > * Harry Putnam <reader@newsguy.com>  on Fri, 25 Jun 1999
  > | Just my own habits, but I find myself wanting to keep more than half
  > | of my mail so ticking would be more time consuming than marking the
  > | ones I don't  want with "E".
  > 
  > You are obviously not on moderate to high volume mailing lists :).

I think there are different kinds of mail: news-like mail (from
mailing lists, for instance) and personal mail.  I treat them
differently: news-like mail gets deleted (well, expired) by default
unless I explicitly say otherwise, whereas personal mail is kept by
default.

Do you do this differently?

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Kai.Grossjohann@CS.Uni-Dortmund.DE  on Sat, 26 Jun 1999
| Do you do this differently?

Yes.  I keep only the mail that for whatever reason I want to keep.  Such
mail is always ticked and frequently moved to 'archive' groups.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3dihWgl+vIlSVSNkRAvSYAKDnCo+XuvRxi+Z45gxd0KCdsxLF4ACeLwjl
3fj8NRbxNfip1OM+Au8SrFg=
=DfcM
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 

Re: some mail annoyances

[Kim-Minh Kaplan]

Stainless Steel Rat writes:

> * Ken McGlothlen <mcglk@serv.net>  on Fri, 25 Jun 1999
> | That's an excellent idea; I wonder why that isn't the default.
> 
> [...] We follow the newsreaderly approach to reading mail, that messages
> marked as read will be expunged automatically [...]

But this is not the default either.

Kim-Minh.

Re: some mail annoyances

[Per Abrahamsen]

Ken McGlothlen <mcglk@serv.net> writes:

> reader@newsguy.com (Harry Putnam) writes (in response to a missive by me):
>
> | Taking a word of advice from Karl K. I've switched the bindings of "E"
> | (gnus-summary-mark-as-expirabl) and "e" (gnus-summary-edit-article) Since
> | expiring is much more common function for me.  That makes it easier to mark
> | as `expirable', since no <SHIFT> is needed
> 
> That's an excellent idea; I wonder why that isn't the default.

I never press `E'.  I use total-expire on "low interest mailing
lists", and never delete private mail.  Why should I?  After 10+ years
I have ~300Mb in my mail archive, which I believe is around $20 worth
of disc space.  I don't think $20 is a high price for the ability to
track my online correspondance back 10 years.

I do press `e' occationally, to remove big attachments.

Re: some mail annoyances

[Karl Kleinpaste]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> I never press `E'.  I use total-expire on "low interest mailing
> lists", and never delete private mail.  

I'm of a similar mind.  nnml:personal.* never disappear.  Once a year
or so, I shovel a great deal of mail to nnml:archive.y1998.<some name>
with `B m'.  nnml:list.* usually have total-expiry set, with the
proviso that certain mailing lists where a somewhat long-term memory
is important have expiry-wait set to some large value.  nnml:list.ding
is set this way, with a 45-day delay.  I also have some weird ones
(such as nnml:tomb, where bad mail [spam] goes to die) that have
immediate total-expiry.

> Why should I?  After 10+ years I have ~300Mb in my mail archive,
> which I believe is around $20 worth of disc space.  I don't think
> $20 is a high price for the ability to track my online
> correspondance back 10 years.

Yup.  I've been using Gnus as a mailer since 1988 or so, back when it
was GNUS 2.10 and I'd done some really rather rude hackery to symlink
an nnspool configuration into my need for a mail-as-news viewpoint,
using too much external shell script hackery for delivery and
deletion, because my elisp skill wasn't adequate to the task at the
time.  Kai's nnir.el is a wondrously good thing for me.

--karl

Re: some mail annoyances

[Wes Hardaker]

>>>>> On 28 Jun 1999 11:37:01 -0400, Karl Kleinpaste <karl@justresearch.com> said:

>> I never press `E'.  I use total-expire on "low interest mailing
>> lists", and never delete private mail.  

Karl> I'm of a similar mind.  nnml:personal.* never disappear.

Man...  How long does it take you to enter groups?

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

Re: some mail annoyances

[Karl Kleinpaste]

Karl Kleinpaste <karl@justresearch.com> said:
>> nnml:personal.* never disappear.

Wes Hardaker <wjhardaker@ucdavis.edu> writes:
> Man...  How long does it take you to enter groups?

Not long.  "ls -1 Mail/personal/general | wc" says I have 916 messages
in nnml:personal.general right now.  Remember, though, that I said I
send mail approx'ly annually into e.g. nnml:archive.y<YEAR>.<ORIGINAL
GROUP NAME> in large groups of #-marked `B m' invocations.

Group entry time is not bad at all -- just a second or two, during
normal entry when I have a few new messages to read.

Re: some mail annoyances

[Russ Allbery]

Per Bothner <per@bothner.com> writes:

> Gnus *could* be that recommended mailer for everybody using Emacs.  It
> is very close - it just needs a little bit of usability engineering,
> some tweaking of the defaults, and some better documentation It
> certainly has the power and flexibility.  However, the defaults are a
> bit unnatural, the standard keybindings are optimized for news rather
> than mail, and there is no good introduction to using Gnus.  (The latter
> should *start* by explaining how to use it for mail, since that is what
> people need *first*.)

For what it's worth, everyone I've converted to Gnus I've converted by
introducing them to Gnus for news and then over time pointing out that the
news interface is a lot better for handling mail too than the mail reader
they're currently using and eventually getting them to use Gnus for mail
as well.

That's the transition path I followed myself.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: some mail annoyances

[Per Abrahamsen]

Two points:

- There are many mail readers imlementing the traditional mail reading
model for reading mail.  Some of them, like VM, are very good.  Gnus
is to my knowledge the only mail reader which directly supports the
news reading model for reading mail.  I think it would be wrong to
change the unique Gnus to be just another good mail reader.

- For real beginners in mail reading (if there are any of them left)
there are no reason why they shouldn't learn the news reading model
for reading mail first.  I don't think the traditional mail reading
model is inherently any more intuitive than the news reading model, it
is just more familiar to people who have used other mail readers.

A "Beginners Guide for Reading Mail with Gnus" might be a good
addition to the manual.  The guide shouldn't describe all the options,
but only how to read mail the Gnus way.

Re: some mail annoyances

[Didier Verna]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> A "Beginners Guide for Reading Mail with Gnus" might be a good
> addition to the manual.

        No. A readable manual might be a good addition to the manual :-)
Actually, the current manual is more like a reference manual with parts of
what should be the user manual splited everywhere.

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /     ENST, INFRES C201.1       mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   +33 (1) 45 81 73 46
                       75013 Paris, France      Fax.   +33 (1) 45 81 31 19

Re: some mail annoyances

[Karl Kleinpaste]

Didier Verna <verna@inf.enst.fr> writes:
> Actually, the current manual is more like a reference manual with parts of

Lars has made this observation a number of times, probably because
documentation about Gnus goes into it directly as a function of code
development, not as an analysis of what a user needs to do.  A genuine
users' manual, reflecting thought on how to get along with Gnus in a
general sense, would surely be a great improvement.

Re: some mail annoyances

[Karl Kleinpaste]

By the way...

> To: Per Abrahamsen <abraham@dina.kvl.dk>
> Cc: ding@gnus.org

If you will add
        (to-address . "ding@gnus.org")
to your group properties for your ding mail group, then when you
followup, you'll generate only
        To: ding@gnus.org
which will happily avoid sending extraneous copies to people who will
see your comments on the list itself anyway.

--karl

customizing (was Re: some mail annoyances)

[Paul Stevenson]

Karl Kleinpaste <karl@justresearch.com> writes:

> If you will add
>         (to-address . "ding@gnus.org")
> to your group properties for your ding mail group, then when you
> followup, you'll generate only
>         To: ding@gnus.org
> which will happily avoid sending extraneous copies to people who will
> see your comments on the list itself anyway.

 Ah, great (I can see its magic at work right now), thanks. 

 When setting this, though, via G c (customize group) I was presented
with lots of things I could customize, but before I could read any of
the long descriptions of the variables (by clicking [more]) I had to
activate the variable first (by clicking the [ ] at the left) before I
could read about it.  I think it would be better to be able to read
about all the variables anyway regardless of whether you have activated
them.  What think ye all?

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

This was a useful discussion, and I've now summarized the points for a 
new node in the manual -- "Mail in a Newsreader".

I'll just include it here; please do suggest changes that will make
things clearer, since this is a quite important subject.


Mail in a Newsreader
--------------------

   If you are used to traditional mail readers, but have decided to
switch to reading mail with Gnus, you may find yourself experiencing
something of a culture shock.

   Gnus does not behave like traditional mail readers.  If you want to
make it behave that way, you can, but it's an uphill battle.

   Gnus, by default, handles all its group using the same approach.
This approach is very newsreaderly--you enter a group, see the
new/unread messages, and when you read the messages, they get marked as
read, and you don't see them any more.  (Unless you explicitly ask for
them.)

   In particular, you do not do anything explicitly to delete messages.

   Does this mean that all the messages that have been marked as read
are deleted?  How awful!

   But, no, it means that old messages are "expired" according to some
scheme or other.  For news messages, the expire process is controlled by
the news administrator; for mail, the expire process is controlled by
you.  The expire process for mail is covered in depth in *note Expiring
Mail::..

   What many Gnus users find, after using it a while for both news and
mail, is that the transport becomes more and more irrelevant.  What
becomes important is the size of the receiving audience.

   Many people subscribe to several mailing lists.  These are
transported via SMTP, and are therefore mail.  Some people have local
news groups which have only a handful of readers.  These are
transported via NNTP, and are therefore news.

   The important distinction turns out to be not the transport
mechanism, but whether the messages are "personal" or "public".  Many
users then subtly alter the behavior of Gnus according to these two
categories.

   Some users never get comfortable using the Gnus (ahem) paradigm and
wish that Gnus should grow up and be a male, er, mail reader.  It is
possible to whip Gnus into a more mailreaderly being, but, as said
before, it's not easy.  People who prefer proper mail readers should
try VM instead, which is an excellent, and proper, mail reader.

   I don't mean to scare anybody off, but I want to make it clear that
you may be required to learn a new way of thinking about messages.
After you've been subjected to The Gnus Way, you will come to love it.
I can guarantee it.  (At least the guy who sold me the Emacs Subliminal
Brain-Washing Functions that I've put into Gnus did guarantee it.  You
Will Be Assimilated.  You Love Gnus.  You Love The Gnus Mail Way.  You
Do.)


-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Harry Putnam]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>    What many Gnus users find, after using it a while for both news and
> mail, is that the transport becomes more and more irrelevant.  What
> becomes important is the size of the receiving audience.

But .... uhh  isn't the receiving audience always an audience of one...

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

Harry Putnam <reader@newsguy.com> writes:

> But .... uhh  isn't the receiving audience always an audience of one...

Many ones make an audience of "many", while one one makes an audience
of "one".  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Harry Putnam]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> > But .... uhh  isn't the receiving audience always an audience of one...
> 
> Many ones make an audience of "many", while one one makes an audience
> of "one".  :-)

Does this have anything to do with the sound of one hand clapping?

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

Harry Putnam <reader@newsguy.com> writes:

> > > But .... uhh  isn't the receiving audience always an audience of one...
> > 
> > Many ones make an audience of "many", while one one makes an audience
> > of "one".  :-)
> 
> Does this have anything to do with the sound of one hand clapping?

That depends on whom the audience it with.  An audience with a king,
for instance, sounds quite dissimilar from one hand clapping.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Harry Putnam]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> > > > But .... uhh  isn't the receiving audience always an audience of one...
> > > 
> > > Many ones make an audience of "many", while one one makes an audience
> > > of "one".  :-)
> > 
> > Does this have anything to do with the sound of one hand clapping?
> 
> That depends on whom the audience it with.  An audience with a king,
> for instance, sounds quite dissimilar from one hand clapping.

Might depend on what the king is the king of too.  An audience with
the king of hearts might be pretty quiet if you are holding the
queen,jack, 10, 9 of clubs.   : )

Re: some mail annoyances

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> That depends on whom the audience it with.  An audience with a king,
> for instance, sounds quite dissimilar from one hand clapping.

It's the sound of one note.

Re: some mail annoyances

[Kai.Grossjohann]

Harry Putnam <reader@newsguy.com> writes:

> But .... uhh  isn't the receiving audience always an audience of one...

The above sentence was received by all members of the Gnus mailing
list.  Which makes the audience a bit larger than one :-)

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> > But .... uhh  isn't the receiving audience always an audience of one...
> 
> The above sentence was received by all members of the Gnus mailing
> list.  Which makes the audience a bit larger than one :-)

It was supposed to be a light hearted, joking comment... next time I'll
remember to include the smiley.  : )

Lars comments are good though and do describe the way a persons usage
leans after using Gnus a while.  The part that will prove the most
usefull and descritive I think is the first few paras where he first
warns of a "Culture Shock" then proceeds to descibes what
"Newsreaderly" is.  At least some of the main things.

Re: some mail annoyances

[Kai.Grossjohann]

Harry Putnam <reader@newsguy.com> writes:

> It was supposed to be a light hearted, joking comment... next time I'll
> remember to include the smiley.  : )

Oh.  Hm.  It must've been the heat :-|  >30 degrees centigrade here
and high moisture.  (Being used to something like 15 or 20 degrees.)

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Hans de Graaff]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I'll just include it here; please do suggest changes that will make
> things clearer, since this is a quite important subject.

It's clear to me, but I would expect it to be clear to most people on
this list. What is needed here is some testing on unsuspecting users
who don't read mail with Gnus. Perhaps posting it in gnu.emacs.gnus
might get you some more useful feeedback.

>    Gnus, by default, handles all its group using the same approach.
                                            s
> This approach is very newsreaderly--you enter a group, see the
> new/unread messages, and when you read the messages, they get marked as
> read, and you don't see them any more.  (Unless you explicitly ask for
> them.)

>    I don't mean to scare anybody off, but I want to make it clear that
> you may be required to learn a new way of thinking about messages.
> After you've been subjected to The Gnus Way, you will come to love it.

If you won't trademark The Gnus Way(tm), I think I will.

Hans

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

Hans de Graaff <graaff@xs4all.nl> writes:

> If you won't trademark The Gnus Way(tm), I think I will.

:-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Kai.Grossjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>    Gnus does not behave like traditional mail readers.  If you want to
> make it behave that way, you can, but it's an uphill battle.

I think that a function which is like gnus-summary-mark-unread-as-read
except that it ticks articles rather than marking them as read is
useful for mail groups, and will go a long way to making Gnus behave
like traditional mail readers.  (Err, you also need to put this
function in gnus-mark-article-hook, of course.)

What else is needed?  Turning on total-expire?  Is that sufficient?

I think there is no harm done in providing a few convenience functions
and maybe a bit of advice (read: sample Lisp code) for people who wish
to do this, so that they can try it for a couple of months before
realizing that they didn't want this in the first place :-)

What do you think?

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> I think that a function which is like gnus-summary-mark-unread-as-read
> except that it ticks articles rather than marking them as read is
> useful for mail groups, and will go a long way to making Gnus behave
> like traditional mail readers.  (Err, you also need to put this
> function in gnus-mark-article-hook, of course.)
> 
> What else is needed?  Turning on total-expire?  Is that sufficient?

Well, don't people who want a Real Mail Reader want to explicitly
delete mail?  

> I think there is no harm done in providing a few convenience functions
> and maybe a bit of advice (read: sample Lisp code) for people who wish
> to do this, so that they can try it for a couple of months before
> realizing that they didn't want this in the first place :-)
> 
> What do you think?

Sounds like a good idea.  Want to write the section in the manual that 
discusses this?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Kai.Grossjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> 
> > I think that a function which is like gnus-summary-mark-unread-as-read
> > except that it ticks articles rather than marking them as read is
> > useful for mail groups, and will go a long way to making Gnus behave
> > like traditional mail readers.  (Err, you also need to put this
> > function in gnus-mark-article-hook, of course.)
> > 
> > What else is needed?  Turning on total-expire?  Is that sufficient?
> 
> Well, don't people who want a Real Mail Reader want to explicitly
> delete mail?  

Exactly.  Please note the function which is like
gnus-summary-mark-unread-as-read except that it ticks articles rather
than marking them as read.

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> > > What else is needed?  Turning on total-expire?  Is that sufficient?
> > 
> > Well, don't people who want a Real Mail Reader want to explicitly
> > delete mail?  
> 
> Exactly.  Please note the function which is like
> gnus-summary-mark-unread-as-read except that it ticks articles rather
> than marking them as read.

Yeah, but I meant "delete" as in `B DEL', not as in "mark as read and
then let expiry handle it".  Er.  But when you use total-expire,
there's not much of a difference, is there?  Never mind.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Jaap-Henk Hoepman]

On 04 Jul 1999 18:58:17 +0200 Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> >    Gnus does not behave like traditional mail readers.  If you want to
> > make it behave that way, you can, but it's an uphill battle.
> 
> I think that a function which is like gnus-summary-mark-unread-as-read
> except that it ticks articles rather than marking them as read is
> useful for mail groups, and will go a long way to making Gnus behave
> like traditional mail readers.  (Err, you also need to put this
> function in gnus-mark-article-hook, of course.)
> 
> What else is needed?  Turning on total-expire?  Is that sufficient?
> 
> I think there is no harm done in providing a few convenience functions
> and maybe a bit of advice (read: sample Lisp code) for people who wish
> to do this, so that they can try it for a couple of months before
> realizing that they didn't want this in the first place :-)
> 
> What do you think?

What I would really love to see is a group/topic parameter called, say,
group-type with two possible values 'mail-group and 'news-group. This parameter
would modify the behaviour of this group to be `like a newsgroup' (the default)
or `like a mail group'. The latter would ensure that

- all articles (read and unread) are visible (e.g. like (display . all))
- the first unread article is selected when opening
- the group is always visible (e.g. like (visible . t))
- replies are Gcc:-ed to the current group (gcc-self . t)
- will have auto-expire off (auto-expire . nil)
- will immediately expire all expirable articles (expiry-wait . immediate)
- all mark commands move to the next article, be it read or unread
        (the current default is to move to the next unread article)

and perhaps also

- set display to threaded mode

Just my opinion of course...

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

> What I would really love to see is a group/topic parameter called,
> say, group-type with two possible values 'mail-group and
> 'news-group.

This sounds workable...

> - all articles (read and unread) are visible (e.g. like (display . all))
> - the first unread article is selected when opening

This is the default, isn't it?

> - the group is always visible (e.g. like (visible . t))
> - replies are Gcc:-ed to the current group (gcc-self . t)
> - will have auto-expire off (auto-expire . nil)

Well, er, why?  auto-expire only makes sense in mail groups...

> - will immediately expire all expirable articles (expiry-wait . immediate)

I don't like that much.

> - all mark commands move to the next article, be it read or unread
>         (the current default is to move to the next unread article)
> - set display to threaded mode

But that's the default?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Jaap-Henk Hoepman]

On 06 Jul 1999 06:02:30 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:
> 
> > What I would really love to see is a group/topic parameter called,
> > say, group-type with two possible values 'mail-group and
> > 'news-group.
> 
> This sounds workable...
> 
> > - all articles (read and unread) are visible (e.g. like (display . all))
> > - the first unread article is selected when opening
> 
> This is the default, isn't it?

I believ so, yes.

> > - the group is always visible (e.g. like (visible . t))
> > - replies are Gcc:-ed to the current group (gcc-self . t)
> > - will have auto-expire off (auto-expire . nil)
> 
> Well, er, why?  auto-expire only makes sense in mail groups...

Well, see below. The `gnus way' of deleting articles is to mark them expirable
and to expire them later, right. So when using gnus to read mail, the only
quirk one needs to learn is that delete = mark expirable. To make this look as
much as an immediate delete, expiry-wait should be set to immediate. 

For mail, the default for a read article is _not_ to delete it (at least for
most mail readers it isn't :-); hence auto-expire should be nil. Deleting
(ie. expiring) should require explicit action by the (novice) user.

> 
> > - will immediately expire all expirable articles (expiry-wait . immediate)
> 
> I don't like that much.

Well, see above.

> 
> > - all mark commands move to the next article, be it read or unread
> >         (the current default is to move to the next unread article)
> > - set display to threaded mode
> 
> But that's the default?

Ah yes, I should have said:
- set display to threaded mode with subtrees hidden.

Perhaps it should be set up such that any change of a group/topic parameter
after setting group-type overrides the (implicit) setting of that parameter 
by group-type. E.g. to set expiry-wait to some other value.

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

> Well, see below. The `gnus way' of deleting articles is to mark them
> expirable and to expire them later, right. So when using gnus to
> read mail, the only quirk one needs to learn is that delete = mark
> expirable. To make this look as much as an immediate delete,
> expiry-wait should be set to immediate.

Right; I see.

> Ah yes, I should have said:
> - set display to threaded mode with subtrees hidden.

I don't think it's a good idea to "hide" stuff in a group buffer.  At
least not by semi-default.

> Perhaps it should be set up such that any change of a group/topic parameter
> after setting group-type overrides the (implicit) setting of that parameter 
> by group-type. E.g. to set expiry-wait to some other value.

Hm, yes.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Robert Bihlmeyer]

Hi,

>>>>> On 04 Jul 1999 18:58:17 +0200
>>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE said:

 Kai> I think that a function which is like
 Kai> gnus-summary-mark-unread-as-read except that it ticks articles
 Kai> rather than marking them as read is useful for mail groups, and
 Kai> will go a long way to making Gnus behave like traditional mail
 Kai> readers.

 Kai> What else is needed?

Changing the default of red for ticked articles to a less alerting
color.

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: some mail annoyances

[François Pinard]

Robert Bihlmeyer <e9426626@stud2.tuwien.ac.at> writes:

>  Kai> What else is needed?

> Changing the default of red for ticked articles to a less alerting
> color.

I've not much experience with ticked articles, but I just want to voice
that for me, the current color for them is appropriate.  So far!  When I
fall asleep on `SPC', these articles will be automatically skipped, despite
they need to be attended one of these days, so I like that Gnus tries to
keep me awake and alert.

And besides, there is little danger that the current color blends in the
surroundings because of too much color similarity. :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: some mail annoyances

[Robert Bihlmeyer]

Hi,

>>>>> On 05 Jul 1999 14:32:21 -0400
>>>>> François Pinard <pinard@iro.umontreal.ca> said:

 FP> Robert Bihlmeyer <e9426626@stud2.tuwien.ac.at> writes:

 FP> I've not much experience with ticked articles, but I just want to
 FP> voice that for me, the current color for them is appropriate.

Alerting Red is good for the normal ticked semantic ("something that
I have to work on in the future"), but no good for Kai's "old mail
gets ticked" scheme. IMHO, YMMV, etc.

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: some mail annoyances

[François Pinard]

Robert Bihlmeyer <e9426626@stud2.tuwien.ac.at> écrit:

> Alerting Red is good for the normal ticked semantic ("something that
> I have to work on in the future"), but no good for Kai's "old mail
> gets ticked" scheme.

So, you are saying that the default is OK for the normal semantics. :-)
I presume that all colours are customisable?

> IMHO, YMMV, etc.

I'm not an English speaker, so I do not have the genius for figuring
out all of those acronyms (yet I get some pleasure when I succeed :-).
I already know `IHMO', but `YMMV' is new to me.  What does it stand for? :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: some mail annoyances

[Lee Willis]

François Pinard <pinard@iro.umontreal.ca> writes:

> > IMHO, YMMV, etc.
> 
> I'm not an English speaker, so I do not have the genius for figuring
> out all of those acronyms (yet I get some pleasure when I succeed :-).
> I already know `IHMO', but `YMMV' is new to me.  What does it stand for? :-)

Your Mileage May Vary ...

HTH :)
Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

Re: some mail annoyances

[Robert Bihlmeyer]

Hi,

>>>>> On 07 Jul 1999 10:20:10 -0400
>>>>> François Pinard <pinard@iro.umontreal.ca> said:

 FP> So, you are saying that the default is OK for the normal
 FP> semantics. :-)

That's what I said the whole time.

But we were talking about a one-stop-solution (something like setting
a single variable) to modify the mail-handling to suit some peoples
expectations. This should change the default ticked color, too.

 FP> I already know `IHMO', but `YMMV' is new to me. What does it
 FP> stand for? :-)

"Your mileage may vary". See
<URL:http://www.tuxedo.org/~esr/jargon/html/entry/YMMV.html> for details.

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

Robert Bihlmeyer <e9426626@stud2.tuwien.ac.at> writes:

> Changing the default of red for ticked articles to a less alerting
> color.

Firebrickred doesn't seem all that scary to me...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Rob Browning]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> I think that a function which is like gnus-summary-mark-unread-as-read
> except that it ticks articles rather than marking them as read is
> useful for mail groups, and will go a long way to making Gnus behave
> like traditional mail readers.  (Err, you also need to put this
> function in gnus-mark-article-hook, of course.)

Would ticking or making them dormant be a better default if you're
going to do this?

I'd guess the latter since I'd imagine that the user wouldn't expect
read articles to show up in the summary buffer next time unless
explicitly requested.  Perhaps I'm not familiar enough with what other
MUAs do...

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: some mail annoyances

[Kai Großjohann]

Rob Browning <rlb@cs.utexas.edu> writes:

> I'd guess the latter since I'd imagine that the user wouldn't expect
> read articles to show up in the summary buffer next time unless
> explicitly requested.  Perhaps I'm not familiar enough with what other
> MUAs do...

My point was more that the user would expect to see *all* articles
(except the deleted ones).

Another way to achieve this (sort of) is to set the display group
parameter to all.  Hm.  Maybe setting expire wait to immediate and
setting display to all would be another viable alternative?

kai
-- 
Life is hard and then you die.

Re: some mail annoyances

[lconrad]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars>    What many Gnus users find, after using it a while for
    Lars> both news and mail, is that the transport becomes more and
    Lars> more irrelevant.  What becomes important is the size of the
    Lars> receiving audience.

    Lars>    Many people subscribe to several mailing lists.  These
    Lars> are transported via SMTP, and are therefore mail.  Some
    Lars> people have local news groups which have only a handful of
    Lars> readers.  These are transported via NNTP, and are therefore
    Lars> news.

    Lars>    The important distinction turns out to be not the
    Lars> transport mechanism, but whether the messages are "personal"
    Lars> or "public".  Many users then subtly alter the behavior of
    Lars> Gnus according to these two categories.

I think this needs some rewriting.  I'm sure we all know what you're
talking about, but a new gnus user who hasn't done any customizing
and doesn't even know what the customizing options are, needs a
different explanation.

My own take on this is that I expire mail that is really "news", that
is, someone else is in charge of archiving it somewhere else.  I also
make a distinction (in how readily I interrupt what I'm doing to read
the group) between groups which might contain discussion of an issue I
am immediately interested in and those which probably won't, which is
sometimes the same as the distinction between the groups where I
contribute and groups where I'm a "lurker".  I haven't actually done
any customizing of score files to automate this distinction, but the
thing I would most miss if I couldn't use gnus to read my mail is the
ability to read the different groups in their order of importance to me.

So here's a rewrite that might explain a little more to a new user:

    Laura> What many Gnus users find, after using it a while for
    Laura> both news and mail, is that the transport mechanism has
    Laura> very little to do with how they want to treat a message.  

    Laura> Many people subscribe to several mailing lists.  These are
    Laura> transported via SMTP, and are therefore mail.  But we might
    Laura> go for weeks without answering, or even reading these
    Laura> messages very carefully. We may not need to save them
    Laura> because if we should need to read one again, they are
    Laura> archived somewhere else.

    Laura> Some people have local news groups which have only a
    Laura> handful of readers.  These are transported via NNTP, and
    Laura> are therefore news.  But we may need to read and answer a
    Laura> large fraction of the messages very carefully in order to
    Laura> do our work.  And there may not be an archive, so we may
    Laura> need to save the interesting messages the same way we would
    Laura> personal mail.

    Laura> The important distinction turns out to be not the
    Laura> transport mechanism, but other factors such as how
    Laura> interested we are in the subject matter, or how easy it is
    Laura> to retrieve the message if we need to read it again.  

    Laura> Gnus provides many options for sorting mail into "groups"
    Laura> (discussed in * Splitting Mail:: ) which behave like
    Laura> newsgroups, and for treating each group (whether mail or
    Laura> news) differently.



-- 
Laura (mailto:lconrad@world.std.com , http://www.world.std.com/~lconrad/ )
(617) 661-8097	fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

lconrad@world.std.com writes:

> So here's a rewrite that might explain a little more to a new user:

Thanks; I'm including your version in 0.92.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Peter von der Ahé]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

 LMI>    Gnus, by default, handles all its group using the same approach.
 LMI> This approach is very newsreaderly--you enter a group, see the
 LMI> new/unread messages, and when you read the messages, they get marked as
 LMI> read, and you don't see them any more.  (Unless you explicitly ask for
 LMI> them.)

I remember that "explicitly asking for them" was a problem for me when
I first started using Gnus.  I think a note about C-u SPC in the group
buffer or C-u C-x C-s in the summary buffer would be nice.

Cheers,
Peter

Re: some mail annoyances

[lconrad]

>>>>> "Ahe" == Peter von der Ahi <pahe@daimi.au.dk> writes:

    Ahe> I remember that "explicitly asking for them" was a problem
    Ahe> for me when I first started using Gnus.  I think a note about
    Ahe> C-u SPC in the group buffer or C-u C-x C-s in the summary
    Ahe> buffer would be nice.

It's certainly a FAQ.

-- 
Laura (mailto:lconrad@world.std.com , http://www.world.std.com/~lconrad/ )
(617) 661-8097	fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

pahe@daimi.au.dk (Peter von der Ahé) writes:

> I remember that "explicitly asking for them" was a problem for me when
> I first started using Gnus.  I think a note about C-u SPC in the group
> buffer or C-u C-x C-s in the summary buffer would be nice.

I didn't want to get bogged down in specifics in this section; just
give an overview of how Gnus treats mail.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Peter von der Ahé]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

 LMI> pahe@daimi.au.dk (Peter von der Ahé) writes:
 >> I remember that "explicitly asking for them" was a problem for me
 >> when I first started using Gnus.  I think a note about C-u SPC in
 >> the group buffer or C-u C-x C-s in the summary buffer would be
 >> nice.

 LMI> I didn't want to get bogged down in specifics in this section;
 LMI> just give an overview of how Gnus treats mail.

Then just insert a reference, if you please.

How about Something like:

Unless you explicitly ask for them (*note Selecting a Group::.)

Cheers,
Peter

Re: some mail annoyances

[Lars Magne Ingebrigtsen]

pahe@daimi.au.dk (Peter von der Ahé) writes:

> How about Something like:
> 
> Unless you explicitly ask for them (*note Selecting a Group::.)

I'd rather not.  People tend to follow references and stop reading.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: some mail annoyances

[Rob Browning]

(Having mail problems.  First try bounced.  Hope everyone doesn't get
 this twice.)

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>    Gnus, by default, handles all its group using the same approach.

(A while back, I started this elaboration to your post and then forgot
 about it.  Now that I've come across it again, I don't really have
 time ATM to polish it up properly, but perhaps it's got some merit as
 is.

 I don't know if you'll find it useful, and perhaps it should go in
 some other section of the docs, but I thought it might help the new
 but somewhat clueful user understand what's going on with mail expiry
 so that they'll be better equipped to decide how they'd like to
 handle their own mail.  Feel free to correct any errors.  This was
 drawn from my current understanding of mail article disposition, but
 I very well may have it wrong...

 Oh, and I'm missing a few useful cross-references in here, and I need
 the code snippet at the bottom that explains how to get Gnus to
 "re-mark" read articles to dormant (or whatever) just after you read
 them.)

Gnus, by default, wants to handle all its groups, both mail and news,
using the same approach.

This approach is very newsreaderly --- when you enter a group, you
will see any new or unread messages.  Whenever you read a message, it
will get marked as read, and you won't see it again unless you
explicitly ask for it.  You will also always see any messages that you
have marked as ticked (!), and any message you marked as dormant, but
you'll only see the dormant ones if and only if it has unread or
ticked followup articles.

This explains what you can expect to *see*, but this tells you nothing
about one of the more important issues when using Gnus for mail, that
of article lifetimes, of determining when your articles be deleted
forever.

For news groups, message "deletion" (or expiry) is handled by the news
server.  After some period of time, older messages are just gone, so
if you want to keep some of them around, you better do something about
it (*note Persistent Articles::.).  Until messages are expired
(deleted) by the server, you can always ask to see them again.

With mail articles, it's more complex.  Mail articles are stored
locally, on your machine, so it's up to you to decide how articles
might eventually meet their demise.  Which options you want will
depend on your own personal habits, and perhaps more importantly, on
how you think about the content of a given mail group; is it this a
group where you want to keep most of the articles, or one you just
skim for the high points and don't care too much about older content?
As usual, Gnus gives you plenty of rope to hang... ahem, uh, rather a
plethora of options for handling the situation.

First it's important to note how the non-scoring marks interact with
mail article disposition.  Ticked, dormant, and unread articles will
never be deleted through an automatic process.  It's only the read
(and expired -- more later) articles that you have to be concerned
with.  Further, if you mark any mail articles as persistent, even
though the actual mail group article might be deleted through the
mechanisms described below, the cached copy will still be available.

So how does Gnus decide which articles to delete?  Gnus makes the
decision based on the article's non-scoring marks and its age.  From
the perspective of mail article expiry (deletion) purposes, there are
three main types of mail groups, total-expirable ones, auto-expirable
ones, and "manually-expirable" ones.

In total-expirable groups, any read articles will eventually be
deleted.  Since Gnus, by default, marks articles you've looked at as
"read", this means that most articles in total-expirable groups will
eventually be deleted unless you intervene and change the article's
mark.  When the deletion happens is controlled by the setting of
expiry-wait.  To keep an article from being deleted, you have to make
sure it's marked as either ticked, dormant, or unread.  Gnus scans
total-expirable groups when they are exited for all read articles that
match the current expiration criterion; matching articles are deleted.
For large groups, this can be expensive, so you may want to use
demon-expiry --- it's quite slick.  Also, total-expirable groups are
the only ones that will let you play with all of Gnus' scoring related
bells and whistles.  In particular, this is the only group type for
which adaptive scoring works because it's the only one that doesn't
rely on the expirable mark ('E'). (Marking an article as expirable
messes up adaptive scoring because Gnus can no longer determine the
difference between read and deleted articles (is that the right
explanation?)).

In auto-expirable and manually-expirable groups, read articles are
never automatically deleted, only articles explicitly marked expirable
(articles that have, one way or another, been given the 'E' mark),
will be deleted according to expiry-wait.  The difference between
auto-expirable and manually-expirable groups is in how the articles
get marked as expired.  In auto-expirable groups, any article you read
is automatically switched (just after you read it) from "read" to
expirable (i.e. the mark changes from 'r' or 'R' to 'E'), so the
default for articles you look at, if you do nothing else to them, is
for them end up marked expired ('E').  In manually-expirable groups,
no article is ever marked as expirable unless you specifically expire
it.

To summarize, the main difference between total-expirable groups and
the other two is that total-expirable groups actually allow all of
Gnus' fancy scoring stuff (specifically adaptive scoring) to work
right, but you can't expect read articles to stick around like you can
in manually-expirable or auto-expirable groups.  The main difference
between manually and auto expirable groups is how articles get marked
as expirable.

For completeness, I'll also mention that if you really want to
power-nuke a particular message right this second, then you can do
that with 'B del'.  This command tells the group backend to do
whatever it takes to banish the offending message to never-never land
*right now*.  This really isn't the best way to handle deleting your
mail, but it's there if you really really want/need it.

The one other issue relevant to mail article deletion is what mark
mail articles are given just after you look at them.  Normally, this
is 'R', or the "read" mark, but you might want to change that to
better accomodate the expiration behavior you've chosen when
considered in the context of the particular mail group in question.
If you choose total-expire for a group, then the default of marking a
read article with an 'R' means that it's scheduled for expiration.  In
groups where you normally delete most of the articles, this might be
exactly what you want, but if it's a group where you normally want to
keep all the articles, having to go back and re-mark each article as
dormant just after you read it can be a pain.  Accordingly, you can
tell Gnus to change the default mark that an articles end up with just
after you read them.  To do that, just use something like this:

  (Need code here, but I forgot what the proper bit of magic was...)

>    What many Gnus users find, after using it a while for both news and
> mail, is that the transport becomes more and more irrelevant.  What
> becomes important is the size of the receiving audience.
> 
>    Many people subscribe to several mailing lists.  These are
> transported via SMTP, and are therefore mail.  Some people have local
> news groups which have only a handful of readers.  These are
> transported via NNTP, and are therefore news.
> 
>    The important distinction turns out to be not the transport
> mechanism, but whether the messages are "personal" or "public".  Many
> users then subtly alter the behavior of Gnus according to these two
> categories.
> 
>    Some users never get comfortable using the Gnus (ahem) paradigm and
> wish that Gnus should grow up and be a male, er, mail reader.  It is
> possible to whip Gnus into a more mailreaderly being, but, as said
> before, it's not easy.  People who prefer proper mail readers should
> try VM instead, which is an excellent, and proper, mail reader.
> 
>    I don't mean to scare anybody off, but I want to make it clear that
> you may be required to learn a new way of thinking about messages.
> After you've been subjected to The Gnus Way, you will come to love it.
> I can guarantee it.  (At least the guy who sold me the Emacs Subliminal
> Brain-Washing Functions that I've put into Gnus did guarantee it.  You
> Will Be Assimilated.  You Love Gnus.  You Love The Gnus Mail Way.  You
> Do.)
> 
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   larsi@gnus.org * Lars Magne Ingebrigtsen
> 
> 

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930