Re: Problem with archiving and nnimap

Niklas Morberg <niklas.morberg <at> axis.com> writes:

> Should this be documented somewhere? Maybe it already is?

I think it's not documented, but it should be.

kai
--

-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Using Eric Raymond's bogofilter tool within Gnus

Hello, my friends.

Some of you might be aware of the speedy Graham filter written by Eric Raymond
last week.  Here is the recipe I cooked for using it from within Gnus.
Despite a bit rough, a bit raw, it might be usable.  Of course, if you improve
on it, please tell me, so I can take advantage of your ideas as well! 

---------------------------------------------------------------------->
;;; Gnus against SPAM, training a Graham filter via Bogofilter.
;;; François Pinard, 2002-08.

;;; This Emacs Lisp code add a few hooks so Oort Gnus could control spam with
;;; the help of Eric Raymond's Bogofilter.  I use Oort Gnus version 0.8 in
;;; development from CVS, see http://quimby.gnus.org/gnus, and Bogofilter 0.4,
;;; see http://www.tuxedo.org/~esr/bogofilter, slightly patched.

;;; The `M-d' command gets added Gnus summary mode to mark current message as
;;; spam, this is indicated by the letter `H'.  Whenever you see a spam
;;; message, make sure to mark its summary line with `M-d' before leaving the
;;; group.  Some groups, as per variable `fp-junk-mailgroups' below,
;;; automatically get an `H' mark for all summary lines which would otherwise
;;; have no other mark.  These groups are normally receiving spam resulting
;;; from splitting on clues added by spam recognisers.  Make sure to _remove_
;;; `H' marks for any message which is _not_ genuine spam, before leaving the
;;; group (through `M-u' to "unread" the message, or `d' for declaring it read
;;; the non-spam way).  When you leave a group, all `H' marked messages are
;;; sent to Bogofilter which will study them as spam samples.

;;; Messages may also be deleted in various other ways, and unless
;;; `fp-ham-marks-form' gets overridden below, marks `R' and `r' for default

Re: Do not want agantized, nnml backend.

Jesper Harder <harder <at> ifa.au.dk> writes:

> Simon Josefsson <jas <at> extundo.com> writes:
>
>> Another try:
>>
>>   The Gnus Agent is now enabled by default, [..]  Revert to the old
>>   behaviour with `(setq gnus-agent nil)'.  Note that putting
>>   (gnus-agentize) in ~/.gnus is not needed any more.
>
> I think the node (gnus)Gnus Unplugged also needs to be updated.

Right, I committed something.

Oort Gnus 0.08 - `Returning to the group buffer' ??

Hi, people.

While using the anti-spam tool I described to you yesterday, I just notice
this bizarre behaviour with CVS Gnus:

[...]
No more unread articles (exiting)...
Studying 1 articles as `ham'... done!
No more unread newsgroups
Mark set
Returning to the group buffer           <---- !!
Studying 1 articles as `ham'... done!
No more unread newsgroups

For years, I enjoyed the automagical opening of the next group once a group is
fully read.  The case above occurred after reading the last message in the
last newsgroup.  The group is exited twice instead of once then?  This is not
welcome in my case that the `gnus-summary-prepare-exit-hook' gets run twice.
Could the behaviour be corrected, short of changing my reading habits?

--

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

Re: Fetching already read e-mail with IMAP source.

Simon Josefsson <jas <at> extundo.com> writes:
> How about frobing :predicate?

I don't know about oort, but 5.8.8 and 5.9.0 have a bug such that
setting :predicate nil doesn't work.  (I just reported this to the
bugs list; my apologies if it's been reported before.)

Since you can use functions as well as variables, I've worked around
the bug with this stupid function:

(defun nullity ()
	nil)

and then I use 
      :predicate (nullity)  ; bug workaround for nil

Jeremy
gnus novice

problem w/ auth-required nntp site

I've been unable to convince gnus to access an auth-required nntp
server I recently re-subscribed to.  

The server responds with:

200 hostname.elided.com InterNetNews NNRP server INN 2.3.2 ready (posting ok).

upon connection and after mode reader, and never gives a 480
response.  It does however respond with:

215 Newsgroups in form "group high low flags".
.

to a list command.

I tried this in ~/.authinfo:

machine hostname.elided.com login ME password PASSWD force

but it was ignored, AFAICT.  

So how do I force gnus to authenticate even when it thinks it doesn't
need to?

Or is it just a bug in v5.9.0?

-JimC

nnir.el with namazu

I installed nnir.el(v 1.78) and namazu to search my mails.  It's
working well on shell command line with "namazu" program, but not
within gnus.

in my .gnus.el,

;; nnir.el with namazu
(require 'nnir)
(setq nnir-search-engine 'namazu
      nnir-mail-backend (nth 0 gnus-secondary-select-methods))
(setq nnir-namazu-index-directory "/home/users/novembre/System/namazuIndex/"
      nnir-namazu-remove-prefix "/home/users/novembre/Mail/")

If I do "G G linux RET" on group buffer, nnir says "Couldn't request
group: Search produced empty results." and following backtrace is
produced.

  # bind (standard-output stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error)
  signal(error ("Couldn't request group: Search produced empty results."))
  # bind (args datum)
  cerror("Couldn't request group: %s" "Search produced empty results.")
  apply(cerror "Couldn't request group: %s" "Search produced empty results.")
  # bind (args datum)
  error("Couldn't request group: %s" "Search produced empty results.")
  # bind (group parameters select-articles request-only quit-config activate method group)
  gnus-group-read-ephemeral-group("nnir:((query . \"linux\"))" (nnir "") t (#<buffer "*Group*"> .
message) nil)
  # bind (parms)
  (let ((parms nil)) (if extra-parms (setq parms ...) (setq parms ...))
(gnus-group-read-ephemeral-group (concat "nnir:" ...) (quote ...) t (cons ...

Re: detecting encoding for Japanese

>>>>> In <vaf1y8g5yck.fsf <at> INBOX.auto.gnus.tok.lucy.cs.uni-dortmund.de>
>>>>>	Kai.Grossjohann <at> CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

>> So, I recommend Japanese Gnus users customize the option
>> `mm-coding-system-priorities' to have popular Japanese charsets
>> as follows:
>>
>> (setq mm-coding-system-priorities
>>       '(iso-2022-jp iso-2022-jp-2 japanese-shift-jis utf-8))

Kai> Why are euc-jp and euc-jisx0213 missing from this list?  (Maybe
Kai> they are different names for an encoding already in the above
Kai> list?)

Yes, there's not euc-jp.  Saying beforehand, I'm not so detailed
to characters.  Before MIME generally spread, iso-2022-jp and
similar 7-bit codes were used in Japan without using any
designator.  It would be the cause that iso-2022-jp is generally
used even now, and any codes other than iso-2022-jp cannot be
read in very old MUAs.

iso-2022-jp-2 is for Japanese extra characters including a part
of Korean symbols like:

♤♡♧♨☎

shift-jis is the addition for katakana-jisx0201 characters

Re: detecting encoding for Japanese

Katsumi Yamaoka <yamaoka <at> jpl.org> writes:

>>>>>> In <vaf1y8g5yck.fsf <at> INBOX.auto.gnus.tok.lucy.cs.uni-dortmund.de>
>>>>>>	Kai.Grossjohann <at> CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
>
> Kai> Another thought: Mule itself also has a priority list of
> Kai> encodings.  So I wonder why does Gnus need another priority list?
> Kai> Normally, I'd guess that Japanese would normally configure their
> Kai> Emacs for the right priorities, and then Gnus should do the right
> Kai> thing automatically.  There could be two reasons why this is not
> Kai> happening: (1) Japanese use a different encoding in email than in
> Kai> editing files, or (2) the priorities that Emacs sets up normally
> Kai> do not propagate properly to Gnus, or (3) Emacs does not set
> Kai> itself up for the right priorities at all when users setup a
> Kai> Japanese language environment.  Yes, I can't count...
>
> That's a good consideration.  (1) is the main reason.  Though
> iso-2022-jp is used for mail messages, euc-jp has mainly been
> used in UNIX and DOS has used shift_jis.  Although it will be
> different with the system-type, Emacs gives a priority to euc-jp
> or shift_jis in general and it is a right way for editing files.
> It seems to be a good way that Emacs offers the priority list
> for mails apart from the list for files for the specified
> language environment.

Okay.  So it seems that Japanese users always want what you are
saying.

What do you think about changing the default value to the following
expression?

How does one pgp/mime encrypt to different recipients?

How does one encrypt mail to key user-ids other than those
auto-detected from the To/CC headers?

        jam