gmane.emacs.gnus.general

Still pounding nnimap and odd gmail behavior

Harry Putnam — 2013-05-22T22:46:26

Sorry to keep pounding on this same subject by being sneaky and
slipping the same question with different subject.

I did not get any help I could use from previous post so here goes
again with an update of sorts, although it still acts the same as
reported earlier.

I've used a specific gmail account and have it incorporated into
gnus.  Been so for a few yrs. (called acc1 onward)

I recently added a new account (called acc2 onward)

So I incorporate acc2 into gnus with this in .gnus:

<Note that names and passwords obfuscated to simplify reading>

-------        ---------       ---=---       ---------      -------- 
(setq gnus-secondary-select-methods
      '((nnml ""))) 

(add-to-list 'gnus-secondary-select-methods '(nnimap "acc1"
                                  (nnimap-address "imap.gmail.com")))

(add-to-list 'gnus-secondary-select-methods
                      '(nnimap "acc2"
               (nnimap-address "imap.gmail.com")))

<Note that the accs do have different names and passwds>
-------        ---------       ---=---       ---------      -------- 

And this in .authinfo

machine imap.gmail.com login acc1< at >gmail.com password xxxxxxxx port imap
machine imap.gmail.com login acc2< at >gmail.com password xxxxxxxx port imap
-------        ---------       ---=---       ---------      -------- 

But, gnus copies all the mail from acc1 and reports it in acc2,
creating a host of folders and so forth that are actually only in
acc1.

Now, this seems like a fairly dangerous thing for gnus to do.

Please someone help me solve it.

Here is what I've done so far:

1) Made double sure that the accs do in fact have different names and
   passwds on gmail.
2) Made double sure that the details in .authinfo are totally
   accurate. 
3) Stripped any reference to acc2 out of .newsrc.eld (with gnus closed
   of course)
4) Did a 'git pull' on gnus so am running the latest version.

Finally, restarted gnus.  But once again it pulls all mail and groups
from acc1 and shows it as belonging to acc2.  Yikes... this is bad.

What else can I do to debug this?

Re: XEmacs builds failing - gnus-spec.el

David Engster — 2013-05-22T20:36:16

Another example is the registry, which is not persistent under XEmacs
because it lacks a printed representation for hash tables.

-David

Re: XEmacs builds failing - gnus-spec.el

Adam Sjøgren — 2013-05-22T20:28:06




It worked!

 * http://www.randomsample.de:4456/waterfall

How small changes are supposed to be ChangeLog'ed? (I didn't write
anything for this, or for the follow up commit I did to another commit
shortly after a change.)


  Cheers all around,

    Adam

Re: XEmacs builds failing - gnus-spec.el

David Engster — 2013-05-22T20:25:59

Sure, but IMO Gnus should try to build fine on XEmacsen that are build
with the defaults. The Buildbot is running a rather old version (b29),
but I don't think --with-mule has become default yet?

-David

Re: XEmacs builds failing - gnus-spec.el

Adam Sjøgren — 2013-05-22T20:18:33


Yep, I have just done so. Let's see what the buildbot says.


Yeah... Lars writing shr.el and the lacklustre performance of XEmacs
21.5 on X on slow(ish) connections was the straw that made me switch to
GNU Emacs.

Paradoxically, I have yet to get used to "emacsclient" not Just Working™
over ssh (-X).


You hung in there longer than could be expected of anyone, and I enjoyed
the XEmacs-specific fruits of your labour for many years, so thanks for
that!


  :-),

   Adam

Re: isync plus dovecot?

Drew Raines — 2013-05-22T18:24:48


[...]

I use dovecot as a real IMAP server.  My mbsync config looks like
this.  It's a little obfuscated by my hack that keeps my IMAP
password out of it.

  https://gist.github.com/drewr/c6e213f0b7ccd712e136

mbsync syncs Gmail IMAP <-> dovecot IMAP and nnimap connects to
dovecot for the different users.  I set up userdb authentication 
in
dovecot to link to different directories in ~/Mail depending on 
who
connects.

  userdb {
    driver = static
    args = uid=1000 gid=1000 home=/home/aar/Mail/dovecot/%n
  }

The maildir approach, however, sounds nice.  Not having to 
maintain a
dovecot instance and bear the cost of Gnus reconnecting to it
periodically is attractive.

Drew

pgpmime signature token at beginning of reply?

Rainer M. Krug — 2013-05-22T13:09:33

Hi

I am using 

,----
| (add-hook 'message-setup-hook 'mml-secure-message-sign-pgpmime)
`----

to sign my messages, but when I reply to a message (F), the signature
token <#secure method=pgpmime mode=sign> is inserted at the end of the
email, although I reply in emails inline o=r before the email (most
people prefer to tread backwards....).

Is there a way to automatically insert the token at the beginning of the
mail?

Thanks,

Rainer

SOLVED: Definition of Archive group

Rainer M. Krug — 2013-05-22T13:04:53


OK - I found the solution: set gnus-parameters for different group name
pattern. If I use the following, it works as I want it:

,----
|  (setq gnus-parameters
|         '(        
|           (".*"
|            (gnus-use-scoring nil)
|            (gcc-self . t)
|            )
|           ("^gmane.*"
|            (gcc-self . "nnimap+Maildir:RMKrugGMAIL.[Gmail].Sent Mail"))
|           ))
`----

Thanks,

Rainer

Re: [nnimap gmail] confused by phenomena

Harry Putnam — 2013-05-22T11:39:16


I have as below, but not sure if that is the same as nnnil.  I think
not.

(setq gnus-secondary-select-methods
      '((nnml ""))) 

This has been the case for years.

Re: [nnimap gmail] confused by phenomena

Alberto Luaces — 2013-05-22T11:09:30


Do you have a gnus-select-method different than nnnil?  It happened
something similar to me, but with splitting, when I had one of the
nnimap accounts as the main one and the other as a secondary select
method.  I see that both of your gmail accounts are
gnus-secondary-select, but just in case.

Re: Definition of Archive group

Katsumi Yamaoka — 2013-05-22T11:03:28




When composing a new mail in a certain group, the archive group
will get that group if gcc-self is set to t for the group.  You
can see it in the Gcc header in a draft message.  But if gcc-self
is not set as a group parameter for the group (for some reason),
setting the default archive group will be helpful.  If you talk
about the way to set gcc-self, see an example in the Info manual:

(info "(gnus)Group Parameters")  <- type `C-x C-e' here

I use:
(setq gnus-parameters
      '(
...
...
("\\`nn[^drt][a-z]*:"
 (gcc-self . t))
...
...
))

[nnimap gmail] confused by phenomena

Harry Putnam — 2013-05-22T10:58:54

I've been reading some gmail imap groups for a yr or so.  
Yesterday I added a new one.  Today the new groups showed up but they
contain all the mail of the wrong account.

From ~/.gnu:

<This one has been in use for a year>
(add-to-list 'gnus-secondary-select-methods '(nnimap "hputnam3"
                                  (nnimap-address "imap.gmail.com")))

<this one was added yesterday>
(add-to-list 'gnus-secondary-select-methods
                       '(nnimap "harrygp3"
                    (nnimap-address "imap.gmail.com")))
 
The accounts have different names and different passwords.  They are
listed in .authinfo like so:

(passwords obfuscated)

machine imap.gmail.com login hputnam3< at >gmail.com password xxxxxxxx port imap
machine imap.gmail.com login harrygp3< at >gmail.com password xxxxxxxx port imap

When I ran gnus, it had pickup all of hputnam3 imap mail and placed
it in groups named harrygp3.  In other words it had retrieved all the
wrong mail for the newly added imap account.

I noticed that the passwords while different were only different by
case. (PAssword and password), so I thought that might be the
reason.

I went to gmail and changed the password of harrygp3 so it was
different by an actual char... an underscore, then  changed the lines
in .authinfo.  I then stripped out all reference to harrygp3 from
.newsrc.eld (with gnus closed) and started gnus again.

However it still retrieves all of hputnam3 mail and places it in
harrygp3 groups.

Gack... now what?

Re: Definition of Archive group

Rainer M. Krug — 2013-05-22T10:36:08


Yes - I agree.


But how can I then specify that the archive group should be the group in
which I started composing the email (unless [1] and [2])?

Rainer

Re: Definition of Archive group

Katsumi Yamaoka — 2013-05-22T09:49:35



I guess the value `t' is the culprit; it should be the default
archive group (a string) for the case where gcc-self is not
allowed[1] or the gcc-self group is unable to specify[2].
Anyway `t' should cause an error when inserting a Gcc header.

[1] A read-only group.
[2] Start composing a mail in the *Group* buffer.

nnimap group gets stuck "offline"

Eric S Fraga — 2013-05-22T09:02:50

Hello,

recently (last few weeks but increasingly so) I find that I cannot open
my main email account (via IMAP to Microsoft Live< at >edu
server).  Initially, more often than not, it simply fails.  If I go to
the server buffer, it is indicated as offline.  I can go to the line and
hit O.  If I try this repeatedly, eventually the server goes "online"
but this can take a very long time.

Once it's online, everything is fine, although the server connection is
lost frequently and has to be regained but that usually works okay.

I'm using gnus up to date as of yesterday from git.

How can I debug this initial offline/online behaviour?  I have no
problems with IMAP access to gmail and NNTP access to gwene, gmane,
etc.

Thanks,
eric

Definition of Archive group

Rainer M. Krug — 2013-05-22T08:23:10

Hi

I would like to set my archive group as follow:

1) if the mail is an email, I want a copy in the group from which I send
(i.e. gcc-self . t) but when I send via a newsgroup, I want to puyt a
copy into a specific group (i.e. "nnimap+Maildir:Sent"). But the
following does not work:

,----
|  (setq gnus-message-archive-group
|          '((if (message-news-p)
|                "nnimap+Maildir:Sent"
|              t)))
`----

How can I achieve the above mentioned goal?

Thanks,

Rainer

Re: XEmacs builds failing - gnus-spec.el

Katsumi Yamaoka — 2013-05-22T05:45:17

Hi Mike,

mike.kupfer< at >xemacs.org wrote:



As for url.el originated in W3, the code is too old to use with
Gnus for both 21.5 and 21.4.  I don't think `url-retrieve' that
gnus-compat.el redefines helps.  A workaround attached below is
the one I used to use, but I'm not sure if they are still useful
since I haven't been using XEmacs for a couple of years.  For
the same reason, and since I failed to have taken notes, I don't
recall other matters I faced.  But it is not hard to imagine
there are inconsistencies here and there, since most Gnus
developers are GNU Emacs users and they like to use Emacs' new
features (also it sometimes causes Gnus not to work for old GNU
Emacsen).


If it is the Gnus XEmacs package, I believe it's safe.  I have
no basis for it, though.


I'm no longer suitable for doing it, sorry.  The foremost reason
I got not to use XEmacs is that now I'm using Cygwin for almost
daytime (in the office).  On that platform, I was unable to build
XEmacs 21.5 that works normally.  It frequently crashes.
(Even so, I kept building it periodically keeping track of hg.
 However, it stopped months ago because it got unable to build
 on the latest Cygwin.)



That's good to here from the XEmacs team. :)  The only matter is
that there might be no Gnus developers who use 21.5.

Regards,

Re: XEmacs builds failing - gnus-spec.el

Mike Kupfer — 2013-05-22T03:02:36


Would it be possible to change that, so that --with-mule is used?  If
Gnus is using UTF-8 in its source code, it seems likely that non-mule
XEmacs will continue to have problems in the future.

mike

Re: XEmacs builds failing - gnus-spec.el

Mike Kupfer — 2013-05-22T02:58:46


Hi Katsumi, is this true for XEmacs 21.5, or just 21.4?  Are these all
new features in Ma Gnus, or are older versions of Gnus also affected?
Are there any bug reports that you can point me at?


Yes, 21.4 is quite old.  If it's too much of a hassle for the Gnus
developers to support, then maybe it's best to drop support for it.
Then whatever time is available for XEmacs support can be focused on
21.5.

best regards,
mike
(Gnus package maintainer for XEmacs)

Re: XEmacs builds failing - gnus-spec.el

Katsumi Yamaoka — 2013-05-21T23:39:09


Oh, sorry.  I did misread the gnus-spec.el code as it does:

(eq delim 171)

By this way XEmacs doesn't recognize these operands are equal:

(eq (aref "«" 0) 171) -> nil
;; Whereas
(eq (aref "«" 0) ?\«) -> t

However, the op is `=', not `eq'.  (= (aref "«" 0) 171) returns t
in XEmacs 21.4/21.5, I verified.  Could you commit 171?




Ah, that is the point.  I forgot there's no stable XEmacs 21.5.
But please let me say, the fact is that some new Gnus features
no longer work on XEmacs (even if the code is compiled with no
error).  Typical ones are the features that use url.el.  As for
XEmacs 21.4, I feel it like old GNU Emacsen that Gnus dropped
the support long ago.  I used to have fun to make Gnus of the
bleeding edge work for XEmacs, but I gave it up someday.

Re: XEmacs builds failing - gnus-spec.el

Adam Sjøgren — 2013-05-21T21:01:54

  Hi Katsumi.


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


But wouldn't just "171" work as well? Then we don't have to worry about
Mule-UCS etc.

I am probably putting my ignorance on display here... :-)


I don't know - I was just checking to see if I could make the buildbot
go green. It feels like a waste to have a buildbot if red builds are
ignored for longer periods of time.

I guess XEmacs 21.5 won't be released this decade either... O:-)


  Best regards,

    Adam