* nov and procmail compatability? @ 2000-07-02 4:17 Stan Norton 2000-07-03 3:24 ` Harry Putnam 2000-07-03 8:14 ` nov and procmail compatability? Kai Großjohann 0 siblings, 2 replies; 16+ messages in thread From: Stan Norton @ 2000-07-02 4:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: nov and procmail compatability? 2000-07-02 4:17 nov and procmail compatability? Stan Norton @ 2000-07-03 3:24 ` Harry Putnam 2000-07-03 12:30 ` Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) Jorge Godoy 2000-07-03 8:14 ` nov and procmail compatability? Kai Großjohann 1 sibling, 1 reply; 16+ messages in thread From: Harry Putnam @ 2000-07-03 3:24 UTC (permalink / raw) 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 ****** ^ permalink raw reply [flat|nested] 16+ messages in thread
* Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 3:24 ` Harry Putnam @ 2000-07-03 12:30 ` Jorge Godoy 2000-07-03 12:59 ` Kai Großjohann 0 siblings, 1 reply; 16+ messages in thread From: Jorge Godoy @ 2000-07-03 12:30 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 12:30 ` Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) Jorge Godoy @ 2000-07-03 12:59 ` Kai Großjohann 2000-07-03 13:10 ` Jorge Godoy 0 siblings, 1 reply; 16+ messages in thread From: Kai Großjohann @ 2000-07-03 12:59 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 12:59 ` Kai Großjohann @ 2000-07-03 13:10 ` Jorge Godoy 2000-07-03 13:10 ` Norbert Koch 0 siblings, 1 reply; 16+ messages in thread From: Jorge Godoy @ 2000-07-03 13:10 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 13:10 ` Jorge Godoy @ 2000-07-03 13:10 ` Norbert Koch 2000-07-03 13:45 ` Per Abrahamsen 0 siblings, 1 reply; 16+ messages in thread From: Norbert Koch @ 2000-07-03 13:10 UTC (permalink / raw) Cc: Kai Großjohann, ding 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!! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 13:10 ` Norbert Koch @ 2000-07-03 13:45 ` Per Abrahamsen 2000-07-03 17:52 ` Harry Putnam 0 siblings, 1 reply; 16+ messages in thread From: Per Abrahamsen @ 2000-07-03 13:45 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 13:45 ` Per Abrahamsen @ 2000-07-03 17:52 ` Harry Putnam 2000-07-03 18:13 ` Jorge Godoy 2000-07-03 18:14 ` Kai Großjohann 0 siblings, 2 replies; 16+ messages in thread From: Harry Putnam @ 2000-07-03 17:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 17:52 ` Harry Putnam @ 2000-07-03 18:13 ` Jorge Godoy 2000-07-03 18:16 ` Kai Großjohann 2000-07-03 19:19 ` Harry Putnam 2000-07-03 18:14 ` Kai Großjohann 1 sibling, 2 replies; 16+ messages in thread From: Jorge Godoy @ 2000-07-03 18:13 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 18:13 ` Jorge Godoy @ 2000-07-03 18:16 ` Kai Großjohann 2000-07-07 2:31 ` Karl Eichwalder 2000-07-03 19:19 ` Harry Putnam 1 sibling, 1 reply; 16+ messages in thread From: Kai Großjohann @ 2000-07-03 18:16 UTC (permalink / raw) Cc: Harry Putnam, ding 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 18:16 ` Kai Großjohann @ 2000-07-07 2:31 ` Karl Eichwalder 0 siblings, 0 replies; 16+ messages in thread From: Karl Eichwalder @ 2000-07-07 2:31 UTC (permalink / raw) Cc: Jorge Godoy, Harry Putnam, ding 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 | ------ (*)/'(*) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 18:13 ` Jorge Godoy 2000-07-03 18:16 ` Kai Großjohann @ 2000-07-03 19:19 ` Harry Putnam 1 sibling, 0 replies; 16+ messages in thread From: Harry Putnam @ 2000-07-03 19:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 17:52 ` Harry Putnam 2000-07-03 18:13 ` Jorge Godoy @ 2000-07-03 18:14 ` Kai Großjohann 2000-07-03 19:37 ` Harry Putnam 1 sibling, 1 reply; 16+ messages in thread From: Kai Großjohann @ 2000-07-03 18:14 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 18:14 ` Kai Großjohann @ 2000-07-03 19:37 ` Harry Putnam 2000-07-03 21:24 ` Kai Großjohann 0 siblings, 1 reply; 16+ messages in thread From: Harry Putnam @ 2000-07-03 19:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) 2000-07-03 19:37 ` Harry Putnam @ 2000-07-03 21:24 ` Kai Großjohann 0 siblings, 0 replies; 16+ messages in thread From: Kai Großjohann @ 2000-07-03 21:24 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: nov and procmail compatability? 2000-07-02 4:17 nov and procmail compatability? Stan Norton 2000-07-03 3:24 ` Harry Putnam @ 2000-07-03 8:14 ` Kai Großjohann 1 sibling, 0 replies; 16+ messages in thread From: Kai Großjohann @ 2000-07-03 8:14 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2000-07-07 2:31 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-07-02 4:17 nov and procmail compatability? Stan Norton 2000-07-03 3:24 ` Harry Putnam 2000-07-03 12:30 ` Suggestion for "file" mail-backend (was Re: nov and procmail compatability?) Jorge Godoy 2000-07-03 12:59 ` Kai Großjohann 2000-07-03 13:10 ` Jorge Godoy 2000-07-03 13:10 ` Norbert Koch 2000-07-03 13:45 ` Per Abrahamsen 2000-07-03 17:52 ` Harry Putnam 2000-07-03 18:13 ` Jorge Godoy 2000-07-03 18:16 ` Kai Großjohann 2000-07-07 2:31 ` Karl Eichwalder 2000-07-03 19:19 ` Harry Putnam 2000-07-03 18:14 ` Kai Großjohann 2000-07-03 19:37 ` Harry Putnam 2000-07-03 21:24 ` Kai Großjohann 2000-07-03 8:14 ` nov and procmail compatability? Kai Großjohann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).