Streamlining first-time Gnus usage

Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

The mission: To make first-time Gnus usage not suck.

(Long-term we want to use Assistants, but let's just contemplate Gnus
defaults for the time being.)

So, created a brand new test user, and I put the following in my .emacs
file:

(setq gnus-select-method '(nnimap "imap.gmail.com"))

I then `M-x gnus', was prompted for username/password (fine), and then
I'm asked whether I want to save the credentials (fine), and I'm then
dumped into .gpg query hell (not fine, but Ted is fixing that, I think),
and then I'm given a "warning" about a drafts groups being created
(wtf?), and then I'm presented with this:

       *: nndraft:queue
       *: nndraft:drafts

And that's all.

So, obvious things to fix is:

1) get rid of messages saying:

   Setting up drafts group
   Warning: Setting up drafts group

2) don't create the queue group -- it should be deferred until it's
   needed (if ever)

3) make sure the draft group is activated, so that it isn't shown.  It's
   empty, so it shouldn't be

4) subscribe all the groups from the primary select method (and activate
   them) if the primary select method is a mail method (like nnimap)

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

Re: Streamlining first-time Gnus usage

[Julien Danjou]

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

On Mon, Dec 13 2010, Lars Magne Ingebrigtsen wrote:

> The mission: To make first-time Gnus usage not suck.

Good idea. :)

> (Long-term we want to use Assistants, but let's just contemplate Gnus
> defaults for the time being.)

I don't think assistants is a good solution. That would just hide a
complexity. But things should not be complex.

> So, created a brand new test user, and I put the following in my .emacs
> file:
>
> (setq gnus-select-method '(nnimap "imap.gmail.com"))

FWIW, it took me several weeks until I understand what was the
differences between gnus-select-method and
gnus-secondary-select-methods. That could be a starting point.

> 2) don't create the queue group -- it should be deferred until it's
>    needed (if ever)

Weird, I do not have one. It may be recent.

> 4) subscribe all the groups from the primary select method (and activate
>    them) if the primary select method is a mail method (like nnimap)

Add nnimap into `gnus-auto-subscribed-groups'?
(I do that in my configuration. I prefer to be auto-subscribed and kill
the group if I do not want it, rather than miss a new group. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> I don't think assistants is a good solution. That would just hide a
> complexity. But things should not be complex.

They shouldn't, but sometimes they are...  That is, it's more pleasant
for the user if we query the user instead of making a wrong guess, in
general. 

>> (setq gnus-select-method '(nnimap "imap.gmail.com"))
>
> FWIW, it took me several weeks until I understand what was the
> differences between gnus-select-method and
> gnus-secondary-select-methods. That could be a starting point.

After the `g' rework, the only difference real is in the group name.
That is, the primary method groups don't have prefixed names, while the
rest do.  We could hide that by not displaying the prefixes (by default)
in the group buffer, but it's a leaky thing...  and doing a total rework
here is ... eh...  Kinda a lot of work.

But we could recommend doing stuff like

(gnus-add-method '(nnimap "imap.gmail.com"))
(gnus-add-method '(nntp "news.gmane.org"))

instead of exposing the primary/secondary stuff directly.  I mean, if we
just drop the idea of a primary method altogether, and just say that
they're all secondary, then everything is fine.  Except for the long,
prefixed group names...

>> 2) don't create the queue group -- it should be deferred until it's
>>    needed (if ever)
>
> Weird, I do not have one. It may be recent.

Perhaps you've killed it?  It's only relevant for Agent users.

>> 4) subscribe all the groups from the primary select method (and activate
>>    them) if the primary select method is a mail method (like nnimap)
>
> Add nnimap into `gnus-auto-subscribed-groups'?

How odd that it isn't in there already.  I've now added it.

> (I do that in my configuration. I prefer to be auto-subscribed and kill
> the group if I do not want it, rather than miss a new group. :)

Yup.

However, that's really not the proper fix, since native groups (again
with the difference) aren't prefixed.  I'll add a different fix.

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

Re: Streamlining first-time Gnus usage

[Julien Danjou]

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

On Mon, Dec 13 2010, Lars Magne Ingebrigtsen wrote:

>> I don't think assistants is a good solution. That would just hide a
>> complexity. But things should not be complex.
>
> They shouldn't, but sometimes they are...  That is, it's more pleasant
> for the user if we query the user instead of making a wrong guess, in
> general. 

Just don't forget who your users are. :)

> After the `g' rework, the only difference real is in the group name.
> That is, the primary method groups don't have prefixed names, while the
> rest do.  We could hide that by not displaying the prefixes (by default)
> in the group buffer, but it's a leaky thing...  and doing a total rework
> here is ... eh...  Kinda a lot of work.

I agree it's a lot of work, but it's not undoable. At least, we should
decide that it would be a good idea to revoke the primary/secondary
mechanism and find something else.
Then we can do the work little by little. I volunteer. :)

> instead of exposing the primary/secondary stuff directly.  I mean, if we
> just drop the idea of a primary method altogether, and just say that
> they're all secondary, then everything is fine.  Except for the long,
> prefixed group names...

Sounds like a plan!
Or we could provide a prefix for each method, just without the backend
name in front of it. So you can still set it to "" if you have one
primary, and to "WhatEver" so you can prefix the other methods.

>> Weird, I do not have one. It may be recent.
>
> Perhaps you've killed it?  It's only relevant for Agent users.

Ah, I do not use the agent since it has a tendency to not work with
IMAP.

> However, that's really not the proper fix, since native groups (again
> with the difference) aren't prefixed.  I'll add a different fix.

I don't know what fix you want, but setting it to "." might be the best
fix. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> Just don't forget who your users are. :)

/me surreptitiously points up to a certain user yesterday. 

> I agree it's a lot of work, but it's not undoable. At least, we should
> decide that it would be a good idea to revoke the primary/secondary
> mechanism and find something else.

Yes.  I agree, but I'm not sure how to progress here.  I mean, we 1)
want things to continue to work, and 2) be better.

So, as a fundamental thing, we want to be able to name groups uniquely,
because that's very pleasant.  You can just put a group name anywhere
(say, Gcc), and Gnus will be able to identify it.  So that's nice, and
leads us to think that prefixed group names will have to remain as they
are, pretty much.

However, they are kinda ugly.

But it would be nice if Gnus only had a single variable, like
`gnus-methods' or something, that had all the methods.

One problem with primary/secondary methods today is that you can't
change a primary into a secondary without renaming all the groups.
That's not very nice.

> Or we could provide a prefix for each method, just without the backend
> name in front of it. So you can still set it to "" if you have one
> primary, and to "WhatEver" so you can prefix the other methods.

That'll still be a distinction between primary and non-primary, wouldn't
it? 

> I don't know what fix you want, but setting it to "." might be the best
> fix. :)

Nooo.  I certainly don't want to subscribe to all the new groups from
Gmane, Gwene and eternal-september.org...

I've fixed is differently, but I'm wondering whether to get rid of
gnus-options-subscribe and/or gnus-auto-subscribed-groups and/or
gnus-options-not-subscribe.  That's a ridiculous number of variables for
doing pretty much the same thing...

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

Re: Streamlining first-time Gnus usage

[Julien Danjou]

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

On Mon, Dec 13 2010, Lars Magne Ingebrigtsen wrote:

>> Or we could provide a prefix for each method, just without the backend
>> name in front of it. So you can still set it to "" if you have one
>> primary, and to "WhatEver" so you can prefix the other methods.
>
> That'll still be a distinction between primary and non-primary, wouldn't
> it? 

Well, if you set no prefix for a method, you can call it "primary" for
sure. But that's up to you. And that could fit in a single variable
`gnus-methods', no need for two variables. And the rest of the Gnus code
would be a lot clearer. :)

Or we just force every methods to have a prefix, so we only handle
something that looks like current secondary methods?

w> Nooo.  I certainly don't want to subscribe to all the new groups from
> Gmane, Gwene and eternal-september.org...

Err. I understand that. :-D
Well, so using the method type to decide is probably still the best.

> I've fixed is differently, but I'm wondering whether to get rid of
> gnus-options-subscribe and/or gnus-auto-subscribed-groups and/or
> gnus-options-not-subscribe.  That's a ridiculous number of variables for
> doing pretty much the same thing...

+1

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Getting rid of the primary/secondary distinction (was: Streamlining first-time Gnus usage)

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> Or we just force every methods to have a prefix, so we only handle
> something that looks like current secondary methods?

Yes, I think that would be clearer.  Then there wouldn't be any subtle
issues of which method gets to be unprefixed and stuff.

However, I don't know how I'd like having all the groups be prefixed.
Then I think the group buffer, at least, should be displayed
differently.  Perhaps just do everything, er, like so:

imap      4342244: misc.unanswered
nntp           23: gmane.discuss
nntp            *: gnu.emacs.gnus

and not mention the complete prefixed name...

However, commands that expect group names will still expect group names,
so people would have to deal with the complete names at some point.
Although it's easier now, since the completion code has gotten so much
better.  I never type a complete name with `j' any more, but just some
random string from the middle of the group name.

This would actually be really easy to implement.

`gnus-select-method' would just default to nnnil, as Adam suggested.
`gnus-methods' would default to `gnus-secondary-select-methods' (for
legacy purposes).  So new users would only use `gnus-methods', while
older users could continue to use their old stuff.

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

Re: Getting rid of the primary/secondary distinction

[Julien Danjou]

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

On Mon, Dec 13 2010, Lars Magne Ingebrigtsen wrote:

> However, I don't know how I'd like having all the groups be prefixed.
> Then I think the group buffer, at least, should be displayed
> differently.  Perhaps just do everything, er, like so:
>
> imap      4342244: misc.unanswered
> nntp           23: gmane.discuss
> nntp            *: gnu.emacs.gnus
>
> and not mention the complete prefixed name...

I'd say OK for the display part, but that's the just a default format
issue.

But then, be careful of conflicts. You can have the same group name on 2
differents servers. So you have to use full name everywhere, which
anyhow would avoid the confusion we have now.

> However, commands that expect group names will still expect group names,
> so people would have to deal with the complete names at some point.
> Although it's easier now, since the completion code has gotten so much
> better.  I never type a complete name with `j' any more, but just some
> random string from the middle of the group name.
>
> This would actually be really easy to implement.
>
> `gnus-select-method' would just default to nnnil, as Adam suggested.
> `gnus-methods' would default to `gnus-secondary-select-methods' (for
> legacy purposes).  So new users would only use `gnus-methods', while
> older users could continue to use their old stuff.

+1

When do we start? ;)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Getting rid of the primary/secondary distinction

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> When do we start? ;)

I wanna do the rtree makeover for the summary buffer first, but I just
haven't managed to find a vacant block of contiguous hours the past
weeks... 

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

Re: Getting rid of the primary/secondary distinction

[Ted Zlatanov]

On Mon, 13 Dec 2010 20:07:49 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> `gnus-select-method' would just default to nnnil, as Adam suggested.
LMI> `gnus-methods' would default to `gnus-secondary-select-methods' (for
LMI> legacy purposes).  So new users would only use `gnus-methods', while
LMI> older users could continue to use their old stuff.

That sounds like a great solution.  Many users (e.g. me) like foreign
groups better than select methods, so they don't even have to care about
`gnus-methods' but can just add a foreign server and browse the groups
it has.

Ted

Re: Getting rid of the primary/secondary distinction

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> That sounds like a great solution.  Many users (e.g. me) like foreign
> groups better than select methods, so they don't even have to care about
> `gnus-methods' but can just add a foreign server and browse the groups
> it has.

I think the only difference between foreign and non-foreign servers now
is that the non-foreign servers are queried for new groups.  I think
that's pretty much it...

Perhaps the idea of "configured servers" in this way is kinda obsolete?
Perhaps "also-fetch-new-groups-from-this-server" should be something you
configure in the server buffer?

However, I do think that a significant portion of Gnus users are more
comfortable with saying

(gnus-add-method '(nnimap "foo.example.org"
                          (nnimap-port 232)))

in their .gnus.el than configuring this sort of stuff in the server
buffer. 
                          
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Getting rid of the primary/secondary distinction

[Ted Zlatanov]

On Wed, 15 Dec 2010 20:42:46 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> That sounds like a great solution.  Many users (e.g. me) like foreign
>> groups better than select methods, so they don't even have to care about
>> `gnus-methods' but can just add a foreign server and browse the groups
>> it has.

LMI> I think the only difference between foreign and non-foreign servers now
LMI> is that the non-foreign servers are queried for new groups.  I think
LMI> that's pretty much it...

The foreign config is stored in newsrc.eld.  So you need almost no ELisp
configuration to get a working foreign server.

LMI> Perhaps the idea of "configured servers" in this way is kinda obsolete?
LMI> Perhaps "also-fetch-new-groups-from-this-server" should be something you
LMI> configure in the server buffer?

I'm not sure what you mean.

LMI> However, I do think that a significant portion of Gnus users are more
LMI> comfortable with saying

LMI> (gnus-add-method '(nnimap "foo.example.org"
LMI>                           (nnimap-port 232)))

LMI> in their .gnus.el than configuring this sort of stuff in the server
LMI> buffer. 

I actually think the foreign servers are much closer to what people
expect, coming from other MUAs like Thunderbird, Evolution, etc.

Ted

Re: Getting rid of the primary/secondary distinction

[Philipp Haselwarter]

Foreign servers are _nice_ to set up, but one PITA when it comes to
portability. Having to configure them on each and every site is really
no fun. I'd love to see some way to pretty-print a foreign server config
so that I could just dump that into my .gnus.el (same with group
parameters and anything you access through `gnus-group-customize').

-- 
Philipp Haselwarter

Re: Getting rid of the primary/secondary distinction

[Ted Zlatanov]

On Wed, 15 Dec 2010 22:17:52 +0100 Philipp Haselwarter <philipp.haselwarter@gmx.de> wrote: 

PH> Foreign servers are _nice_ to set up, but one PITA when it comes to
PH> portability. Having to configure them on each and every site is really
PH> no fun. I'd love to see some way to pretty-print a foreign server config
PH> so that I could just dump that into my .gnus.el (same with group
PH> parameters and anything you access through `gnus-group-customize').

Yeah, I think the gnus-sync.el discussion covers their synchronization too.

Ted

Re: Getting rid of the primary/secondary distinction

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> LMI> Perhaps the idea of "configured servers" in this way is kinda obsolete?
> LMI> Perhaps "also-fetch-new-groups-from-this-server" should be something you
> LMI> configure in the server buffer?
>
> I'm not sure what you mean.

A command in the server buffer to configure a server for fetching new
groups. 

> LMI> However, I do think that a significant portion of Gnus users are more
> LMI> comfortable with saying
>
> LMI> (gnus-add-method '(nnimap "foo.example.org"
> LMI>                           (nnimap-port 232)))
>
> LMI> in their .gnus.el than configuring this sort of stuff in the server
> LMI> buffer. 
>
> I actually think the foreign servers are much closer to what people
> expect, coming from other MUAs like Thunderbird, Evolution, etc.

Sure.  

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

Re: Getting rid of the primary/secondary distinction

[Ted Zlatanov]

On Wed, 15 Dec 2010 22:27:41 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
LMI> Perhaps the idea of "configured servers" in this way is kinda obsolete?
LMI> Perhaps "also-fetch-new-groups-from-this-server" should be something you
LMI> configure in the server buffer?
>> 
>> I'm not sure what you mean.

LMI> A command in the server buffer to configure a server for fetching new
LMI> groups. 

Oh, OK.  Yeah, maybe.  To me it's not very interesting as I prefer to
never autosubscribe, but I can see the use.

In any case, with gnus-sync.el you wouldn't have foreign
vs. primary/secondary servers anymore, you'd just have "servers" defined
for your particular configuration.  So you'd say "I'm at 'work,
gnus-sync me" and you'd get all the servers that have the 'work tag, and
all the subscriptions for those, and the marks that apply to them.

Ted

Re: Getting rid of the primary/secondary distinction

[Adam Sjøgren]

On Wed, 15 Dec 2010 14:51:24 -0600, Ted wrote:

LMI> (gnus-add-method '(nnimap "foo.example.org"
LMI> (nnimap-port 232)))

LMI> in their .gnus.el than configuring this sort of stuff in the server
LMI> buffer. 

> I actually think the foreign servers are much closer to what people
> expect, coming from other MUAs like Thunderbird, Evolution, etc.

... those users always struggle to remember what the correct answer is
to all the questions. Being able to just look at and copy/paste the
whole shebang is - to me - a nice property.

Maybe I am just oldfashioned, but I really like being able to find
everything and reading it, rather than having to rummage through the
server buffer, group parameters and topic parameters. I always forget
that I have those...


  Just a couple of cents,

     Adam

-- 
 "Accept the mystery!"                                        Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Getting rid of the primary/secondary distinction

[Steinar Bang]

>>>>> Ted Zlatanov <tzz@lifelogs.com>:

> That sounds like a great solution.  Many users (e.g. me) like foreign
> groups better than select methods, so they don't even have to care
> about `gnus-methods' but can just add a foreign server and browse the
> groups it has.

I've never quite understood the relationship between servers in the
server buffer and select methods, be they primary or secondary.

I started out with an NNTP server, and then later select methods for
nnmh, and then nnml, and then nnimap, and eventually a succession of
nnimap servers and nntp servers.

Most new nntp servers I've just added in the server buffer (currently
news.eclipse.org and news.opera.com), and then browsed to the groups I
want.

I've understood vaguely that these are somehow different than e.g. the
gmane nntp server that is defined with a select method.  But to all
appearances they have looked the same, so I haven't worried about it. :-)

Re: Getting rid of the primary/secondary distinction

[Ted Zlatanov]

On Wed, 15 Dec 2010 21:29:17 +0100 Steinar Bang <sb@dod.no> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com>:
>> That sounds like a great solution.  Many users (e.g. me) like foreign
>> groups better than select methods, so they don't even have to care
>> about `gnus-methods' but can just add a foreign server and browse the
>> groups it has.

SB> I've never quite understood the relationship between servers in the
SB> server buffer and select methods, be they primary or secondary.

SB> I started out with an NNTP server, and then later select methods for
SB> nnmh, and then nnml, and then nnimap, and eventually a succession of
SB> nnimap servers and nntp servers.

SB> Most new nntp servers I've just added in the server buffer (currently
SB> news.eclipse.org and news.opera.com), and then browsed to the groups I
SB> want.

SB> I've understood vaguely that these are somehow different than e.g. the
SB> gmane nntp server that is defined with a select method.  But to all
SB> appearances they have looked the same, so I haven't worried about it. :-)

You're using foreign servers.  "Foreign" means they are not coming from
the select methods; the select methods are a pure ELisp data structure
that defines what you want to see when you start up.  All foreign server
config and subscriptions are stored in the newsrc.eld file.

Ted

Re: Getting rid of the primary/secondary distinction

[Steinar Bang]

>>>>> Ted Zlatanov <tzz@lifelogs.com>:

> You're using foreign servers.  "Foreign" means they are not coming
> from the select methods; the select methods are a pure ELisp data
> structure that defines what you want to see when you start up.  All
> foreign server config and subscriptions are stored in the newsrc.eld
> file.

Right.  But the server buffer contains servers corresponding to the
entries in the select mode variables, doesn't it...? 

Re: Getting rid of the primary/secondary distinction

[Ted Zlatanov]

On Wed, 15 Dec 2010 22:05:36 +0100 Steinar Bang <sb@dod.no> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com>:
>> You're using foreign servers.  "Foreign" means they are not coming
>> from the select methods; the select methods are a pure ELisp data
>> structure that defines what you want to see when you start up.  All
>> foreign server config and subscriptions are stored in the newsrc.eld
>> file.

SB> Right.  But the server buffer contains servers corresponding to the
SB> entries in the select mode variables, doesn't it...? 

That plus the foreign servers.

Ted

Re: Getting rid of the primary/secondary distinction

[Andy Moreton]

On Wed 15 Dec 2010, Ted Zlatanov wrote:

> On Wed, 15 Dec 2010 21:29:17 +0100 Steinar Bang <sb@dod.no> wrote: 
>
>>>>>>> Ted Zlatanov <tzz@lifelogs.com>:
>>> That sounds like a great solution.  Many users (e.g. me) like foreign
>>> groups better than select methods, so they don't even have to care
>>> about `gnus-methods' but can just add a foreign server and browse the
>>> groups it has.
>
> SB> I've never quite understood the relationship between servers in the
> SB> server buffer and select methods, be they primary or secondary.
>
> SB> I started out with an NNTP server, and then later select methods for
> SB> nnmh, and then nnml, and then nnimap, and eventually a succession of
> SB> nnimap servers and nntp servers.
>
> SB> Most new nntp servers I've just added in the server buffer (currently
> SB> news.eclipse.org and news.opera.com), and then browsed to the groups I
> SB> want.
>
> SB> I've understood vaguely that these are somehow different than e.g. the
> SB> gmane nntp server that is defined with a select method.  But to all
> SB> appearances they have looked the same, so I haven't worried about it. :-)
>
> You're using foreign servers.  "Foreign" means they are not coming from
> the select methods; the select methods are a pure ELisp data structure
> that defines what you want to see when you start up.  All foreign server
> config and subscriptions are stored in the newsrc.eld file.
>
> Ted

Ted,

This is the first explanation I've seen of the difference between select
methods and foreign servers: it's much more useful than the definitions
in the Terminology page of the manual.

Can this be added to the manual ?

    AndyM

Re: Getting rid of the primary/secondary distinction

[Ted Zlatanov]

On Thu, 16 Dec 2010 13:21:06 +0000 Andy Moreton <andrewjmoreton@gmail.com> wrote: 

AM> On Wed 15 Dec 2010, Ted Zlatanov wrote:
>> You're using foreign servers.  "Foreign" means they are not coming from
>> the select methods; the select methods are a pure ELisp data structure
>> that defines what you want to see when you start up.  All foreign server
>> config and subscriptions are stored in the newsrc.eld file.

AM> This is the first explanation I've seen of the difference between select
AM> methods and foreign servers: it's much more useful than the definitions
AM> in the Terminology page of the manual.

AM> Can this be added to the manual ?

I did that, under "Foreign Groups" but I rewrote it to mention the other
stuff and generally be more consistent.

Thanks
Ted

Re: Streamlining first-time Gnus usage

[Dan Christensen]

Julien Danjou <julien@danjou.info> writes:

> Or we could provide a prefix for each method, just without the backend
> name in front of it. So you can still set it to "" if you have one
> primary, and to "WhatEver" so you can prefix the other methods.

I like the idea of being able to set custom prefixes for some servers.
So instead of "nnimap+host.name:group.name" I could use "custom:group.name".

This could also make it easier to share a .gnus file between different
hosts.  They may use a different hostname but I could configure them to
use the same prefix, so some custom code wouldn't need to know the
difference.

And when switching to a different server, some things could remain
unchanged.

Dan

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> I like the idea of being able to set custom prefixes for some servers.
> So instead of "nnimap+host.name:group.name" I could use
> "custom:group.name".

I think that might turn out to be pretty fragile.  I mean, groups don't
change names after they've been made, so you could end up with some with
+ names and some without...

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

Re: Streamlining first-time Gnus usage

[Ted Zlatanov]

On Mon, 13 Dec 2010 21:22:39 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Dan Christensen <jdc@uwo.ca> writes:
>> I like the idea of being able to set custom prefixes for some servers.
>> So instead of "nnimap+host.name:group.name" I could use
>> "custom:group.name".

LMI> I think that might turn out to be pretty fragile.  I mean, groups don't
LMI> change names after they've been made, so you could end up with some with
LMI> + names and some without...

I think it's a bad idea.  Customizing the group line format to use a
custom function would be better if you want to *see* a custom prefix,
but it's very important to have a unique name for any group and
overriding the prefix would break that.

Ted

Re: Streamlining first-time Gnus usage

[Adam Sjøgren]

On Mon, 13 Dec 2010 14:55:30 -0500, Dan wrote:

> This could also make it easier to share a .gnus file between different
> hosts.  They may use a different hostname but I could configure them to
> use the same prefix, so some custom code wouldn't need to know the
> difference.

Can't you do that already, using something like this:

        (nntp "news.gmane.org"
              (nntp-open-connection-function nntp-open-tls-stream)
              (nntp-port-number 563)
              (nntp-address "snews.gmane.org"))

?

I usually comment out the three last lines when snews isn't working;
then I just get unencrypted access to news.gmane.org.


  Best regards,

    Adam

-- 
 "Accept the mystery!"                                        Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Can't you do that already, using something like this:
>
>         (nntp "news.gmane.org"
>               (nntp-open-connection-function nntp-open-tls-stream)
>               (nntp-port-number 563)
>               (nntp-address "snews.gmane.org"))

Yup.

> I usually comment out the three last lines when snews isn't working;
> then I just get unencrypted access to news.gmane.org.

Just a note -- if you have

(require 'gnutls)

in your Emacs 24, Gnus will automatically upgrade your news.gmane.org
connection to TLS even if you connect to the normal NNTP port.

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

Re: Streamlining first-time Gnus usage

[Adam Sjøgren]

On Mon, 13 Dec 2010 21:26:18 +0100, Lars wrote:

>> (nntp-open-connection-function nntp-open-tls-stream)
>> (nntp-port-number 563)
>> (nntp-address "snews.gmane.org"))

[...]

> Just a note -- if you have

> (require 'gnutls)

> in your Emacs 24, Gnus will automatically upgrade your news.gmane.org
> connection to TLS even if you connect to the normal NNTP port.

Thanks for the note - I haven't entirely given up on XEmacs yet, so I'll
keep my current setup around a little longer, but I'll make a note of
it.


  Best regards,

    Adam

-- 
 "Accept the mystery!"                                        Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Streamlining first-time Gnus usage

[Adam Sjøgren]

On Mon, 13 Dec 2010 17:29:55 +0100, Lars wrote:

> But we could recommend doing stuff like

> (gnus-add-method '(nnimap "imap.gmail.com"))
> (gnus-add-method '(nntp "news.gmane.org"))

> instead of exposing the primary/secondary stuff directly.  I mean, if we
> just drop the idea of a primary method altogether, and just say that
> they're all secondary, then everything is fine.  Except for the long,
> prefixed group names...

Sound good, I think!

I have grown accustomed to setting the primary method to nnnil when I am
configuring a new Gnus (i.e. when changing jobs) - so all servers are
secondary, and equal, citizens.

Should any other mail-type groups besides nnimap groups default to being
automatically subscribed as well?


  Best regards,

    Adam

-- 
 "That's a mystery, but I don't intend to inquire into        Adam Sjøgren
  it further."                                           asjo@koldfront.dk

Re: Streamlining first-time Gnus usage

[Adam Sjøgren]

On Mon, 13 Dec 2010 18:02:59 +0100, Adam wrote:

> Should any other mail-type groups besides nnimap groups default to being
> automatically subscribed as well?

Hah, too slow, you already committed something to that effect.


  :-),

   Adam

-- 
 "You add an agreeable sense of the macabre to any            Adam Sjøgren
  delirium."                                             asjo@koldfront.dk

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

>> Should any other mail-type groups besides nnimap groups default to being
>> automatically subscribed as well?
>
> Hah, too slow, you already committed something to that effect.

Yup.  All mail-like groups will now be subscribed automatically, no
matter what their names are.  Seems to work in my test case, too.

The drafts group is still not activated, though, but I'm tracking that
down...

The one place where things break down completely now is that I'm queried
for the .authinfo.gpg file password a *lot* of times.  I suspect
something should be cached...  somewhere...

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

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

My test case now starts up fine (if you disregard the .gpg issues), but
I discovered while doing this that on Gnus startup, Gnus reads all the
active files twice.  Once in the old, slow way, and once in the new,
slightly faster way.

So I just removed that stuff altogether.

This may or may not cause subtle and not-so-subtle problems, but it
seems to work for me.  But let me know whether it works or not...

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

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

I've now made netrc.el cache in-memory the contents of the
~/.authinfo.gpg file.  It uses state-of-the-art rot13+base64 encryption
to make it impossible for root to look at /dev/kmem to find out what the
passwords really are.

And now just using this minimal configuration:

(setq gnus-select-method '(nnimap "imap.gmail.com"))

works satisfactorily for me starting from a blank slate, and when
restarting Gnus again.  (Well, except for the initial .gpg interface,
but that's a more general Emacs issue.)

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

Re: Streamlining first-time Gnus usage

[Ted Zlatanov]

On Mon, 13 Dec 2010 20:11:06 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> I've now made netrc.el cache in-memory the contents of the
LMI> ~/.authinfo.gpg file.  It uses state-of-the-art rot13+base64 encryption
LMI> to make it impossible for root to look at /dev/kmem to find out what the
LMI> passwords really are.

Oh, but what if the user modifies the file, do you refresh?  

I really don't like my secrets in memory outside of the EPA-managed
buffer.  So I'm against this change even if it seems to be more
convenient.  Better to let EPA cache the results, if it can, or use a
non-encrypted file if you don't like it.

So maybe auth-source.el should, the first time it's started, ask "hey,
do you want a EPA-GPG-encrypted file, or are you happy with storing all
your secrets in plain sight?" instead of defaulting to EPA as it does
now.  But regardless of all that the data should not be cached in memory.

Ted

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Oh, but what if the user modifies the file, do you refresh?  

Yes, it checks the timestamp before handing out the cached copy.

> I really don't like my secrets in memory outside of the EPA-managed
> buffer.  So I'm against this change even if it seems to be more
> convenient.  Better to let EPA cache the results, if it can, or use a
> non-encrypted file if you don't like it.

I don't really like storing this data in Emacs memory, either, but
storing it as plain text files is even more yucky.  I think.  But only
slightly.

But if we don't store this data in Emacs memory (by default), then Gnus
is basically unusable for a new user.  So it's a trade-off.  So, if we
think that having secrets in memory is better than having them on disk
(slightly), then I think this is the best ~/.authinfo.gpg solution so
far.  But I'd, too, like to see this solved a better way.

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

Re: Streamlining first-time Gnus usage

[Ted Zlatanov]

On Mon, 13 Dec 2010 18:02:59 +0100 asjo@koldfront.dk (Adam Sjøgren) wrote: 

AS> On Mon, 13 Dec 2010 17:29:55 +0100, Lars wrote:
>> But we could recommend doing stuff like

>> (gnus-add-method '(nnimap "imap.gmail.com"))
>> (gnus-add-method '(nntp "news.gmane.org"))

>> instead of exposing the primary/secondary stuff directly.  I mean, if we
>> just drop the idea of a primary method altogether, and just say that
>> they're all secondary, then everything is fine.  Except for the long,
>> prefixed group names...

AS> Sound good, I think!

AS> I have grown accustomed to setting the primary method to nnnil when I am
AS> configuring a new Gnus (i.e. when changing jobs) - so all servers are
AS> secondary, and equal, citizens.

I think the primary method should be nnnil by default.

Ted

Re: Streamlining first-time Gnus usage

[Tassilo Horn]

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

Hi!

>>> 4) subscribe all the groups from the primary select method (and activate
>>>    them) if the primary select method is a mail method (like nnimap)
>>
>> Add nnimap into `gnus-auto-subscribed-groups'?
>
> How odd that it isn't in there already.  I've now added it.

I just want to mention that for example the IMAP server of my university
has more than 200 groups, most of which are "shared folders".  Those
contain all university-internal newsgroups (don't ask me what that's
good for...).

So as a new user, I'd be very overwhelmed in getting a *Group* buffer
with hundreds of groups containing thousands of unread messages...

Maybe one could subscribe to only groups where a user has both read and
write permissions?  I think that would filter out these shared folders
for me...

Bye,
Tassilo

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> So as a new user, I'd be very overwhelmed in getting a *Group* buffer
> with hundreds of groups containing thousands of unread messages...

I would imagine that it's not the common case, though.  And I would
guess that if you point Apple Mail towards such a server, it would just
list all the folders.

> Maybe one could subscribe to only groups where a user has both read and
> write permissions?  I think that would filter out these shared folders
> for me...

It's possible, but it would require a lot of work, since that
information isn't available to Gnus in that phase.  

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

Re: Streamlining first-time Gnus usage

[Tassilo Horn]

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

Hi Lars,

>> So as a new user, I'd be very overwhelmed in getting a *Group* buffer
>> with hundreds of groups containing thousands of unread messages...
>
> I would imagine that it's not the common case, though.

Probably.

> And I would guess that if you point Apple Mail towards such a server,
> it would just list all the folders.

I cannot speak for Apple Mail, but at least KMail opens a dialog that
lets you subscribe to individual groups when adding a new account.

And with GUI clients, that's a bit less of an issue, because in their
tree views you can simply collapse the Shared Folders.  You can do
basically the same with Gnus' topics, but you have to create them
first.

But I guess subscribing to all groups is ok for the time being.  But a
future setup assistant should have a subscription step (which is needed
for nntp anyway).

Bye,
Tassilo

Re: Streamlining first-time Gnus usage

[Julien Danjou]

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

On Tue, Dec 14 2010, Tassilo Horn wrote:

> I cannot speak for Apple Mail, but at least KMail opens a dialog that
> lets you subscribe to individual groups when adding a new account.

That's even worst. Mail clients can use IMAP subscriptions system, which
Gnus has no clue about, unfortunately. :(

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Streamlining first-time Gnus usage

[Tassilo Horn]

Julien Danjou <julien@danjou.info> writes:

Hi Julien,

>> I cannot speak for Apple Mail, but at least KMail opens a dialog that
>> lets you subscribe to individual groups when adding a new account.
>
> That's even worst.

What's worse than what?  A one-time dialog is worse than subscribing all
groups?  At least not in my book...

> Mail clients can use IMAP subscriptions system, which Gnus has no clue
> about, unfortunately. :(

Yes, sadly.  But IMO that's not a too important issue...

Bye,
Tassilo

Re: Streamlining first-time Gnus usage

[Julien Danjou]

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

On Tue, Dec 14 2010, Tassilo Horn wrote:

>> That's even worst.
>
> What's worse than what?  A one-time dialog is worse than subscribing all
> groups?  At least not in my book...

No, sorry, I meant "that's even worse than what you think".

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Streamlining first-time Gnus usage

[Rupert Swarbrick]

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

Tassilo Horn <tassilo@member.fsf.org> writes:
>> Mail clients can use IMAP subscriptions system, which Gnus has no clue
>> about, unfortunately. :(
>
> Yes, sadly.  But IMO that's not a too important issue...

And possibly the most common account - GMail - uses a server which
doesn't support IMAP subscriptions. As a result, using Evolution or
Thunderbind with GMail is painful: "NO, FOR THE LOVE OF GOD, DON'T SYNC
'ALL MAIL' AGAIN!!!"

(In case you're wondering, the university's systems have Evolution and
not Gnus. If I die of heart failure brought on by high blood pressure, I
know where to send my next-of-kin to sue...)


Rupert

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: Streamlining first-time Gnus usage

[Ted Zlatanov]

On Tue, 14 Dec 2010 09:07:06 +0100 Tassilo Horn <tassilo@member.fsf.org> wrote: 

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

>> And I would guess that if you point Apple Mail towards such a server,
>> it would just list all the folders.

TH> I cannot speak for Apple Mail, but at least KMail opens a dialog that
TH> lets you subscribe to individual groups when adding a new account.

TH> And with GUI clients, that's a bit less of an issue, because in their
TH> tree views you can simply collapse the Shared Folders.  You can do
TH> basically the same with Gnus' topics, but you have to create them
TH> first.

TH> But I guess subscribing to all groups is ok for the time being.  But a
TH> future setup assistant should have a subscription step (which is needed
TH> for nntp anyway).

Yes, this is exactly what Assistants should do: show a bunch of visual
information and allow the user to navigate through it before making a
final commitment.

Also I think the topic mode should be on by default and if there are no
topics, the user should be asked if he'd like to make a global topic
that contains everything so far.  From that point on, if Gnus starts up
and finds groups without topics, it should ask the user to move them
into an existing topic or create a new one.

Ted

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Also I think the topic mode should be on by default and if there are no
> topics, the user should be asked if he'd like to make a global topic
> that contains everything so far. 

I have a suspicion that the common case for most new users wouldn't be
to have so many groups that topics make much sense.  But I could be
wrong.  :-)

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

Re: Streamlining first-time Gnus usage

[Ted Zlatanov]

On Wed, 15 Dec 2010 21:05:09 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Also I think the topic mode should be on by default and if there are no
>> topics, the user should be asked if he'd like to make a global topic
>> that contains everything so far. 

LMI> I have a suspicion that the common case for most new users wouldn't be
LMI> to have so many groups that topics make much sense.  But I could be
LMI> wrong.  :-)

It's not that they need the topics at first, it's that showing even one
topic will make them wonder what topics are and how to use them.  From
there they'll learn about topic parameters, and soon enough they'll be
contributing to Gnus.  So this is really a request for minions[1].

On Wed, 15 Dec 2010 21:11:10 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:

>> I really don't like my secrets in memory outside of the EPA-managed
>> buffer.  So I'm against this change even if it seems to be more
>> convenient.  Better to let EPA cache the results, if it can, or use a
>> non-encrypted file if you don't like it.

LMI> I don't really like storing this data in Emacs memory, either, but
LMI> storing it as plain text files is even more yucky.  I think.  But only
LMI> slightly.

LMI> But if we don't store this data in Emacs memory (by default), then Gnus
LMI> is basically unusable for a new user.  So it's a trade-off.  So, if we
LMI> think that having secrets in memory is better than having them on disk
LMI> (slightly), then I think this is the best ~/.authinfo.gpg solution so
LMI> far.  But I'd, too, like to see this solved a better way.

Let me see what I can do with auth-source.el rewrite.  Coming Real Soon
Now.  Like this year.  I'm going to devour netrc.el anyhow so I'll try
to remove the in-memory cache if possible.

Ted

Re: Streamlining first-time Gnus usage

[Ted Zlatanov]

On Wed, 15 Dec 2010 14:57:46 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> It's not that they need the topics at first, it's that showing even one
TZ> topic will make them wonder what topics are and how to use them.  From
TZ> there they'll learn about topic parameters, and soon enough they'll be
TZ> contributing to Gnus.  So this is really a request for minions[1].

I forgot the footnote:

[1] I had to watch "Despicable Me" with the kids and it gave me ideas.

Poll time: Topics should default to on or off? (was: Streamlining first-time Gnus usage)

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It's not that they need the topics at first, it's that showing even one
> topic will make them wonder what topics are and how to use them.  From
> there they'll learn about topic parameters, and soon enough they'll be
> contributing to Gnus.  So this is really a request for minions[1].

That's a good point.

Let's do a poll: Should topics default (for first-time users) to on or
off?

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

Re: Poll time: Topics should default to on or off?

[Julien Danjou]

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

On Thu, Dec 16 2010, Lars Magne Ingebrigtsen wrote:

> Let's do a poll: Should topics default (for first-time users) to on or
> off?

Off.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Poll time: Topics should default to on or off?

[David Edmondson]

* larsi@gnus.org [2010-12-16 Thu 16:22]
> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> It's not that they need the topics at first, it's that showing even one
>> topic will make them wonder what topics are and how to use them.  From
>> there they'll learn about topic parameters, and soon enough they'll be
>> contributing to Gnus.  So this is really a request for minions[1].
>
> That's a good point.
>
> Let's do a poll: Should topics default (for first-time users) to on or
> off?

On.

dme.
-- 
David Edmondson, http://dme.org

Re: Poll time: Topics should default to on or off?

[Steinar Bang]

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

> Let's do a poll: Should topics default (for first-time users) to on or
> off?

On.

With just a single topic to show that it's there.

Re: Poll time: Topics should default to on or off?

[Richard Riley]

Steinar Bang <sb@dod.no> writes:

>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
>
>> Let's do a poll: Should topics default (for first-time users) to on or
>> off?
>
> On.
>
> With just a single topic to show that it's there.
>

I would go further. 2 if not 3.

Archives
Email
News

And why not provide a default group for gnus and emacs at gmane too?

Re: Poll time: Topics should default to on or off?

[Lars Magne Ingebrigtsen]

Richard Riley <rileyrg@googlemail.com> writes:

> And why not provide a default group for gnus and emacs at gmane too?

I think that would be a bit presumptuous.  I mean, just because people
are using Emacs to read their mail doesn't mean that they're all that
into Emacs per se.

Speaking of which, I've just checked in a change that adds the following
line to the end of all email sent from Gnus:

Sent from my Emacs

Sent from my Emacs

Re: Poll time: Topics should default to on or off?

[Steinar Bang]

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

> Speaking of which, I've just checked in a change that adds the
> following line to the end of all email sent from Gnus:

> Sent from my Emacs

> Sent from my Emacs

Please tell me you're joking.

Re: Poll time: Topics should default to on or off?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Please tell me you're joking.

Ok, I'll tell you I'm joking.

Sent from my Emacs

Re: Poll time: Topics should default to on or off?

[Adam Sjøgren]

I like it. OK LOL.

Sent from my Emacs

Lars wrote:

> Steinar Bang <sb@dod.no> writes:
>> Please tell me you're joking.

> Ok, I'll tell you I'm joking.

> Sent from my Emacs

Re: Poll time: Topics should default to on or off?

[Rupert Swarbrick]

asjo@koldfront.dk (Adam Sjøgren) writes:
> I like it. OK LOL.
>
> Sent from my Emacs
>
> Lars wrote:
>
>> Steinar Bang <sb@dod.no> writes:
>>> Please tell me you're joking.
>
>> Ok, I'll tell you I'm joking.
>
>> Sent from my Emacs

Ah! It's really clever! The new version both forces top-posting and
works out to only insert the spam line before the quoted text. Nice!

Rupert

Sent from someone else's vim

Re: Poll time: Topics should default to on or off?

[jidanni]

I think I tried them once before you all were born, but now at age 50,
"I feel they would just confuse the older user. Best to leave them for
the eager beavers who try everything they find in the manual."

Re: Poll time: Topics should default to on or off?

[Richard Riley]

jidanni@jidanni.org writes:

> I think I tried them once before you all were born, but now at age 50,
> "I feel they would just confuse the older user. Best to leave them for
> the eager beavers who try everything they find in the manual."
>

Topics are a very valuable and powerful subset of gnus and easily get
missed by the newcomer drowning in Gnus complexities. I've been using it
for years now and am totally flummoxed by agent categories for example,
not to mention the recent changes to spam handling.

Have them turned with a sensible default on and people know they are
there and can go from there. It is important to visually differentiate
between groups of mail groups and nntp groups for example and topics aid
that. Not to mention the ability to build a hierarchy with topics to
better organise your email and nntp.

Expert or older users can turn them off easily enough.

changes to spam.el (was: Poll time: Topics should default to on or off?)

[Ted Zlatanov]

On Fri, 17 Dec 2010 11:32:12 +0100 Richard Riley <rileyrg@googlemail.com> wrote: 

RR> [I'm] totally flummoxed by [...] the recent changes to spam
RR> handling.

I swear I haven't done any serious work on spam.el in years (although I
keep threatening to).  The last minor change was from Sep 14 2009.  What
changes are flummoxing you?

Ted

Re: Poll time: Topics should default to on or off?

[Greg Troxel]

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


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

> Steinar Bang <sb@dod.no> writes:
>
>> Please tell me you're joking.
>
> Ok, I'll tell you I'm joking.
>
> Sent from my Emacs

Two suggestions, one of them serious:

  BBDB integration to record senders that have product signature spam,
  and add "Sent from my Emacs" on unicast mail to them.

  Add a washing mode that remotes the usual spammy signature lines about
  iFoo, crackberry, etc., and default it to on.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: Poll time: Topics should default to on or off?

[Reiner Steib]

On Thu, Dec 16 2010, Lars Magne Ingebrigtsen wrote:

> Let's do a poll: Should topics default (for first-time users) to on or
> off?

On.

A default layout might be ...

[ Gnus ]
  [ Mail ]
  [ News ]
  [ Drafts ]
  [ Sent ]

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Poll time: Topics should default to on or off?

[Steinar Bang]

>>>>> Reiner Steib <reinersteib+gmane@imap.cc>:

> On Thu, Dec 16 2010, Lars Magne Ingebrigtsen wrote:
>> Let's do a poll: Should topics default (for first-time users) to on or
>> off?

> On.

> A default layout might be ...

> [ Gnus ]
>   [ Mail ]
>   [ News ]
>   [ Drafts ]
>   [ Sent ]

But: the topics should be open by default.  If not, the new user might
not understand what's going on.  The user may then later discover that
the topics are closable.

Re: Poll time: Topics should default to on or off?

[Ted Zlatanov]

On Sat, 18 Dec 2010 21:41:49 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Thu, Dec 16 2010, Lars Magne Ingebrigtsen wrote:
>> Let's do a poll: Should topics default (for first-time users) to on or
>> off?

RS> On.

RS> A default layout might be ...

RS> [ Gnus ]
RS>   [ Mail ]
RS>   [ News ]
RS>   [ Drafts ]
RS>   [ Sent ]

I like that layout.  In addition each nn* backend should have a function
that says "my groups should probably be under topic X".  So news-p
backends would say "News" and nndraft would say "Drafts" for example.

It shouldn't be enforced, but maybe the user could be gently guided to
use that topic the first time he subscribes to a group.

Ted

Re: Poll time: Topics should default to on or off?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> RS> A default layout might be ...
>
> RS> [ Gnus ]
> RS>   [ Mail ]
> RS>   [ News ]
> RS>   [ Drafts ]
> RS>   [ Sent ]
>
> I like that layout.  In addition each nn* backend should have a function
> that says "my groups should probably be under topic X".  So news-p
> backends would say "News" and nndraft would say "Drafts" for example.
>
> It shouldn't be enforced, but maybe the user could be gently guided to
> use that topic the first time he subscribes to a group.

It's just a matter of creating the initial topic hierarchy with

((subscribe . "^sent\\."))

entries.  Or rather, that should probably be extended to take news-p
(etc), but that's rather trivial.

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

Re: Poll time: Topics should default to on or off?

[Ted Zlatanov]

On Sun, 19 Dec 2010 16:44:40 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
RS> A default layout might be ...
>> 
RS> [ Gnus ]
RS> [ Mail ]
RS> [ News ]
RS> [ Drafts ]
RS> [ Sent ]
>> 
>> I like that layout.  In addition each nn* backend should have a function
>> that says "my groups should probably be under topic X".  So news-p
>> backends would say "News" and nndraft would say "Drafts" for example.
>> 
>> It shouldn't be enforced, but maybe the user could be gently guided to
>> use that topic the first time he subscribes to a group.

LMI> It's just a matter of creating the initial topic hierarchy with

LMI> ((subscribe . "^sent\\."))

LMI> entries.  Or rather, that should probably be extended to take news-p
LMI> (etc), but that's rather trivial.

...so the votes were cast in favor of topics, right?  And we can set up
the initial topic hierarchy as you described?

Ted

Re: Poll time: Topics should default to on or off?

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> ...so the votes were cast in favor of topics, right?  And we can set up
> the initial topic hierarchy as you described?

Yes, Gnus should default to topics.  But I wasn't really all that keen
on any of the suggested default topics.  :-)

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

Re: Poll time: Topics should default to on or off?

[Ted Zlatanov]

On Sat, 22 Jan 2011 04:03:30 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> ...so the votes were cast in favor of topics, right?  And we can set up
>> the initial topic hierarchy as you described?

LI> Yes, Gnus should default to topics.  But I wasn't really all that keen
LI> on any of the suggested default topics.  :-)

How about:

sent (gets all the new sent-xyz folders)

mail

news
 nntp
 gmane
 gwene

nsfw
 kittehs

Re: Poll time: Topics should default to on or off?

[Robert Pluim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sat, 22 Jan 2011 04:03:30 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 
>
> LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> ...so the votes were cast in favor of topics, right?  And we can set up
>>> the initial topic hierarchy as you described?
>
> LI> Yes, Gnus should default to topics.  But I wasn't really all that keen
> LI> on any of the suggested default topics.  :-)
>
> How about:
>
> sent (gets all the new sent-xyz folders)
>
> mail
>
> news
>  nntp
>  gmane
>  gwene
>
> nsfw
>  kittehs

I'm with whoever made the point that Gnus doesn't really make much
distinction between mail and not-mail, how about:

Sent

Gnus
        (all the funky nntp, gmane and gwene feeds pertaining to gnus)
Emacs
        (ditto for Emacs)
Groups
        everything else

That should be enough to give people a hint on topics.

Robert

Re: Poll time: Topics should default to on or off?

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Sent
>
> Gnus
>         (all the funky nntp, gmane and gwene feeds pertaining to gnus)
> Emacs
>         (ditto for Emacs)
> Groups
>         everything else

I don't think it's reasonable to assume that everybody that uses Gnus
is, like, interested in Gnus.  :-)

Perhaps something like this:

[ Gnus -- 252912 ]
  [ Stuff -- 377 ]
  [ Sent -- 4232422 ]
  
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Poll time: Topics should default to on or off?

[Ted Zlatanov]

On Mon, 24 Jan 2011 14:11:56 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Robert Pluim <rpluim@gmail.com> writes:
>> Sent
>> 
>> Gnus
>> (all the funky nntp, gmane and gwene feeds pertaining to gnus)
>> Emacs
>> (ditto for Emacs)
>> Groups
>> everything else

LI> I don't think it's reasonable to assume that everybody that uses Gnus
LI> is, like, interested in Gnus.  :-)

LI> Perhaps something like this:

LI> [ Gnus -- 252912 ]
LI>   [ Stuff -- 377 ]
LI>   [ Sent -- 4232422 ]

That's reasonably milquetoasty.

Ted

Re: Poll time: Topics should default to on or off?

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> That's reasonably milquetoasty.

Mmm...  toasted milk...

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

Re: Poll time: Topics should default to on or off?

[Ted Zlatanov]

On Mon, 24 Jan 2011 14:37:34 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> That's reasonably milquetoasty.

LI> Mmm...  toasted milk...

Can you commit that default hierarchy or do you want me to?

Ted

Re: Poll time: Topics should default to on or off?

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Can you commit that default hierarchy or do you want me to?

Sure, go ahead.  The weather's too nice to be indoors, anyway.

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

Re: Poll time: Topics should default to on or off?

[Ted Zlatanov]

On Tue, 25 Jan 2011 14:09:45 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Can you commit that default hierarchy or do you want me to?

LI> Sure, go ahead.  The weather's too nice to be indoors, anyway.

I'm not sure that this will work alone:

(defvar gnus-topic-topology (("Gnus" visible nil nil)
                             (("Stuff" visible nil nil))
                             (("Sent" visible nil nil)))

  "The complete topic hierarchy.")

Am I missing anything?

Ted

Re: Poll time: Topics should default to on or off?

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I'm not sure that this will work alone:
>
> (defvar gnus-topic-topology (("Gnus" visible nil nil)
>                              (("Stuff" visible nil nil))
>                              (("Sent" visible nil nil)))
>
>   "The complete topic hierarchy.")

Hm...  That might work.  I had imagined just some special code at the
first startup that would add this, but perhaps that's not necessary?

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

how to start clean Gnus (was: Poll time: Topics should default to on or off?)

[Ted Zlatanov]

On Wed, 26 Jan 2011 14:58:10 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I'm not sure that this will work alone:
>> 
>> (defvar gnus-topic-topology (("Gnus" visible nil nil)
>> (("Stuff" visible nil nil))
>> (("Sent" visible nil nil)))
>> 
>> "The complete topic hierarchy.")

LI> Hm...  That might work.  I had imagined just some special code at the
LI> first startup that would add this, but perhaps that's not necessary?

Slightly related: how would I start Gnus with a completely clear
configuration, ignoring everything in ~/News, ~/Mail, and all Gnus init
files?

I tend to test things with all my existing customizations, which is not
how most people will see them.

Ted

Re: how to start clean Gnus

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Slightly related: how would I start Gnus with a completely clear
> configuration, ignoring everything in ~/News, ~/Mail, and all Gnus init
> files?

I think that's virtually impossible.  :-)

When I'm testing start-up-from-scratch, I create a test user and rm -r
everything that user has first.

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

Re: how to start clean Gnus

[Reiner Steib]

On Fri, Jan 28 2011, Lars Ingebrigtsen wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> Slightly related: how would I start Gnus with a completely clear
>> configuration, ignoring everything in ~/News, ~/Mail, and all Gnus init
>> files?
>
> I think that's virtually impossible.  :-)
>
> When I'm testing start-up-from-scratch, I create a test user and rm -r
> everything that user has first.

If you don't have root access:

--8<---------------cut here---------------start------------->8---
emacs_test=~/path/to/my/emacs_test
mkdir -p $emacs_test
cd $emacs_test
ln -s ~/.Xauthority .
HOME=$PWD emacs &
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: how to start clean Gnus

[Ted Zlatanov]

On Fri, 28 Jan 2011 08:39:38 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Fri, Jan 28 2011, Lars Ingebrigtsen wrote:
>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
>>> Slightly related: how would I start Gnus with a completely clear
>>> configuration, ignoring everything in ~/News, ~/Mail, and all Gnus init
>>> files?
>> 
>> I think that's virtually impossible.  :-)
>> 
>> When I'm testing start-up-from-scratch, I create a test user and rm -r
>> everything that user has first.

RS> If you don't have root access:
RS> emacs_test=~/path/to/my/emacs_test
RS> mkdir -p $emacs_test
RS> cd $emacs_test
RS> ln -s ~/.Xauthority .
RS> HOME=$PWD emacs &

I'll work something out based on $HOME remapping, thanks for the
suggestion.

Ted

Re: Poll time: Topics should default to on or off?

[Steven E. Harris]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> A default layout might be ...
>
> [ Gnus ]
>   [ Mail ]
>   [ News ]
>   [ Drafts ]
>   [ Sent ]

I thought that one of the selling points of Gnus is that it lets one
manage news and email similarly. For years I've had mail groups and news
groups together within topics -- organized by discussion topic, not by
the technology by which I collect or access the messages on that
discussion topic.

When it comes to mailing lists, this is most valuable, though having
Gmane around gives more flexibility in turning what would be mail back
into news.

I understand that drafts and sent messages could warrant their own
topics, but separating mail and news sets up the user to miss out on one
of Gnus's best qualities. I concede, though, that it will take a more
advanced user to come to appreciate this quality, and by then that same
user will have rebuilt his topic structure to match his new perspective.

-- 
Steven E. Harris

Re: Poll time: Topics should default to on or off?

[Tassilo Horn]

"Steven E. Harris" <seh@panix.com> writes:

>> A default layout might be ...
>>
>> [ Gnus ]
>>   [ Mail ]
>>   [ News ]
>>   [ Drafts ]
>>   [ Sent ]
>
> [...]
>
> I understand that drafts and sent messages could warrant their own
> topics, but separating mail and news sets up the user to miss out on
> one of Gnus's best qualities.

IMHO, putting sent mail into a separate group is a stupid convention
(except for mailinglists), and I'd refrain from suggesting that this is
the preferred way of organizing your mail in Gnus.  gcc-self is so much
better.

Bye,
Tassilo
-- 
Sent from my Emacs

Re: Poll time: Topics should default to on or off?

[Steven E. Harris]

Tassilo Horn <tassilo@member.fsf.org> writes:

> gcc-self is so much better.

Do you do this for even your primary "inbox", whereby email you send
winds up in the same place as email you receive? I guess that could
allow you to see proper threads develop in your inbox, just like mailing
lists.

I've never been able to convince myself to try that with Gnus, given
that the various other email clients I use against the same mailboxes
can't even conceive of such a thing. I'd still wind up with the messages
sent by the other clients off in a separate group.

-- 
Steven E. Harris

Re: Poll time: Topics should default to on or off?

[Tassilo Horn]

"Steven E. Harris" <seh@panix.com> writes:

Hi Steven,

>> gcc-self is so much better.
>
> Do you do this for even your primary "inbox", whereby email you send
> winds up in the same place as email you receive?

Yes.  I do that for all mail groups except mailinglists.

> I guess that could allow you to see proper threads develop in your
> inbox, just like mailing lists.

Exactly.

> I've never been able to convince myself to try that with Gnus, given
> that the various other email clients I use against the same mailboxes
> can't even conceive of such a thing.

KDE's mail client KMail also has an option "Keep replies in current
folder".

> I'd still wind up with the messages sent by the other clients off in a
> separate group.

Well, when I sometimes use the webclient, I manually move sent mail to
the right group.  Of course, that's a bit annoying when you have to do
that for each and every mail.  OTOH, I really don't want to read my mail
as non-threaded hunks.

So I'd suggest trying it out yourself.

Bye,
Tassilo

Re: Poll time: Topics should default to on or off?

[Matt Lundin]

Tassilo Horn <tassilo@member.fsf.org> writes:

> "Steven E. Harris" <seh@panix.com> writes:
>
> Hi Steven,
>
>>> gcc-self is so much better.
>>
>> Do you do this for even your primary "inbox", whereby email you send
>> winds up in the same place as email you receive?
>
> Yes.  I do that for all mail groups except mailinglists.
>

A bit OT: Might I asked what you do with mail that is not initiated from
a group? Do you first navigate to the correct gnus mail group before
sending mail?

I write many quick messages by calling gnus-msg-mail from non-Gnus
buffers. AFAICT, gcc-self isn't much use in this case, because either a)
I do not have an open Gnus group or b) I have recently been browsing
some other Gnus group unrelated to the current email (causing the sent
mail to be filed to that folder).

>> I'd still wind up with the messages sent by the other clients off in a
>> separate group.
>
> Well, when I sometimes use the webclient, I manually move sent mail to
> the right group.  Of course, that's a bit annoying when you have to do
> that for each and every mail.  OTOH, I really don't want to read my mail
> as non-threaded hunks.

I imagine another solution to keeping threads intact is to save all sent
mails to an inbox and/or mail spool and then to rely on splitting and
the registry to refile them to the correct groups.

Best,
Matt

Re: Poll time: Topics should default to on or off?

[Tassilo Horn]

Matt Lundin <mdl@imapmail.org> writes:

Hi Matt,

>>>> gcc-self is so much better.
>>>
>>> Do you do this for even your primary "inbox", whereby email you send
>>> winds up in the same place as email you receive?
>>
>> Yes.  I do that for all mail groups except mailinglists.
>
> A bit OT: Might I asked what you do with mail that is not initiated
> from a group? Do you first navigate to the correct gnus mail group
> before sending mail?

Nope, you don't have to enter a group to apply its posting styles:

,----[ C-h k m ]
| m runs the command gnus-group-mail, which is an interactive compiled Lisp
| function in `gnus-msg.el'.
| 
| It is bound to m, <menu-bar> <Gnus> <Send a mail>.
| 
| (gnus-group-mail &optional ARG)
| 
| Start composing a mail.
| If ARG, use the group under the point to find a posting style.
| If ARG is 1, prompt for a group name to find the posting style.
`----

> I write many quick messages by calling gnus-msg-mail from non-Gnus
> buffers. AFAICT, gcc-self isn't much use in this case, because either
> a) I do not have an open Gnus group or b) I have recently been
> browsing some other Gnus group unrelated to the current email (causing
> the sent mail to be filed to that folder).

Hm, indeed.  Using that function seems to apply the posting style of the
group that's currently opened with a summary buffer.  Currenly I have 2
open summaries and when using gnus-msg-mail it seems both posting styles
are applied leading to some strange mix...

Using gnus-group-mail from other buffers than *Group* and selecting some
group doesn't work satisfactory as well...

>>> I'd still wind up with the messages sent by the other clients off in
>>> a separate group.
>>
>> Well, when I sometimes use the webclient, I manually move sent mail
>> to the right group.  Of course, that's a bit annoying when you have
>> to do that for each and every mail.  OTOH, I really don't want to
>> read my mail as non-threaded hunks.
>
> I imagine another solution to keeping threads intact is to save all sent
> mails to an inbox and/or mail spool and then to rely on splitting and
> the registry to refile them to the correct groups.

Yes, that might work.  But I do splitting solely on the server side
using sieve...

Bye,
Tassilo
-- 
Sent from my Emacs

Re: Poll time: Topics should default to on or off?

[Steinar Bang]

>>>>> Tassilo Horn <tassilo@member.fsf.org>:

> "Steven E. Harris" <seh@panix.com> writes:

>> Do you do this for even your primary "inbox", whereby email you send
>> winds up in the same place as email you receive?

> Yes.  I do that for all mail groups except mailinglists.

I filter my personal email addresses into separate folders.  I don't use
gcc.  I use bcc and let the server side mail filters that handle
incoming mail send it to the same folder as incoming email to that
address.

That works in a MUA neutral manner.  I've had Evolution and Emacs
coexist on the same folders.

Mailing lists I handle differently: I don't BCC.  I let the list manager
bounce the message back to me.  In that way I know that the message has
actually reached the list.

Not that there are all that many mailing lists anymore, thanks to gmane.

Re: Poll time: Topics should default to on or off?

[Ted Zlatanov]

On Tue, 21 Dec 2010 22:14:51 +0100 Tassilo Horn <tassilo@member.fsf.org> wrote: 

TH> IMHO, putting sent mail into a separate group is a stupid convention
TH> (except for mailinglists), and I'd refrain from suggesting that this is
TH> the preferred way of organizing your mail in Gnus.  gcc-self is so much
TH> better.

I'd say both have advantages.  Reiner Steib has a really good system for
organizing sent mail with Gnus but I don't think he's ever explained it
fully :)

Ted

Re: Poll time: Topics should default to on or off?

[Lars Magne Ingebrigtsen]

"Steven E. Harris" <seh@panix.com> writes:

>> A default layout might be ...
>>
>> [ Gnus ]
>>   [ Mail ]
>>   [ News ]
>>   [ Drafts ]
>>   [ Sent ]
>
> I thought that one of the selling points of Gnus is that it lets one
> manage news and email similarly. For years I've had mail groups and news
> groups together within topics -- organized by discussion topic, not by
> the technology by which I collect or access the messages on that
> discussion topic.

Yes...  but as a default, it might make sense anyway.  People can just
kill the topics if they don't want them.

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

Re: Poll time: Topics should default to on or off?

[Steinar Bang]

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

> Yes...  but as a default, it might make sense anyway.  People can just
> kill the topics if they don't want them.

I think he means that if they aren't shown the possibility of mixing
groups, the possibility may not occur to them?  Maybe they even will
think tha topics have to be there, and that mail groups have to go into
mail, and news groups have to go into news.

In that case it may be better to leave topics off by default...?

Re: Poll time: Topics should default to on or off?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> I think he means that if they aren't shown the possibility of mixing
> groups, the possibility may not occur to them?  Maybe they even will
> think tha topics have to be there, and that mail groups have to go into
> mail, and news groups have to go into news.

It's possible...  but, like, that's not really a catastrophe, is it?

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

Re: Poll time: Topics should default to on or off?

[Steinar Bang]

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

> It's possible...  but, like, that's not really a catastrophe, is it?

Nope.

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> I cannot speak for Apple Mail, but at least KMail opens a dialog that
> lets you subscribe to individual groups when adding a new account.

Is there really that much of a difference between clicketing-clicketing
on all the groups that you want to have, and leaning on the `C-k' key to
get rid of all the stuff you don't want?  (Or `C-SPC' and `C-w' to
delete all the groups in the region...)

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

Re: Streamlining first-time Gnus usage

[Philipp Haselwarter]

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

> I've now made netrc.el cache in-memory the contents of the
> ~/.authinfo.gpg file.  It uses state-of-the-art rot13+base64 encryption
> to make it impossible for root to look at /dev/kmem to find out what the
> passwords really are.
rot13+base64 encryption? Like, rot13+base64 instead of encryption? Don't
get it :\

Wouldn't that be what
`epa-file-cache-passphrase-for-symmetric-encryption' is for?


-- 
Philipp Haselwarter

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Philipp Haselwarter <philipp.haselwarter@gmx.de> writes:

> rot13+base64 encryption? Like, rot13+base64 instead of encryption? Don't
> get it :\

It's like a joke.

> Wouldn't that be what
> `epa-file-cache-passphrase-for-symmetric-encryption' is for?

That caches the password for the file itself.  (In plain text in-memory,
by the way.)

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

Re: Streamlining first-time Gnus usage

[Philipp Haselwarter]

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

> Philipp Haselwarter <philipp.haselwarter@gmx.de> writes:
>
>> rot13+base64 encryption? Like, rot13+base64 instead of encryption? Don't
>> get it :\
>
> It's like a joke.
relieving, for a moment I wasn't sure :)

>> Wouldn't that be what
>> `epa-file-cache-passphrase-for-symmetric-encryption' is for?
>
> That caches the password for the file itself.  (In plain text in-memory,
> by the way.)

Oh awesomeness. I was hoping that'd be taken care of in a more sensible
way. But as it appears, just caching the passwords that have been
demanded would actually improve the situation; I could turn
epa-file-cache.. off.


-- 
Philipp Haselwarter

Re: Streamlining first-time Gnus usage

[Ted Zlatanov]

On Mon, 13 Dec 2010 22:57:56 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Philipp Haselwarter <philipp.haselwarter@gmx.de> writes:
>> rot13+base64 encryption? Like, rot13+base64 instead of encryption? Don't
>> get it :\

LMI> It's like a joke.

>> Wouldn't that be what
>> `epa-file-cache-passphrase-for-symmetric-encryption' is for?

LMI> That caches the password for the file itself.  (In plain text in-memory,
LMI> by the way.)

Nothing stored in Emacs' memory is reasonably secure (an attacker would
need very little effort to compromise such secrets).  The Secrets API is
the only reasonable way to manage secrets so only some of them leak into
Emacs.  But we discussed secure tokens that are only accessible in
special ways, right?  Those could store their contents in a more secure
way and at least mitigate the risks.

A very common theme in the security literature, a theme which even rank
amateurs like me can pick up, is that perfect security is impossible and
the game is about trading risk mitigation for convenience.  Emacs is
currently 100% on the convenience side and thus full of security risks.
I'm not sure that the Emacs community would welcome a move in the other
direction.  They may say so, but I would be suspicious even then.  If
they can't even get package namespaces together...

Ted

Re: Streamlining first-time Gnus usage

[Francis Moreau]

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

> Julien Danjou <julien@danjou.info> writes:
>
>> I don't think assistants is a good solution. That would just hide a
>> complexity. But things should not be complex.
>
> They shouldn't, but sometimes they are...  That is, it's more pleasant
> for the user if we query the user instead of making a wrong guess, in
> general. 
>
>>> (setq gnus-select-method '(nnimap "imap.gmail.com"))
>>
>> FWIW, it took me several weeks until I understand what was the
>> differences between gnus-select-method and
>> gnus-secondary-select-methods. That could be a starting point.
>
> After the `g' rework, the only difference real is in the group name.
> That is, the primary method groups don't have prefixed names, while the
> rest do.  We could hide that by not displaying the prefixes (by default)
> in the group buffer, but it's a leaky thing...  and doing a total rework
> here is ... eh...  Kinda a lot of work.
>
> But we could recommend doing stuff like
>
> (gnus-add-method '(nnimap "imap.gmail.com"))
> (gnus-add-method '(nntp "news.gmane.org"))
>
> instead of exposing the primary/secondary stuff directly.  I mean, if we
> just drop the idea of a primary method altogether, and just say that
> they're all secondary, then everything is fine.  Except for the long,
> prefixed group names...

+1000000

This is the first thing I found weird, hard to understand (I think I'm
still missing things), no intuitive in Gnus.

If I remember correctly, groups from primary server are displayed with
prefix where as secondary groups are not.

For me (as a user), that doesn't seem to be a big deal but since Gnus
offering primary and secondary server, there must be something else
very important I was missing.

Something I found later, IIRC, is that secondary servers can be changed
easily where as changing the primary one is hard, but I'm not sure.

I don't think the differences are really explained in the info pages and
I believe it gives a really bad feeling for the first Gnus experience.

-- 
Francis

Re: Streamlining first-time Gnus usage

[Adam Sjøgren]

On Tue, 14 Dec 2010 09:55:03 +0100, Francis wrote:

> If I remember correctly, groups from primary server are displayed with
> prefix where as secondary groups are not.

It is the other way around.

> For me (as a user), that doesn't seem to be a big deal but since Gnus
> offering primary and secondary server, there must be something else
> very important I was missing.

Nah.


   :-),

    Adam

-- 
 "Accept the mystery!"                                        Adam Sjøgren
                                                         asjo@koldfront.dk

Unmark old messages

[Johnny]

Sorry for disturbing your time, but it seems I cannot succeed in marking
old messages that are not flagged as unread. Any ideas?
-- 
Johnny
http://www.seashepherd.org/

Re: Unmark old messages

[Adam Sjøgren]

On Tue, 15 Feb 2011 21:04:43 +0000, Johnny wrote:

> Sorry for disturbing your time, but it seems I cannot succeed in marking
> old messages that are not flagged as unread. Any ideas?

What did you try? What happened? What did you expect to happen?

Is M-u what you are looking for?


  Best regards,

    Adam

-- 
 "Examination and mastering of a new highly                   Adam Sjøgren
  intellectual equipment was a hard labour."             asjo@koldfront.dk

Re: Unmark old messages

[Johnny]

asjo@koldfront.dk (Adam Sjøgren) writes:
> What did you try? What happened? What did you expect to happen?
>
> Is M-u what you are looking for?
I tried M-P-b and u (or M-u or M-& u or M-& U) and expected ALL messages
to be marked as unread, and ideally I would like to mark all messages
except for the ticked ones (!) as unread.

I am sure this should be easy, but cannot for my life make it out and am
sorry to waste your time on this.

-- 
Johnny
http://www.seashepherd.org/

Re: Unmark old messages

[Adam Sjøgren]

On Tue, 15 Feb 2011 21:39:17 +0000, Johnny wrote:

> I tried M-P-b and u (or M-u or M-& u or M-& U) and expected ALL
> messages to be marked as unread, and ideally I would like to mark all
> messages except for the ticked ones (!) as unread.

Ah, ok. You can do that by first marking the messages you want to
process, using #, and then you can go C-u M-u to "unread" them all at
once.

Maybe you can explain why you want to do this? Perhaps the problem can
be solved in some other way (like always showing read messages in some
groups).

> I am sure this should be easy, but cannot for my life make it out and
> am sorry to waste your time on this.

Don't worry about wasting our time - if people don't have time, they
just don't read or don't answer.


  Best regards,

    Adam

-- 
 "Examination and mastering of a new highly                   Adam Sjøgren
  intellectual equipment was a hard labour."             asjo@koldfront.dk

Re: Unmark old messages

[Johnny]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Ah, ok. You can do that by first marking the messages you want to
> process, using #, and then you can go C-u M-u to "unread" them all at
> once.
Hmmm, I think this cleared the 'read' mark, but now (due to my error as
below), the 'tick' is still there for ALL articles...

>
> Maybe you can explain why you want to do this? Perhaps the problem can
> be solved in some other way (like always showing read messages in some
> groups).
I marked a bunch of messages as read by accident while configuring a
second imap server, and tried to revert it. Attempting this, I
unfortunately marked all as 'ticked'! So, for the future, I'd like to
understand: 

1) How to remove ALL marks from articles in a Summary buffer.

2) How to remove all read marks (E, o and what more?), and leave other
marks (e.g. 'ticks' intact.

Thanks,
-- 
Johnny
http://www.seashepherd.org/

Re: Unmark old messages

[Adam Sjøgren]

On Tue, 15 Feb 2011 22:28:49 +0000, Johnny wrote:

> 1) How to remove ALL marks from articles in a Summary buffer.

M-u on them?

> 2) How to remove all read marks (E, o and what more?), and leave other
> marks (e.g. 'ticks' intact.

Dunno.


  Best regards,

-- 
 "Examination and mastering of a new highly                   Adam Sjøgren
  intellectual equipment was a hard labour."             asjo@koldfront.dk

Re: Unmark old messages

[Johnny]

asjo@koldfront.dk (Adam Sjøgren) writes:

>> 1) How to remove ALL marks from articles in a Summary buffer.
>
> M-u on them?
>
>> 2) How to remove all read marks (E, o and what more?), and leave other
>> marks (e.g. 'ticks' intact.
>
> Dunno.
Thanks, I have eventually manged to get all articles as unread (w/o
preserving the 'ticks' though), and am at square one again.

Thanks for the advice though, it got me in the right direction although
the 2nd query remains....

-- 
Johnny
http://www.seashepherd.org/

Re: Streamlining first-time Gnus usage

[Ted Zlatanov]

On Mon, 13 Dec 2010 17:29:55 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Julien Danjou <julien@danjou.info> writes:
>> I don't think assistants is a good solution. That would just hide a
>> complexity. But things should not be complex.

LMI> They shouldn't, but sometimes they are...  That is, it's more pleasant
LMI> for the user if we query the user instead of making a wrong guess, in
LMI> general. 

Assistants are good when you have a tree structure of preference sheets
and each one can have many option fields.  For example, setting up the
list of servers is a classic Assistant need, while asking a y/n question
is not.

Obviously I say this, having avoided working on the Assistants for 5+
years now.  But I have excuses!

Ted

Re: Streamlining first-time Gnus usage

[Ludovic Courtès]

Hi,

>>> (setq gnus-select-method '(nnimap "imap.gmail.com"))
>>
>> FWIW, it took me several weeks until I understand what was the
>> differences between gnus-select-method and
>> gnus-secondary-select-methods. That could be a starting point.
>
> After the `g' rework, the only difference real is in the group name.

Would it be possible to display abbreviated prefixes, akin to how ERC
abbreviates channel names?

> But we could recommend doing stuff like
>
> (gnus-add-method '(nnimap "imap.gmail.com"))
> (gnus-add-method '(nntp "news.gmane.org"))

How about a declarative approach, like:

  (define-gnus-methods '((nnimap ...) ...))

I think it’d make it harder to shoot oneself in the foot, e.g., when
re-evaluating ~/.gnus.

Thanks,
Ludo’.

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

ludo@gnu.org (Ludovic Courtès) writes:

> Would it be possible to display abbreviated prefixes, akin to how ERC
> abbreviates channel names?

That's definitely a possibility.  A typical group name is

nnimap+imap.gmail.com:INBOX

which could be displayed as, er...  uhm...

imap+gmail:INBOX

?  The heuristic here is that you drop the "nn", the ".com" suffix
(well, all suffixes), and known stuff like "imap", "news", "nntp" from
the name before displaying.

> How about a declarative approach, like:
>
>   (define-gnus-methods '((nnimap ...) ...))
>
> I think it’d make it harder to shoot oneself in the foot, e.g., when
> re-evaluating ~/.gnus.

That would kinda be the same as

(setq gnus-methods
      '((nnimap ...)
        (nntp ...)))

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

Re: Streamlining first-time Gnus usage

[Ludovic Courtès]

Hi!

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

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Would it be possible to display abbreviated prefixes, akin to how ERC
>> abbreviates channel names?
>
> That's definitely a possibility.  A typical group name is
>
> nnimap+imap.gmail.com:INBOX

Using ERC-like heuristics, it would be “n+i.g.c:INBOX”.  But if there’s
also, say, an “nnimap+imap.gmurf.org:INBOX”, then it the first one would
be abbreviated as “n+i.gma.c:INBOX”, to disambiguate.

Hmm I now realize this may not be very readable...

>> How about a declarative approach, like:
>>
>>   (define-gnus-methods '((nnimap ...) ...))
>>
>> I think it’d make it harder to shoot oneself in the foot, e.g., when
>> re-evaluating ~/.gnus.
>
> That would kinda be the same as
>
> (setq gnus-methods
>       '((nnimap ...)
>         (nntp ...)))

Yes.  I was suggesting not to advocate an imperative approach like
‘gnus-add-method’.

Thanks,
Ludo’.

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

ludo@gnu.org (Ludovic Courtès) writes:

> Using ERC-like heuristics, it would be “n+i.g.c:INBOX”.  But if there’s
> also, say, an “nnimap+imap.gmurf.org:INBOX”, then it the first one would
> be abbreviated as “n+i.gma.c:INBOX”, to disambiguate.
>
> Hmm I now realize this may not be very readable...

Not extremely.  :-)

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

Re: Streamlining first-time Gnus usage

[Reiner Steib]

On Thu, Dec 16 2010, Lars Magne Ingebrigtsen wrote:

> That's definitely a possibility.  A typical group name is
>
> nnimap+imap.gmail.com:INBOX
>
> which could be displayed as, er...  uhm...
>
> imap+gmail:INBOX
>
> ?  The heuristic here is that you drop the "nn", the ".com" suffix
> (well, all suffixes), and known stuff like "imap", "news", "nntp" from
> the name before displaying.

What's wrong with using the name (?) of the method.  (I'm not sure if
we call it the "name" of the method, because I couldn't find the
correct term in the manual.)

I have ...

,----[ <f1> v gnus-select-method RET ]
| Its value is (nntp "localhost")
`----

,----[ <f1> v gnus-secondary-select-methods RET ]
| ((nnimap "kiz"
| 	 (nnimap-address "imap.kiz.somewhere.invalid") [...]
|  (nnml "personal" [...]
|  (nnml "news"     [...]
|  (nnml "archive"  [...]
`----

... and in my Group buffer, I have:

        0: personal:Some.One
        0: kiz:INBOX
        0: kiz:Sent
        0: kiz:Trash
       29: gmane.emacs.devel
       28: gmane.emacs.bugs
        0: news:comp.emacs
        0: archive:gmane.emacs.gnus.general

The relevant format char in my `gnus-group-line-format' is:

,----
| %c    Short (collapsed) group name.  See `gnus-group-uncollapsed-levels'.
`----

However, I can't use the short name to `j'ump to the group or do any
other operations.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> What's wrong with using the name (?) of the method.  (I'm not sure if
> we call it the "name" of the method, because I couldn't find the
> correct term in the manual.)

I almost never give the methods names.  I just put the server name into
the name slot...

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

Re: Streamlining first-time Gnus usage

[Richard Riley]

Julien Danjou <julien@danjou.info> writes:

> On Mon, Dec 13 2010, Lars Magne Ingebrigtsen wrote:
>
>> The mission: To make first-time Gnus usage not suck.
>
> Good idea. :)
>
>> (Long-term we want to use Assistants, but let's just contemplate Gnus
>> defaults for the time being.)
>
> I don't think assistants is a good solution. That would just hide a
> complexity. But things should not be complex.
>
>> So, created a brand new test user, and I put the following in my .emacs
>> file:
>>
>> (setq gnus-select-method '(nnimap "imap.gmail.com"))
>
> FWIW, it took me several weeks until I understand what was the
> differences between gnus-select-method and
> gnus-secondary-select-methods. That could be a starting point.

Could you explain? Many old hands dont even use the primary method at
all anymore from what I have gathered.

Re: Streamlining first-time Gnus usage

[Eric Abrahamsen]

On Tue, Dec 14 2010, Lars Magne Ingebrigtsen wrote:

> The mission: To make first-time Gnus usage not suck.

As a recent first-time Gnus user, the real suckage came with importing
existing old mail. Getting ride of the primary/secondary server
distinction seems like a great idea, but I do hope that some attention
can be paid to the mail importation process as well. I'd be happy to
self-induce some flashbacks if a newbie perspective is needed.

Eric

Re: Streamlining first-time Gnus usage

[Steinar Bang]

>>>>> Eric Abrahamsen <eric@ericabrahamsen.net>:

> As a recent first-time Gnus user, the real suckage came with importing
> existing old mail. Getting ride of the primary/secondary server
> distinction seems like a great idea, but I do hope that some attention
> can be paid to the mail importation process as well. I'd be happy to
> self-induce some flashbacks if a newbie perspective is needed.

What format was the old email email in?  mbox?  mh?  maildir?

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> As a recent first-time Gnus user, the real suckage came with importing
> existing old mail.

I've never actually imported any mail from anywhere, so I don't know
what the issues are.  Parsing Outlook mboxes or something?

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

Re: Streamlining first-time Gnus usage

[Eric Abrahamsen]

On Thu, Dec 16 2010, Lars Magne Ingebrigtsen wrote:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> As a recent first-time Gnus user, the real suckage came with importing
>> existing old mail.
>
> I've never actually imported any mail from anywhere, so I don't know
> what the issues are.  Parsing Outlook mboxes or something?

Yeah, it's an issue one never thinks about once you've got it working,
so I think it's an easy candidate for developer overlook. Even I, three
months later, am having trouble remembering why I lost so much hair.

In my case I was snarfing mboxes from an Apple Mail installation. I was
following the instructions under 6.4.8 "Incorporating Old Mail",
creating a nndoc group and then respooling. If nothing went wrong it was
okay, but the minute it choked, everything went to hell and it was
nearly impossible to get back on track. I ended up with three or four
duplicate copies of emails and some emails that I never could import. I
didn't understand the precariousness of the .newsrc.eld file back then,
and kept trying to change the nnml article numbers, and nothing worked,
and I felt like gnus hated me. My nnml article numbers were approaching
100,000 by the time I figured it out (gnus-group-compact-group was a
godsend). This would be a prime candidate for Assistance, I think.

Even now, I have a heck of a time importing emails. While I was screwing
up moving my gnus installation into a different directory I got a
spurious Mail/misc directory with a single email in it, and there is
apparently no command to take that email and put it into my gnus system.
I tried all kinds of temporary secondary server methods, then just ended
up renaming the mail file to the next nnml number, killing emacs, and
doing what you're not supposed to do: editing .newsrc.eld and the active
file.

I think a small set of importation commands (and nuclear-option restart
commands) would be great. In particular something that abstracted out
the whole nndoc-respooling process, with some sort of unwind protection,
so that the inevitable blowups didn't wreck one's whole installation.
That might be a daunting amount of work, but anyway I think it would
make things a lot more friendly for new users…

Thanks,
Eric

Re: Streamlining first-time Gnus usage

[Steinar Bang]

>>>>> Eric Abrahamsen <eric@ericabrahamsen.net>:

> Even now, I have a heck of a time importing emails. While I was
> screwing up moving my gnus installation into a different directory I
> got a spurious Mail/misc directory with a single email in it, and
> there is apparently no command to take that email and put it into my
> gnus system.

Did you try open that single email as an nnmbox folder?  After that, you
could `B m' it to a different folder.

I've done most of my migration using `B m'.

I started out with RMAIL as (almost) the first email client I used on a
regular basis (there was a DECNet and an EARN client I had, but they
were so inconvenient to get at, they never got out of the
experimentation stage).

I quickly moved on to VM, since that let me have mbox folders that other
email tools could read.

When the MIME talk started in 1993 or thereabouts, there were no MIME
plans for VM.  But there were an least one non-emacs MH client that
supported MIME.  So I moved to having my folders as MH and using mh-e
and mew, until I finally made the decision to go all gnus (in 1995 or
1996 or thenabouts). 

Then I used nnmh and nntp until the nnmh folders were transformed into
nnml.  And then nnimap hit the stage and I used a mix of nnml and nnimap
and nntp.  And a mix of server side and client side filtering.

In 2001 I finally dropped nnml, and `B m'-d all the nnml email into
mailboxes on my private IMAP server (a cyrus server... that I had to
move into twice, because I had to patch cyrus to not strip the 8th bit
and ruin all of my just-send-8 emails from the nineties).

Since then I've run a combination of nntp and nnimap.  Sometimes two
nnimap servers, sometimes just my personal nnimap server.

When migrating servers I have talked to both servers and `B m'-d the
stuff I have cared to keep.

But I digress...

Re: Streamlining first-time Gnus usage

[Eric Abrahamsen]

On Thu, Dec 16 2010, Steinar Bang wrote:

>>>>>> Eric Abrahamsen <eric@ericabrahamsen.net>:
>
>> Even now, I have a heck of a time importing emails. While I was
>> screwing up moving my gnus installation into a different directory I
>> got a spurious Mail/misc directory with a single email in it, and
>> there is apparently no command to take that email and put it into my
>> gnus system.
>
> Did you try open that single email as an nnmbox folder?  After that, you
> could `B m' it to a different folder.
>
> I've done most of my migration using `B m'.
>
> I started out with RMAIL as (almost) the first email client I used on a
> regular basis (there was a DECNet and an EARN client I had, but they
> were so inconvenient to get at, they never got out of the
> experimentation stage).
>
> I quickly moved on to VM, since that let me have mbox folders that other
> email tools could read.
>
> When the MIME talk started in 1993 or thereabouts, there were no MIME
> plans for VM.  But there were an least one non-emacs MH client that
> supported MIME.  So I moved to having my folders as MH and using mh-e
> and mew, until I finally made the decision to go all gnus (in 1995 or
> 1996 or thenabouts). 
>
> Then I used nnmh and nntp until the nnmh folders were transformed into
> nnml.  And then nnimap hit the stage and I used a mix of nnml and nnimap
> and nntp.  And a mix of server side and client side filtering.
>
> In 2001 I finally dropped nnml, and `B m'-d all the nnml email into
> mailboxes on my private IMAP server (a cyrus server... that I had to
> move into twice, because I had to patch cyrus to not strip the 8th bit
> and ruin all of my just-send-8 emails from the nineties).
>
> Since then I've run a combination of nntp and nnimap.  Sometimes two
> nnimap servers, sometimes just my personal nnimap server.
>
> When migrating servers I have talked to both servers and `B m'-d the
> stuff I have cared to keep.
>
> But I digress...

Man, that was a scary story. Are you trying to tell us kids that we
don't have it so bad? :)

Re: Streamlining first-time Gnus usage

[Steinar Bang]

>>>>> Eric Abrahamsen <eric@ericabrahamsen.net>:

> On Thu, Dec 16 2010, Steinar Bang wrote:

>> Did you try open that single email as an nnmbox folder?  After that, you
>> could `B m' it to a different folder.
[snip!]

> Man, that was a scary story. Are you trying to tell us kids that we
> don't have it so bad? :)

Nah... once us old coots starts rambling, it's hard to stop.

But there was a real question before the rambling started.  Probably got
lost in the noise.  Quoted above.

Re: Streamlining first-time Gnus usage

[Bjørn Mork]

Steinar Bang <sb@dod.no> writes:

> I started out with RMAIL as (almost) the first email client I used on a
> regular basis (there was a DECNet and an EARN client I had, but they
> were so inconvenient to get at, they never got out of the
> experimentation stage).
>
> I quickly moved on to VM, since that let me have mbox folders that other
> email tools could read.
>
> When the MIME talk started in 1993 or thereabouts, there were no MIME
> plans for VM.  But there were an least one non-emacs MH client that
> supported MIME.  So I moved to having my folders as MH and using mh-e
> and mew, until I finally made the decision to go all gnus (in 1995 or
> 1996 or thenabouts). 
>
> Then I used nnmh and nntp until the nnmh folders were transformed into
> nnml.  And then nnimap hit the stage and I used a mix of nnml and nnimap
> and nntp.  And a mix of server side and client side filtering.
>
> In 2001 I finally dropped nnml, and `B m'-d all the nnml email into
> mailboxes on my private IMAP server (a cyrus server... that I had to
> move into twice, because I had to patch cyrus to not strip the 8th bit
> and ruin all of my just-send-8 emails from the nineties).

Lucky you.  While living in a shoe box we had to use clients like elm,
eudora and even mr2ice.  When finally moving to IMAP, the most modern
migrating tool I could find was formail(1).  If you try to tell the kids
this today....


Bjørn

Re: Streamlining first-time Gnus usage

[Ted Zlatanov]

On Fri, 17 Dec 2010 15:54:37 +0100 Bjørn Mork <bjorn@mork.no> wrote: 

BM> Steinar Bang <sb@dod.no> writes:
>> I started out with RMAIL as (almost) the first email client I used on a
>> regular basis (there was a DECNet and an EARN client I had, but they
>> were so inconvenient to get at, they never got out of the
>> experimentation stage).

BM> Lucky you.  While living in a shoe box we had to use clients like elm,
BM> eudora and even mr2ice.  When finally moving to IMAP, the most modern
BM> migrating tool I could find was formail(1).  If you try to tell the kids
BM> this today....

*cough* *hack*

Right you are, Bjørn-iah, right you are.

But you were lucky!  I started reading e-mail on a VAX that crashed
twice a day and took human sacrifices.  Fortunately the random sort was
broken so being a Zlatanov, I was safe.

Then I used UCB mail (mailx today) on AIX and APPRECIATED what I had,
and called it $HOME.  There was no SCROLLBACK BUFFER.  There were no
ARROW KEYS.  The $MAIL file got corrupted daily and we[1] LIKED it.  And
the sysadmin would read our mail, break our termcaps, steal our print
quota, and make us go to bed EARLY by shutting down at 8 PM[2].

Ted

[1] Boston University class of 1997

[2] BOFH SIG president for two years in a row until he got electrocuted
by his successor

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> In my case I was snarfing mboxes from an Apple Mail installation. I was
> following the instructions under 6.4.8 "Incorporating Old Mail",
> creating a nndoc group and then respooling. If nothing went wrong it was
> okay, but the minute it choked, everything went to hell and it was
> nearly impossible to get back on track.

Right.  That's probably not been tested a lot.  Do you remember what
went wrong?

> I didn't understand the precariousness of the .newsrc.eld file back
> then, and kept trying to change the nnml article numbers, and nothing
> worked, and I felt like gnus hated me.

This is one of the reasons the .newsrc.eld file looks like it does -- so
that nobody would be tempted to edit it.  I mean, nobody tries to edit,
say, Thunderbird data files by hand...  perhaps Gnus should start
base64-ing the file before saving it.  :-)

> Even now, I have a heck of a time importing emails. While I was screwing
> up moving my gnus installation into a different directory I got a
> spurious Mail/misc directory with a single email in it, and there is
> apparently no command to take that email and put it into my gnus system.

nndir/nneething + `B c' should do the trick?

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

Re: Streamlining first-time Gnus usage

[Eric Abrahamsen]

On Fri, Dec 17 2010, Lars Magne Ingebrigtsen wrote:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> In my case I was snarfing mboxes from an Apple Mail installation. I was
>> following the instructions under 6.4.8 "Incorporating Old Mail",
>> creating a nndoc group and then respooling. If nothing went wrong it was
>> okay, but the minute it choked, everything went to hell and it was
>> nearly impossible to get back on track.
>
> Right.  That's probably not been tested a lot.  Do you remember what
> went wrong?

Just plain old parsing errors, I think. The error messages weren't that
helpful, it just told me a message couldn't be read, and that threw the
whole enchilada out the window.

>
>> I didn't understand the precariousness of the .newsrc.eld file back
>> then, and kept trying to change the nnml article numbers, and nothing
>> worked, and I felt like gnus hated me.
>
> This is one of the reasons the .newsrc.eld file looks like it does -- so
> that nobody would be tempted to edit it.  I mean, nobody tries to edit,
> say, Thunderbird data files by hand...  perhaps Gnus should start
> base64-ing the file before saving it.  :-)

I think import commands with error recovery would keep people from being
tempted to mess directly with that file (no obfuscation please!). But
the fact is, once something gets out of sync between what's in your
.newsrc.eld/active files, and what's actually in your directories,
you're pretty screwed.

>
>> Even now, I have a heck of a time importing emails. While I was screwing
>> up moving my gnus installation into a different directory I got a
>> spurious Mail/misc directory with a single email in it, and there is
>> apparently no command to take that email and put it into my gnus system.
>
> nndir/nneething + `B c' should do the trick?

I tried "directory", "maildir" and "file" in my mail sources, and
neither were able to parse the (gnus-produced) mail file, both left a
mail import crash log in my home directory. I don't know any other way
of getting mail into gnus. Anyway, I guess the point isn't solving my
particular problem here, but just to say that this whole area is far
from obvious, and I think a prime candidate for newbie-oriented
smoothing. Why not have a 'gnus-snarf-mail' command that can be pointed
at an mbox, a single-mail file or a directory, and then be reasonably
expected to spool those mails into its servers?

Why not, indeed, except that someone would have to write it. :)

E

Re: Streamlining first-time Gnus usage

[Lars Magne Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Why not have a 'gnus-snarf-mail' command that can be pointed at an
> mbox, a single-mail file or a directory, and then be reasonably
> expected to spool those mails into its servers?
>
> Why not, indeed, except that someone would have to write it. :)

Sounds like a good idea, but it'd have the same problems parsing the
individual file formats that Gnus has today.  If Gnus has those problems
today...

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

Re: Streamlining first-time Gnus usage

[Richard Riley]

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

> The mission: To make first-time Gnus usage not suck.
>
> (Long-term we want to use Assistants, but let's just contemplate Gnus
> defaults for the time being.)
>
> So, created a brand new test user, and I put the following in my .emacs
> file:
>
> (setq gnus-select-method '(nnimap "imap.gmail.com"))
>
> I then `M-x gnus', was prompted for username/password (fine), and then
> I'm asked whether I want to save the credentials (fine), and I'm then
> dumped into .gpg query hell (not fine, but Ted is fixing that, I think),
> and then I'm given a "warning" about a drafts groups being created
> (wtf?), and then I'm presented with this:
>
>        *: nndraft:queue
>        *: nndraft:drafts
>
> And that's all.
>
> So, obvious things to fix is:
>
> 1) get rid of messages saying:
>
>    Setting up drafts group
>    Warning: Setting up drafts group
>
> 2) don't create the queue group -- it should be deferred until it's
>    needed (if ever)
>
> 3) make sure the draft group is activated, so that it isn't shown.  It's
>    empty, so it shouldn't be
>
> 4) subscribe all the groups from the primary select method (and activate
>    them) if the primary select method is a mail method (like nnimap)
>
> Thoughts?   

This is a brilliant and long overdue initiative. Getting gnus to work
"out of the box" with gmail would win over a lot of people - especially
now imap is much more efficient. Its amazing how often gmail issues pop
up in #emacs and elsewhere and people tend to give up disillusioned and
confused. Nice one.