nov and procmail compatability?

nov and procmail compatability?

[Stan Norton]

The code that I use to configure splitting by procmail (scarfed from
some post years ago) suggests that " nnml-nov-is-evil t" should be
set. I don't understand why.

Lack of nov breaks the transport functions of nnir.  Us there a
compelling reason to not use nov after splitting with procmail?

Thanks.

Re: nov and procmail compatability?

[Harry Putnam]

Stan Norton <stan@stannorton.com> writes:

> The code that I use to configure splitting by procmail (scarfed from
> some post years ago) suggests that " nnml-nov-is-evil t" should be
> set. I don't understand why.
> 
> Lack of nov breaks the transport functions of nnir.  Us there a
> compelling reason to not use nov after splitting with procmail?


I found that same example mnths ago when setting up procmail.  In the
course of getting it setup and posting here about how to do so, I
found out I didn't need it and have been running for months with out
it.

Current code for procmail is:

;; ********** begin procmail *********
(setq nnmail-use-procmail t)
(setq mail-sources
      '((file      :path "/var/spool/mail/reader")
        (directory :path "/home/reader/spool/"
                   :suffix ".in")))
;;********** end procmail ******

Re: nov and procmail compatability?

[Kai Großjohann]

Stan Norton <stan@stannorton.com> writes:

> The code that I use to configure splitting by procmail (scarfed from
> some post years ago) suggests that " nnml-nov-is-evil t" should be
> set. I don't understand why.

This depends on how you do your procmail stuff.  Here's how you
_should_ use it:

Tell procmail to write messages for the nnml:foo.bar group into the
file ~/procmail/foo.bar.in, and tell Gnus to fetch mail from that
directory, like so:

(add-to-list 'mail-sources
             '(directory :path "/home/jrl/procmail/"
                         :suffix ".in"))

Here's how you should _not_ use it:

Tell procmail to write messages for the nnml:foo.bar group into the
directory ~/Mail/foo/bar/ (or ~/Mail/foo.bar/, depending on the
use-long-filenames setting), numbering files as it goes along.

But if you do use the second method, then it is possible to set
nnml-nov-is-evil to t to make it slightly less horrible.  You can also
tell Gnus to never delete the last message to make another epsilon of
difference.  But you should really use the first method.

Why is the second method bad?  Because Gnus gets really really REALLY
upset when some other program messes with its files (in ~/Mail/).
Don't do that.

kai
-- 
I like BOTH kinds of music.

Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Jorge Godoy]

Harry Putnam <reader@newsguy.com> writes:


Harry, forgive me but I'm getting your message as an example. :-) 


> (setq nnmail-use-procmail t)
> (setq mail-sources
>       '((file      :path "/var/spool/mail/reader")

Since this backend if for fetching messages from a file...

>         (directory :path "/home/reader/spool/"

... and this one from a directory, couldn't we change :path on the
first to be :file since it would be more intuitive. 
At least we won't have things like this where we have a line with
:path "file" and in the line below :path "directory/". 


What about it?



Be seeing you,
-- 
Godoy.	<godoy@conectiva.com> 

Departamento de Publicações
Publishing Department                   Conectiva S.A.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Kai Großjohann]

Jorge Godoy <godoy@conectiva.com> writes:

> ... and this one from a directory, couldn't we change :path on the
> first to be :file since it would be more intuitive. 

For consistency, this would have to be:

(file :file "/path/to/file")
(directory :directory "/path/to/dir/")

But I don't think it's a problem that the option is named :path, since
Customize users don't have to know the option name.  And novice users
are encouraged to use Customize, anyway.

kai
-- 
I like BOTH kinds of music.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Norbert Koch]

Jorge Godoy <godoy@conectiva.com> writes:

> Is there anyway to specify that Customize should save my Gnus
> configuration in, e.g., .gnus (or ~/emacs/gnus)? 
> 
> I don't like the way it puts everything in .emacs --- with no comments
> ;-) --- making it harder to understand it later or hard to get
> someone's configuration and adapting it for others to use.

If you want to do this, you've got to set the variable 'custom-file'
to your .gnus (or whatever you want), make your changes, and reset it
afterwards to its current value.

You might want to write a function for it.
norbert
-- 
..  I have a VISION!  It's a RANCID double-FISHWICH on an ENRICHED BUN!!

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Jorge Godoy]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Jorge Godoy <godoy@conectiva.com> writes:
> 
> > ... and this one from a directory, couldn't we change :path on the
> > first to be :file since it would be more intuitive. 
> 
> For consistency, this would have to be:
> 
> (file :file "/path/to/file")
> (directory :directory "/path/to/dir/")
> 
> But I don't think it's a problem that the option is named :path, since
> Customize users don't have to know the option name.  And novice users
> are encouraged to use Customize, anyway.

Is there anyway to specify that Customize should save my Gnus
configuration in, e.g., .gnus (or ~/emacs/gnus)? 

I don't like the way it puts everything in .emacs --- with no comments
;-) --- making it harder to understand it later or hard to get
someone's configuration and adapting it for others to use.


Be seeing you,
-- 
Godoy.	<godoy@conectiva.com> 

Departamento de Publicações
Publishing Department                   Conectiva S.A.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Per Abrahamsen]

Norbert Koch <nk@LF.net> writes:

> If you want to do this, you've got to set the variable 'custom-file'
> to your .gnus (or whatever you want), make your changes, and reset it
> afterwards to its current value.

It won't work, customize always write everything it knows has been
customize, so it will lead to duplicate setting and potential
confusion. 

Sufficiently new versions of customize have comments, other groupings
of settings will be available when theme support gets sufficiently
advanced.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Harry Putnam]

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

> Norbert Koch <nk@LF.net> writes:
> 
> > If you want to do this, you've got to set the variable 'custom-file'
> > to your .gnus (or whatever you want), make your changes, and reset it
> > afterwards to its current value.
> 
> It won't work, customize always write everything it knows has been
> customize, so it will lead to duplicate setting and potential
> confusion. 

I found this out (Per's observation) doing exactly what is suggested
above, but it can still work.  Since I'm elisp impaired I set the var
`custom-file' for a session, to a separate file all-together
`~/tmp.el'. 

Do whatever customizing thing it is and write it to that file.  As Per
says the whole mass of what emacs knows as done in customize is
written to the file too.  But with some care you can pick out the new
stuff, and transfer it wherever.   This is a good technique for elisp
impaired users, to see what the code is supposed to look like.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Jorge Godoy]

Harry Putnam <reader@newsguy.com> writes:

> I found this out (Per's observation) doing exactly what is suggested
> above, but it can still work.  Since I'm elisp impaired I set the var
> `custom-file' for a session, to a separate file all-together
> `~/tmp.el'. 
> 
> Do whatever customizing thing it is and write it to that file.  As Per
> says the whole mass of what emacs knows as done in customize is
> written to the file too.  But with some care you can pick out the new
> stuff, and transfer it wherever.   This is a good technique for elisp
> impaired users, to see what the code is supposed to look like.

Then, what's the difference of letting Customize write to you .emacs
file and cutting of what isn't needed? 

The problem is that you'll have to edit the output anyway... 

I'll keep editing things by hand. And, for people who do that, the
":path" problem is still present.

I don't know what is better: leaving everything in .emacs (newbie
using Customize), making Customize a little smarter placing a "(load
file.el)" in .emacs and adding everything to this file, making
Customize a _smart_ tool and besides doing that creating a file for
each main group, or, the last choice, editing things by hand. The best
solution for newbies would be having Customize to put changes in one
file per group. The best thing for experienced users would be grabbing
his newbie configuration from these files, cutting off what's not
needed and saving them. Elisp hackers would still be able to write
things by hand ;-)


See you,
-- 
Godoy.	<godoy@conectiva.com> 

Departamento de Publicações
Publishing Department                   Conectiva S.A.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Kai Großjohann]

Harry Putnam <reader@newsguy.com> writes:

> Do whatever customizing thing it is and write it to that file.  As Per
> says the whole mass of what emacs knows as done in customize is
> written to the file too.  But with some care you can pick out the new
> stuff, and transfer it wherever.   This is a good technique for elisp
> impaired users, to see what the code is supposed to look like.

Please do not advise people to use copy and paste on Custom-generated
Lisp code.  This might easily lead to people having more than one
custom-set-variables statement, and down that path lies madness.

Explanation of madness:  Suppose you have two custom-set-variables
statements in ~/.emacs, and the second (!) sets some variable foo.
Suppose you use Customize to change that variable, then save your
changes.  Customize will write all variable settings to the first
custom-set-variables statement.  Then, you start Emacs.  The two
custom-set-variables statements are executed, and the second one
wins.

What's the net effect?  You have used Customize to change a variable,
and it didn't work!

Yes, the implementation of Customize should probably be improved, but
right now, that's just the way it is.

kai
-- 
I like BOTH kinds of music.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Kai Großjohann]

Jorge Godoy <godoy@conectiva.com> writes:

> I'll keep editing things by hand. And, for people who do that, the
> ":path" problem is still present.

Okay.  So, let's take a poll:

Which of the following lines would you prefer:

[ ] (add-to-list 'mail-sources (file :path "/tmp/foo"))
[ ] (add-to-list 'mail-sources (file :file "/tmp/foo"))

kai
-- 
I like BOTH kinds of music.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Harry Putnam]

Jorge Godoy <godoy@conectiva.com> writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> > I found this out (Per's observation) doing exactly what is suggested
> > above, but it can still work.  Since I'm elisp impaired I set the var
> > `custom-file' for a session, to a separate file all-together
> > `~/tmp.el'. 
> > 
> > Do whatever customizing thing it is and write it to that file.  As Per
> > says the whole mass of what emacs knows as done in customize is
> > written to the file too.  But with some care you can pick out the new
> > stuff, and transfer it wherever.   This is a good technique for elisp
> > impaired users, to see what the code is supposed to look like.
> 
> Then, what's the difference of letting Customize write to you .emacs
> file and cutting of what isn't needed? 

Obvious difference being if you get it wrong, you haven't hosed the
basic init file.  Only ~/.tmp.el
> 
> The problem is that you'll have to edit the output anyway... 
> 
> I'll keep editing things by hand. And, for people who do that, the
> ":path" problem is still present.

I was suggesting to let customize inform your hand edits with a clue
or two as to how it should look.  I didn't say so explicitly but the
implication was that tmp.el would be discarded once the proper syntax
was arrived at and the final edit moved to where ever the user keeps
variable settings.

In short, if the user isn't much good at elisp he/she can still get a
good idea of what the syntax is supposed to be by writing to a
temporary file with Customize.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> > Do whatever customizing thing it is and write it to that file.  As Per
> > says the whole mass of what emacs knows as done in customize is
> > written to the file too.  But with some care you can pick out the new
> > stuff, and transfer it wherever.   This is a good technique for elisp
> > impaired users, to see what the code is supposed to look like.
> 
> Please do not advise people to use copy and paste on Custom-generated
> Lisp code.  This might easily lead to people having more than one
> custom-set-variables statement, and down that path lies madness.

I must have been very unclear... (no mention of copy and paste in my
post). 

To clarify a bit..  I'm very poor at elisp syntax.  But don't like to
use `Customize' too much because it is so cumbersome and slow.

I've hit on a method since the early days of `Customize' that works
for me as a new user and elisp impaired user.

I didn't mention this in my previous post but I keep all `Customize'
generated things in a file called .emacs-custom, and load it from
`site-lisp/site-start.el  with:

(setq custom-file "~/.emacs-custom") 
(load custom-file)

Mostly it contains numerous gnus face settings, and basic color
settings.  Too much guff to keep in .emacs, and a handy way to keep
.emacs for fast var settings that may be experimental etc.

Now if I decide to try to customize some variable I don't really
understand , that is covered in Customize, I will set the custom file
temporarily to something else (tmp.el) write the customisation to it
for study of the syntax and then maybe put a hand written version in
emacs and try it out.. 

This way I get a look at the syntax and have done no harm to any
permanent files.  Sort of a handy way to have an expert show you the
syntax for your own use.

[...] 

> Yes, the implementation of Customize should probably be improved, but
> right now, that's just the way it is.

Mine was not a complaint.  I view customize as a handy tutor.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Kai Großjohann]

Harry Putnam <reader@newsguy.com> writes:

> Now if I decide to try to customize some variable I don't really
> understand , that is covered in Customize, I will set the custom file
> temporarily to something else (tmp.el) write the customisation to it
> for study of the syntax and then maybe put a hand written version in
> emacs and try it out.. 

Ah, now I see.  Very good.  No writing to normal init files.  Nifty
idea.

FWIW, you can also tell Customize to show you the Lisp expression, by
clicking on the `State' button.  Maybe that's useful, too.

kai
-- 
I like BOTH kinds of music.

Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?)

[Karl Eichwalder]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Okay.  So, let's take a poll:

Stupid idea ;-)

> Which of the following lines would you prefer:

None.  Leave it as is.  It works and it isn't confusing at all; it's
documented.

-- 
work : ke@suse.de                          |          ------    ,__o
     : http://www.suse.de/~ke/             |         ------   _-\_<,
home : keichwa@gmx.net                     |        ------   (*)/'(*)