help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnus + Gmail + IMAP


From: Jude DaShiell
Subject: Re: Gnus + Gmail + IMAP
Date: Tue, 30 Jun 2015 23:37:43 -0400 (EDT)
User-agent: Alpine 2.11 (NEB 23 2013-08-11)

Is it possible to get gmail with gnus without lowering security protections on a gmail account? I sure couldn't do it with fetchmail.

On Tue, 30 Jun 2015, Eli Zaretskii wrote:

Date: Tue, 30 Jun 2015 16:04:09
From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Gnus + Gmail + IMAP

Date: Tue, 30 Jun 2015 21:10:44 +0200
From: Alexander Shukaev <haroogan@gmail.com>
Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>

God damn it. I don't know if you remember my post from yesterday where I was
talking which hooks to attach `minibuffer-line--update' to in order to update
minibuffer line on window and buffer switches properly. The conclusion was

(add-hook 'buffer-list-update-hook #'minibuffer-line--update)
(add-hook 'window-configuration-change-hook #'minibuffer-line--update)

By examining the GDB output (which obviously repeats):

#1084 0x00000004001f0978 in run_hook_with_args (nargs=1, args=0x7a8d40,
funcall=0x4001f0434 <funcall_nil>) at
C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2529
#1085 0x00000004001f04e2 in Frun_hook_with_args (nargs=1, args=0x7a8d40) at
C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2390
#1086 0x00000004001f0a0a in run_hook (hook=-17119289912) at
C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2543
#1087 0x00000004001f049c in Frun_hooks (nargs=1, args=0x7a8e88) at
C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2372

I've somehow recalled those hooks. It turns out that this one

(add-hook 'buffer-list-update-hook #'minibuffer-line--update)

is seems to be causing the infinite recursion and most importantly only in the
case of `M-x gnus RET' as I haven't experienced that before.

Yes, the recursion is clearly visible in the Lisp backtrace.

What could be the problem here, Eli?

I think this part of the Lisp backtrace should give you a clue:

 "format-time-string" (0x8318d0)
 "propertize" (0x831b18)
 "let*" (0x831d68)
 "eval" (0x831fc8)
 "format-mode-line" (0x833810)
 "minibuffer-line--update" (0x833e88)
 "run-hooks" (0x833fc8)
 "format-time-string" (0x8356a0)
 "propertize" (0x8358e8)
 "let*" (0x835b38)
 "eval" (0x835d98)
 "format-mode-line" (0x8375e0)
 "minibuffer-line--update" (0x837c58)
 "run-hooks" (0x837d98)
 "utf-7-imap-post-read-conversion" (0x839ce8)
 "decode-coding-string" (0x83a380)
 "utf7-decode" (0x83a8d0)
 "nnimap-get-groups" (0x83ae40)
 "nnimap-request-newgroups" (0x83b3b0)
 "gnus-request-newgroups" (0x83b920)
 "gnus-ask-server-for-new-groups" (0x83be90)

Somehow, minibuffer-line--update calls format-mode-line, which calls
format-time-string, which again calls run-hooks, which again calls
minibuffer-line--update.  Look into your hook and see how this can
happen.



--




reply via email to

[Prev in Thread] Current Thread [Next in Thread]