unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#18522: 24.4.50; mapcar is very slow
@ 2014-09-22 10:37 Peter Münster
  2014-09-22 10:43 ` bug#18522: further information Peter Münster
  2014-09-22 12:49 ` bug#18522: 24.4.50; mapcar is very slow Stefan Monnier
  0 siblings, 2 replies; 84+ messages in thread
From: Peter Münster @ 2014-09-22 10:37 UTC (permalink / raw)
  To: 18522

Hi,

ELP shows, that the mapcar function called from gnus-thread-latest-date
takes a lot of time (uptime of emacs is several days):

function                calls       total time [s]   time per call [s]
-----------------------------------------------------------------------
mapcar                  20250       5.3743043500      0.0002653977

After restarting emacs:

mapcar                  21468       0.1387124370      6.461...e-06

About 40 times faster now!!


Thanks in advance for any help or hints how to debug further,


Further details:

In GNU Emacs 24.4.50.1 (x86_64-suse-linux-gnu, GTK+ Version 3.10.9)
 of 2014-09-14 on micropit
Repository revision: 117880 michael.albinus@gmx.de-20140914090011-2k4yr2tapso2uoz6
Windowing system distributor `The X.Org Foundation', version 11.0.11403901
System Description:	openSUSE 13.1 (Bottle) (x86_64)

Configured using:
 `configure --without-toolkit-scroll-bars'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY LIBSELINUX LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LC_ALL: en_GB.utf8
  value of $LC_CTYPE: en_GB.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  gnus-undo-mode: t
  pm/keys-minor-mode: t
  savehist-mode: t
  show-paren-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t

Features:
(shadow emacsbug mule-util mm-archive gnus-dup org-colview elp misearch
multi-isearch mailalias bbdb-message vc-dispatcher vc-svn org-rmail
org-mhe org-irc org-info org-gnus org-docview org-bibtex bibtex org-bbdb
org-w3m sort smiley gnus-cite mail-extr gnus-async gnus-bcklg qp
gnus-salt gnus-ml disp-table bbdb-gnus bbdb-mua bbdb-com crm gnus-delay
gnus-draft nndraft nnmh nnml gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg gnus-cache gnus-demon nntp gnus-icalendar org-capture
gnus-art mm-uu mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo
icalendar diary-lib diary-loaddefs json jl-encrypt epg mml2015
epg-config gnus-start gnus-cloud nnimap nnmail mail-source tls utf7
netrc nnoo parse-time gnus-spec gnus-int gnus-range message sendmail
dired rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
gnus-win gnus gnus-ems gnus-compat url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
auth-source eieio eieio-core password-cache url-vars mailcap nnheader
gnus-util mail-utils mm-util mail-prsvr wid-edit notifications dbus xml
wombat-theme savehist paren delsel server org-clock bbdb bbdb-site
timezone lua-mode edmacro kmacro rx org-notify org-element org byte-opt
bytecomp byte-compile cconv advice help-fns org-macro org-footnote
org-pcomplete pcomplete org-list org-faces org-entities noutline outline
easy-mmode org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob
ob-table ob-keys ob-exp ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs format-spec find-func cal-menu calendar cal-loaddefs
slime-autoloads cl-macs bbdb-loaddefs tex-site auto-loads gnus-load cl
gv autoinsert compile comint ansi-color po-mode php-mode derived etags
ring cc-langs cl-loaddefs cl-lib cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs speedbar sb-image
ezimage dframe easymenu time-date tooltip electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 344956 38663)
 (symbols 48 43128 62)
 (miscs 40 123 587)
 (strings 32 96718 17145)
 (string-bytes 1 3253927)
 (vectors 16 43741)
 (vector-slots 8 1564631 71072)
 (floats 8 335 1543)
 (intervals 56 2324 486)
 (buffers 976 21)
 (heap 1024 66555 4558))

-- 
        Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: further information
  2014-09-22 10:37 bug#18522: 24.4.50; mapcar is very slow Peter Münster
@ 2014-09-22 10:43 ` Peter Münster
  2014-09-22 12:49 ` bug#18522: 24.4.50; mapcar is very slow Stefan Monnier
  1 sibling, 0 replies; 84+ messages in thread
From: Peter Münster @ 2014-09-22 10:43 UTC (permalink / raw)
  To: 18522

Hi,

Here is a thread about this issue:

http://thread.gmane.org/gmane.emacs.gnus.general/84605

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2014-09-22 10:37 bug#18522: 24.4.50; mapcar is very slow Peter Münster
  2014-09-22 10:43 ` bug#18522: further information Peter Münster
@ 2014-09-22 12:49 ` Stefan Monnier
  2014-09-22 13:47   ` Peter Münster
  1 sibling, 1 reply; 84+ messages in thread
From: Stefan Monnier @ 2014-09-22 12:49 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

> ELP shows, that the mapcar function called from gnus-thread-latest-date
> takes a lot of time (uptime of emacs is several days):

This is the wrong measurement: it just means that some calls to mapcar
spend a lot of time in the corresponding loop, but the
time for mapcar includes the time spent in the function passed to
mapcar, which is where most of the time is likely spent anyway.

Could you use the native, sampling, profiler instead of ELP?

- M-x profiler-start RET RET
- ... reproduce the slow operation ...
- M-x profiler-report RET
- C-u RET on the first entry to unfold it


        Stefan





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2014-09-22 12:49 ` bug#18522: 24.4.50; mapcar is very slow Stefan Monnier
@ 2014-09-22 13:47   ` Peter Münster
  2014-09-25 21:36     ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2014-09-22 13:47 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 18522

On Mon, Sep 22 2014, Stefan Monnier wrote:

> the time for mapcar includes the time spent in the function passed to
> mapcar, which is where most of the time is likely spent anyway.

Yes. The function is:

	         (lambda (header) (gnus-float-time
				   (gnus-date-get-time
				    (mail-header-date header))))

I've checked all 3 functions (gnus-float-time, gnus-date-get-time and
mail-header-date) with ELP, but emacs did not spend any significant time
in these 3 functions...


> Could you use the native, sampling, profiler instead of ELP?
>
> - M-x profiler-start RET RET
> - ... reproduce the slow operation ...
> - M-x profiler-report RET
> - C-u RET on the first entry to unfold it

Yes. I'll do that in some days, when mapcar becomes slow again.

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2014-09-22 13:47   ` Peter Münster
@ 2014-09-25 21:36     ` Peter Münster
  2014-09-26  6:57       ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2014-09-25 21:36 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 18522

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Mon, Sep 22 2014, Peter Münster wrote:

>> Could you use the native, sampling, profiler instead of ELP?
>>
>> - M-x profiler-start RET RET
>> - ... reproduce the slow operation ...
>> - M-x profiler-report RET
>> - C-u RET on the first entry to unfold it
>
> Yes. I'll do that in some days, when mapcar becomes slow again.

Hi,

Please find attached 2 files with profiler-reports when entering a Gnus
group:
- profiler-slow.txt: entering a group is slow, and emacs was uptime since
  about 3 days
- profiler-fast.txt: entering the same group after a fresh restart of emacs

-- 
           Peter

[-- Attachment #2: profiler-slow.txt --]
[-- Type: text/plain, Size: 33345 bytes --]

- command-execute                                                2464  45%
 - call-interactively                                            2463  45%
  - funcall-interactively                                        2158  39%
   - gnus-group-select-group                                     1964  36%
    - gnus-group-read-group                                      1964  36%
     - gnus-summary-read-group                                   1964  36%
      - gnus-summary-read-group-1                                1964  36%
       - gnus-summary-prepare                                    1325  24%
        - gnus-sort-threads                                      1116  20%
         - byte-code                                             1116  20%
          - gnus-sort-threads-recursive                          1116  20%
           - sort                                                1116  20%
            - #<compiled 0xf8f403>                               1116  20%
             - gnus-thread-sort-by-most-recent-date               1116  20%
              - gnus-thread-latest-date                          1114  20%
               - mapcar                                          1090  20%
                - apply                                          1090  20%
                 - #<compiled 0xf0d90b>                          1090  20%
                  - apply                                        1082  20%
                   - #<subr mapcar>                              1081  20%
                    - #<compiled 0xea16e1>                       1079  19%
                     - safe-date-to-time                         1075  19%
                      - date-to-time                             1074  19%
                       - byte-code                               1074  19%
                        - parse-time-string                      1059  19%
                         - parse-time-tokenize                     25   0%
                            byte-code                               5   0%
                          apply                                     2   0%
                    time-subtract                                   2   0%
               - message-flatten-list                              24   0%
                - mapcar                                           23   0%
                 - apply                                           21   0%
                  - #<compiled 0xf0d90b>                           19   0%
                   - apply                                         10   0%
                    - #<subr mapcar>                               10   0%
                     - message-flatten-list                        10   0%
                      - mapcar                                      9   0%
                       - apply                                      9   0%
                        - #<compiled 0xf0d90b>                      6   0%
                         - apply                                    6   0%
                          - #<subr mapcar>                          6   0%
                           - message-flatten-list                   6   0%
                            - mapcar                                6   0%
                             - apply                                6   0%
                              - #<compiled 0xf0d90b>                  5   0%
                                 time-subtract                      2   0%
                               - apply                              2   0%
                                - #<subr mapcar>                    2   0%
                                 - message-flatten-list                  2   0%
                                  - mapcar                          2   0%
                                     apply                          2   0%
                     time-subtract                                  2   0%
                  apply                                             1   0%
        - gnus-summary-prepare-threads                            174   3%
         - eval                                                   164   3%
          - let                                                   164   3%
           - gnus-add-text-properties                             156   2%
            - progn                                               156   2%
             - insert                                             155   2%
              - format                                            152   2%
               - let*                                             126   2%
                - eval                                            126   2%
                 - let                                            126   2%
                  - eval                                          124   2%
                   - gnus-summary-from-or-to-or-newsgroups                123   2%
                    - mail-decode-encoded-address-string                117   2%
                     - rfc2047-decode-string                       93   1%
                      - rfc2047-decode-encoded-words                 43   0%
                       - byte-code                                 43   0%
                        - quoted-printable-decode-string                 41   0%
                           generate-new-buffer                     16   0%
                         - byte-code                                7   0%
                          - kill-buffer                             3   0%
                           - replace-buffer-in-windows                  2   0%
                              unrecord-window-buffer                  1   0%
                             uniquify-kill-buffer-function                  1   0%
                           mm-disable-multibyte                     5   0%
                           quoted-printable-decode-region                  1   0%
                        generate-new-buffer                        27   0%
                      - byte-code                                  18   0%
                       - kill-buffer                                4   0%
                        - replace-buffer-in-windows                  2   0%
                         - unrecord-window-buffer                   1   0%
                            window-normalize-window                  1   0%
                          uniquify-kill-buffer-function                  1   0%
                      gnus-extract-address-components                  3   0%
                  - if                                              1   0%
                     if                                             1   0%
               - gnus-user-date                                    25   0%
                - byte-code                                        23   0%
                 - eval                                            13   0%
                    gnus-seconds-today                              7   0%
                    gnus-seconds-year                               6   0%
                   seconds-to-time                                  1   0%
             if                                                     1   0%
         - mapcar                                                   4   0%
          - apply                                                   4   0%
           - #<compiled 0xf0d90b>                                   4   0%
              apply                                                 1   0%
           gnus-summary-highlight-line                              2   0%
        - gnus-gather-threads-by-references                        25   0%
         - mail-header-remove-comments                             24   0%
            generate-new-buffer                                    15   0%
          - byte-code                                               7   0%
           - kill-buffer                                            2   0%
            - replace-buffer-in-windows                             1   0%
               unrecord-window-buffer                               1   0%
        - gnus-make-threads                                         2   0%
         - mapatoms                                                 2   0%
          - #<compiled 0xe9e253>                                    2   0%
           - mapcar                                                 2   0%
            - apply                                                 2   0%
             - #<compiled 0xf0d90b>                                 1   0%
                time-subtract                                       1   0%
       - gnus-select-newsgroup                                    633  11%
        - gnus-fetch-headers                                      629  11%
         - gnus-get-newsgroup-headers-xover                       627  11%
          - byte-code                                             616  11%
           - byte-code                                            532   9%
            - mail-decode-encoded-address-string                  356   6%
             - rfc2047-decode-string                              280   5%
              - rfc2047-decode-encoded-words                      194   3%
               - byte-code                                        191   3%
                - quoted-printable-decode-string                  187   3%
                   generate-new-buffer                             61   1%
                 - byte-code                                       38   0%
                  - kill-buffer                                     6   0%
                   - replace-buffer-in-windows                      2   0%
                      unrecord-window-buffer                        2   0%
                   mm-disable-multibyte                            31   0%
                   quoted-printable-decode-region                   2   0%
                 rfc2047-charset-to-coding-system                   3   0%
              - generate-new-buffer                                45   0%
                 get-buffer-create                                  1   0%
              - byte-code                                          29   0%
               - kill-buffer                                        4   0%
                - replace-buffer-in-windows                         2   0%
                   unrecord-window-buffer                           1   0%
              - rfc2047-strip-backslashes-in-quoted-strings                  2   0%
                 byte-code                                          1   0%
            - mail-decode-encoded-word-string                     129   2%
             - rfc2047-decode-encoded-words                        91   1%
              - byte-code                                          89   1%
               - quoted-printable-decode-string                    88   1%
                  generate-new-buffer                              27   0%
                  mm-disable-multibyte                             18   0%
                - byte-code                                        16   0%
                 - kill-buffer                                      3   0%
                  - replace-buffer-in-windows                       2   0%
                     unrecord-window-buffer                         1   0%
                - quoted-printable-decode-region                    2   0%
                   mm-coding-system-p                               1   0%
                rfc2047-charset-to-coding-system                    1   0%
               byte-code                                           18   0%
               generate-new-buffer                                 14   0%
           - mail-header-remove-comments                           57   1%
              generate-new-buffer                                  43   0%
            - byte-code                                            12   0%
             - kill-buffer                                          4   0%
                replace-buffer-in-windows                           1   0%
              ietf-drums-unfold-fws                                 2   0%
         - gnus-retrieve-headers                                    2   0%
          - gnus-cache-retrieve-headers                             2   0%
           - gnus-retrieve-headers                                  2   0%
            - nnml-retrieve-headers                                 2   0%
             - nnml-retrieve-headers-with-nov                       2   0%
              - nnheader-insert-file-contents                       1   0%
                 mm-insert-file-contents                            1   0%
                nnheader-nov-delete-outside-range                   1   0%
        - gnus-request-group                                        1   0%
         - nnml-request-group                                       1   0%
            nnml-possibly-change-directory                          1   0%
        - gnus-set-global-variables                                 1   0%
           generate-new-buffer                                      1   0%
        - gnus-group-auto-expirable-p                               1   0%
           gnus-group-find-parameter                                1   0%
        - gnus-article-setup-buffer                                 1   0%
         - gnus-article-mode                                        1   0%
          - gnus-update-format-specifications                       1   0%
             gnus-continuum-version                                 1   0%
       - gnus-summary-setup-buffer                                  2   0%
          gnus-get-buffer-create                                    1   0%
        - gnus-summary-mode                                         1   0%
         - gnus-update-summary-mark-positions                       1   0%
          - gnus-summary-insert-line                                1   0%
           - byte-code                                              1   0%
            - eval                                                  1   0%
             - let                                                  1   0%
              - gnus-add-text-properties                            1   0%
               - progn                                              1   0%
                - insert                                            1   0%
                   format                                           1   0%
       - gnus-possibly-score-headers                                1   0%
        - gnus-all-score-files                                      1   0%
         - gnus-score-find-bnews                                    1   0%
            gnus-get-buffer-create                                  1   0%
       - gnus-summary-initial-limit                                 1   0%
        - mapatoms                                                  1   0%
           #<compiled 0xea9eef>                                     1   0%
         gnus-configure-windows                                     1   0%
       - gnus-set-mode-line                                         1   0%
        - gnus-group-decoded-name                                   1   0%
           gnus-group-name-decode                                   1   0%
   - next-line                                                     98   1%
    - funcall                                                      95   1%
     - #<compiled 0xf5d409>                                        95   1%
      - line-move                                                  95   1%
       - line-move-visual                                          71   1%
        - posn-at-point                                             1   0%
           eval                                                     1   0%
       - line-move-partial                                         14   0%
        - default-line-height                                       6   0%
           default-font-height                                      6   0%
        - window-screen-lines                                       6   0%
         - default-line-height                                      5   0%
            default-font-height                                     2   0%
       - default-line-height                                        2   0%
          default-font-height                                       1   0%
   - previous-line                                                 28   0%
    - funcall                                                      27   0%
     - #<compiled 0xdf1c53>                                        27   0%
      - line-move                                                  27   0%
       - line-move-visual                                          20   0%
        - posn-at-point                                             1   0%
           file-remote-p                                            1   0%
       - line-move-partial                                          2   0%
        - default-line-height                                       2   0%
           default-font-height                                      2   0%
   - execute-extended-command                                      24   0%
    - command-execute                                              18   0%
     - call-interactively                                          18   0%
      - funcall-interactively                                      18   0%
       - profiler-report                                           18   0%
        - profiler-report-cpu                                      18   0%
         - profiler-report-profile-other-window                    10   0%
          - profiler-report-setup-buffer                            9   0%
           - profiler-report-render-calltree                        8   0%
            - profiler-report-rerender-calltree                     8   0%
             - profiler-report-render-calltree-1                    8   0%
              - profiler-calltree-build                             8   0%
               - profiler-calltree-build-unified                    8   0%
                - maphash                                           8   0%
                   #<compiled 0x12ffbe1>                            2   0%
                 - #<compiled 0xf48ceb>                             1   0%
                  - puthash                                         1   0%
                     #<compiled 0xf72255>                           1   0%
                   #<compiled 0xf81b5d>                             1   0%
             profiler-report-setup-buffer-1                         1   0%
          - switch-to-buffer-other-window                           1   0%
           - pop-to-buffer                                          1   0%
            - display-buffer                                        1   0%
             - display-buffer--maybe-pop-up-frame-or-window                  1   0%
              - display-buffer-pop-up-window                        1   0%
               - window--try-to-split-window                        1   0%
                - funcall                                           1   0%
                 - split-window-sensibly                            1   0%
                  - split-window-below                              1   0%
                   - split-window                                   1   0%
                      byte-code                                     1   0%
           profiler-cpu-profile                                     8   0%
   - profiler-report-toggle-entry                                  14   0%
    - profiler-report-expand-entry                                 13   0%
     - profiler-report-expand-entry                                11   0%
      - profiler-report-insert-calltree-children                   10   0%
       - mapc                                                      10   0%
        - profiler-report-insert-calltree                           8   0%
         - profiler-report-line-format                              7   0%
          - profiler-format                                         4   0%
           - apply                                                  4   0%
              profiler-format                                       1   0%
            profiler-report-make-name-part                          1   0%
     - profiler-report-insert-calltree-children                     1   0%
        mapc                                                        1   0%
     left-char                                                      7   0%
   - find-file                                                      6   0%
    - find-file-noselect                                            6   0%
     - find-file-noselect-1                                         4   0%
      - after-find-file                                             4   0%
       - normal-mode                                                2   0%
        - funcall                                                   2   0%
         - #<compiled 0x22a7b3>                                     2   0%
          - set-auto-mode                                           2   0%
           - hack-local-variables                                   2   0%
            - inhibit-local-variables-p                             2   0%
               file-name-sans-versions                              2   0%
       - run-hooks                                                  2   0%
        - vc-find-file-hook                                         2   0%
         - vc-backend                                               2   0%
          - vc-registered                                           2   0%
           - byte-code                                              2   0%
            - mapc                                                  1   0%
             - #<compiled 0x27cda9>                                 1   0%
              - vc-call-backend                                     1   0%
               - apply                                              1   0%
                - vc-svn-registered                                 1   0%
                   generate-new-buffer                              1   0%
     - find-buffer-visiting                                         1   0%
        file-truename                                               1   0%
     scroll-up-command                                              3   0%
   - end-of-buffer                                                  3   0%
      push-mark                                                     2   0%
     right-char                                                     2   0%
   - kill-ring-save                                                 2   0%
    - copy-region-as-kill                                           2   0%
     - #<compiled 0xf426d1>                                         2   0%
      - apply                                                       2   0%
       - rectangle--extract-region                                  2   0%
        - #<compiled 0x3cebb1>                                      2   0%
         - filter-buffer-substring                                  2   0%
          - buffer-substring--filter                                2   0%
           - #<compiled 0xf6ccd1>                                   2   0%
              apply                                                 2   0%
   - yank                                                           2   0%
    - current-kill                                                  1   0%
     - x-selection-value                                            1   0%
        x-selection-value-internal                                  1   0%
    - insert-for-yank                                               1   0%
     - insert-for-yank-1                                            1   0%
        remove-yank-excluded-properties                             1   0%
   - pm/save-buffer                                                 2   0%
    - save-buffer                                                   2   0%
     - basic-save-buffer                                            1   0%
      - basic-save-buffer-1                                         1   0%
       - basic-save-buffer-2                                        1   0%
        - write-region                                              1   0%
         - select-safe-coding-system                                1   0%
          - find-auto-coding                                        1   0%
             auto-coding-alist-lookup                               1   0%
   - universal-argument                                             1   0%
      universal-argument--mode                                      1   0%
   - newline                                                        1   0%
      self-insert-command                                           1   0%
  - byte-code                                                     305   5%
   - read-extended-command                                        263   4%
    - completing-read                                             263   4%
     - completing-read-default                                    263   4%
      - read-from-minibuffer                                      225   4%
       - command-execute                                          103   1%
        - call-interactively                                      103   1%
         - funcall-interactively                                  103   1%
          - minibuffer-complete                                   102   1%
           - completion-in-region                                 102   1%
            - completion--in-region                               102   1%
             - #<compiled 0xf60147>                               102   1%
              - apply                                             102   1%
               - #<compiled 0x246799>                             102   1%
                - completion--in-region-1                         102   1%
                 - completion--do-completion                      101   1%
                  - completion-try-completion                      55   1%
                   - completion--nth-completion                    55   1%
                    - completion--some                             55   1%
                     - funcall                                     55   1%
                      - #<compiled 0x15a1ee7>                      55   1%
                       - #<compiled 0x16b4437>                     55   1%
                        - completion-basic-try-completion                 55   1%
                         - try-completion                           2   0%
                          - completion-file-name-table                  2   0%
                           - funcall                                2   0%
                              #<compiled 0xf77c67>                  2   0%
                  - minibuffer-completion-help                     38   0%
                   - funcall                                       22   0%
                    - #<compiled 0xf3fe05>                         22   0%
                       fit-window-to-buffer                        22   0%
                   - completion-all-completions                    11   0%
                    - completion--nth-completion                   11   0%
                     - completion--some                            11   0%
                      - funcall                                    11   0%
                       - #<compiled 0x175f097>                     11   0%
                        - #<compiled 0x175ecab>                    11   0%
                         - completion-basic-all-completions                 11   0%
                            completion-pcm--all-completions                 11   0%
                   - temp-buffer-window-show                        3   0%
                    - display-buffer                                2   0%
                     - display-buffer-at-bottom                     2   0%
                      - walk-window-tree                            1   0%
                       - walk-window-tree-1                         1   0%
                        - walk-window-tree-1                        1   0%
                         - #<compiled 0x2278fd>                     1   0%
                            window-in-direction                     1   0%
                      - byte-code                                   1   0%
                       - split-window                               1   0%
                          byte-code                                 1   0%
                   - display-completion-list                        1   0%
                    - run-hooks                                     1   0%
                       completion-setup-function                    1   0%
                  - completion--done                                7   0%
                   - completion--message                            7   0%
                    - minibuffer-message                            7   0%
                       sit-for                                      6   0%
                  - minibuffer-hide-completions                     1   0%
                   - bury-buffer                                    1   0%
                    - window--delete                                1   0%
                     - delete-window                                1   0%
                        byte-code                                   1   0%
                 - pos-visible-in-window-p                          1   0%
                  - eval                                            1   0%
                     if                                             1   0%
          - backward-kill-word                                      1   0%
           - kill-word                                              1   0%
            - kill-region                                           1   0%
             - funcall                                              1   0%
              - #<compiled 0x15ecd63>                               1   0%
               - kill-new                                           1   0%
                - x-select-text                                     1   0%
                   x-set-selection                                  1   0%
       - timer-event-handler                                       23   0%
        - byte-code                                                20   0%
         - apply                                                   20   0%
          - file-truename                                           1   0%
           - file-symlink-p                                         1   0%
            - tramp-completion-file-name-handler                    1   0%
             - let                                                  1   0%
              - if                                                  1   0%
               - tramp-completion-run-real-handler                  1   0%
                - let*                                              1   0%
                 - apply                                            1   0%
                  - file-symlink-p                                  1   0%
                   - tramp-completion-file-name-handler                  1   0%
                    - let                                           1   0%
                     - if                                           1   0%
                      - tramp-completion-run-real-handler                  1   0%
                       - let*                                       1   0%
                          apply                                     1   0%
        - timer-activate-when-idle                                  1   0%
         - timer--activate                                          1   0%
            timer--time-less-p                                      1   0%
         redisplay_internal (C function)                            1   0%
   - find-file-read-args                                           42   0%
    - read-file-name                                               42   0%
     - read-file-name-default                                      42   0%
      - completing-read                                            41   0%
       - completing-read-default                                   41   0%
        - read-from-minibuffer                                     20   0%
         - timer-event-handler                                      1   0%
          - byte-code                                               1   0%
             apply                                                  1   0%
+ ...                                                            1819  33%
+ timer-event-handler                                            1074  19%
+ redisplay_internal (C function)                                  36   0%
+ internal-timer-start-idle                                         3   0%
  tooltip-hide                                                      3   0%
+ deactivate-mark                                                   1   0%
+ gnus-set-global-variables                                         1   0%

[-- Attachment #3: profiler-fast.txt --]
[-- Type: text/plain, Size: 12676 bytes --]

- command-execute                                                 303  70%
 - call-interactively                                             303  70%
  - funcall-interactively                                         272  63%
   - gnus-group-select-group                                      261  60%
    - gnus-group-read-group                                       261  60%
     - gnus-summary-read-group                                    261  60%
      - gnus-summary-read-group-1                                 261  60%
       - gnus-summary-prepare                                     149  34%
        - gnus-sort-threads                                        80  18%
         - byte-code                                               80  18%
          - gnus-sort-threads-recursive                            80  18%
           - sort                                                  69  16%
            - #<compiled 0xecd8db>                                 68  15%
             - gnus-thread-sort-by-most-recent-date                 67  15%
              - gnus-thread-latest-date                            67  15%
               - mapcar                                            64  14%
                - #<compiled 0xe50cbd>                             63  14%
                 - safe-date-to-time                               61  14%
                  - date-to-time                                   61  14%
                   - byte-code                                     60  13%
                    - parse-time-string                            54  12%
                     - parse-time-tokenize                          8   1%
                        byte-code                                   2   0%
                      apply                                         3   0%
           - mapcar                                                11   2%
            - #<compiled 0xe4f509>                                 11   2%
             - gnus-sort-subthreads-recursive                      11   2%
              - sort                                                7   1%
               - #<compiled 0xecd8db>                               7   1%
                - gnus-thread-sort-by-most-recent-date                  7   1%
                 - gnus-thread-latest-date                          7   1%
                  - mapcar                                          7   1%
                   - #<compiled 0xe50cbd>                           7   1%
                    - safe-date-to-time                             7   1%
                     - date-to-time                                 7   1%
                      - byte-code                                   7   1%
                       - parse-time-string                          7   1%
                          parse-time-tokenize                       1   0%
              - mapcar                                              4   0%
               - #<compiled 0xe4fc53>                               4   0%
                - gnus-sort-subthreads-recursive                    4   0%
                 - mapcar                                           3   0%
                  - #<compiled 0xe4fc53>                            3   0%
                   - gnus-sort-subthreads-recursive                  3   0%
                    - sort                                          3   0%
                     - #<compiled 0xecd8db>                         3   0%
                      - gnus-thread-sort-by-most-recent-date                  3   0%
                       - gnus-thread-latest-date                    3   0%
                        - mapcar                                    3   0%
                         - #<compiled 0xe50cbd>                     3   0%
                          - safe-date-to-time                       3   0%
                           - date-to-time                           3   0%
                            - byte-code                             3   0%
                             - parse-time-string                    3   0%
                                parse-time-tokenize                  1   0%
                 - sort                                             1   0%
                  - #<compiled 0xecd8db>                            1   0%
                   - gnus-thread-sort-by-most-recent-date                  1   0%
                    - gnus-thread-latest-date                       1   0%
                     - mapcar                                       1   0%
                      - #<compiled 0xe50cbd>                        1   0%
                       - safe-date-to-time                          1   0%
                        - date-to-time                              1   0%
                         - byte-code                                1   0%
                            apply                                   1   0%
        - gnus-summary-prepare-threads                             57  13%
         - eval                                                    46  10%
          - let                                                    46  10%
           - gnus-add-text-properties                              44  10%
            - progn                                                43   9%
             - insert                                              42   9%
              - format                                             39   9%
               - let*                                              19   4%
                - eval                                             18   4%
                 - let                                             18   4%
                  - eval                                           18   4%
                   - gnus-summary-from-or-to-or-newsgroups                 18   4%
                    - mail-decode-encoded-address-string                 13   3%
                     - rfc2047-decode-string                        7   1%
                      - rfc2047-decode-encoded-words                  4   0%
                       - byte-code                                  4   0%
                          quoted-printable-decode-string                  2   0%
                      - byte-code                                   2   0%
                       - kill-buffer                                1   0%
                        - replace-buffer-in-windows                  1   0%
                           unrecord-window-buffer                   1   0%
                        rfc2047-strip-backslashes-in-quoted-strings                  1   0%
                      gnus-extract-address-components                  1   0%
               - gnus-user-date                                    19   4%
                - byte-code                                        16   3%
                 - eval                                            12   2%
                    gnus-seconds-year                               8   1%
                    gnus-seconds-today                              3   0%
                    -                                               1   0%
              cons                                                  1   0%
             if                                                     1   0%
           gnus-summary-highlight-line                              5   1%
           apply                                                    1   0%
        - gnus-gather-threads-by-references                         2   0%
         - mail-header-remove-comments                              2   0%
          - byte-code                                               2   0%
           - kill-buffer                                            1   0%
              replace-buffer-in-windows                             1   0%
       - gnus-select-newsgroup                                    109  25%
        - gnus-fetch-headers                                      107  24%
         - gnus-get-newsgroup-headers-xover                       105  24%
          - byte-code                                              98  22%
           - byte-code                                             78  18%
            - mail-decode-encoded-address-string                   53  12%
             - rfc2047-decode-string                               41   9%
              - rfc2047-decode-encoded-words                       25   5%
               - byte-code                                         23   5%
                - quoted-printable-decode-string                   18   4%
                   generate-new-buffer                              3   0%
                   mm-disable-multibyte                             3   0%
                 - byte-code                                        2   0%
                    kill-buffer                                     1   0%
               - rfc2047-charset-to-coding-system                   1   0%
                  mm-charset-to-coding-system                       1   0%
                generate-new-buffer                                 3   0%
                byte-code                                           3   0%
                rfc2047-strip-backslashes-in-quoted-strings                  2   0%
            - mail-decode-encoded-word-string                      15   3%
             - rfc2047-decode-encoded-words                        11   2%
              - byte-code                                          11   2%
               - quoted-printable-decode-string                     8   1%
                - byte-code                                         4   0%
                   kill-buffer                                      2   0%
                  mm-disable-multibyte                              2   0%
                  generate-new-buffer                               1   0%
               generate-new-buffer                                  1   0%
               byte-code                                            1   0%
           - mail-header-remove-comments                            3   0%
            - byte-code                                             3   0%
             - kill-buffer                                          1   0%
                replace-buffer-in-windows                           1   0%
         - gnus-retrieve-headers                                    2   0%
          - gnus-cache-retrieve-headers                             2   0%
           - gnus-retrieve-headers                                  2   0%
            - nnml-retrieve-headers                                 2   0%
             - nnml-retrieve-headers-with-nov                       2   0%
              - nnheader-insert-file-contents                       2   0%
                 mm-insert-file-contents                            2   0%
          gnus-articles-to-read                                     1   0%
       - gnus-summary-setup-buffer                                  1   0%
        - gnus-summary-mode                                         1   0%
         - gnus-update-summary-mark-positions                       1   0%
            gnus-summary-insert-line                                1   0%
       - gnus-summary-initial-limit                                 1   0%
          mapatoms                                                  1   0%
       - gnus-summary-auto-select-subject                           1   0%
        - gnus-summary-first-unread-subject                         1   0%
         - gnus-summary-first-subject                               1   0%
          - gnus-message                                            1   0%
             apply                                                  1   0%
   - execute-extended-command                                      11   2%
    - command-execute                                               8   1%
     - call-interactively                                           8   1%
      - funcall-interactively                                       8   1%
       - profiler-report                                            8   1%
        - profiler-report-cpu                                       8   1%
           profiler-cpu-profile                                     8   1%
  - byte-code                                                      31   7%
   - read-extended-command                                         31   7%
    - completing-read                                              31   7%
     - completing-read-default                                     31   7%
        read-from-minibuffer                                       22   5%
+ ...                                                             128  29%

^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2014-09-25 21:36     ` Peter Münster
@ 2014-09-26  6:57       ` Eli Zaretskii
  2014-09-26  7:15         ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2014-09-26  6:57 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

> From: Peter Münster <pmlists@free.fr>
> Date: Thu, 25 Sep 2014 23:36:36 +0200
> Cc: 18522@debbugs.gnu.org
> 
> Please find attached 2 files with profiler-reports when entering a Gnus
> group:
> - profiler-slow.txt: entering a group is slow, and emacs was uptime since
>   about 3 days
> - profiler-fast.txt: entering the same group after a fresh restart of emacs

Is that for the same input?  How come command-execute was called 2464
times in the first profile, and only 303 times in the second?  This
alone can explain an 8-fold slowdown.

Sorry if this is a silly question: I don't use Gnus.  But to compare 2
profiles, you need to create each one of them when Emacs does the same
job in each time.  Otherwise, there's a factor at work that we cannot
glean from the profile alone.

Anyway, looks like gnus-summary-read-group-1 takes a lot of CPU in
both cases, which is above the mapcar part.  Below mapcar, the most
expensive part is parse-time-string, which doesn't really surprise me.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2014-09-26  6:57       ` Eli Zaretskii
@ 2014-09-26  7:15         ` Peter Münster
  2014-09-26  7:36           ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2014-09-26  7:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 18522

On Fri, Sep 26 2014, Eli Zaretskii wrote:

>> Please find attached 2 files with profiler-reports when entering a Gnus
>> group:
>> - profiler-slow.txt: entering a group is slow, and emacs was uptime since
>>   about 3 days
>> - profiler-fast.txt: entering the same group after a fresh restart of emacs
>
> Is that for the same input?

Yes. In both cases I call gnus-group-select-group for the same group.


> How come command-execute was called 2464 times in the first profile,
> and only 303 times in the second? This alone can explain an 8-fold
> slowdown.

Sorry, I forgot to label the columns: 303 and 2464 are "CPU samples".


> Anyway, looks like gnus-summary-read-group-1 takes a lot of CPU in
> both cases, which is above the mapcar part.  Below mapcar, the most
> expensive part is parse-time-string, which doesn't really surprise me.

On line 16, the slow mapcar takes 1090 CPU samples and the fast one 64.
Below line 16, the profiler outputs are different and I don't know why
and how to debug further...

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2014-09-26  7:15         ` Peter Münster
@ 2014-09-26  7:36           ` Eli Zaretskii
  2014-10-01 19:55             ` Peter Münster
  2014-10-01 19:58             ` Glenn Morris
  0 siblings, 2 replies; 84+ messages in thread
From: Eli Zaretskii @ 2014-09-26  7:36 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: monnier@iro.umontreal.ca,  18522@debbugs.gnu.org
> Date: Fri, 26 Sep 2014 09:15:01 +0200
> 
> > How come command-execute was called 2464 times in the first profile,
> > and only 303 times in the second? This alone can explain an 8-fold
> > slowdown.
> 
> Sorry, I forgot to label the columns: 303 and 2464 are "CPU samples".

No, it's me that needs to be sorry: I keep forgetting that.

> > Anyway, looks like gnus-summary-read-group-1 takes a lot of CPU in
> > both cases, which is above the mapcar part.  Below mapcar, the most
> > expensive part is parse-time-string, which doesn't really surprise me.
> 
> On line 16, the slow mapcar takes 1090 CPU samples and the fast one 64.
> Below line 16, the profiler outputs are different and I don't know why
> and how to debug further...

I think the conclusion is that parse-time-string takes the blame.  To
see what part in parse-time-string is the culprit, perhaps load
parse-time.el (the source) before the experiment, and maybe the
profile will show more useful info.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2014-09-26  7:36           ` Eli Zaretskii
@ 2014-10-01 19:55             ` Peter Münster
  2014-10-01 19:58             ` Glenn Morris
  1 sibling, 0 replies; 84+ messages in thread
From: Peter Münster @ 2014-10-01 19:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 18522

On Fri, Sep 26 2014, Eli Zaretskii wrote:

> I think the conclusion is that parse-time-string takes the blame.  To
> see what part in parse-time-string is the culprit, perhaps load
> parse-time.el (the source) before the experiment, and maybe the
> profile will show more useful info.

This is the result:

--8<---------------cut here---------------start------------->8---
- command-execute                                                3228  94%
 - call-interactively                                            3228  94%
  - funcall-interactively                                        3150  92%
   - gnus-group-select-group                                     3142  92%
    - gnus-group-read-group                                      3142  92%
     - gnus-summary-read-group                                   3142  92%
      - gnus-summary-read-group-1                                3142  92%
       - gnus-summary-prepare                                    2772  81%
        - gnus-sort-threads                                      2657  78%
         - byte-code                                             2657  78%
          - gnus-sort-threads-recursive                          2657  78%
           - sort                                                2649  77%
            - #<compiled 0x16237ad>                              2649  77%
             - gnus-thread-sort-by-most-recent-date               2648  77%
              - gnus-thread-latest-date                          2648  77%
               - mapcar                                          2647  77%
                - #<compiled 0x8d9233>                           2645  77%
                 - safe-date-to-time                             2641  77%
                  - date-to-time                                 2641  77%
                   - byte-code                                   2641  77%
                    - parse-time-string                          2638  77%
                     - let                                       2637  77%
                      - parse-time-tokenize                      2613  76%
                       - let                                     2612  76%
                        - while                                  2612  76%
                         - while                                 2605  76%
                          - and                                  2602  76%
                           - setq                                1719  50%
                            - parse-time-string-chars               1712  50%
                             - save-match-data                   1697  49%
                              - let                              1689  49%
                               - unwind-protect                  1680  49%
                                - progn                          1675  49%
                                 - let                             26   0%
                                  - cond                           19   0%
                                     string-match                   1   0%
                           - not                                  876  25%
                            - setq                                875  25%
                             - parse-time-string-chars                874  25%
                              - save-match-data                   870  25%
                               - let                              868  25%
                                - unwind-protect                  865  25%
                                 - progn                          861  25%
                                  - let                            22   0%
                                   - cond                          22   0%
                                    - string-match                  4   0%
                                       setq                         4   0%
                                   set-match-data                   1   0%
                           - <                                      2   0%
                              setq                                  1   0%
                            setq                                    1   0%
                         - if                                       4   0%
                          - setq                                    4   0%
                           - cons                                   2   0%
                            - if                                    2   0%
                             - parse-integer                        1   0%
                              - let                                 1   0%
                               - if                                 1   0%
                                - progn                             1   0%
                                   let                              1   0%
                      - while                                      24   0%
                       - let                                       24   0%
                        - while                                    23   0%
                         - let*                                    20   0%
                          - if                                     13   0%
                           - progn                                  7   0%
                            - while                                 6   0%
                             - let                                  6   0%
                              - if                                  6   0%
                               - let                                6   0%
                                - if                                5   0%
                                 - parse-integer                    5   0%
                                  - let                             4   0%
                                   - if                             4   0%
                                    - progn                         3   0%
                                     - let                          3   0%
                                      - while                       1   0%
                                         and                        1   0%
                                        if                          1   0%
                                - car-safe                          1   0%
                                 - prog1                            1   0%
                                    setq                            1   0%
                           - and                                    6   0%
                            - setq                                  5   0%
                             - cond                                 5   0%
                              - and                                 2   0%
                               - not                                1   0%
                                  eq                                1   0%
                                 <=                                 1   0%
                                cdr                                 1   0%
                                funcall                             1   0%
                          - car-safe                                6   0%
                           - prog1                                  3   0%
                              setq                                  2   0%
                           and                                      1   0%
                          car-safe                                  1   0%
                      apply                                         3   0%
               - message-flatten-list                               1   0%
                  apply                                             1   0%
           - mapcar                                                 7   0%
            - #<compiled 0x8d7e39>                                  7   0%
             - gnus-sort-subthreads-recursive                       7   0%
              - mapcar                                              4   0%
               - #<compiled 0x8d8185>                               4   0%
                - gnus-sort-subthreads-recursive                    4   0%
                 - mapcar                                           4   0%
                  - #<compiled 0x8d8185>                            3   0%
                   - gnus-sort-subthreads-recursive                  3   0%
                    - sort                                          3   0%
                     - #<compiled 0x16237ad>                        3   0%
                      - gnus-thread-sort-by-most-recent-date                  3   0%
                       - gnus-thread-latest-date                    3   0%
                        - mapcar                                    3   0%
                         - #<compiled 0x8d9233>                     3   0%
                          - safe-date-to-time                       3   0%
                           - date-to-time                           3   0%
                            - byte-code                             3   0%
                             - parse-time-string                    2   0%
                              - let                                 2   0%
                               - parse-time-tokenize                  2   0%
                                - let                               2   0%
                                 - while                            2   0%
                                    while                           1   0%
                               apply                                1   0%
              - sort                                                3   0%
               - #<compiled 0x16237ad>                              3   0%
                - gnus-thread-sort-by-most-recent-date                  3   0%
                 - gnus-thread-latest-date                          3   0%
                  - mapcar                                          3   0%
                   - #<compiled 0x8d9233>                           3   0%
                    - safe-date-to-time                             3   0%
                     - date-to-time                                 3   0%
                      - byte-code                                   3   0%
                         apply                                      2   0%
                       - parse-time-string                          1   0%
                        - let                                       1   0%
                         - while                                    1   0%
                          - let                                     1   0%
                             while                                  1   0%
        - gnus-summary-prepare-threads                             97   2%
         - eval                                                    88   2%
          - let                                                    88   2%
           - gnus-add-text-properties                              85   2%
            - progn                                                84   2%
             - insert                                              82   2%
              - format                                             80   2%
               - let*                                              54   1%
                - eval                                             54   1%
                 - let                                             54   1%
                  - eval                                           51   1%
                   - gnus-summary-from-or-to-or-newsgroups                 50   1%
                    - mail-decode-encoded-address-string                 49   1%
                     - rfc2047-decode-string                       35   1%
                      - rfc2047-decode-encoded-words                 16   0%
                       - byte-code                                 16   0%
                        - quoted-printable-decode-string                 16   0%
                           generate-new-buffer                      5   0%
                         - byte-code                                3   0%
                          - kill-buffer                             1   0%
                           - replace-buffer-in-windows                  1   0%
                              unrecord-window-buffer                  1   0%
                           mm-disable-multibyte                     2   0%
                           quoted-printable-decode-region                  1   0%
                        generate-new-buffer                         7   0%
                      - byte-code                                   6   0%
                         kill-buffer                                4   0%
                        rfc2047-strip-backslashes-in-quoted-strings                  2   0%
                      bidi-string-mark-left-to-right                  1   0%
                  - if                                              2   0%
                     if                                             1   0%
                     >                                              1   0%
               - gnus-user-date                                    23   0%
                - byte-code                                        21   0%
                 - eval                                            17   0%
                    gnus-seconds-year                               8   0%
                    gnus-seconds-today                              6   0%
                  - +                                               2   0%
                     gnus-seconds-today                             1   0%
                 gnus-summary-line-message-size                     3   0%
            - cons                                                  1   0%
               cons                                                 1   0%
         - gnus-summary-highlight-line                              3   0%
            gnus-put-text-property-excluding-characters-with-faces                  1   0%
        - gnus-gather-threads-by-references                         9   0%
         - mail-header-remove-comments                              8   0%
          - byte-code                                               5   0%
           - kill-buffer                                            2   0%
            - replace-buffer-in-windows                             1   0%
               unrecord-window-buffer                               1   0%
            generate-new-buffer                                     3   0%
        - gnus-make-threads                                         1   0%
         - mapatoms                                                 1   0%
          - #<compiled 0x8d6107>                                    1   0%
           - mapcar                                                 1   0%
              #<compiled 0x8d60e3>                                  1   0%
       - gnus-select-newsgroup                                    366  10%
        - gnus-fetch-headers                                      363  10%
         - gnus-get-newsgroup-headers-xover                       362  10%
          - byte-code                                             354  10%
           - byte-code                                            292   8%
            - mail-decode-encoded-address-string                  203   5%
             - rfc2047-decode-string                              141   4%
              - rfc2047-decode-encoded-words                      105   3%
               - byte-code                                         97   2%
                - quoted-printable-decode-string                   86   2%
                   generate-new-buffer                             19   0%
                 - byte-code                                       19   0%
                  - kill-buffer                                     2   0%
                     replace-buffer-in-windows                      1   0%
                   mm-disable-multibyte                            16   0%
                   quoted-printable-decode-region                   1   0%
               - rfc2047-charset-to-coding-system                   7   0%
                - mm-charset-to-coding-system                       3   0%
                   mm-coding-system-p                               2   0%
                generate-new-buffer                                16   0%
              - byte-code                                          13   0%
               - kill-buffer                                        4   0%
                - replace-buffer-in-windows                         2   0%
                   unrecord-window-buffer                           2   0%
              - rfc2047-strip-backslashes-in-quoted-strings                  2   0%
               - byte-code                                          2   0%
                  forward-sexp                                      2   0%
            - mail-decode-encoded-word-string                      58   1%
             - rfc2047-decode-encoded-words                        44   1%
              - byte-code                                          43   1%
               - quoted-printable-decode-string                    40   1%
                  mm-disable-multibyte                              7   0%
                - byte-code                                         5   0%
                 - kill-buffer                                      1   0%
                    replace-buffer-in-windows                       1   0%
                  generate-new-buffer                               4   0%
             - byte-code                                            7   0%
              - kill-buffer                                         1   0%
               - replace-buffer-in-windows                          1   0%
                  unrecord-window-buffer                            1   0%
               generate-new-buffer                                  2   0%
           - mail-header-remove-comments                           33   0%
              generate-new-buffer                                  21   0%
            - byte-code                                            12   0%
             - kill-buffer                                          4   0%
              - replace-buffer-in-windows                           2   0%
                 unrecord-window-buffer                             1   0%
         - gnus-retrieve-headers                                    1   0%
          - gnus-cache-retrieve-headers                             1   0%
           - gnus-retrieve-headers                                  1   0%
            - nnml-retrieve-headers                                 1   0%
             - nnml-retrieve-headers-with-nov                       1   0%
              - nnheader-insert-file-contents                       1   0%
                 mm-insert-file-contents                            1   0%
        - gnus-summary-setup-default-charset                        1   0%
           gnus-parameter-charset                                   1   0%
        - gnus-article-setup-buffer                                 1   0%
           gnus-get-buffer-create                                   1   0%
       - gnus-group-decoded-name                                    1   0%
          gnus-group-name-decode                                    1   0%
       - gnus-summary-setup-buffer                                  1   0%
        - gnus-summary-mode                                         1   0%
         - gnus-update-summary-mark-positions                       1   0%
            gnus-summary-insert-line                                1   0%
       - gnus-run-hooks                                             1   0%
        - apply                                                     1   0%
         - run-hooks                                                1   0%
          - gnus-apply-kill-file                                    1   0%
             gnus-newsgroup-kill-file                               1   0%
   - execute-extended-command                                       8   0%
    - command-execute                                               6   0%
     - call-interactively                                           6   0%
      - funcall-interactively                                       6   0%
       - profiler-report                                            6   0%
        - profiler-report-cpu                                       6   0%
           profiler-cpu-profile                                     6   0%
  - byte-code                                                      78   2%
   - read-extended-command                                         78   2%
    - completing-read                                              78   2%
     - completing-read-default                                     78   2%
      - read-from-minibuffer                                       66   1%
       - redisplay_internal (C function)                            1   0%
          menu-bar-update-buffers                                   1   0%
       - timer-event-handler                                        1   0%
        - timer-activate-when-idle                                  1   0%
         - timer--activate                                          1   0%
            timer--time-less-p                                      1   0%
+ ...                                                             167   4%
+ timer-event-handler                                               6   0%
  redisplay_internal (C function)                                   1   0%
--8<---------------cut here---------------end--------------->8---

Is "progn" the problem?

What do you think?

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2014-09-26  7:36           ` Eli Zaretskii
  2014-10-01 19:55             ` Peter Münster
@ 2014-10-01 19:58             ` Glenn Morris
  2014-10-01 20:25               ` Peter Münster
  1 sibling, 1 reply; 84+ messages in thread
From: Glenn Morris @ 2014-10-01 19:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Peter Münster, 18522

Eli Zaretskii wrote:

> I think the conclusion is that parse-time-string takes the blame.

http://debbugs.gnu.org/14776





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2014-10-01 19:58             ` Glenn Morris
@ 2014-10-01 20:25               ` Peter Münster
  2015-02-13  8:26                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2014-10-01 20:25 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 18522

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

On Wed, Oct 01 2014, Glenn Morris wrote:

> http://debbugs.gnu.org/14776

Thanks. But it does not explain, why it's much faster after restarting
emacs. Please find attached 2 recent profiler reports for comparison.

-- 
           Peter

[-- Attachment #2: profiler-slow3.txt --]
[-- Type: text/plain, Size: 21479 bytes --]

- command-execute                                                3228  94%
 - call-interactively                                            3228  94%
  - funcall-interactively                                        3150  92%
   - gnus-group-select-group                                     3142  92%
    - gnus-group-read-group                                      3142  92%
     - gnus-summary-read-group                                   3142  92%
      - gnus-summary-read-group-1                                3142  92%
       - gnus-summary-prepare                                    2772  81%
        - gnus-sort-threads                                      2657  78%
         - byte-code                                             2657  78%
          - gnus-sort-threads-recursive                          2657  78%
           - sort                                                2649  77%
            - #<compiled 0x16237ad>                              2649  77%
             - gnus-thread-sort-by-most-recent-date               2648  77%
              - gnus-thread-latest-date                          2648  77%
               - mapcar                                          2647  77%
                - #<compiled 0x8d9233>                           2645  77%
                 - safe-date-to-time                             2641  77%
                  - date-to-time                                 2641  77%
                   - byte-code                                   2641  77%
                    - parse-time-string                          2638  77%
                     - let                                       2637  77%
                      - parse-time-tokenize                      2613  76%
                       - let                                     2612  76%
                        - while                                  2612  76%
                         - while                                 2605  76%
                          - and                                  2602  76%
                           - setq                                1719  50%
                            - parse-time-string-chars               1712  50%
                             - save-match-data                   1697  49%
                              - let                              1689  49%
                               - unwind-protect                  1680  49%
                                - progn                          1675  49%
                                 - let                             26   0%
                                  - cond                           19   0%
                                     string-match                   1   0%
                           - not                                  876  25%
                            - setq                                875  25%
                             - parse-time-string-chars                874  25%
                              - save-match-data                   870  25%
                               - let                              868  25%
                                - unwind-protect                  865  25%
                                 - progn                          861  25%
                                  - let                            22   0%
                                   - cond                          22   0%
                                    - string-match                  4   0%
                                       setq                         4   0%
                                   set-match-data                   1   0%
                           - <                                      2   0%
                              setq                                  1   0%
                            setq                                    1   0%
                         - if                                       4   0%
                          - setq                                    4   0%
                           - cons                                   2   0%
                            - if                                    2   0%
                             - parse-integer                        1   0%
                              - let                                 1   0%
                               - if                                 1   0%
                                - progn                             1   0%
                                   let                              1   0%
                      - while                                      24   0%
                       - let                                       24   0%
                        - while                                    23   0%
                         - let*                                    20   0%
                          - if                                     13   0%
                           - progn                                  7   0%
                            - while                                 6   0%
                             - let                                  6   0%
                              - if                                  6   0%
                               - let                                6   0%
                                - if                                5   0%
                                 - parse-integer                    5   0%
                                  - let                             4   0%
                                   - if                             4   0%
                                    - progn                         3   0%
                                     - let                          3   0%
                                      - while                       1   0%
                                         and                        1   0%
                                        if                          1   0%
                                - car-safe                          1   0%
                                 - prog1                            1   0%
                                    setq                            1   0%
                           - and                                    6   0%
                            - setq                                  5   0%
                             - cond                                 5   0%
                              - and                                 2   0%
                               - not                                1   0%
                                  eq                                1   0%
                                 <=                                 1   0%
                                cdr                                 1   0%
                                funcall                             1   0%
                          - car-safe                                6   0%
                           - prog1                                  3   0%
                              setq                                  2   0%
                           and                                      1   0%
                          car-safe                                  1   0%
                      apply                                         3   0%
               - message-flatten-list                               1   0%
                  apply                                             1   0%
           - mapcar                                                 7   0%
            - #<compiled 0x8d7e39>                                  7   0%
             - gnus-sort-subthreads-recursive                       7   0%
              - mapcar                                              4   0%
               - #<compiled 0x8d8185>                               4   0%
                - gnus-sort-subthreads-recursive                    4   0%
                 - mapcar                                           4   0%
                  - #<compiled 0x8d8185>                            3   0%
                   - gnus-sort-subthreads-recursive                  3   0%
                    - sort                                          3   0%
                     - #<compiled 0x16237ad>                        3   0%
                      - gnus-thread-sort-by-most-recent-date                  3   0%
                       - gnus-thread-latest-date                    3   0%
                        - mapcar                                    3   0%
                         - #<compiled 0x8d9233>                     3   0%
                          - safe-date-to-time                       3   0%
                           - date-to-time                           3   0%
                            - byte-code                             3   0%
                             - parse-time-string                    2   0%
                              - let                                 2   0%
                               - parse-time-tokenize                  2   0%
                                - let                               2   0%
                                 - while                            2   0%
                                    while                           1   0%
                               apply                                1   0%
              - sort                                                3   0%
               - #<compiled 0x16237ad>                              3   0%
                - gnus-thread-sort-by-most-recent-date                  3   0%
                 - gnus-thread-latest-date                          3   0%
                  - mapcar                                          3   0%
                   - #<compiled 0x8d9233>                           3   0%
                    - safe-date-to-time                             3   0%
                     - date-to-time                                 3   0%
                      - byte-code                                   3   0%
                         apply                                      2   0%
                       - parse-time-string                          1   0%
                        - let                                       1   0%
                         - while                                    1   0%
                          - let                                     1   0%
                             while                                  1   0%
        - gnus-summary-prepare-threads                             97   2%
         - eval                                                    88   2%
          - let                                                    88   2%
           - gnus-add-text-properties                              85   2%
            - progn                                                84   2%
             - insert                                              82   2%
              - format                                             80   2%
               - let*                                              54   1%
                - eval                                             54   1%
                 - let                                             54   1%
                  - eval                                           51   1%
                   - gnus-summary-from-or-to-or-newsgroups                 50   1%
                    - mail-decode-encoded-address-string                 49   1%
                     - rfc2047-decode-string                       35   1%
                      - rfc2047-decode-encoded-words                 16   0%
                       - byte-code                                 16   0%
                        - quoted-printable-decode-string                 16   0%
                           generate-new-buffer                      5   0%
                         - byte-code                                3   0%
                          - kill-buffer                             1   0%
                           - replace-buffer-in-windows                  1   0%
                              unrecord-window-buffer                  1   0%
                           mm-disable-multibyte                     2   0%
                           quoted-printable-decode-region                  1   0%
                        generate-new-buffer                         7   0%
                      - byte-code                                   6   0%
                         kill-buffer                                4   0%
                        rfc2047-strip-backslashes-in-quoted-strings                  2   0%
                      bidi-string-mark-left-to-right                  1   0%
                  - if                                              2   0%
                     if                                             1   0%
                     >                                              1   0%
               - gnus-user-date                                    23   0%
                - byte-code                                        21   0%
                 - eval                                            17   0%
                    gnus-seconds-year                               8   0%
                    gnus-seconds-today                              6   0%
                  - +                                               2   0%
                     gnus-seconds-today                             1   0%
                 gnus-summary-line-message-size                     3   0%
            - cons                                                  1   0%
               cons                                                 1   0%
         - gnus-summary-highlight-line                              3   0%
            gnus-put-text-property-excluding-characters-with-faces                  1   0%
        - gnus-gather-threads-by-references                         9   0%
         - mail-header-remove-comments                              8   0%
          - byte-code                                               5   0%
           - kill-buffer                                            2   0%
            - replace-buffer-in-windows                             1   0%
               unrecord-window-buffer                               1   0%
            generate-new-buffer                                     3   0%
        - gnus-make-threads                                         1   0%
         - mapatoms                                                 1   0%
          - #<compiled 0x8d6107>                                    1   0%
           - mapcar                                                 1   0%
              #<compiled 0x8d60e3>                                  1   0%
       - gnus-select-newsgroup                                    366  10%
        - gnus-fetch-headers                                      363  10%
         - gnus-get-newsgroup-headers-xover                       362  10%
          - byte-code                                             354  10%
           - byte-code                                            292   8%
            - mail-decode-encoded-address-string                  203   5%
             - rfc2047-decode-string                              141   4%
              - rfc2047-decode-encoded-words                      105   3%
               - byte-code                                         97   2%
                - quoted-printable-decode-string                   86   2%
                   generate-new-buffer                             19   0%
                 - byte-code                                       19   0%
                  - kill-buffer                                     2   0%
                     replace-buffer-in-windows                      1   0%
                   mm-disable-multibyte                            16   0%
                   quoted-printable-decode-region                   1   0%
               - rfc2047-charset-to-coding-system                   7   0%
                - mm-charset-to-coding-system                       3   0%
                   mm-coding-system-p                               2   0%
                generate-new-buffer                                16   0%
              - byte-code                                          13   0%
               - kill-buffer                                        4   0%
                - replace-buffer-in-windows                         2   0%
                   unrecord-window-buffer                           2   0%
              - rfc2047-strip-backslashes-in-quoted-strings                  2   0%
               - byte-code                                          2   0%
                  forward-sexp                                      2   0%
            - mail-decode-encoded-word-string                      58   1%
             - rfc2047-decode-encoded-words                        44   1%
              - byte-code                                          43   1%
               - quoted-printable-decode-string                    40   1%
                  mm-disable-multibyte                              7   0%
                - byte-code                                         5   0%
                 - kill-buffer                                      1   0%
                    replace-buffer-in-windows                       1   0%
                  generate-new-buffer                               4   0%
             - byte-code                                            7   0%
              - kill-buffer                                         1   0%
               - replace-buffer-in-windows                          1   0%
                  unrecord-window-buffer                            1   0%
               generate-new-buffer                                  2   0%
           - mail-header-remove-comments                           33   0%
              generate-new-buffer                                  21   0%
            - byte-code                                            12   0%
             - kill-buffer                                          4   0%
              - replace-buffer-in-windows                           2   0%
                 unrecord-window-buffer                             1   0%
         - gnus-retrieve-headers                                    1   0%
          - gnus-cache-retrieve-headers                             1   0%
           - gnus-retrieve-headers                                  1   0%
            - nnml-retrieve-headers                                 1   0%
             - nnml-retrieve-headers-with-nov                       1   0%
              - nnheader-insert-file-contents                       1   0%
                 mm-insert-file-contents                            1   0%
        - gnus-summary-setup-default-charset                        1   0%
           gnus-parameter-charset                                   1   0%
        - gnus-article-setup-buffer                                 1   0%
           gnus-get-buffer-create                                   1   0%
       - gnus-group-decoded-name                                    1   0%
          gnus-group-name-decode                                    1   0%
       - gnus-summary-setup-buffer                                  1   0%
        - gnus-summary-mode                                         1   0%
         - gnus-update-summary-mark-positions                       1   0%
            gnus-summary-insert-line                                1   0%
       - gnus-run-hooks                                             1   0%
        - apply                                                     1   0%
         - run-hooks                                                1   0%
          - gnus-apply-kill-file                                    1   0%
             gnus-newsgroup-kill-file                               1   0%
   - execute-extended-command                                       8   0%
    - command-execute                                               6   0%
     - call-interactively                                           6   0%
      - funcall-interactively                                       6   0%
       - profiler-report                                            6   0%
        - profiler-report-cpu                                       6   0%
           profiler-cpu-profile                                     6   0%
  - byte-code                                                      78   2%
   - read-extended-command                                         78   2%
    - completing-read                                              78   2%
     - completing-read-default                                     78   2%
      - read-from-minibuffer                                       66   1%
       - redisplay_internal (C function)                            1   0%
          menu-bar-update-buffers                                   1   0%
       - timer-event-handler                                        1   0%
        - timer-activate-when-idle                                  1   0%
         - timer--activate                                          1   0%
            timer--time-less-p                                      1   0%
+ ...                                                             167   4%
+ timer-event-handler                                               6   0%
  redisplay_internal (C function)                                   1   0%

[-- Attachment #3: profiler-fast3.txt --]
[-- Type: text/plain, Size: 16944 bytes --]

- command-execute                                                1047  84%
 - call-interactively                                            1047  84%
  - funcall-interactively                                        1002  81%
   - gnus-group-select-group                                      995  80%
    - gnus-group-read-group                                       995  80%
     - gnus-summary-read-group                                    995  80%
      - gnus-summary-read-group-1                                 995  80%
       - gnus-summary-prepare                                     869  70%
        - gnus-sort-threads                                       799  64%
         - byte-code                                              799  64%
          - gnus-sort-threads-recursive                           799  64%
           - sort                                                 797  64%
            - #<compiled 0xdc607d>                                797  64%
             - gnus-thread-sort-by-most-recent-date                797  64%
              - gnus-thread-latest-date                           797  64%
               - mapcar                                           795  64%
                - #<compiled 0x9dc9e9>                            791  64%
                 - safe-date-to-time                              789  63%
                  - date-to-time                                  789  63%
                   - byte-code                                    789  63%
                    - parse-time-string                           786  63%
                     - let                                        786  63%
                      - parse-time-tokenize                       762  61%
                       - let                                      762  61%
                        - while                                   762  61%
                         - while                                  754  61%
                          - and                                   750  60%
                           - setq                                 469  38%
                            - parse-time-string-chars                467  37%
                             - save-match-data                    450  36%
                              - let                               444  35%
                               - unwind-protect                   440  35%
                                - progn                           436  35%
                                 - let                             29   2%
                                  - cond                           25   2%
                                   - string-match                   6   0%
                                      setq                          5   0%
                           - not                                  272  22%
                            - setq                                272  22%
                             - parse-time-string-chars                269  21%
                              - save-match-data                   265  21%
                               - let                              261  21%
                                - unwind-protect                  261  21%
                                 - progn                          260  21%
                                  - let                            13   1%
                                   - cond                          12   0%
                                    - string-match                  4   0%
                                       setq                         4   0%
                           - <                                      2   0%
                              setq                                  2   0%
                            setq                                    2   0%
                         - if                                       6   0%
                          - setq                                    5   0%
                           - cons                                   5   0%
                            - if                                    4   0%
                             - parse-integer                        3   0%
                              - let                                 3   0%
                               - if                                 3   0%
                                - progn                             3   0%
                                 - let                              3   0%
                                  - while                           2   0%
                                   - and                            1   0%
                                    - setq                          1   0%
                                       digit-char-p                  1   0%
                                    if                              1   0%
                      - while                                      24   1%
                       - let                                       24   1%
                        - while                                    24   1%
                         - let*                                    23   1%
                          - if                                     18   1%
                           - progn                                 14   1%
                            - while                                14   1%
                             - let                                 14   1%
                              - if                                 12   0%
                               - let                               12   0%
                                - if                               12   0%
                                 - parse-integer                    9   0%
                                  - let                             8   0%
                                   - if                             8   0%
                                    - progn                         7   0%
                                     - let                          7   0%
                                      - if                          3   0%
                                         or                         2   0%
                                      - while                       2   0%
                                         setq                       1   0%
                                       - and                        1   0%
                                          setq                      1   0%
                                   funcall                          2   0%
                              - rplaca                              1   0%
                                 nthcdr                             1   0%
                           - and                                    3   0%
                            - not                                   2   0%
                               nth                                  1   0%
                              setq                                  1   0%
                          - car-safe                                3   0%
                           - prog1                                  2   0%
                              setq                                  2   0%
                      apply                                         3   0%
        - gnus-summary-prepare-threads                             64   5%
         - eval                                                    59   4%
          - let                                                    59   4%
           - gnus-add-text-properties                              52   4%
            - progn                                                51   4%
             - insert                                              49   3%
              - format                                             48   3%
               - let*                                              29   2%
                - eval                                             28   2%
                 - let                                             28   2%
                  - eval                                           25   2%
                   - gnus-summary-from-or-to-or-newsgroups                 24   1%
                    - mail-decode-encoded-address-string                 16   1%
                     - rfc2047-decode-string                       11   0%
                      - rfc2047-decode-encoded-words                  3   0%
                       - byte-code                                  2   0%
                          quoted-printable-decode-string                  2   0%
                         rfc2047-charset-to-coding-system                  1   0%
                        generate-new-buffer                         3   0%
                      - rfc2047-strip-backslashes-in-quoted-strings                  2   0%
                         byte-code                                  1   0%
                        byte-code                                   1   0%
                      gnus-extract-address-components                  6   0%
                      bidi-string-mark-left-to-right                  1   0%
                  - if                                              3   0%
                   - if                                             2   0%
                    - gnus-lrm-string-p                             1   0%
                       memq                                         1   0%
                     >                                              1   0%
                  -                                                 1   0%
               - gnus-user-date                                    14   1%
                - byte-code                                        14   1%
                 - eval                                             8   0%
                    gnus-seconds-year                               6   0%
                    gnus-seconds-today                              2   0%
                 gnus-summary-line-message-size                     3   0%
           gnus-summary-highlight-line                              2   0%
        - gnus-gather-threads-by-references                         4   0%
         - mail-header-remove-comments                              4   0%
            generate-new-buffer                                     2   0%
            ietf-drums-unfold-fws                                   1   0%
       - gnus-select-newsgroup                                    121   9%
        - gnus-fetch-headers                                      119   9%
         - gnus-get-newsgroup-headers-xover                       117   9%
          - byte-code                                             112   9%
           - byte-code                                             93   7%
            - mail-decode-encoded-address-string                   60   4%
             - rfc2047-decode-string                               42   3%
              - rfc2047-decode-encoded-words                       26   2%
               - byte-code                                         22   1%
                - quoted-printable-decode-string                   20   1%
                   mm-disable-multibyte                             4   0%
                   byte-code                                        2   0%
                   generate-new-buffer                              2   0%
                   quoted-printable-decode-region                   1   0%
               - rfc2047-charset-to-coding-system                   2   0%
                  mm-charset-to-coding-system                       1   0%
              - byte-code                                           5   0%
               - kill-buffer                                        3   0%
                  replace-buffer-in-windows                         1   0%
                generate-new-buffer                                 4   0%
                rfc2047-strip-backslashes-in-quoted-strings                  3   0%
            - mail-decode-encoded-word-string                      17   1%
             - rfc2047-decode-encoded-words                        13   1%
              - byte-code                                          12   0%
               - quoted-printable-decode-string                    11   0%
                  mm-disable-multibyte                              5   0%
                  generate-new-buffer                               1   0%
                - byte-code                                         1   0%
                 - kill-buffer                                      1   0%
                  - replace-buffer-in-windows                       1   0%
                     unrecord-window-buffer                         1   0%
                - quoted-printable-decode-region                    1   0%
                   mm-coding-system-p                               1   0%
                rfc2047-charset-to-coding-system                    1   0%
               byte-code                                            1   0%
           - mail-header-remove-comments                            6   0%
              generate-new-buffer                                   3   0%
              byte-code                                             2   0%
              ietf-drums-unfold-fws                                 1   0%
         - gnus-retrieve-headers                                    2   0%
          - gnus-cache-retrieve-headers                             2   0%
           - gnus-retrieve-headers                                  2   0%
            - nnml-retrieve-headers                                 2   0%
             - nnml-retrieve-headers-with-nov                       2   0%
              - nnheader-insert-file-contents                       1   0%
                 mm-insert-file-contents                            1   0%
                nnheader-nov-delete-outside-range                   1   0%
          gnus-articles-to-read                                     1   0%
          mapcar                                                    1   0%
         gnus-group-decoded-name                                    1   0%
       - gnus-summary-setup-buffer                                  1   0%
        - gnus-summary-mode                                         1   0%
         - gnus-update-summary-mark-positions                       1   0%
          - gnus-summary-insert-line                                1   0%
           - byte-code                                              1   0%
            - eval                                                  1   0%
             - let                                                  1   0%
              - gnus-add-text-properties                            1   0%
               - progn                                              1   0%
                - insert                                            1   0%
                 - format                                           1   0%
                  - let*                                            1   0%
                   - eval                                           1   0%
                    - let                                           1   0%
                       eval                                         1   0%
         gnus-set-global-variables                                  1   0%
       - gnus-summary-initial-limit                                 1   0%
        - mapatoms                                                  1   0%
           #<compiled 0x9e52a5>                                     1   0%
       - gnus-set-mode-line                                         1   0%
        - gnus-group-decoded-name                                   1   0%
           gnus-group-name-charset                                  1   0%
   - execute-extended-command                                       7   0%
    - command-execute                                               6   0%
     - call-interactively                                           6   0%
      - funcall-interactively                                       6   0%
       - profiler-report                                            6   0%
        - profiler-report-cpu                                       6   0%
           profiler-cpu-profile                                     6   0%
  - byte-code                                                      45   3%
   - read-extended-command                                         45   3%
    - completing-read                                              45   3%
     - completing-read-default                                     45   3%
        read-from-minibuffer                                       27   2%
+ ...                                                             186  15%
  redisplay_internal (C function)                                   1   0%

^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2014-10-01 20:25               ` Peter Münster
@ 2015-02-13  8:26                 ` Lars Ingebrigtsen
  2015-02-13 14:39                   ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Lars Ingebrigtsen @ 2015-02-13  8:26 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

Peter Münster <pmlists@free.fr> writes:

> Thanks. But it does not explain, why it's much faster after restarting
> emacs. Please find attached 2 recent profiler reports for comparison.

It's kinda puzzling.

Could you `M-x debug-on-entry RET gnus-sort-threads RET' and then save
the value of the `threads' variable when this is slow and when this is
fast.

And then either compare the values to see whether they're really the
same, or post them here for inspection...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2015-02-13  8:26                 ` Lars Ingebrigtsen
@ 2015-02-13 14:39                   ` Peter Münster
  2015-02-14  4:19                     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2015-02-13 14:39 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 18522

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On Fri, Feb 13 2015, Lars Ingebrigtsen wrote:

> Could you `M-x debug-on-entry RET gnus-sort-threads RET' and then save
> the value of the `threads' variable when this is slow and when this is
> fast.
>
> And then either compare the values to see whether they're really the
> same, or post them here for inspection...

Hi Lars,

They are the same. Please find attached an example.

-- 
           Peter

[-- Attachment #2: gnus-sort-threads-debug.txt --]
[-- Type: text/plain, Size: 81796 bytes --]

Debugger entered--entering a function:
* gnus-sort-threads((([85605 "Re: gnus-dired-attach: default mime-type application/octet-stream, why" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 15:11:41 +1100" "<87386vzgqq.fsf@building.gnus.org>" "<87mwc37mh7.fsf@mat.ucm.es>" 3794 28 "news.gmane.org gmane.emacs.gnus.general:85605" nil]) ([85303 "Re: Snoozing a message in gnus?" "Ted Zlatanov <tzz@lifelogs.com>" "Mon, 08 Dec 2014 11:59:00 -0500" "<m2tx16qdrf.fsf@lifelogs.com>" "<m21tpfs8nu.fsf@krugs.de> <8761erw9fv.fsf@thinkpad-t440p.tsdh.org> <87bnojja3i.fsf@gmail.com> <87fvdrf9n2.fsf@lifelogs.com> <87zjbzdulx.fsf@topper.koldfront.dk> <m2mw7zyusw.fsf@krugs.de> <87mw7x6xn6.fsf@uwo.ca>" 4829 11 "news.gmane.org gmane.emacs.gnus.general:85303" nil]) ([85280 "[PATCH] Accept new TLDs when validating FQDNs" "Albert Krewinkel <albert
 +gnus@zeitkraut.de>" "Sat, 15 Nov 2014 11:53:15 +0100" "<1416048795-30803-1-git-send-email-albert+gnus@zeitkraut.de>" "" 5994 65 "news.gmane.org gmane.emacs.gnus.general:85280" nil] ([85285 "Re: [PA
 TCH] Accept new TLDs when validating FQDNs" "Julien Danjou <julien@danjou.info>" "Mon, 17 Nov 2014 09:36:36 +0100" "<m2oas6p6jv.fsf@danjou.info>" "<1416048795-30803-1-git-send-email-albert+gnus@zeitkraut.de>" 4231 42 "news.gmane.org gmane.emacs.gnus.general:85285" nil] ([85517 "Re: [PATCH] Accept new TLDs when validating FQDNs" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:16:13 +1100" "<877fwajhwy.fsf@building.gnus.org>" "<1416048795-30803-1-git-send-email-albert+gnus@zeitkraut.de> <m2oas6p6jv.fsf@danjou.info>" 3565 21 "news.gmane.org gmane.emacs.gnus.general:85517" nil]))) ([85287 "access mail spool on another server?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 18 Nov 2014 11:24:13 +0800" "<87lhn9ur6q.fsf@ericabrahamsen.net>" "" 4555 15 "news.gmane.org gmane.emacs.gnu
 s.general:85287" nil] ([85302 "Re: access mail spool on another server?" "Ted Zlatanov <tzz@lifelogs.com>" "Mon, 08 Dec 2014 11:54:24 -0500" "<m21toarsjj.fsf@lifelogs.com>" "<87lhn9ur6q.fsf@ericabra
 hamsen.net>" 5051 18 "news.gmane.org gmane.emacs.gnus.general:85302" nil] ([85314 "Re: access mail spool on another server?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 09 Dec 2014 10:30:02 +0800" "<87tx15a72t.fsf@ericabrahamsen.net>" "<87lhn9ur6q.fsf@ericabrahamsen.net> <m21toarsjj.fsf@lifelogs.com>" 5005 24 "news.gmane.org gmane.emacs.gnus.general:85314" nil]))) ([85288 "autoloads only generated on every 2nd make" "Tassilo Horn <tsdh@gnu.org>" "Thu, 20 Nov 2014 08:20:16 +0100" "<87wq6qfidr.fsf@thinkpad-t440p.tsdh.org>" "" 4487 50 "news.gmane.org gmane.emacs.gnus.general:85288" nil] ([85516 "Re: autoloads only generated on every 2nd make" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:13:28 +1100" "<87bnlmji1j.fsf@building.gnus.org>" "<87wq6qfidr.fsf@thinkpad-t440p.tsdh.
 org>" 3545 23 "news.gmane.org gmane.emacs.gnus.general:85516" nil] ([85528 "Re: autoloads only generated on every 2nd make" "Tassilo Horn <tsdh@gnu.org>" "Mon, 26 Jan 2015 08:15:56 +0100" "<87twze2e
 s3.fsf@gnu.org>" "<87wq6qfidr.fsf@thinkpad-t440p.tsdh.org> <87bnlmji1j.fsf@building.gnus.org>" 4773 52 "news.gmane.org gmane.emacs.gnus.general:85528" nil] ([85534 "Re: autoloads only generated on every 2nd make" "Tassilo Horn <tsdh@gnu.org>" "Mon, 26 Jan 2015 16:14:10 +0100" "<87oapl1sn1.fsf@gnu.org>" "<87wq6qfidr.fsf@thinkpad-t440p.tsdh.org> <87bnlmji1j.fsf@building.gnus.org> <87twze2es3.fsf@gnu.org>" 3429 21 "news.gmane.org gmane.emacs.gnus.general:85534" nil])))) ([85289 "Prevent mails from being expired" "Stefan Nobis <stefan-ml@snobis.de>" "Sun, 23 Nov 2014 09:06:02 +0100" "<m1r3wuuys5.fsf@nobis-it.eu>" "" 4580 31 "news.gmane.org gmane.emacs.gnus.general:85289" nil] ([85515 "Re: Prevent mails from being expired" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:11:34 +1100" 
 "<87fvayji4p.fsf@building.gnus.org>" "<m1r3wuuys5.fsf@nobis-it.eu>" 4036 33 "news.gmane.org gmane.emacs.gnus.general:85515" nil])) ([85290 "Some imap accounts not updating in 24.4" "Alberto Luaces <
 aluaces@udc.es>" "Tue, 25 Nov 2014 23:55:26 +0100" "<87bnnuao0x.fsf@eps142.cdf.udc.es>" "" 4169 45 "news.gmane.org gmane.emacs.gnus.general:85290" nil] ([85301 "Re: Some imap accounts not updating in 24.4" "Ted Zlatanov <tzz@lifelogs.com>" "Mon, 08 Dec 2014 11:53:27 -0500" "<m261dmrsl4.fsf@lifelogs.com>" "<87bnnuao0x.fsf@eps142.cdf.udc.es>" 4899 15 "news.gmane.org gmane.emacs.gnus.general:85301" nil] ([85365 "Re: Some imap accounts not updating in 24.4" "Alberto Luaces <aluaces@udc.es>" "Thu, 18 Dec 2014 21:24:12 +0100" "<87r3vw4sgj.fsf@eps142.cdf.udc.es>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com>" 3683 21 "news.gmane.org gmane.emacs.gnus.general:85365" nil] ([85375 "Re: Some imap accounts not updating in 24.4" "Ted Zlatanov <tzz@lifelogs.com>" "Fri, 19 Dec 2014 22
 :07:25 -0500" "<87bnmzt3wy.fsf@lifelogs.com>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com> <87r3vw4sgj.fsf@eps142.cdf.udc.es>" 4433 30 "news.gmane.org gmane.emacs.gnus.general:8
 5375" nil] ([85396 "Re: Some imap accounts not updating in 24.4" "Alberto Luaces <aluaces@udc.es>" "Mon, 22 Dec 2014 20:48:37 +0100" "<87y4pza2ju.fsf@eps142.cdf.udc.es>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com> <87r3vw4sgj.fsf@eps142.cdf.udc.es> <87bnmzt3wy.fsf@lifelogs.com>" 4910 58 "news.gmane.org gmane.emacs.gnus.general:85396" nil] ([85714 "Re: Some imap accounts not updating in 24.4" "Ted Zlatanov <tzz@lifelogs.com>" "Wed, 04 Feb 2015 06:48:27 -0500" "<87sielyk1g.fsf@lifelogs.com>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com> <87r3vw4sgj.fsf@eps142.cdf.udc.es> <87bnmzt3wy.fsf@lifelogs.com> <87y4pza2ju.fsf@eps142.cdf.udc.es>" 4273 28 "news.gmane.org gmane.emacs.gnus.general:85714" nil]) ([85731 "Re: Some imap accounts not updating in 24.4"
  "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:14:49 +1100" "<87wq3xuk0m.fsf@building.gnus.org>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com> <87r3vw4sgj.fsf@eps142.
 cdf.udc.es> <87bnmzt3wy.fsf@lifelogs.com> <87y4pza2ju.fsf@eps142.cdf.udc.es>" 3274 12 "news.gmane.org gmane.emacs.gnus.general:85731" nil])))))) ([85291 "gmane is always closed." "Uwe Brauer <oub@mat.ucm.es>" "Wed, 26 Nov 2014 12:34:10 +0100" "<87bnnu42ml.fsf@mat.ucm.es>" "" 11916 154 "news.gmane.org gmane.emacs.gnus.general:85291" nil] ([85292 "Re: gmane is always closed." "Alberto Luaces <aluaces@udc.es>" "Wed, 26 Nov 2014 16:43:22 +0100" "<8761e29dd1.fsf@eps142.cdf.udc.es>" "<87bnnu42ml.fsf@mat.ucm.es>" 3212 14 "news.gmane.org gmane.emacs.gnus.general:85292" nil] ([85293 "Re: gmane is always closed." "Uwe Brauer <oub@mat.ucm.es>" "Wed, 26 Nov 2014 19:19:11 +0100" "<87ioi1akps.fsf@mat.ucm.es>" "<87bnnu42ml.fsf@mat.ucm.es> <8761e29dd1.fsf@eps142.cdf.udc.es>" 5387 53 "news.gmane.org gmane
 .emacs.gnus.general:85293" nil] ([85294 "Re: gmane is always closed." "Alberto Luaces <aluaces@udc.es>" "Thu, 27 Nov 2014 18:33:37 +0100" "<87zjbc8s5q.fsf@eps142.cdf.udc.es>" "<87bnnu42ml.fsf@mat.uc
 m.es> <8761e29dd1.fsf@eps142.cdf.udc.es> <87ioi1akps.fsf@mat.ucm.es>" 3645 27 "news.gmane.org gmane.emacs.gnus.general:85294" nil] ([85295 "Re: gmane is always closed." "Uwe Brauer <oub@mat.ucm.es>" "Thu, 27 Nov 2014 19:03:19 +0100" "<87zjbcttaw.fsf@mat.ucm.es>" "<87bnnu42ml.fsf@mat.ucm.es> <8761e29dd1.fsf@eps142.cdf.udc.es> <87ioi1akps.fsf@mat.ucm.es> <87zjbc8s5q.fsf@eps142.cdf.udc.es>" 3463 12 "news.gmane.org gmane.emacs.gnus.general:85295" nil]))))) ([85296 "with local imap: sent mail (Gcc) sometimes not saved" "Christoph Groth <christoph@grothesque.org>" "Fri, 28 Nov 2014 00:41:08 +0100" "<87d2888b57.fsf@grothesque.org>" "" 5399 58 "news.gmane.org gmane.emacs.gnus.general:85296" nil] ([85297 "Couldn't store article in group" "Christoph Groth <christoph@grothesque.org>" "Fri, 28 Nov 20
 14 12:44:13 +0100" "<874mtjh7n6.fsf@grothesque.org>" "<87d2888b57.fsf@grothesque.org>" 4630 45 "news.gmane.org gmane.emacs.gnus.general:85297" nil] ([85514 "Re: Couldn't store article in group" "Lar
 s Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:07:42 +1100" "<87lhkqjib5.fsf@building.gnus.org>" "<87d2888b57.fsf@grothesque.org> <874mtjh7n6.fsf@grothesque.org>" 3737 24 "news.gmane.org gmane.emacs.gnus.general:85514" nil] ([85537 "Re: Couldn't store article in group" "Christoph Groth <christoph@grothesque.org>" "Mon, 26 Jan 2015 23:13:18 +0100" "<878ugpp4w1.fsf@grothesque.org>" "<87d2888b57.fsf@grothesque.org> <874mtjh7n6.fsf@grothesque.org> <87lhkqjib5.fsf@building.gnus.org>" 4741 70 "news.gmane.org gmane.emacs.gnus.general:85537" nil] ([85538 "Re: Couldn't store article in group" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 11:50:59 +1100" "<87twzddp1o.fsf@building.gnus.org>" "<87d2888b57.fsf@grothesque.org> <874mtjh7n6.fsf@grothesque.org> <87lhkqjib5.fsf@building.gnu
 s.org> <878ugpp4w1.fsf@grothesque.org>" 3942 31 "news.gmane.org gmane.emacs.gnus.general:85538" nil] ([85628 "Re: Couldn't store article in group" "Alan Schmitt <alan.schmitt@polytechnique.org>" "We
 d, 28 Jan 2015 13:56:05 +0100" "<m2lhknnjx6.fsf@polytechnique.org>" "<87d2888b57.fsf@grothesque.org> <874mtjh7n6.fsf@grothesque.org> <87lhkqjib5.fsf@building.gnus.org> <878ugpp4w1.fsf@grothesque.org> <87twzddp1o.fsf@building.gnus.org>" 4577 47 "news.gmane.org gmane.emacs.gnus.general:85628" nil] ([85641 "Re: Couldn't store article in group" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 12:37:19 +1100" "<87r3uenz8w.fsf@building.gnus.org>" "<87d2888b57.fsf@grothesque.org> <874mtjh7n6.fsf@grothesque.org> <87lhkqjib5.fsf@building.gnus.org> <878ugpp4w1.fsf@grothesque.org> <87twzddp1o.fsf@building.gnus.org> <m2lhknnjx6.fsf@polytechnique.org>" 3447 14 "news.gmane.org gmane.emacs.gnus.general:85641" nil]))))))) ([85299 "virtual groups based on subjects" "Uwe Brauer <oub@mat.ucm.es>" "Mon
 , 08 Dec 2014 10:39:16 +0100" "<87k322zdiz.fsf@mat.ucm.es>" "" 11243 126 "news.gmane.org gmane.emacs.gnus.general:85299" nil] ([85307 "Re: virtual groups based on subjects" "Glyn Millington <glyn.mi
 llington@gmail.com>" "Mon, 08 Dec 2014 20:57:09 +0000" "<87k321j1wa.fsf@nowhere.org>" "<87k322zdiz.fsf@mat.ucm.es>" 3703 22 "news.gmane.org gmane.emacs.gnus.general:85307" nil] ([85319 "Re: virtual groups based on subjects" "Uwe Brauer <oub@mat.ucm.es>" "Tue, 09 Dec 2014 13:43:04 +0100" "<8761dl6lk7.fsf@mat.ucm.es>" "<87k322zdiz.fsf@mat.ucm.es> <87k321j1wa.fsf@nowhere.org>" 3645 24 "news.gmane.org gmane.emacs.gnus.general:85319" nil] ([85323 "Re: virtual groups based on subjects" "Glyn Millington <glyn.millington@gmail.com>" "Tue, 09 Dec 2014 14:34:59 +0000" "<87zjaw99ik.fsf@nowhere.org>" "<87k322zdiz.fsf@mat.ucm.es> <87k321j1wa.fsf@nowhere.org> <8761dl6lk7.fsf@mat.ucm.es>" 4694 47 "news.gmane.org gmane.emacs.gnus.general:85323" nil])))) ([85300 "Mutt/Gnus hybrid for mail?" "Peter Davis <
 pfd@pfdstudio.com>" "Mon, 08 Dec 2014 08:20:05 -0500" "<m2sigqcm7u.fsf@PFDStudio-Air.home>" "" 3681 21 "news.gmane.org gmane.emacs.gnus.general:85300" nil] ([85305 "Re: Mutt/Gnus hybrid for mail?" "
 Peter Münster <pmlists@free.fr>" "Mon, 08 Dec 2014 21:06:41 +0100" "<87egs952jy.fsf@micropit.roche-blanche.homenet.org>" "<m2sigqcm7u.fsf@PFDStudio-Air.home>" 3222 13 "news.gmane.org gmane.emacs.gnus.general:85305" nil] ([85308 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Mon, 08 Dec 2014 17:47:00 -0500" "<m2oarddajf.fsf@PFDStudio-Air.home>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org>" 4627 34 "news.gmane.org gmane.emacs.gnus.general:85308" nil] ([85309 "Re: Mutt/Gnus hybrid for mail?" "Peter Münster <pmlists@free.fr>" "Tue, 09 Dec 2014 00:25:59 +0100" "<87r3w93erc.fsf@micropit.roche-blanche.homenet.org>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-A
 ir.home>" 5008 55 "news.gmane.org gmane.emacs.gnus.general:85309" nil] ([85310 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Mon, 08 Dec 2014 19:15:17 -0500" "<m2h9x5d6ga.fsf@P
 FDStudio-Air.home>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <87r3w93erc.fsf@micropit.roche-blanche.homenet.org>" 6061 70 "news.gmane.org gmane.emacs.gnus.general:85310" nil]) ([85313 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Mon, 08 Dec 2014 19:51:06 -0500" "<m28uihd4sl.fsf@PFDStudio-Air.home>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <87r3w93erc.fsf@micropit.roche-blanche.homenet.org>" 4105 24 "news.gmane.org gmane.emacs.gnus.general:85313" nil] ([85317 "Re: Mutt/Gnus hybrid for mail?" "Peter Münster <pmlists@free.fr>" "Tue, 09 Dec 2014 09:00:13 +0100" "<87fvcp2qya.fsf@micropit.roche-blanche.hom
 enet.org>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <87r3w93erc.fsf@micropit.roche-blanche.homenet.org> <m28uihd4s
 l.fsf@PFDStudio-Air.home>" 3976 25 "news.gmane.org gmane.emacs.gnus.general:85317" nil]))) ([85311 "Re: Mutt/Gnus hybrid for mail?" "jorge.alfaro-murillo@yale.edu (Jorge A. Alfaro-Murillo)" "Mon, 08 Dec 2014 19:20:29 -0500" "<87bnndsmgi.fsf@yale.edu>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home>" 5197 63 "news.gmane.org gmane.emacs.gnus.general:85311" nil] ([85312 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Mon, 08 Dec 2014 19:47:14 -0500" "<m2d27td4z1.fsf@PFDStudio-Air.home>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <87bnndsmgi.fsf@yale.edu>" 5535 69 "news.gmane.org gmane.emacs.gnus.general:85312" nil])
 ) ([85315 "Re: Mutt/Gnus hybrid for mail?" "Charles Philip Chan <cpchan@bell.net>" "Mon, 08 Dec 2014 22:57:42 -0500" "<87lhmhlbk9.fsf@karnak.MagnumOpus.khem>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <8
 7egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home>" 4670 47 "news.gmane.org gmane.emacs.gnus.general:85315" nil] ([85316 "Re: Mutt/Gnus hybrid for mail?" "Charles Philip Chan <cpchan@bell.net>" "Mon, 08 Dec 2014 23:04:41 -0500" "<87h9x5lb8m.fsf@karnak.MagnumOpus.khem>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <87lhmhlbk9.fsf@karnak.MagnumOpus.khem>" 4264 35 "news.gmane.org gmane.emacs.gnus.general:85316" nil])) ([85318 "Re: Mutt/Gnus hybrid for mail?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 9 Dec 2014 10:46:34 +0000" "<8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudi
 o-Air.home>" 5978 56 "news.gmane.org gmane.emacs.gnus.general:85318" nil] ([85320 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Tue, 09 Dec 2014 07:49:21 -0500" "<m24mt5c7ji.fs
 f@PFDStudio-Air.home>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk>" 5152 44 "news.gmane.org gmane.emacs.gnus.general:85320" nil] ([85321 "Re: Mutt/Gnus hybrid for mail?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 9 Dec 2014 14:10:08 +0000" "<87ppbsgbi7.fsf@ucl.ac.uk>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home>" 6403 69 "news.gmane.org gmane.emacs.gnus.general:85321" nil] ([85322 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Tue, 09 Dec 2014 09:34:10 -0500" "<m2zjawc2ot.fsf@PFDStudio-Air.home>"
  "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.h
 ome> <87ppbsgbi7.fsf@ucl.ac.uk>" 9179 158 "news.gmane.org gmane.emacs.gnus.general:85322" nil] ... ...))))))) ([85304 "merging monthly post-out directories." "Sharon Kimble <boudiccas@skimble.plus.com>" "Mon, 08 Dec 2014 18:47:26 +0000" "<8761dmasht.fsf@skimble.plus.com>" "" 4441 41 "news.gmane.org gmane.emacs.gnus.general:85304" nil] ([85306 "Re: merging monthly post-out directories." "Xavier Maillard <xavier@maillard.im>" "Mon, 08 Dec 2014 21:56:59 +0100" "<m0d27t7td0.fsf@kcals.intra.maillard.im>" "<8761dmasht.fsf@skimble.plus.com>" 4035 17 "news.gmane.org gmane.emacs.gnus.general:85306" nil]) ([85327 "Re: merging monthly post-out directories." "asjo@koldfront.dk (Adam Sjøgren)" "Tue, 09 Dec 2014 19:39:54 +0100" "<87vblkacqt.fsf@koldfront.dk>" "<8761dmasht.fsf@skimble.plus.com>" 3771 2
 5 "news.gmane.org gmane.emacs.gnus.general:85327" nil] ([85332 "Re: merging monthly post-out directories." "Xavier Maillard <xavier@maillard.im>" "Tue, 09 Dec 2014 22:30:29 +0100" "<m0zjaw5x56.fsf@k
 cals.intra.maillard.im>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk>" 4223 20 "news.gmane.org gmane.emacs.gnus.general:85332" nil]) ([85338 "Re: merging monthly post-out directories." "Sharon Kimble <boudiccas@skimble.plus.com>" "Wed, 10 Dec 2014 02:36:35 +0000" "<87388o2pp0.fsf@skimble.plus.com>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk>" 5046 49 "news.gmane.org gmane.emacs.gnus.general:85338" nil] ([85339 "Re: merging monthly post-out directories." "asjo@koldfront.dk (Adam Sjøgren)" "Wed, 10 Dec 2014 11:25:10 +0100" "<87vblj94zd.fsf@topper.koldfront.dk>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com>" 4189 26 "news.gmane.org gmane.emacs.gnus.general:85339" nil] ([85340 "Re: merging monthly p
 ost-out directories." "Sharon Kimble <boudiccas@skimble.plus.com>" "Wed, 10 Dec 2014 14:20:42 +0000" "<87ppbrwpqd.fsf@skimble.plus.com>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.
 dk> <87388o2pp0.fsf@skimble.plus.com> <87vblj94zd.fsf@topper.koldfront.dk>" 5276 58 "news.gmane.org gmane.emacs.gnus.general:85340" nil] ([85341 "Re: merging monthly post-out directories." "asjo@koldfront.dk (Adam Sjøgren)" "Wed, 10 Dec 2014 15:32:55 +0100" "<87ppbr8tig.fsf@topper.koldfront.dk>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com> <87vblj94zd.fsf@topper.koldfront.dk> <87ppbrwpqd.fsf@skimble.plus.com>" 4505 36 "news.gmane.org gmane.emacs.gnus.general:85341" nil] ([85342 "Re: merging monthly post-out directories." "Sharon Kimble <boudiccas@skimble.plus.com>" "Thu, 11 Dec 2014 02:53:03 +0000" "<87d27qq4mo.fsf@skimble.plus.com>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com> <87
 vblj94zd.fsf@topper.koldfront.dk> <87ppbrwpqd.fsf@skimble.plus.com> <87ppbr8tig.fsf@topper.koldfront.dk>" 5773 74 "news.gmane.org gmane.emacs.gnus.general:85342" nil] ... ...))) ([85428 "Re: merging
  monthly post-out directories." "Sharon Kimble <boudiccas@skimble.plus.com>" "Sun, 04 Jan 2015 18:04:25 +0000" "<87d26u5snq.fsf@skimble.plus.com>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com> <87vblj94zd.fsf@topper.koldfront.dk>" 5435 37 "news.gmane.org gmane.emacs.gnus.general:85428" nil]))))) ([85344 "restore the setup file?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Thu, 11 Dec 2014 17:55:16 +0000" "<87r3w6vzp7.fsf@skimble.plus.com>" "" 5645 42 "news.gmane.org gmane.emacs.gnus.general:85344" nil] ([85345 "Re: restore the setup file?" "jorge.alfaro-murillo@yale.edu (Jorge A. Alfaro-Murillo)" "Thu, 11 Dec 2014 13:08:07 -0500" "<87oaraoy9k.fsf@yale.edu>" "<87r3w6vzp7.fsf@skimble.plus.com>" 3529 18 "news.gmane.org gmane.emacs.gnus.g
 eneral:85345" nil] ([85346 "Re: restore the setup file?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Thu, 11 Dec 2014 19:05:11 +0000" "<87fvcmuhw8.fsf@skimble.plus.com>" "<87r3w6vzp7.fsf@skimble.p
 lus.com> <87oaraoy9k.fsf@yale.edu>" 6259 53 "news.gmane.org gmane.emacs.gnus.general:85346" nil]))) ([85347 "A little coaching on massive downloading or messages" "Harry Putnam <reader@newsguy.com>" "Thu, 11 Dec 2014 14:10:43 -0500" "<87fvcmovd8.fsf@reader.local.lan>" "" 3407 14 "news.gmane.org gmane.emacs.gnus.general:85347" nil]) ([85348 "shr.el: add linebreaks to mouse-over tooltips (title attributes)" "asjo@koldfront.dk (Adam Sjøgren)" "Fri, 12 Dec 2014 22:29:21 +0100" "<877fxwr1zi.fsf@topper.koldfront.dk>" "" 5604 38 "news.gmane.org gmane.emacs.devel:179964 gmane.emacs.gnus.general:85348" nil] ([85357 "Re: shr.el: add linebreaks to mouse-over tooltips (title attributes)" "Lars Magne Ingebrigtsen <larsi@gnus.org>" "Sat, 13 Dec 2014 16:24:31 +0100" "<m3zjar1sk0.fsf@stories.gnus.org>" 
 "<877fxwr1zi.fsf@topper.koldfront.dk>" 5762 23 "news.gmane.org gmane.emacs.devel:180011 gmane.emacs.gnus.general:85357" nil])) ([85353 "Does nnir support nnrss?" "Frank <kulugox@gmail.com>" "Sat, 13
  Dec 2014 10:30:48 +0800" "<87vblguvqf.fsf@gmail.com>" "" 3497 20 "news.gmane.org gmane.emacs.gnus.general:85353" nil] ([85513 "Re: Does nnir support nnrss?" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:41:08 +1100" "<87ppa2jjjf.fsf@building.gnus.org>" "<87vblguvqf.fsf@gmail.com>" 3027 12 "news.gmane.org gmane.emacs.gnus.general:85513" nil])) ([85363 "anything newer than emacs-w3m for rendering html" "Harry Putnam <reader@newsguy.com>" "Thu, 18 Dec 2014 16:22:56 -0500" "<87k31or6tr.fsf@reader.local.lan>" "" 4316 14 "news.gmane.org gmane.emacs.gnus.general:85363" nil] ([85364 "Re: anything newer than emacs-w3m for rendering html" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 18 Dec 2014 19:31:17 +0100" "<87sigchksq.fsf@topper.koldfront.dk>" "<87k31or6tr.fsf@reader.local.lan>" 4625
  43 "news.gmane.org gmane.emacs.gnus.general:85364" nil] ([85371 "Re: anything newer than emacs-w3m for rendering html" "Malcolm Purvis <malcolm@purvis.id.au>" "Fri, 19 Dec 2014 14:10:22 +1100" "<m1
 k31opc69.fsf@mpurvis.dyn.syd.atlassian.com>" "<87k31or6tr.fsf@reader.local.lan> <87sigchksq.fsf@topper.koldfront.dk>" 3589 15 "news.gmane.org gmane.emacs.gnus.general:85371" nil] ([85372 "Re: anything newer than emacs-w3m for rendering html" "Harry Putnam <reader@newsguy.com>" "Fri, 19 Dec 2014 12:22:10 -0500" "<87388b5zct.fsf@reader.local.lan>" "<87k31or6tr.fsf@reader.local.lan> <87sigchksq.fsf@topper.koldfront.dk> <m1k31opc69.fsf@mpurvis.dyn.syd.atlassian.com>" 3564 15 "news.gmane.org gmane.emacs.gnus.general:85372" nil] ([85379 "Re: anything newer than emacs-w3m for rendering html" "Steinar Bang <sb@dod.no>" "Sat, 20 Dec 2014 10:06:13 +0100" "<878ui2k7wa.fsf@dod.no>" "<87k31or6tr.fsf@reader.local.lan> <87sigchksq.fsf@topper.koldfront.dk> <m1k31opc69.fsf@mpurvis.dyn.syd.atlassian.com> <
 87388b5zct.fsf@reader.local.lan>" 3429 9 "news.gmane.org gmane.emacs.gnus.general:85379" nil]) ([85390 "Re: anything newer than emacs-w3m for rendering html" "Malcolm Purvis <malcolmp@xemacs.org>" "
 Sun, 21 Dec 2014 22:28:47 +1100" "<m2r3vt2qds.fsf@xemacs.org>" "<87k31or6tr.fsf@reader.local.lan> <87sigchksq.fsf@topper.koldfront.dk> <m1k31opc69.fsf@mpurvis.dyn.syd.atlassian.com> <87388b5zct.fsf@reader.local.lan>" 4632 19 "news.gmane.org gmane.emacs.gnus.general:85390" nil])))) ([85366 "Re: anything newer than emacs-w3m for rendering html" "Filipp Gunbin <fgunbin@fastmail.fm>" "Fri, 19 Dec 2014 01:07:41 +0300" "<m2a92ksjbm.fsf@fastmail.fm>" "<87k31or6tr.fsf@reader.local.lan>" 4095 15 "news.gmane.org gmane.emacs.gnus.general:85366" nil] ([85367 "Re: anything newer than emacs-w3m for rendering html" "Harry Putnam <reader@newsguy.com>" "Thu, 18 Dec 2014 21:11:12 -0500" "<87h9wsmlrz.fsf@reader.local.lan>" "<87k31or6tr.fsf@reader.local.lan> <m2a92ksjbm.fsf@fastmail.fm>" 4771 20 "news.gmane.
 org gmane.emacs.gnus.general:85367" nil] ([85512 "Re: anything newer than emacs-w3m for rendering html" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:40:33 +1100" "<87twzejjke.fsf@buildi
 ng.gnus.org>" "<87k31or6tr.fsf@reader.local.lan> <m2a92ksjbm.fsf@fastmail.fm> <87h9wsmlrz.fsf@reader.local.lan>" 3304 14 "news.gmane.org gmane.emacs.gnus.general:85512" nil])))) ([85374 "movemail failing .. apparently permission issue" "Harry Putnam <reader@newsguy.com>" "Fri, 19 Dec 2014 19:36:05 -0500" "<87bnmzduoa.fsf@reader.local.lan>" "" 4308 39 "news.gmane.org gmane.emacs.gnus.general:85374" nil] ([85378 "Re: movemail failing .. apparently permission issue" "Andreas Schwab <schwab@linux-m68k.org>" "Sat, 20 Dec 2014 09:55:08 +0100" "<m2egruk8er.fsf@linux-m68k.org>" "<87bnmzduoa.fsf@reader.local.lan>" 4876 18 "news.gmane.org gmane.emacs.gnus.general:85378" nil] ([85381 "Re: movemail failing .. apparently permission issue" "Harry Putnam <reader@newsguy.com>" "Sat, 20 Dec 2014 07:59:33 
 -0500" "<87tx0qo4sq.fsf@reader.local.lan>" "<87bnmzduoa.fsf@reader.local.lan> <m2egruk8er.fsf@linux-m68k.org>" 3517 23 "news.gmane.org gmane.emacs.gnus.general:85381" nil])) ([85393 "Re: movemail fa
 iling .. apparently permission issue" "Harry Putnam <reader@newsguy.com>" "Sun, 21 Dec 2014 16:05:20 -0500" "<874msovhm7.fsf@reader.local.lan>" "<87bnmzduoa.fsf@reader.local.lan>" 5024 61 "news.gmane.org gmane.emacs.gnus.general:85393" nil])) ([85383 "Track down a failure involving shr" "Harry Putnam <reader@newsguy.com>" "Sat, 20 Dec 2014 16:16:50 -0500" "<87fvcaf2d9.fsf@reader.local.lan>" "" 5542 70 "news.gmane.org gmane.emacs.gnus.general:85383" nil] ([85384 "Re: Track down a failure involving shr" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 20 Dec 2014 22:57:43 +0100" "<87h9wqvvag.fsf@topper.koldfront.dk>" "<87fvcaf2d9.fsf@reader.local.lan>" 3937 19 "news.gmane.org gmane.emacs.gnus.general:85384" nil]) ([85385 "Re: Track down a failure involving shr" "Steinar Bang <sb@dod.no>" "Sat, 20 
 Dec 2014 23:45:24 +0100" "<86tx0qkkjf.fsf@dod.no>" "<87fvcaf2d9.fsf@reader.local.lan>" 3291 10 "news.gmane.org gmane.emacs.gnus.general:85385" nil] ([85386 "Re: Track down a failure involving shr" "
 Clemens Schüller <cs.mlists+gnus@mailbox.org>" "Sat, 20 Dec 2014 23:52:46 +0100" "<87oaqyc4sh.fsf@cougar.home.aneadesign.com>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no>" 4764 25 "news.gmane.org gmane.emacs.gnus.general:85386" nil] ([85388 "Re: Track down a failure involving shr" "Harry Putnam <reader@newsguy.com>" "Sat, 20 Dec 2014 18:19:55 -0500" "<873889gb8k.fsf@reader.local.lan>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no> <87oaqyc4sh.fsf@cougar.home.aneadesign.com>" 5424 67 "news.gmane.org gmane.emacs.gnus.general:85388" nil] ([85389 "Re: Track down a failure involving shr" "asjo@koldfront.dk (Adam Sjøgren)" "Sun, 21 Dec 2014 07:35:05 +0100" "<8761d5qzmu.fsf@topper.koldfront.dk>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no> <87oaqyc4sh.f
 sf@cougar.home.aneadesign.com> <873889gb8k.fsf@reader.local.lan>" 4133 23 "news.gmane.org gmane.emacs.gnus.general:85389" nil]) ([85391 "Re: Track down a failure involving shr" "Clemens Schüller <c
 s.mlists+gnus@mailbox.org>" "Sun, 21 Dec 2014 13:27:59 +0100" "<873889p4q8.fsf@cougar.home.aneadesign.com>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no> <87oaqyc4sh.fsf@cougar.home.aneadesign.com> <873889gb8k.fsf@reader.local.lan>" 6893 65 "news.gmane.org gmane.emacs.gnus.general:85391" nil] ([85392 "Re: Track down a failure involving shr" "Harry Putnam <reader@newsguy.com>" "Sun, 21 Dec 2014 06:51:50 -0500" "<877fxlxlt5.fsf@reader.local.lan>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no> <87oaqyc4sh.fsf@cougar.home.aneadesign.com> <873889gb8k.fsf@reader.local.lan> <873889p4q8.fsf@cougar.home.aneadesign.com>" 4303 30 "news.gmane.org gmane.emacs.gnus.general:85392" nil])))) ([85387 "Re: Track down a failure involving shr" "Harry Putnam <reader@newsguy.com>" "Sat,
  20 Dec 2014 17:54:18 -0500" "<877fxmexut.fsf@reader.local.lan>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no>" 4170 39 "news.gmane.org gmane.emacs.gnus.general:85387" nil]))) ([85394 "
 large number of References: breaks gnus when tramp is in use" "Wes Hardaker <wes@hardakers.net>" "Mon, 22 Dec 2014 06:35:42 -0800" "<0loaqvlpkx.fsf@wjh.hardakers.net>" "" 4236 24 "news.gmane.org gmane.emacs.gnus.general:85394" nil] ([85511 "Re: large number of References: breaks gnus when tramp is in use" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:31:17 +1100" "<87y4oqjjzu.fsf@building.gnus.org>" "<0loaqvlpkx.fsf@wjh.hardakers.net>" 3603 24 "news.gmane.org gmane.emacs.gnus.general:85511" nil])) ([85395 "using nnimap-split-fancy to split mail on server?" "Stephen Leake <stephen_leake@stephe-leake.org>" "Mon, 22 Dec 2014 10:48:55 -0600" "<85h9wnocjs.fsf@stephe-leake.org>" "" 4616 52 "news.gmane.org gmane.emacs.gnus.general:85395" nil] ([85510 "Re: using nnimap-split-fancy to 
 split mail on server?" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:29:48 +1100" "<87386ykymr.fsf@building.gnus.org>" "<85h9wnocjs.fsf@stephe-leake.org>" 3800 35 "news.gmane.org gmane.e
 macs.gnus.general:85510" nil] ([85531 "Re: using nnimap-split-fancy to split mail on server?" "Stephen Leake <stephen_leake@stephe-leake.org>" "Mon, 26 Jan 2015 04:04:29 -0600" "<85egqhdfiq.fsf@stephe-leake.org>" "<85h9wnocjs.fsf@stephe-leake.org> <87386ykymr.fsf@building.gnus.org>" 5471 64 "news.gmane.org gmane.emacs.gnus.general:85531" nil] ([85540 "Re: using nnimap-split-fancy to split mail on server?" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 11:55:38 +1100" "<87ioftdotx.fsf@building.gnus.org>" "<85h9wnocjs.fsf@stephe-leake.org> <87386ykymr.fsf@building.gnus.org> <85egqhdfiq.fsf@stephe-leake.org>" 3226 15 "news.gmane.org gmane.emacs.gnus.general:85540" nil] ([85587 "Re: using nnimap-split-fancy to split mail on server?" "Stephen Leake <stephen_leake@stephe-leake.org>" "Tu
 e, 27 Jan 2015 03:25:52 -0600" "<854mrcbmn3.fsf@stephe-leake.org>" "<85h9wnocjs.fsf@stephe-leake.org> <87386ykymr.fsf@building.gnus.org> <85egqhdfiq.fsf@stephe-leake.org> <87ioftdotx.fsf@building.gn
 us.org>" 4069 22 "news.gmane.org gmane.emacs.gnus.general:85587" nil] ([85588 "Re: using nnimap-split-fancy to split mail on server?" "Stephen Leake <stephen_leake@stephe-leake.org>" "Tue, 27 Jan 2015 04:16:42 -0600" "<85386wedf9.fsf@stephe-leake.org>" "<85h9wnocjs.fsf@stephe-leake.org> <87386ykymr.fsf@building.gnus.org> <85egqhdfiq.fsf@stephe-leake.org> <87ioftdotx.fsf@building.gnus.org> <854mrcbmn3.fsf@stephe-leake.org>" 4321 28 "news.gmane.org gmane.emacs.gnus.general:85588" nil])))))) ([85397 "How to search inside emails?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Sun, 28 Dec 2014 19:52:07 +0000" "<87d273r1qw.fsf@skimble.plus.com>" "" 4363 39 "news.gmane.org gmane.emacs.gnus.general:85397" nil] ([85398 "Re: How to search inside emails?" "asjo@koldfront.dk (Adam Sjøgren)" "Sun, 28
  Dec 2014 21:42:20 +0100" "<87mw678q1f.fsf@topper.koldfront.dk>" "<87d273r1qw.fsf@skimble.plus.com>" 4362 32 "news.gmane.org gmane.emacs.gnus.general:85398" nil] ([85420 "Re: How to search inside em
 ails?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Sat, 03 Jan 2015 15:11:25 +0000" "<871tnbvqzm.fsf@skimble.plus.com>" "<87d273r1qw.fsf@skimble.plus.com> <87mw678q1f.fsf@topper.koldfront.dk>" 5392 70 "news.gmane.org gmane.emacs.gnus.general:85420" nil] ([85421 "Re: How to search inside emails?" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 03 Jan 2015 20:19:39 +0100" "<87h9w7hdtg.fsf@topper.koldfront.dk>" "<87d273r1qw.fsf@skimble.plus.com> <87mw678q1f.fsf@topper.koldfront.dk> <871tnbvqzm.fsf@skimble.plus.com>" 4300 25 "news.gmane.org gmane.emacs.gnus.general:85421" nil])) ([85422 "Re: How to search inside emails?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Sat, 03 Jan 2015 19:30:13 +0000" "<877fx37jcq.fsf@skimble.plus.com>" "<87d273r1qw.fsf@skimble.plus.com> <87mw678q1f.fsf@topper.koldf
 ront.dk>" 4743 47 "news.gmane.org gmane.emacs.gnus.general:85422" nil])) ([85400 "Re: How to search inside emails?" "Steinar Bang <sb@dod.no>" "Mon, 29 Dec 2014 08:32:31 +0100" "<86387yhpww.fsf@dod.
 no>" "<87d273r1qw.fsf@skimble.plus.com>" 3461 13 "news.gmane.org gmane.emacs.gnus.general:85400" nil])) ([85399 "Need help on setting multiple gmail imap account" "Eric <thegreatfq@gmail.com>" "Mon, 29 Dec 2014 01:27:06 +0000 (UTC)" "<loom.20141229T020733-950@post.gmane.org>" "" 5900 34 "news.gmane.org gmane.emacs.gnus.general:85399" nil] ([85401 "Re: Need help on setting multiple gmail imap account" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 29 Dec 2014 10:11:10 +0100" "<874mseu8gh.fsf@topper.koldfront.dk>" "<loom.20141229T020733-950@post.gmane.org>" 4382 34 "news.gmane.org gmane.emacs.gnus.general:85401" nil] ([85713 "Re: Need help on setting multiple gmail imap account" "Ted Zlatanov <tzz@lifelogs.com>" "Wed, 04 Feb 2015 06:46:52 -0500" "<87wq3xyk43.fsf@lifelogs.com>" "<loom.20141229T02
 0733-950@post.gmane.org> <874mseu8gh.fsf@topper.koldfront.dk>" 4078 25 "news.gmane.org gmane.emacs.gnus.general:85713" nil] ([85729 "Re: Need help on setting multiple gmail imap account" "Lars Ingeb
 rigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:13:40 +1100" "<871tm5vymz.fsf@building.gnus.org>" "<loom.20141229T020733-950@post.gmane.org> <874mseu8gh.fsf@topper.koldfront.dk> <87wq3xyk43.fsf@lifelogs.com>" 3974 35 "news.gmane.org gmane.emacs.gnus.general:85729" nil] ([85750 "Re: Need help on setting multiple gmail imap account" "Ted Zlatanov <tzz@lifelogs.com>" "Thu, 05 Feb 2015 05:52:28 -0500" "<87oap8wryr.fsf@lifelogs.com>" "<loom.20141229T020733-950@post.gmane.org> <874mseu8gh.fsf@topper.koldfront.dk> <87wq3xyk43.fsf@lifelogs.com> <871tm5vymz.fsf@building.gnus.org>" 3652 13 "news.gmane.org gmane.emacs.gnus.general:85750" nil])) ([85752 "Re: Need help on setting multiple gmail imap account" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 05 Feb 2015 16:51:00 +0100" "<8761bg5pcr.fsf@topper.k
 oldfront.dk>" "<loom.20141229T020733-950@post.gmane.org> <874mseu8gh.fsf@topper.koldfront.dk> <87wq3xyk43.fsf@lifelogs.com>" 4099 25 "news.gmane.org gmane.emacs.gnus.general:85752" nil])))) ([85402 
 "choosing iso-8859-1 over utf-8 for some newsgroups" "Julien Cubizolles <j.cubizolles@free.fr>" "Mon, 29 Dec 2014 17:21:47 +0100" "<87ppb2a0kk.fsf@free.fr>" "" 3973 28 "news.gmane.org gmane.emacs.gnus.general:85402" nil] ([85403 "Re: choosing iso-8859-1 over utf-8 for some newsgroups" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 29 Dec 2014 18:35:35 +0100" "<87oaqms6jc.fsf@topper.koldfront.dk>" "<87ppb2a0kk.fsf@free.fr>" 4162 28 "news.gmane.org gmane.emacs.gnus.general:85403" nil] ([85404 "Re: choosing iso-8859-1 over utf-8 for some newsgroups" "Julien Cubizolles <j.cubizolles@free.fr>" "Tue, 30 Dec 2014 00:11:12 +0100" "<87sifyvypb.fsf@free.fr>" "<87ppb2a0kk.fsf@free.fr> <87oaqms6jc.fsf@topper.koldfront.dk>" 4570 41 "news.gmane.org gmane.emacs.gnus.general:85404" nil] ([85411 "Re: choosing 
 iso-8859-1 over utf-8 for some newsgroups" "Malcolm Purvis <malcolmp@xemacs.org>" "Thu, 01 Jan 2015 17:20:46 +1100" "<m2vbkrauo1.fsf@xemacs.org>" "<87ppb2a0kk.fsf@free.fr> <87oaqms6jc.fsf@topper.kol
 dfront.dk> <87sifyvypb.fsf@free.fr>" 4063 30 "news.gmane.org gmane.emacs.gnus.general:85411" nil])))) ([85405 "Trouble viewing PDF attachments (with patches)" "peder@news.klingenberg.no (Peder O. Klingenberg)" "Tue, 30 Dec 2014 12:35:40 +0100" "<kssifxl69f.fsf@luna.netfonds.no>" "" 9027 174 "news.gmane.org gmane.emacs.gnus.general:85405" nil] ([85406 "Re: Trouble viewing PDF attachments (with patches)" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 31 Dec 2014 09:20:22 +0800" "<87iogszkbt.fsf@ericabrahamsen.net>" "<kssifxl69f.fsf@luna.netfonds.no>" 5363 51 "news.gmane.org gmane.emacs.gnus.general:85406" nil] ([85407 "Re: Trouble viewing PDF attachments (with patches)" "peder@news.klingenberg.no (Peder O. Klingenberg)" "Wed, 31 Dec 2014 10:16:33 +0100" "<ks1tngji1a.fsf@luna.netfonds.no>
 " "<kssifxl69f.fsf@luna.netfonds.no> <87iogszkbt.fsf@ericabrahamsen.net>" 3807 22 "news.gmane.org gmane.emacs.gnus.general:85407" nil] ([85408 "Re: Trouble viewing PDF attachments (with patches)" "E
 ric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 31 Dec 2014 18:29:53 +0800" "<87a924xgbi.fsf@ericabrahamsen.net>" "<kssifxl69f.fsf@luna.netfonds.no> <87iogszkbt.fsf@ericabrahamsen.net> <ks1tngji1a.fsf@luna.netfonds.no>" 3941 24 "news.gmane.org gmane.emacs.gnus.general:85408" nil] ([85409 "Re: Trouble viewing PDF attachments (with patches)" "peder@news.klingenberg.no (Peder O. Klingenberg)" "Wed, 31 Dec 2014 15:04:18 +0100" "<kssifvj4pp.fsf@luna.netfonds.no>" "<kssifxl69f.fsf@luna.netfonds.no> <87iogszkbt.fsf@ericabrahamsen.net> <ks1tngji1a.fsf@luna.netfonds.no> <87a924xgbi.fsf@ericabrahamsen.net>" 3836 23 "news.gmane.org gmane.emacs.gnus.general:85409" nil])))) ([85509 "Re: Trouble viewing PDF attachments (with patches)" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:28:02 +110
 0" "<877fwakypp.fsf@building.gnus.org>" "<kssifxl69f.fsf@luna.netfonds.no>" 3759 23 "news.gmane.org gmane.emacs.gnus.general:85509" nil])) ([85412 "fancy splitting interactively" "Uwe Brauer <oub@ma
 t.ucm.es>" "Sat, 03 Jan 2015 11:22:51 +0100" "<87fvbs6u4k.fsf@mat.ucm.es>" "" 13299 147 "news.gmane.org gmane.emacs.gnus.general:85412" nil] ([85413 "Re: fancy splitting interactively" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Sat, 3 Jan 2015 10:57:48 +0000" "<87lhlk168j.fsf@ucl.ac.uk>" "<87fvbs6u4k.fsf@mat.ucm.es>" 4955 24 "news.gmane.org gmane.emacs.gnus.general:85413" nil] ([85415 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Sat, 03 Jan 2015 21:53:28 +0800" "<871tncvulj.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk>" 3676 25 "news.gmane.org gmane.emacs.gnus.general:85415" nil] ([85418 "Re: fancy splitting interactively" "Uwe Brauer <oub@mat.ucm.es>" "Sat, 03 Jan 2015 18:43:06 +0100" "<877fx37ob9.fsf@mat.ucm.es>" "<87fvbs6u
 4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net>" 12808 160 "news.gmane.org gmane.emacs.gnus.general:85418" nil] ([85425 "Re: fancy splitting interactively" "Eric Ab
 rahamsen <eric@ericabrahamsen.net>" "Sun, 04 Jan 2015 11:12:54 +0800" "<87k313utl5.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es>" 5219 59 "news.gmane.org gmane.emacs.gnus.general:85425" nil] ([85429 "Re: fancy splitting interactively" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Mon, 5 Jan 2015 12:31:53 +0000" "<874ms54ddy.fsf@ucl.ac.uk>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net>" 5706 30 "news.gmane.org gmane.emacs.gnus.general:85429" nil] ([85430 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Mon, 05 Jan 2015 22:34:15 +0800" "<87mw5x70uw.fsf@ericabraham
 sen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk>" 4679
  35 "news.gmane.org gmane.emacs.gnus.general:85430" nil] ...)))))) ([85414 "Re: fancy splitting interactively" "Glyn Millington <glyn.millington@gmail.com>" "Sat, 03 Jan 2015 10:39:10 +0000" "<87k314up0x.fsf@nowhere.org>" "<87fvbs6u4k.fsf@mat.ucm.es>" 3926 34 "news.gmane.org gmane.emacs.gnus.general:85414" nil]) ([85416 "Re: fancy splitting interactively" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 03 Jan 2015 15:48:24 +0100" "<87tx07j4xz.fsf@topper.koldfront.dk>" "<87fvbs6u4k.fsf@mat.ucm.es>" 5314 58 "news.gmane.org gmane.emacs.gnus.general:85416" nil] ([85417 "Re: fancy splitting interactively" "Uwe Brauer <oub@mat.ucm.es>" "Sat, 03 Jan 2015 18:38:24 +0100" "<87bnmf7oj3.fsf@mat.ucm.es>" "<87fvbs6u4k.fsf@mat.ucm.es> <87tx07j4xz.fsf@topper.koldfront.dk>" 13256 137 "news.gmane.org gmane.emac
 s.gnus.general:85417" nil] ([85419 "Re: fancy splitting interactively" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 03 Jan 2015 18:51:01 +0100" "<87lhljhhx6.fsf@topper.koldfront.dk>" "<87fvbs6u4k.fsf@m
 at.ucm.es> <87tx07j4xz.fsf@topper.koldfront.dk> <87bnmf7oj3.fsf@mat.ucm.es>" 3913 19 "news.gmane.org gmane.emacs.gnus.general:85419" nil] ([85423 "Re: fancy splitting interactively" "Uwe Brauer <oub@mat.ucm.es>" "Sat, 03 Jan 2015 23:49:49 +0100" "<87mw5zqy2a.fsf@mat.ucm.es>" "<87fvbs6u4k.fsf@mat.ucm.es> <87tx07j4xz.fsf@topper.koldfront.dk> <87bnmf7oj3.fsf@mat.ucm.es> <87lhljhhx6.fsf@topper.koldfront.dk>" 12215 142 "news.gmane.org gmane.emacs.gnus.general:85423" nil]) ([85427 "[bug] (was: fancy splitting interactively)" "Uwe Brauer <oub@mat.ucm.es>" "Sun, 04 Jan 2015 15:56:58 +0100" "<878uhiiog5.fsf_-_@mat.ucm.es>" "<87fvbs6u4k.fsf@mat.ucm.es> <87tx07j4xz.fsf@topper.koldfront.dk> <87bnmf7oj3.fsf@mat.ucm.es> <87lhljhhx6.fsf@topper.koldfront.dk>" 15048 157 "news.gmane.org gmane.emacs.gnus.ge
 neral:85427" nil] ([85508 "Re: [bug]" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:15:22 +1100" "<87iofukzat.fsf@building.gnus.org>" "<87fvbs6u4k.fsf@mat.ucm.es> <87tx07j4xz.fsf@topper.
 koldfront.dk> <87bnmf7oj3.fsf@mat.ucm.es> <87lhljhhx6.fsf@topper.koldfront.dk> <878uhiiog5.fsf_-_@mat.ucm.es>" 3569 20 "news.gmane.org gmane.emacs.gnus.general:85508" nil])))))) ([85424 "IMAP time out" "Kete Foy <kete@ninthfloor.org>" "Sat, 03 Jan 2015 20:24:01 -0500" "<54A89631.3090900@ninthfloor.org>" "" 2878 12 "news.gmane.org gmane.emacs.gnus.general:85424" nil] ([85426 "Re: IMAP time out" "Steinar Bang <sb@dod.no>" "Sun, 04 Jan 2015 09:23:49 +0100" "<upzck31354yy.fsf@dod.no>" "<54A89631.3090900@ninthfloor.org>" 3646 22 "news.gmane.org gmane.emacs.gnus.general:85426" nil])) ([85440 "Performance problem of imap move" "mremond@process-one.net (Mickaël Rémond)" "Tue, 06 Jan 2015 20:06:47 +0100" "<m2bnmbk9tk.fsf@process-one.net>" "" 5253 39 "news.gmane.org gmane.emacs.gnus.general:85440
 " nil] ([85496 "Re: Performance problem of imap move" "mremond@process-one.net (Mickaël Rémond)" "Wed, 21 Jan 2015 15:11:44 +0100" "<m2vbk0mden.fsf@process-one.net>" "<m2bnmbk9tk.fsf@process-one.n
 et>" 4610 26 "news.gmane.org gmane.emacs.gnus.general:85496" nil] ([85506 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Sun, 25 Jan 2015 15:57:23 +1100" "<87oapn5ufg.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net>" 3767 25 "news.gmane.org gmane.emacs.gnus.general:85506" nil] ([85507 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 13:52:46 +1100" "<87vbjul0ch.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org>" 3130 13 "news.gmane.org gmane.emacs.gnus.general:85507" nil] ([85532 "Re: Performance problem of imap move" "Tassilo Horn <tsdh@gnu.org>" "Mon, 26 Jan 2015 13:11:24 +0100" "<87siex213n.fsf@gn
 u.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org>" 3789 27 "news.gmane.org gmane.emacs.gnus.general:855
 32" nil] ([85535 "Re: Performance problem of imap move" "Steinar Bang <sb@dod.no>" "Mon, 26 Jan 2015 17:55:25 +0100" "<upzc8ugpzdky.fsf@dod.no>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org>" 3470 10 "news.gmane.org gmane.emacs.gnus.general:85535" nil]) ([85539 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 11:54:15 +1100" "<87mw55dow8.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org>" 3967 27 "news.gmane.org gmane.emacs.gnus.general:85539" nil] ([85579 "Re: Performance problem of imap move" "Ta
 ssilo Horn <tsdh@gnu.org>" "Tue, 27 Jan 2015 08:23:42 +0100" "<87mw54ptz5.fsf@gnu.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul
 0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87mw55dow8.fsf@building.gnus.org>" 3867 28 "news.gmane.org gmane.emacs.gnus.general:85579" nil] ... ...)) ([85556 "Re: Performance problem of imap move" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 27 Jan 2015 11:46:11 +0800" "<87oapkrim4.fsf@ericabrahamsen.net>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org>" 6162 43 "news.gmane.org gmane.emacs.gnus.general:85556" nil] ([85559 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 15:48:00 +1100" "<874mrcbzi7.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.o
 rg> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net>" 3343 13 "news.gmane.org gmane.emacs.gnus.general:85559" nil] ...))))))) ([85444 "saving \"sent\" 
 to just one folder?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Wed, 07 Jan 2015 13:26:44 +0000" "<87lhleyb57.fsf@skimble.plus.com>" "" 4906 55 "news.gmane.org gmane.emacs.gnus.general:85444" nil] ([85446 "Re: saving \"sent\" to just one folder?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Wed, 7 Jan 2015 15:02:27 +0000" "<874ms2y6po.fsf@ucl.ac.uk>" "<87lhleyb57.fsf@skimble.plus.com>" 5290 25 "news.gmane.org gmane.emacs.gnus.general:85446" nil])) ([85448 "Sorting threaded articles on top of summary" "Ivan Kanis <ivan@kanis.fr>" "Thu, 08 Jan 2015 09:11:36 +0100" "<87a91tpu87.fsf@kanis.fr>" "" 5871 41 "news.gmane.org gmane.emacs.gnus.general:85448" nil] ([85451 "Re: Sorting threaded articles on top of summary" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Thu, 8 Jan 2015 16:20:41 +0000" "<87wq4xfdly.fsf@u
 cl.ac.uk>" "<87a91tpu87.fsf@kanis.fr>" 5289 21 "news.gmane.org gmane.emacs.gnus.general:85451" nil])) ([85449 "local mailing list? I think so, but how?" "Sharon Kimble <boudiccas@skimble.plus.com>" 
 "Thu, 08 Jan 2015 15:22:38 +0000" "<871tn547r5.fsf@skimble.plus.com>" "" 5173 56 "news.gmane.org gmane.emacs.gnus.general:85449" nil] ([85452 "Re: local mailing list? I think so, but how?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Thu, 8 Jan 2015 16:26:27 +0000" "<87siflfdcc.fsf@ucl.ac.uk>" "<871tn547r5.fsf@skimble.plus.com>" 5009 16 "news.gmane.org gmane.emacs.gnus.general:85452" nil])) ([85450 "Gnus attempting to move mail from /var/spool/mail" "Harry Putnam <reader@newsguy.com>" "Thu, 08 Jan 2015 10:42:57 -0500" "<87wq4x9t32.fsf@reader.local.lan>" "" 8202 124 "news.gmane.org gmane.emacs.gnus.general:85450" nil] ([85453 "Re: Gnus attempting to move mail from /var/spool/mail" "Dan Christensen <jdc@uwo.ca>" "Thu, 08 Jan 2015 13:10:33 -0500" "<878uhdqh2e.fsf@uwo.ca>" "<87wq4x9t32.fsf@reader.loca
 l.lan>" 3355 13 "news.gmane.org gmane.emacs.gnus.general:85453" nil] ([85456 "Re: Gnus attempting to move mail from /var/spool/mail" "Harry Putnam <reader@newsguy.com>" "Thu, 08 Jan 2015 21:35:14 -0
 500" "<874ms0r89p.fsf@reader.local.lan>" "<87wq4x9t32.fsf@reader.local.lan> <878uhdqh2e.fsf@uwo.ca>" 3819 24 "news.gmane.org gmane.emacs.gnus.general:85456" nil] ([85460 "Re: Gnus attempting to move mail from /var/spool/mail" "asjo@koldfront.dk (Adam Sjøgren)" "Fri, 09 Jan 2015 20:19:47 +0100" "<87ppanvk18.fsf@topper.koldfront.dk>" "<87wq4x9t32.fsf@reader.local.lan> <878uhdqh2e.fsf@uwo.ca> <874ms0r89p.fsf@reader.local.lan>" 4360 30 "news.gmane.org gmane.emacs.gnus.general:85460" nil] ([85462 "Re: Gnus attempting to move mail from /var/spool/mail" "Harry Putnam <reader@newsguy.com>" "Sun, 11 Jan 2015 09:42:42 -0500" "<871tn1pee5.fsf@reader.local.lan>" "<87wq4x9t32.fsf@reader.local.lan> <878uhdqh2e.fsf@uwo.ca> <874ms0r89p.fsf@reader.local.lan> <87ppanvk18.fsf@topper.koldfront.dk>" 3973 25 
 "news.gmane.org gmane.emacs.gnus.general:85462" nil] ([85464 "Re: Gnus attempting to move mail from /var/spool/mail" "asjo@koldfront.dk (Adam Sjøgren)" "Sun, 11 Jan 2015 15:48:19 +0100" "<87vbkdnzk
 c.fsf@topper.koldfront.dk>" "<87wq4x9t32.fsf@reader.local.lan> <878uhdqh2e.fsf@uwo.ca> <874ms0r89p.fsf@reader.local.lan> <87ppanvk18.fsf@topper.koldfront.dk> <871tn1pee5.fsf@reader.local.lan>" 3895 17 "news.gmane.org gmane.emacs.gnus.general:85464" nil]))))) ([85454 "Re: Gnus attempting to move mail from /var/spool/mail" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 08 Jan 2015 20:38:48 +0100" "<87mw5t3vw7.fsf@topper.koldfront.dk>" "<87wq4x9t32.fsf@reader.local.lan>" 3799 18 "news.gmane.org gmane.emacs.gnus.general:85454" nil] ([85455 "Re: Gnus attempting to move mail from /var/spool/mail" "Harry Putnam <reader@newsguy.com>" "Thu, 08 Jan 2015 21:22:38 -0500" "<87d26oae1d.fsf@reader.local.lan>" "<87wq4x9t32.fsf@reader.local.lan> <87mw5t3vw7.fsf@topper.koldfront.dk>" 3440 14 "news.gmane.org gma
 ne.emacs.gnus.general:85455" nil] ([85459 "Re: Gnus attempting to move mail from /var/spool/mail" "asjo@koldfront.dk (Adam Sjøgren)" "Fri, 09 Jan 2015 20:11:15 +0100" "<871tn3wyzw.fsf@topper.koldfr
 ont.dk>" "<87wq4x9t32.fsf@reader.local.lan> <87mw5t3vw7.fsf@topper.koldfront.dk> <87d26oae1d.fsf@reader.local.lan>" 4099 27 "news.gmane.org gmane.emacs.gnus.general:85459" nil] ([85463 "Re: Gnus attempting to move mail from /var/spool/mail" "Harry Putnam <reader@newsguy.com>" "Sun, 11 Jan 2015 09:43:51 -0500" "<87wq4tnzrs.fsf@reader.local.lan>" "<87wq4x9t32.fsf@reader.local.lan> <87mw5t3vw7.fsf@topper.koldfront.dk> <87d26oae1d.fsf@reader.local.lan> <871tn3wyzw.fsf@topper.koldfront.dk>" 3782 24 "news.gmane.org gmane.emacs.gnus.general:85463" nil]))))) ([85465 "[OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Harry Putnam <reader@newsguy.com>" "Sun, 11 Jan 2015 09:55:40 -0500" "<87sifhnz83.fsf@reader.local.lan>" "" 3810 24 "news.gmane.org gmane.emacs.gnus.general:85465" nil] 
 ([85466 "Re: [OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Andreas Schwab <schwab@linux-m68k.org>" "Sun, 11 Jan 2015 17:12:41 +0100" "<87387hthxi.fsf@igel.home>" "<87sifhnz83.fsf@r
 eader.local.lan>" 3773 14 "news.gmane.org gmane.emacs.gnus.general:85466" nil] ([85470 "Re: [OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Harry Putnam <reader@newsguy.com>" "Sun, 11 Jan 2015 16:31:02 -0500" "<87lhl9m2cp.fsf@reader.local.lan>" "<87sifhnz83.fsf@reader.local.lan> <87387hthxi.fsf@igel.home>" 3514 16 "news.gmane.org gmane.emacs.gnus.general:85470" nil]) ([85471 "Re: [OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Harry Putnam <reader@newsguy.com>" "Sun, 11 Jan 2015 16:37:44 -0500" "<87h9vxm21j.fsf@reader.local.lan>" "<87sifhnz83.fsf@reader.local.lan> <87387hthxi.fsf@igel.home>" 5328 59 "news.gmane.org gmane.emacs.gnus.general:85471" nil])) ([85472 "Re: [OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Mike Kupfer <m.kupfer@acm.or
 g>" "Sun, 11 Jan 2015 19:39:28 -0800" "<26348.1421033968@allegro.localdomain>" "<87sifhnz83.fsf@reader.local.lan>" 3885 32 "news.gmane.org gmane.emacs.gnus.general:85472" nil] ([85481 "Re: [OT ssh -
 Y] Attempting to start emacsclient .. unusual error?" "Harry Putnam <reader@newsguy.com>" "Mon, 12 Jan 2015 13:39:43 -0500" "<87k30r93k9.fsf@reader.local.lan>" "<87sifhnz83.fsf@reader.local.lan> <26348.1421033968@allegro.localdomain>" 4210 31 "news.gmane.org gmane.emacs.gnus.general:85481" nil]))) ([85467 "Article mode for raw email message?" "Peter Davis <pfd@pfdstudio.com>" "Sun, 11 Jan 2015 14:10:36 -0500" "<m2ppal5e1f.fsf@PFDStudio-Air.home>" "" 3512 19 "news.gmane.org gmane.emacs.gnus.general:85467" nil] ([85468 "Re: Article mode for raw email message?" "david.goldberg6@verizon.net (Dave Goldberg)" "Sun, 11 Jan 2015 14:34:27 -0500" "<84mw5paz7g.fsf@davestoy.home>" "<m2ppal5e1f.fsf@PFDStudio-Air.home>" 3977 19 "news.gmane.org gmane.emacs.gnus.general:85468" nil] ([85474 "Re: Article m
 ode for raw email message?" "Peter Davis <pfd@pfdstudio.com>" "Mon, 12 Jan 2015 07:20:19 -0500" "<m2iogc5gxo.fsf@PFDStudio-Air.home>" "<m2ppal5e1f.fsf@PFDStudio-Air.home> <84mw5paz7g.fsf@davestoy.ho
 me>" 4487 27 "news.gmane.org gmane.emacs.gnus.general:85474" nil])) ([85469 "Re: Article mode for raw email message?" "asjo@koldfront.dk (Adam Sjøgren)" "Sun, 11 Jan 2015 20:51:33 +0100" "<87iogdnliy.fsf@topper.koldfront.dk>" "<m2ppal5e1f.fsf@PFDStudio-Air.home>" 4395 40 "news.gmane.org gmane.emacs.gnus.general:85469" nil] ([85475 "Re: Article mode for raw email message?" "Peter Davis <pfd@pfdstudio.com>" "Mon, 12 Jan 2015 07:22:34 -0500" "<m2egr05gtx.fsf@PFDStudio-Air.home>" "<m2ppal5e1f.fsf@PFDStudio-Air.home> <87iogdnliy.fsf@topper.koldfront.dk>" 4581 39 "news.gmane.org gmane.emacs.gnus.general:85475" nil] ([85476 "Re: Article mode for raw email message?" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 12 Jan 2015 15:23:26 +0100" "<87k30s3wo1.fsf@topper.koldfront.dk>" "<m2ppal5e1f.fsf@PFDSt
 udio-Air.home> <87iogdnliy.fsf@topper.koldfront.dk> <m2egr05gtx.fsf@PFDStudio-Air.home>" 4030 20 "news.gmane.org gmane.emacs.gnus.general:85476" nil] ([85477 "Re: Article mode for raw email message?
 " "Peter Davis <pfd@pfdstudio.com>" "Mon, 12 Jan 2015 09:34:12 -0500" "<m1fvbgjcez.fsf@pdavismbp15.iscinternal.com>" "<m2ppal5e1f.fsf@PFDStudio-Air.home> <87iogdnliy.fsf@topper.koldfront.dk> <m2egr05gtx.fsf@PFDStudio-Air.home> <87k30s3wo1.fsf@topper.koldfront.dk>" 4838 34 "news.gmane.org gmane.emacs.gnus.general:85477" nil] ([85478 "Re: Article mode for raw email message?" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 12 Jan 2015 18:43:46 +0100" "<87twzv3ne5.fsf@topper.koldfront.dk>" "<m2ppal5e1f.fsf@PFDStudio-Air.home> <87iogdnliy.fsf@topper.koldfront.dk> <m2egr05gtx.fsf@PFDStudio-Air.home> <87k30s3wo1.fsf@topper.koldfront.dk> <m1fvbgjcez.fsf@pdavismbp15.iscinternal.com>" 4229 23 "news.gmane.org gmane.emacs.gnus.general:85478" nil]))))) ([85482 "Re: Article mode for raw email message?" "Pete
 r Davis <pfd@pfdstudio.com>" "Tue, 13 Jan 2015 10:22:28 -0500" "<20150113152227.GB33607@pdavismbp15.iscinternal.com>" "<m2ppal5e1f.fsf@PFDStudio-Air.home>" 4625 35 "news.gmane.org gmane.emacs.gnus.g
 eneral:85482" nil])) ([85486 "importing PGP keys" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 20 Jan 2015 18:45:57 +0800" "<87d269ohlm.fsf@ericabrahamsen.net>" "" 3447 15 "news.gmane.org gmane.emacs.gnus.general:85486" nil] ([85488 "Re: importing PGP keys" "Greg Troxel <gdt@lexort.com>" "Tue, 20 Jan 2015 05:49:41 -0500" "<smuzj9dhgl6.fsf@linuxpal.mit.edu>" "<87d269ohlm.fsf@ericabrahamsen.net>" 4014 41 "news.gmane.org gmane.emacs.gnus.general:85488" nil] ([85491 "Re: importing PGP keys" "Russ Allbery <eagle@eyrie.org>" "Tue, 20 Jan 2015 22:29:10 -0800" "<87mw5csl3d.fsf@hope.eyrie.org>" "<87d269ohlm.fsf@ericabrahamsen.net> <smuzj9dhgl6.fsf@linuxpal.mit.edu>" 3536 21 "news.gmane.org gmane.emacs.gnus.general:85491" nil] ([85492 "Re: importing PGP keys" "Eric Abrahamsen <eric@ericabraham
 sen.net>" "Wed, 21 Jan 2015 15:03:10 +0800" "<877fwghaz5.fsf@ericabrahamsen.net>" "<87d269ohlm.fsf@ericabrahamsen.net> <smuzj9dhgl6.fsf@linuxpal.mit.edu> <87mw5csl3d.fsf@hope.eyrie.org>" 4386 32 "ne
 ws.gmane.org gmane.emacs.gnus.general:85492" nil] ([85493 "Re: importing PGP keys" "Jens Lechtenboerger <jens.lechtenboerger@fsfe.org>" "Wed, 21 Jan 2015 14:03:51 +0100" "<861tmo1e14.fsf@informationelle-selbstbestimmung-im-internet.de>" "<87d269ohlm.fsf@ericabrahamsen.net> <smuzj9dhgl6.fsf@linuxpal.mit.edu> <87mw5csl3d.fsf@hope.eyrie.org> <877fwghaz5.fsf@ericabrahamsen.net>" 4628 36 "news.gmane.org gmane.emacs.gnus.general:85493" nil] ([85494 "Re: importing PGP keys" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 21 Jan 2015 21:36:54 +0800" "<87lhkwfe6h.fsf@ericabrahamsen.net>" "<87d269ohlm.fsf@ericabrahamsen.net> <smuzj9dhgl6.fsf@linuxpal.mit.edu> <87mw5csl3d.fsf@hope.eyrie.org> <877fwghaz5.fsf@ericabrahamsen.net> <861tmo1e14.fsf@informationelle-selbstbestimmung-im-internet.de>" 4905 
 47 "news.gmane.org gmane.emacs.gnus.general:85494" nil])))))) ([85487 "problems in sending out emails" "Sharon Kimble <boudiccas@skimble.plus.com>" "Tue, 20 Jan 2015 13:12:26 +0000" "<87egqpy4sl.fsf
 @skimble.plus.com>" "" 5448 71 "news.gmane.org gmane.emacs.gnus.general:85487" nil] ([85489 "Re: problems in sending out emails" "Steinar Bang <sb@dod.no>" "Tue, 20 Jan 2015 18:21:14 +0100" "<upzc3875fjw5.fsf@dod.no>" "<87egqpy4sl.fsf@skimble.plus.com>" 3449 13 "news.gmane.org gmane.emacs.gnus.general:85489" nil]) ([85490 "Re: problems in sending out emails" "<e.fraga@ucl.ac.uk>" "Tue, 20 Jan 2015 18:03:48 +0000" "<87ppa9qqgr.fsf@ucl.ac.uk>" "<87egqpy4sl.fsf@skimble.plus.com>" 4596 12 "news.gmane.org gmane.emacs.gnus.general:85490" nil] ([85502 "Re: problems in sending out emails" "Sharon Kimble <boudiccas@skimble.plus.com>" "Thu, 22 Jan 2015 18:45:02 +0000" "<87egqmac41.fsf@skimble.plus.com>" "<87egqpy4sl.fsf@skimble.plus.com> <87ppa9qqgr.fsf@ucl.ac.uk>" 4539 41 "news.gmane.org gmane.ema
 cs.gnus.general:85502" nil]))) ([85495 "nnimap: article list is not correct." "Uwe Brauer <oub@mat.ucm.es>" "Wed, 21 Jan 2015 15:07:47 +0100" "<87wq4gz0p8.fsf@mat.ucm.es>" "" 12311 146 "news.gmane.o
 rg gmane.emacs.gnus.general:85495" nil] ([85497 "Re: nnimap: article list is not correct." "<e.fraga@ucl.ac.uk>" "Wed, 21 Jan 2015 15:41:50 +0000" "<87bnlskuo1.fsf@ucl.ac.uk>" "<87wq4gz0p8.fsf@mat.ucm.es>" 4722 18 "news.gmane.org gmane.emacs.gnus.general:85497" nil] ([85498 "Re: nnimap: article list is not correct." "Uwe Brauer <oub@mat.ucm.es>" "Wed, 21 Jan 2015 18:39:53 +0100" "<87oapsc9sm.fsf@mat.ucm.es>" "<87wq4gz0p8.fsf@mat.ucm.es> <87bnlskuo1.fsf@ucl.ac.uk>" 12203 142 "news.gmane.org gmane.emacs.gnus.general:85498" nil] ([85500 "Re: nnimap: article list is not correct." "Steinar Bang <sb@dod.no>" "Wed, 21 Jan 2015 22:00:28 +0100" "<upzc61bz4zo3.fsf@dod.no>" "<87wq4gz0p8.fsf@mat.ucm.es> <87bnlskuo1.fsf@ucl.ac.uk> <87oapsc9sm.fsf@mat.ucm.es>" 4226 36 "news.gmane.org gmane.emacs.gnus.g
 eneral:85500" nil] ([85501 "Re: nnimap: article list is not correct." "Uwe Brauer <oub@mat.ucm.es>" "Wed, 21 Jan 2015 23:22:37 +0100" "<87k30fhiz6.fsf@mat.ucm.es>" "<87wq4gz0p8.fsf@mat.ucm.es> <87bn
 lskuo1.fsf@ucl.ac.uk> <87oapsc9sm.fsf@mat.ucm.es> <upzc61bz4zo3.fsf@dod.no>" 12671 150 "news.gmane.org gmane.emacs.gnus.general:85501" nil]))))) ([85499 "gmail: can't visited the starred group" "Uwe Brauer <oub@mat.ucm.es>" "Wed, 21 Jan 2015 18:41:46 +0100" "<87k30gc9ph.fsf@mat.ucm.es>" "" 13263 160 "news.gmane.org gmane.emacs.gnus.general:85499" nil] ([85505 "Re: gmail: can't visited the starred group" "Lars Ingebrigtsen <larsi@gnus.org>" "Sun, 25 Jan 2015 14:52:32 +1100" "<87wq4b5xfj.fsf@building.gnus.org>" "<87k30gc9ph.fsf@mat.ucm.es>" 3191 14 "news.gmane.org gmane.emacs.gnus.general:85505" nil] ([85591 "Re: gmail: can't visited the starred group" "Uwe Brauer <oub@mat.ucm.es>" "Tue, 27 Jan 2015 15:45:18 +0100" "<87egqg470h.fsf@mat.ucm.es>" "<87k30gc9ph.fsf@mat.ucm.es> <87wq4b5xfj.fsf@b
 uilding.gnus.org>" 12713 156 "news.gmane.org gmane.emacs.gnus.general:85591" nil]))) ([85503 "Outdated manual on www.gnus.org" "halimsrama@gmail.com (Naim, Halim.)" "Thu, 22 Jan 2015 18:38:20 -0430"
  "<87y4ouza57.fsf@gmail.com>" "" 3911 13 "news.gmane.org gmane.emacs.gnus.general:85503" nil] ([85504 "Re: Outdated manual on www.gnus.org" "Lars Ingebrigtsen <larsi@gnus.org>" "Sun, 25 Jan 2015 14:44:24 +1100" "<87386z7cdj.fsf@building.gnus.org>" "<87y4ouza57.fsf@gmail.com>" 3707 12 "news.gmane.org gmane.emacs.gnus.general:85504" nil])) ([85592 "How do I make a new message html washer?" "joakim@verona.se" "Tue, 27 Jan 2015 20:02:07 +0100" "<m361bsoxn4.fsf@exodia.verona.se>" "" 3232 10 "news.gmane.org gmane.emacs.gnus.general:85592" nil] ([85593 "Re: How do I make a new message html washer?" "Andreas Schwab <schwab@linux-m68k.org>" "Tue, 27 Jan 2015 22:20:48 +0100" "<87386v9az3.fsf@igel.home>" "<m361bsoxn4.fsf@exodia.verona.se>" 4083 18 "news.gmane.org gmane.emacs.gnus.general:85593" nil]
  ([85596 "Re: How do I make a new message html washer?" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 11:48:31 +1100" "<87iofr20io.fsf@building.gnus.org>" "<m361bsoxn4.fsf@exodia.verona.se>
  <87386v9az3.fsf@igel.home>" 3510 19 "news.gmane.org gmane.emacs.gnus.general:85596" nil]))) ([85602 "git am/send-email support?" "Daiki Ueno <ueno@gnu.org>" "Wed, 28 Jan 2015 12:55:08 +0900" "<m3vbjreezn.fsf-ueno@gnu.org>" "" 2740 15 "news.gmane.org gmane.emacs.gnus.general:85602" nil] ([85648 "Re: git am/send-email support?" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 13:23:51 +1100" "<87vbjqmiiw.fsf@building.gnus.org>" "<m3vbjreezn.fsf-ueno@gnu.org>" 3169 13 "news.gmane.org gmane.emacs.gnus.general:85648" nil] ([85656 "Re: git am/send-email support?" "Daiki Ueno <ueno@gnu.org>" "Thu, 29 Jan 2015 18:05:57 +0900" "<m3k306ot1m.fsf-ueno@gnu.org>" "<m3vbjreezn.fsf-ueno@gnu.org> <87vbjqmiiw.fsf@building.gnus.org>" 3356 23 "news.gmane.org gmane.emacs.gnus.general:85656" nil] ([8566
 6 "Re: git am/send-email support?" "David Engster <deng@randomsample.de>" "Thu, 29 Jan 2015 20:53:51 +0100" "<87386t9xdc.fsf@randomsample.de>" "<m3vbjreezn.fsf-ueno@gnu.org> <87vbjqmiiw.fsf@building
 .gnus.org> <m3k306ot1m.fsf-ueno@gnu.org>" 4759 55 "news.gmane.org gmane.emacs.gnus.general:85666" nil] ([85689 "Re: git am/send-email support?" "Daiki Ueno <ueno@gnu.org>" "Mon, 02 Feb 2015 17:11:29 +0900" "<877fw0lolq.fsf-ueno@gnu.org>" "<m3vbjreezn.fsf-ueno@gnu.org> <87vbjqmiiw.fsf@building.gnus.org> <m3k306ot1m.fsf-ueno@gnu.org> <87386t9xdc.fsf@randomsample.de>" 3538 34 "news.gmane.org gmane.emacs.gnus.general:85689" nil])) ([85672 "Re: git am/send-email support?" "Lars Ingebrigtsen <larsi@gnus.org>" "Fri, 30 Jan 2015 10:37:48 +1100" "<87r3udyx83.fsf@building.gnus.org>" "<m3vbjreezn.fsf-ueno@gnu.org> <87vbjqmiiw.fsf@building.gnus.org> <m3k306ot1m.fsf-ueno@gnu.org>" 3397 18 "news.gmane.org gmane.emacs.gnus.general:85672" nil])))) ([85631 "address and name from posting styles are ignored
 " "Vitalie Spinu <spinuvit@gmail.com>" "Wed, 28 Jan 2015 12:24:43 +0100" "<87twzbrvus.fsf@gmail.com>" "" 3387 23 "news.gmane.org gmane.emacs.gnus.general:85631" nil] ([85634 "Re: address and name fr
 om posting styles are ignored" "Robert Pluim <rpluim@gmail.com>" "Wed, 28 Jan 2015 18:19:47 +0100" "<82d25yoma4.fsf@gmail.com>" "<87twzbrvus.fsf@gmail.com>" 4012 34 "news.gmane.org gmane.emacs.gnus.general:85634" nil])) ([85652 "latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 09:02:40 +0100" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr>" "" 4699 57 "news.gmane.org gmane.emacs.gnus.general:85652" nil] ([85653 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 09:04:33 +0100" "<m2bnlixbam.fsf@charm-ecran.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr>" 4056 34 "news.gmane.org gmane.emacs.gnus.general:85653" nil]) ([85654 "Re: latest imap changes break refiling" "Lars Ingebrigtsen <larsi@
 gnus.org>" "Thu, 29 Jan 2015 19:06:58 +1100" "<87a9123t99.fsf@building.gnus.org>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr>" 3698 25 "news.gmane.org gmane.emacs.gnus.general:85654" nil] ([85655 "Re: la
 test imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 09:51:06 +0100" "<m27fw6x951.fsf@charm-ecran.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org>" 4897 53 "news.gmane.org gmane.emacs.gnus.general:85655" nil] ([85657 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 11:18:29 +0100" "<m2twz951qi.fsf@charm-wifi.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr>" 5007 55 "news.gmane.org gmane.emacs.gnus.general:85657" nil] ([85658 "Re: latest imap changes break refiling" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 22:08:18 +1100" "<87iofp3kv1.fsf@building.gnus.org>" "<m2fv
 auxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr> <m2twz951qi.fsf@charm-wifi.irisa.fr>" 3473 18 "news.gmane.org gmane.emacs.gnus.general:85658
 " nil] ([85659 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 13:03:26 +0100" "<m2fvat94kx.fsf@charm-wifi.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr> <m2twz951qi.fsf@charm-wifi.irisa.fr> <87iofp3kv1.fsf@building.gnus.org>" 4560 47 "news.gmane.org gmane.emacs.gnus.general:85659" nil] ([85724 "Re: latest imap changes break refiling" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 13:29:34 +1100" "<87sielw0oh.fsf@building.gnus.org>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr> <m2twz951qi.fsf@charm-wifi.irisa.fr> <87iofp3kv1.fsf@building.gnus.org> <m2fvat94kx.fsf@charm-wifi.irisa.fr
 >" 3293 11 "news.gmane.org gmane.emacs.gnus.general:85724" nil] ...)))) ([85662 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 11:19:33 +0
 100" "<m2lhkl51oq.fsf@charm-wifi.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr>" 5009 55 "news.gmane.org gmane.emacs.gnus.general:85662" nil])))) ([85660 "[A bit OT] Text usenet server ?" "Xavier Maillard <xavier@maillard.im>" "Thu, 29 Jan 2015 13:18:50 +0100" "<m0zj91n5jp.fsf@kcals.intra.maillard.im>" "" 4370 28 "news.gmane.org gmane.emacs.gnus.general:85660" nil] ([85661 "Re: [A bit OT] Text usenet server ?" "Charles Philip Chan <cpchan@bell.net>" "Thu, 29 Jan 2015 08:01:56 -0500" "<87k305kaez.fsf@karnak.MagnumOpus.khem>" "<m0zj91n5jp.fsf@kcals.intra.maillard.im>" 3942 31 "news.gmane.org gmane.emacs.gnus.general:85661" nil] ([85667 "Re: [A bit OT] Text usenet server ?" "Xavier Maillard <xavier@maillard.im>" "Thu
 , 29 Jan 2015 22:17:00 +0100" "<m0wq45mgmr.fsf@kcals.intra.maillard.im>" "<m0zj91n5jp.fsf@kcals.intra.maillard.im> <87k305kaez.fsf@karnak.MagnumOpus.khem>" 4303 18 "news.gmane.org gmane.emacs.gnus.g
 eneral:85667" nil])) ([85663 "Re: [A bit OT] Text usenet server ?" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 29 Jan 2015 18:57:06 +0100" "<87mw51pj0t.fsf@topper.koldfront.dk>" "<m0zj91n5jp.fsf@kcals.intra.maillard.im>" 4154 29 "news.gmane.org gmane.emacs.gnus.general:85663" nil]) ([85664 "Re: [A bit OT] Text usenet server ?" "Harry Putnam <reader@newsguy.com>" "Thu, 29 Jan 2015 13:13:11 -0500" "<87k305e9qg.fsf@reader.local.lan>" "<m0zj91n5jp.fsf@kcals.intra.maillard.im>" 3406 14 "news.gmane.org gmane.emacs.gnus.general:85664" nil])) ([85678 "Why doesn't this render in gnus shr/eww?" "Steinar Bang <sb@dod.no>" "Fri, 30 Jan 2015 21:30:47 +0100" "<87k3043tag.fsf@dod.no>" "" 4120 27 "news.gmane.org gmane.emacs.gnus.general:85678" nil] ([85680 "Re: Why doesn't this render in gnus shr/eww?" "as
 jo@koldfront.dk (Adam Sjøgren)" "Sat, 31 Jan 2015 00:51:27 +0100" "<87wq43su80.fsf@topper.koldfront.dk>" "<87k3043tag.fsf@dod.no>" 3977 21 "news.gmane.org gmane.emacs.gnus.general:85680" nil]) ([85
 681 "Re: Why doesn't this render in gnus shr/eww?" "Lars Ingebrigtsen <larsi@gnus.org>" "Sat, 31 Jan 2015 11:49:26 +1100" "<87zj8zu63t.fsf@building.gnus.org>" "<87k3043tag.fsf@dod.no>" 3125 15 "news.gmane.org gmane.emacs.gnus.general:85681" nil] ([85683 "Re: Why doesn't this render in gnus shr/eww?" "Steinar Bang <sb@dod.no>" "Sat, 31 Jan 2015 15:02:41 +0100" "<upzczj8zf3pa.fsf@dod.no>" "<87k3043tag.fsf@dod.no> <87zj8zu63t.fsf@building.gnus.org>" 4578 37 "news.gmane.org gmane.emacs.gnus.general:85683" nil] ([85733 "Re: Why doesn't this render in gnus shr/eww?" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:37:30 +1100" "<87fval111h.fsf@building.gnus.org>" "<87k3043tag.fsf@dod.no> <87zj8zu63t.fsf@building.gnus.org> <upzczj8zf3pa.fsf@dod.no>" 3909 33 "news.gmane.org gmane.emacs.g
 nus.general:85733" nil] ([85753 "Re: Why doesn't this render in gnus shr/eww?" "Steinar Bang <sb@dod.no>" "Thu, 05 Feb 2015 18:19:00 +0100" "<upzcfvak9szf.fsf@dod.no>" "<87k3043tag.fsf@dod.no> <87zj
 8zu63t.fsf@building.gnus.org> <upzczj8zf3pa.fsf@dod.no> <87fval111h.fsf@building.gnus.org>" 3363 9 "news.gmane.org gmane.emacs.gnus.general:85753" nil] ([85754 "Re: Why doesn't this render in gnus shr/eww?" "Steinar Bang <sb@dod.no>" "Thu, 05 Feb 2015 21:24:14 +0100" "<upzc61bg9kep.fsf@dod.no>" "<87k3043tag.fsf@dod.no> <87zj8zu63t.fsf@building.gnus.org> <upzczj8zf3pa.fsf@dod.no> <87fval111h.fsf@building.gnus.org> <upzcfvak9szf.fsf@dod.no>" 3507 14 "news.gmane.org gmane.emacs.gnus.general:85754" nil] ([85757 "Re: Why doesn't this render in gnus shr/eww?" "Lars Ingebrigtsen <larsi@gnus.org>" "Fri, 06 Feb 2015 21:03:35 +1100" "<87wq3vicg8.fsf@building.gnus.org>" "<87k3043tag.fsf@dod.no> <87zj8zu63t.fsf@building.gnus.org> <upzczj8zf3pa.fsf@dod.no> <87fval111h.fsf@building.gnus.org> <upzcfvak9
 szf.fsf@dod.no> <upzc61bg9kep.fsf@dod.no>" 3155 11 "news.gmane.org gmane.emacs.gnus.general:85757" nil]))))))) ([85682 "Gnus gets terribly slow when exiting high-traffic groups" "Jason L Tibbitts II
 I <tibbs@math.uh.edu>" "Fri, 30 Jan 2015 19:54:08 -0600" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu>" "" 3688 24 "news.gmane.org gmane.emacs.gnus.general:85682" nil] ([85732 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:30:45 +1100" "<87k2zx11cq.fsf@building.gnus.org>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu>" 3547 17 "news.gmane.org gmane.emacs.gnus.general:85732" nil] ([85735 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Wed, 04 Feb 2015 21:38:19 -0600" "<ufa1tm5uixg.fsf@epithumia.math.uh.edu>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org>" 2962 10 "news.gmane.org gmane.emacs.gnus.general:85735" nil] ([85736 "Re: Gnus gets ter
 ribly slow when exiting high-traffic groups" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:47:31 +1100" "<87sielyq7g.fsf@building.gnus.org>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k
 2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu>" 3716 22 "news.gmane.org gmane.emacs.gnus.general:85736" nil] ([85737 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Wed, 04 Feb 2015 22:06:21 -0600" "<ufar3u5vw76.fsf@epithumia.math.uh.edu>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org>" 3862 36 "news.gmane.org gmane.emacs.gnus.general:85737" nil] ([85742 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 15:51:28 +1100" "<877fvxyn8v.fsf@building.gnus.org>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5
 uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org> <ufar3u5vw76.fsf@epithumia.math.uh.edu>" 3957 35 "news.gmane.org gmane.emacs.gnus.general:85742" nil] ([85743 "Re: Gnus gets terrib
 ly slow when exiting high-traffic groups" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Thu, 05 Feb 2015 00:12:39 -0600" "<ufasiek28fc.fsf@epithumia.math.uh.edu>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org> <ufar3u5vw76.fsf@epithumia.math.uh.edu> <877fvxyn8v.fsf@building.gnus.org>" 3690 24 "news.gmane.org gmane.emacs.gnus.general:85743" nil] ... ...))))))) ([85686 "Recent nnir update broke search on office365" "david.goldberg6@verizon.net (Dave Goldberg)" "Sat, 31 Jan 2015 11:53:28 -0500" "<84386qhoxj.fsf@davestoy.home>" "" 3524 20 "news.gmane.org gmane.emacs.gnus.general:85686" nil] ([85687 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" 
 "Sun, 01 Feb 2015 09:40:28 +0800" "<87r3ua9zoz.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home>" 5421 28 "news.gmane.org gmane.emacs.gnus.general:85687" nil]) ([85691 "Re: Recent nnir update
  broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Sun, 01 Feb 2015 14:22:44 +0800" "<871tma9mmj.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home>" 6590 67 "news.gmane.org gmane.emacs.gnus.general:85691" nil] ([85701 "Re: Recent nnir update broke search on office365" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 3 Feb 2015 11:49:00 +0000" "<87k2zzdxlf.fsf@pinto.chemeng.ucl.ac.uk>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net>" 5112 31 "news.gmane.org gmane.emacs.gnus.general:85701" nil] ([85702 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 03 Feb 2015 21:01:41 +0800" "<87egq79miy.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <87k2zzdxlf.fsf@pi
 nto.chemeng.ucl.ac.uk>" 5712 33 "news.gmane.org gmane.emacs.gnus.general:85702" nil] ([85703 "Re: Recent nnir update broke search on office365" "<e.fraga@ucl.ac.uk>" "Tue, 3 Feb 2015 15:57:08 +0000"
  "<87iofj7zu3.fsf@ucl.ac.uk>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <87k2zzdxlf.fsf@pinto.chemeng.ucl.ac.uk> <87egq79miy.fsf@ericabrahamsen.net>" 4682 20 "news.gmane.org gmane.emacs.gnus.general:85703" nil] ([85705 "Re: Recent nnir update broke search on office365" "david.goldberg6@verizon.net (Dave Goldberg)" "Tue, 03 Feb 2015 18:21:36 -0500" "<84mw4utwcf.fsf@davestoy.home>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <87k2zzdxlf.fsf@pinto.chemeng.ucl.ac.uk> <87egq79miy.fsf@ericabrahamsen.net> <87iofj7zu3.fsf@ucl.ac.uk>" 3695 18 "news.gmane.org gmane.emacs.gnus.general:85705" nil] ([85707 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 04 Feb 2015 11:02:12 +0800" "<87oapa8jm3.fsf@er
 icabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <87k2zzdxlf.fsf@pinto.chemeng.ucl.ac.uk> <87egq79miy.fsf@ericabrahamsen.net> <87iofj7zu3.fsf@ucl.ac.uk> <84mw4u
 twcf.fsf@davestoy.home>" 5179 19 "news.gmane.org gmane.emacs.gnus.general:85707" nil] ...))))) ([85706 "Re: Recent nnir update broke search on office365" "Katsumi Yamaoka <yamaoka@jpl.org>" "Wed, 04 Feb 2015 09:15:19 +0900" "<b4mh9v2wmzs.fsf@jpl.org>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net>" 3969 20 "news.gmane.org gmane.emacs.gnus.general:85706" nil] ([85708 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 04 Feb 2015 11:30:52 +0800" "<87k2zy8iab.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <b4mh9v2wmzs.fsf@jpl.org>" 6166 44 "news.gmane.org gmane.emacs.gnus.general:85708" nil] ([85715 "Re: Recent nnir update broke search on office365" "Andreas Schwab <schwab@lin
 ux-m68k.org>" "Wed, 04 Feb 2015 19:28:24 +0100" "<87mw4ta5vb.fsf@igel.home>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <b4mh9v2wmzs.fsf@jpl.org> <87k2zy8iab.fsf@ericabraham
 sen.net>" 4300 22 "news.gmane.org gmane.emacs.gnus.general:85715" nil] ([85723 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Thu, 05 Feb 2015 09:03:36 +0800" "<8761bhrwyf.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <b4mh9v2wmzs.fsf@jpl.org> <87k2zy8iab.fsf@ericabrahamsen.net> <87mw4ta5vb.fsf@igel.home>" 5244 20 "news.gmane.org gmane.emacs.gnus.general:85723" nil])))))) ([85692 "Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 00:18:54 +0100" "<m3r3u7aom9.fsf@neo.luffy.cx>" "" 3743 13 "news.gmane.org gmane.emacs.gnus.general:85692" nil] ([85694 "Re: Unable to get all messages in an IMAP group" "Steinar Bang <sb@dod.no>" "Tue, 03 Feb 2015 07:42:
 22 +0100" "<upzciofjfqcx.fsf@dod.no>" "<m3r3u7aom9.fsf@neo.luffy.cx>" 3550 14 "news.gmane.org gmane.emacs.gnus.general:85694" nil] ([85695 "Re: Unable to get all messages in an IMAP group" "Vincent 
 Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 08:40:47 +0100" "<m3egq7a1ds.fsf@neo.luffy.cx>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no>" 4679 25 "news.gmane.org gmane.emacs.gnus.general:85695" nil] ([85696 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 08:44:31 +0100" "<m38ugfa17k.fsf@neo.luffy.cx>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx>" 5202 42 "news.gmane.org gmane.emacs.gnus.general:85696" nil]) ([85697 "Re: Unable to get all messages in an IMAP group" "Steinar Bang <sb@dod.no>" "Tue, 03 Feb 2015 09:05:23 +0100" "<upzcegq7fmik.fsf@dod.no>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx>" 4008 30 "news.gmane.org gmane.emacs.gnus.gen
 eral:85697" nil] ([85698 "Re: Unable to get all messages in an IMAP group" "Tassilo Horn <tsdh@gnu.org>" "Tue, 03 Feb 2015 09:17:47 +0100" "<87h9v38l3o.fsf@gnu.org>" "<m3r3u7aom9.fsf@neo.luffy.cx> <
 upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no>" 3142 24 "news.gmane.org gmane.emacs.gnus.general:85698" nil]) ([85699 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 10:09:56 +0100" "<87oapbe4yj.fsf@zoro.exoscale.ch>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no>" 4523 19 "news.gmane.org gmane.emacs.gnus.general:85699" nil] ([85700 "Re: Unable to get all messages in an IMAP group" "Steinar Bang <sb@dod.no>" "Tue, 03 Feb 2015 11:54:48 +0100" "<upzca90vfeo7.fsf@dod.no>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch>" 3619 15 "news.gmane.or
 g gmane.emacs.gnus.general:85700" nil] ([85704 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 21:52:55 +0100" "<m3fvamzpi0.fsf@neo.luffy.cx>" 
 "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no>" 4845 28 "news.gmane.org gmane.emacs.gnus.general:85704" nil] ...))))))) ([85693 "Unable to see all messages since recent IMAP changes" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 00:19:25 +0100" "<m3mw4vaole.fsf@neo.luffy.cx>" "" 3796 14 "news.gmane.org gmane.emacs.gnus.general:85693" nil]) ([85758 "Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 10 Feb 2015 14:05:08 +0800" "<87iofawbcb.fsf@ericabrahamsen.net>" "" 5231 31 "news.gmane.org gmane.emacs.gnus.general:85758" nil] ([85759 "Re: Gnus Own-Cloudy?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 10 Feb 2015 09:17:25 +0000" "<87twyu6s7u.fsf@
 ucl.ac.uk>" "<87iofawbcb.fsf@ericabrahamsen.net>" 5221 23 "news.gmane.org gmane.emacs.gnus.general:85759" nil] ([85760 "Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 10 Feb
  2015 18:20:48 +0800" "<87mw4mukxr.fsf@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk>" 5971 39 "news.gmane.org gmane.emacs.gnus.general:85760" nil] ([85761 "Re: Gnus Own-Cloudy?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 10 Feb 2015 10:48:37 +0000" "<87wq3qm48q.fsf@ucl.ac.uk>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net>" 6597 62 "news.gmane.org gmane.emacs.gnus.general:85761" nil] ([85762 "Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 10 Feb 2015 18:53:33 +0800" "<874mquujf6.fsf@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk>" 6996 69 "news.gmane.org gmane.emacs.gnus.genera
 l:85762" nil] ([85763 "Re: Gnus Own-Cloudy?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 10 Feb 2015 11:45:49 +0000" "<87lhk6kn0y.fsf@ucl.ac.uk>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@uc
 l.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net>" 5398 30 "news.gmane.org gmane.emacs.gnus.general:85763" nil] ([85766 "Re: Gnus Own-Cloudy?" "jorge.alfaro-murillo@yale.edu (Jorge A. Alfaro-Murillo)" "Tue, 10 Feb 2015 10:19:19 -0500" "<877fvpokug.fsf@yale.edu>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk>" 3552 17 "news.gmane.org gmane.emacs.gnus.general:85766" nil]) ([85768 "Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 11 Feb 2015 10:12:03 +0800" "<87iof9tcwc.fsf@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fs
 f@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk>" 5981 32 "news.gmane.org gmane.emacs.gnus.general:85768" nil] ... ...)))))) ([85767 "R
 e: Gnus Own-Cloudy?" "jorge.alfaro-murillo@yale.edu (Jorge A. Alfaro-Murillo)" "Tue, 10 Feb 2015 10:31:00 -0500" "<87386dokaz.fsf@yale.edu>" "<87iofawbcb.fsf@ericabrahamsen.net>" 3924 32 "news.gmane.org gmane.emacs.gnus.general:85767" nil])) ...))
  gnus-summary-prepare()
  gnus-summary-read-group-1("nntp+news.gmane.org:gmane.emacs.gnus.general" nil t nil nil nil)
  gnus-summary-read-group("nntp+news.gmane.org:gmane.emacs.gnus.general" nil t nil nil nil nil)
  gnus-group-read-group(nil t)
  gnus-group-select-group(nil)
  funcall-interactively(gnus-group-select-group nil)
  call-interactively(gnus-group-select-group nil nil)
  command-execute(gnus-group-select-group)

^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2015-02-13 14:39                   ` Peter Münster
@ 2015-02-14  4:19                     ` Lars Ingebrigtsen
  2015-03-02 14:34                       ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Lars Ingebrigtsen @ 2015-02-14  4:19 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

Peter Münster <pmlists@free.fr> writes:

> They are the same. Please find attached an example.

The backtrace doesn't contain the full info, unfortunately.

After you enter the debugger, can you go to the *scratch* buffer and

`M-: (pp threads (current-buffer)) RET'

Then post the output here.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2015-02-14  4:19                     ` Lars Ingebrigtsen
@ 2015-03-02 14:34                       ` Peter Münster
  2015-07-20 12:52                         ` Peter Münster
  2016-02-07  6:31                         ` Lars Ingebrigtsen
  0 siblings, 2 replies; 84+ messages in thread
From: Peter Münster @ 2015-03-02 14:34 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 18522

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Sat, Feb 14 2015, Lars Ingebrigtsen wrote:

> After you enter the debugger, can you go to the *scratch* buffer and
>
> `M-: (pp threads (current-buffer)) RET'

Hi,

`threads' is not defined then... Instead I've modified
`gnus-sort-threads' to print `threads' into the buffer.

In both cases it's the same. Please find attached an example.

-- 
           Peter

[-- Attachment #2: gnus-sort-threads.txt --]
[-- Type: text/plain, Size: 181972 bytes --]

(([85605 "Re: gnus-dired-attach: default mime-type application/octet-stream, why" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 15:11:41 +1100" "<87386vzgqq.fsf@building.gnus.org>" "<87mwc37mh7.fsf@mat.ucm.es>" 3794 28 "news.gmane.org gmane.emacs.gnus.general:85605" nil])
 ([85344 "restore the setup file?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Thu, 11 Dec 2014 17:55:16 +0000" "<87r3w6vzp7.fsf@skimble.plus.com>" "" 5645 42 "news.gmane.org gmane.emacs.gnus.general:85344" nil]
  ([85345 "Re: restore the setup file?" "jorge.alfaro-murillo@yale.edu (Jorge A. Alfaro-Murillo)" "Thu, 11 Dec 2014 13:08:07 -0500" "<87oaraoy9k.fsf@yale.edu>" "<87r3w6vzp7.fsf@skimble.plus.com>" 3529 18 "news.gmane.org gmane.emacs.gnus.general:85345" nil]
   ([85346 "Re: restore the setup file?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Thu, 11 Dec 2014 19:05:11 +0000" "<87fvcmuhw8.fsf@skimble.plus.com>" "<87r3w6vzp7.fsf@skimble.plus.com> <87oaraoy9k.fsf@yale.edu>" 6259 53 "news.gmane.org gmane.emacs.gnus.general:85346" nil])))
 ([85347 "A little coaching on massive downloading or messages" "Harry Putnam <reader@newsguy.com>" "Thu, 11 Dec 2014 14:10:43 -0500" "<87fvcmovd8.fsf@reader.local.lan>" "" 3407 14 "news.gmane.org gmane.emacs.gnus.general:85347" nil])
 ([85348 "shr.el: add linebreaks to mouse-over tooltips (title attributes)" "asjo@koldfront.dk (Adam Sjøgren)" "Fri, 12 Dec 2014 22:29:21 +0100" "<877fxwr1zi.fsf@topper.koldfront.dk>" "" 5604 38 "news.gmane.org gmane.emacs.devel:179964 gmane.emacs.gnus.general:85348" nil]
  ([85357 "Re: shr.el: add linebreaks to mouse-over tooltips (title attributes)" "Lars Magne Ingebrigtsen <larsi@gnus.org>" "Sat, 13 Dec 2014 16:24:31 +0100" "<m3zjar1sk0.fsf@stories.gnus.org>" "<877fxwr1zi.fsf@topper.koldfront.dk>" 5762 23 "news.gmane.org gmane.emacs.devel:180011 gmane.emacs.gnus.general:85357" nil]))
 ([85353 "Does nnir support nnrss?" "Frank <kulugox@gmail.com>" "Sat, 13 Dec 2014 10:30:48 +0800" "<87vblguvqf.fsf@gmail.com>" "" 3497 20 "news.gmane.org gmane.emacs.gnus.general:85353" nil]
  ([85513 "Re: Does nnir support nnrss?" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:41:08 +1100" "<87ppa2jjjf.fsf@building.gnus.org>" "<87vblguvqf.fsf@gmail.com>" 3027 12 "news.gmane.org gmane.emacs.gnus.general:85513" nil]))
 ([85363 "anything newer than emacs-w3m for rendering html" "Harry Putnam <reader@newsguy.com>" "Thu, 18 Dec 2014 16:22:56 -0500" "<87k31or6tr.fsf@reader.local.lan>" "" 4316 14 "news.gmane.org gmane.emacs.gnus.general:85363" nil]
  ([85364 "Re: anything newer than emacs-w3m for rendering html" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 18 Dec 2014 19:31:17 +0100" "<87sigchksq.fsf@topper.koldfront.dk>" "<87k31or6tr.fsf@reader.local.lan>" 4625 43 "news.gmane.org gmane.emacs.gnus.general:85364" nil]
   ([85371 "Re: anything newer than emacs-w3m for rendering html" "Malcolm Purvis <malcolm@purvis.id.au>" "Fri, 19 Dec 2014 14:10:22 +1100" "<m1k31opc69.fsf@mpurvis.dyn.syd.atlassian.com>" "<87k31or6tr.fsf@reader.local.lan> <87sigchksq.fsf@topper.koldfront.dk>" 3589 15 "news.gmane.org gmane.emacs.gnus.general:85371" nil]
    ([85372 "Re: anything newer than emacs-w3m for rendering html" "Harry Putnam <reader@newsguy.com>" "Fri, 19 Dec 2014 12:22:10 -0500" "<87388b5zct.fsf@reader.local.lan>" "<87k31or6tr.fsf@reader.local.lan> <87sigchksq.fsf@topper.koldfront.dk> <m1k31opc69.fsf@mpurvis.dyn.syd.atlassian.com>" 3564 15 "news.gmane.org gmane.emacs.gnus.general:85372" nil]
     ([85379 "Re: anything newer than emacs-w3m for rendering html" "Steinar Bang <sb@dod.no>" "Sat, 20 Dec 2014 10:06:13 +0100" "<878ui2k7wa.fsf@dod.no>" "<87k31or6tr.fsf@reader.local.lan> <87sigchksq.fsf@topper.koldfront.dk> <m1k31opc69.fsf@mpurvis.dyn.syd.atlassian.com> <87388b5zct.fsf@reader.local.lan>" 3429 9 "news.gmane.org gmane.emacs.gnus.general:85379" nil])
     ([85390 "Re: anything newer than emacs-w3m for rendering html" "Malcolm Purvis <malcolmp@xemacs.org>" "Sun, 21 Dec 2014 22:28:47 +1100" "<m2r3vt2qds.fsf@xemacs.org>" "<87k31or6tr.fsf@reader.local.lan> <87sigchksq.fsf@topper.koldfront.dk> <m1k31opc69.fsf@mpurvis.dyn.syd.atlassian.com> <87388b5zct.fsf@reader.local.lan>" 4632 19 "news.gmane.org gmane.emacs.gnus.general:85390" nil]))))
  ([85366 "Re: anything newer than emacs-w3m for rendering html" "Filipp Gunbin <fgunbin@fastmail.fm>" "Fri, 19 Dec 2014 01:07:41 +0300" "<m2a92ksjbm.fsf@fastmail.fm>" "<87k31or6tr.fsf@reader.local.lan>" 4095 15 "news.gmane.org gmane.emacs.gnus.general:85366" nil]
   ([85367 "Re: anything newer than emacs-w3m for rendering html" "Harry Putnam <reader@newsguy.com>" "Thu, 18 Dec 2014 21:11:12 -0500" "<87h9wsmlrz.fsf@reader.local.lan>" "<87k31or6tr.fsf@reader.local.lan> <m2a92ksjbm.fsf@fastmail.fm>" 4771 20 "news.gmane.org gmane.emacs.gnus.general:85367" nil]
    ([85512 "Re: anything newer than emacs-w3m for rendering html" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:40:33 +1100" "<87twzejjke.fsf@building.gnus.org>" "<87k31or6tr.fsf@reader.local.lan> <m2a92ksjbm.fsf@fastmail.fm> <87h9wsmlrz.fsf@reader.local.lan>" 3304 14 "news.gmane.org gmane.emacs.gnus.general:85512" nil]))))
 ([85374 "movemail failing .. apparently permission issue" "Harry Putnam <reader@newsguy.com>" "Fri, 19 Dec 2014 19:36:05 -0500" "<87bnmzduoa.fsf@reader.local.lan>" "" 4308 39 "news.gmane.org gmane.emacs.gnus.general:85374" nil]
  ([85378 "Re: movemail failing .. apparently permission issue" "Andreas Schwab <schwab@linux-m68k.org>" "Sat, 20 Dec 2014 09:55:08 +0100" "<m2egruk8er.fsf@linux-m68k.org>" "<87bnmzduoa.fsf@reader.local.lan>" 4876 18 "news.gmane.org gmane.emacs.gnus.general:85378" nil]
   ([85381 "Re: movemail failing .. apparently permission issue" "Harry Putnam <reader@newsguy.com>" "Sat, 20 Dec 2014 07:59:33 -0500" "<87tx0qo4sq.fsf@reader.local.lan>" "<87bnmzduoa.fsf@reader.local.lan> <m2egruk8er.fsf@linux-m68k.org>" 3517 23 "news.gmane.org gmane.emacs.gnus.general:85381" nil]))
  ([85393 "Re: movemail failing .. apparently permission issue" "Harry Putnam <reader@newsguy.com>" "Sun, 21 Dec 2014 16:05:20 -0500" "<874msovhm7.fsf@reader.local.lan>" "<87bnmzduoa.fsf@reader.local.lan>" 5024 61 "news.gmane.org gmane.emacs.gnus.general:85393" nil]))
 ([85383 "Track down a failure involving shr" "Harry Putnam <reader@newsguy.com>" "Sat, 20 Dec 2014 16:16:50 -0500" "<87fvcaf2d9.fsf@reader.local.lan>" "" 5542 70 "news.gmane.org gmane.emacs.gnus.general:85383" nil]
  ([85384 "Re: Track down a failure involving shr" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 20 Dec 2014 22:57:43 +0100" "<87h9wqvvag.fsf@topper.koldfront.dk>" "<87fvcaf2d9.fsf@reader.local.lan>" 3937 19 "news.gmane.org gmane.emacs.gnus.general:85384" nil])
  ([85385 "Re: Track down a failure involving shr" "Steinar Bang <sb@dod.no>" "Sat, 20 Dec 2014 23:45:24 +0100" "<86tx0qkkjf.fsf@dod.no>" "<87fvcaf2d9.fsf@reader.local.lan>" 3291 10 "news.gmane.org gmane.emacs.gnus.general:85385" nil]
   ([85386 "Re: Track down a failure involving shr" "Clemens Schüller <cs.mlists+gnus@mailbox.org>" "Sat, 20 Dec 2014 23:52:46 +0100" "<87oaqyc4sh.fsf@cougar.home.aneadesign.com>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no>" 4764 25 "news.gmane.org gmane.emacs.gnus.general:85386" nil]
    ([85388 "Re: Track down a failure involving shr" "Harry Putnam <reader@newsguy.com>" "Sat, 20 Dec 2014 18:19:55 -0500" "<873889gb8k.fsf@reader.local.lan>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no> <87oaqyc4sh.fsf@cougar.home.aneadesign.com>" 5424 67 "news.gmane.org gmane.emacs.gnus.general:85388" nil]
     ([85389 "Re: Track down a failure involving shr" "asjo@koldfront.dk (Adam Sjøgren)" "Sun, 21 Dec 2014 07:35:05 +0100" "<8761d5qzmu.fsf@topper.koldfront.dk>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no> <87oaqyc4sh.fsf@cougar.home.aneadesign.com> <873889gb8k.fsf@reader.local.lan>" 4133 23 "news.gmane.org gmane.emacs.gnus.general:85389" nil])
     ([85391 "Re: Track down a failure involving shr" "Clemens Schüller <cs.mlists+gnus@mailbox.org>" "Sun, 21 Dec 2014 13:27:59 +0100" "<873889p4q8.fsf@cougar.home.aneadesign.com>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no> <87oaqyc4sh.fsf@cougar.home.aneadesign.com> <873889gb8k.fsf@reader.local.lan>" 6893 65 "news.gmane.org gmane.emacs.gnus.general:85391" nil]
      ([85392 "Re: Track down a failure involving shr" "Harry Putnam <reader@newsguy.com>" "Sun, 21 Dec 2014 06:51:50 -0500" "<877fxlxlt5.fsf@reader.local.lan>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no> <87oaqyc4sh.fsf@cougar.home.aneadesign.com> <873889gb8k.fsf@reader.local.lan> <873889p4q8.fsf@cougar.home.aneadesign.com>" 4303 30 "news.gmane.org gmane.emacs.gnus.general:85392" nil]))))
   ([85387 "Re: Track down a failure involving shr" "Harry Putnam <reader@newsguy.com>" "Sat, 20 Dec 2014 17:54:18 -0500" "<877fxmexut.fsf@reader.local.lan>" "<87fvcaf2d9.fsf@reader.local.lan> <86tx0qkkjf.fsf@dod.no>" 4170 39 "news.gmane.org gmane.emacs.gnus.general:85387" nil])))
 ([85394 "large number of References: breaks gnus when tramp is in use" "Wes Hardaker <wes@hardakers.net>" "Mon, 22 Dec 2014 06:35:42 -0800" "<0loaqvlpkx.fsf@wjh.hardakers.net>" "" 4236 24 "news.gmane.org gmane.emacs.gnus.general:85394" nil]
  ([85511 "Re: large number of References: breaks gnus when tramp is in use" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:31:17 +1100" "<87y4oqjjzu.fsf@building.gnus.org>" "<0loaqvlpkx.fsf@wjh.hardakers.net>" 3603 24 "news.gmane.org gmane.emacs.gnus.general:85511" nil]))
 ([85395 "using nnimap-split-fancy to split mail on server?" "Stephen Leake <stephen_leake@stephe-leake.org>" "Mon, 22 Dec 2014 10:48:55 -0600" "<85h9wnocjs.fsf@stephe-leake.org>" "" 4616 52 "news.gmane.org gmane.emacs.gnus.general:85395" nil]
  ([85510 "Re: using nnimap-split-fancy to split mail on server?" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:29:48 +1100" "<87386ykymr.fsf@building.gnus.org>" "<85h9wnocjs.fsf@stephe-leake.org>" 3800 35 "news.gmane.org gmane.emacs.gnus.general:85510" nil]
   ([85531 "Re: using nnimap-split-fancy to split mail on server?" "Stephen Leake <stephen_leake@stephe-leake.org>" "Mon, 26 Jan 2015 04:04:29 -0600" "<85egqhdfiq.fsf@stephe-leake.org>" "<85h9wnocjs.fsf@stephe-leake.org> <87386ykymr.fsf@building.gnus.org>" 5471 64 "news.gmane.org gmane.emacs.gnus.general:85531" nil]
    ([85540 "Re: using nnimap-split-fancy to split mail on server?" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 11:55:38 +1100" "<87ioftdotx.fsf@building.gnus.org>" "<85h9wnocjs.fsf@stephe-leake.org> <87386ykymr.fsf@building.gnus.org> <85egqhdfiq.fsf@stephe-leake.org>" 3226 15 "news.gmane.org gmane.emacs.gnus.general:85540" nil]
     ([85587 "Re: using nnimap-split-fancy to split mail on server?" "Stephen Leake <stephen_leake@stephe-leake.org>" "Tue, 27 Jan 2015 03:25:52 -0600" "<854mrcbmn3.fsf@stephe-leake.org>" "<85h9wnocjs.fsf@stephe-leake.org> <87386ykymr.fsf@building.gnus.org> <85egqhdfiq.fsf@stephe-leake.org> <87ioftdotx.fsf@building.gnus.org>" 4069 22 "news.gmane.org gmane.emacs.gnus.general:85587" nil]
      ([85588 "Re: using nnimap-split-fancy to split mail on server?" "Stephen Leake <stephen_leake@stephe-leake.org>" "Tue, 27 Jan 2015 04:16:42 -0600" "<85386wedf9.fsf@stephe-leake.org>" "<85h9wnocjs.fsf@stephe-leake.org> <87386ykymr.fsf@building.gnus.org> <85egqhdfiq.fsf@stephe-leake.org> <87ioftdotx.fsf@building.gnus.org> <854mrcbmn3.fsf@stephe-leake.org>" 4321 28 "news.gmane.org gmane.emacs.gnus.general:85588" nil]))))))
 ([85397 "How to search inside emails?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Sun, 28 Dec 2014 19:52:07 +0000" "<87d273r1qw.fsf@skimble.plus.com>" "" 4363 39 "news.gmane.org gmane.emacs.gnus.general:85397" nil]
  ([85398 "Re: How to search inside emails?" "asjo@koldfront.dk (Adam Sjøgren)" "Sun, 28 Dec 2014 21:42:20 +0100" "<87mw678q1f.fsf@topper.koldfront.dk>" "<87d273r1qw.fsf@skimble.plus.com>" 4362 32 "news.gmane.org gmane.emacs.gnus.general:85398" nil]
   ([85420 "Re: How to search inside emails?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Sat, 03 Jan 2015 15:11:25 +0000" "<871tnbvqzm.fsf@skimble.plus.com>" "<87d273r1qw.fsf@skimble.plus.com> <87mw678q1f.fsf@topper.koldfront.dk>" 5392 70 "news.gmane.org gmane.emacs.gnus.general:85420" nil]
    ([85421 "Re: How to search inside emails?" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 03 Jan 2015 20:19:39 +0100" "<87h9w7hdtg.fsf@topper.koldfront.dk>" "<87d273r1qw.fsf@skimble.plus.com> <87mw678q1f.fsf@topper.koldfront.dk> <871tnbvqzm.fsf@skimble.plus.com>" 4300 25 "news.gmane.org gmane.emacs.gnus.general:85421" nil]))
   ([85422 "Re: How to search inside emails?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Sat, 03 Jan 2015 19:30:13 +0000" "<877fx37jcq.fsf@skimble.plus.com>" "<87d273r1qw.fsf@skimble.plus.com> <87mw678q1f.fsf@topper.koldfront.dk>" 4743 47 "news.gmane.org gmane.emacs.gnus.general:85422" nil]))
  ([85400 "Re: How to search inside emails?" "Steinar Bang <sb@dod.no>" "Mon, 29 Dec 2014 08:32:31 +0100" "<86387yhpww.fsf@dod.no>" "<87d273r1qw.fsf@skimble.plus.com>" 3461 13 "news.gmane.org gmane.emacs.gnus.general:85400" nil]))
 ([85399 "Need help on setting multiple gmail imap account" "Eric <thegreatfq@gmail.com>" "Mon, 29 Dec 2014 01:27:06 +0000 (UTC)" "<loom.20141229T020733-950@post.gmane.org>" "" 5900 34 "news.gmane.org gmane.emacs.gnus.general:85399" nil]
  ([85401 "Re: Need help on setting multiple gmail imap account" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 29 Dec 2014 10:11:10 +0100" "<874mseu8gh.fsf@topper.koldfront.dk>" "<loom.20141229T020733-950@post.gmane.org>" 4382 34 "news.gmane.org gmane.emacs.gnus.general:85401" nil]
   ([85713 "Re: Need help on setting multiple gmail imap account" "Ted Zlatanov <tzz@lifelogs.com>" "Wed, 04 Feb 2015 06:46:52 -0500" "<87wq3xyk43.fsf@lifelogs.com>" "<loom.20141229T020733-950@post.gmane.org> <874mseu8gh.fsf@topper.koldfront.dk>" 4078 25 "news.gmane.org gmane.emacs.gnus.general:85713" nil]
    ([85729 "Re: Need help on setting multiple gmail imap account" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:13:40 +1100" "<871tm5vymz.fsf@building.gnus.org>" "<loom.20141229T020733-950@post.gmane.org> <874mseu8gh.fsf@topper.koldfront.dk> <87wq3xyk43.fsf@lifelogs.com>" 3974 35 "news.gmane.org gmane.emacs.gnus.general:85729" nil]
     ([85750 "Re: Need help on setting multiple gmail imap account" "Ted Zlatanov <tzz@lifelogs.com>" "Thu, 05 Feb 2015 05:52:28 -0500" "<87oap8wryr.fsf@lifelogs.com>" "<loom.20141229T020733-950@post.gmane.org> <874mseu8gh.fsf@topper.koldfront.dk> <87wq3xyk43.fsf@lifelogs.com> <871tm5vymz.fsf@building.gnus.org>" 3652 13 "news.gmane.org gmane.emacs.gnus.general:85750" nil]))
    ([85752 "Re: Need help on setting multiple gmail imap account" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 05 Feb 2015 16:51:00 +0100" "<8761bg5pcr.fsf@topper.koldfront.dk>" "<loom.20141229T020733-950@post.gmane.org> <874mseu8gh.fsf@topper.koldfront.dk> <87wq3xyk43.fsf@lifelogs.com>" 4099 25 "news.gmane.org gmane.emacs.gnus.general:85752" nil]))))
 ([85402 "choosing iso-8859-1 over utf-8 for some newsgroups" "Julien Cubizolles <j.cubizolles@free.fr>" "Mon, 29 Dec 2014 17:21:47 +0100" "<87ppb2a0kk.fsf@free.fr>" "" 3973 28 "news.gmane.org gmane.emacs.gnus.general:85402" nil]
  ([85403 "Re: choosing iso-8859-1 over utf-8 for some newsgroups" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 29 Dec 2014 18:35:35 +0100" "<87oaqms6jc.fsf@topper.koldfront.dk>" "<87ppb2a0kk.fsf@free.fr>" 4162 28 "news.gmane.org gmane.emacs.gnus.general:85403" nil]
   ([85404 "Re: choosing iso-8859-1 over utf-8 for some newsgroups" "Julien Cubizolles <j.cubizolles@free.fr>" "Tue, 30 Dec 2014 00:11:12 +0100" "<87sifyvypb.fsf@free.fr>" "<87ppb2a0kk.fsf@free.fr> <87oaqms6jc.fsf@topper.koldfront.dk>" 4570 41 "news.gmane.org gmane.emacs.gnus.general:85404" nil]
    ([85411 "Re: choosing iso-8859-1 over utf-8 for some newsgroups" "Malcolm Purvis <malcolmp@xemacs.org>" "Thu, 01 Jan 2015 17:20:46 +1100" "<m2vbkrauo1.fsf@xemacs.org>" "<87ppb2a0kk.fsf@free.fr> <87oaqms6jc.fsf@topper.koldfront.dk> <87sifyvypb.fsf@free.fr>" 4063 30 "news.gmane.org gmane.emacs.gnus.general:85411" nil]))))
 ([85405 "Trouble viewing PDF attachments (with patches)" "peder@news.klingenberg.no (Peder O. Klingenberg)" "Tue, 30 Dec 2014 12:35:40 +0100" "<kssifxl69f.fsf@luna.netfonds.no>" "" 9027 174 "news.gmane.org gmane.emacs.gnus.general:85405" nil]
  ([85406 "Re: Trouble viewing PDF attachments (with patches)" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 31 Dec 2014 09:20:22 +0800" "<87iogszkbt.fsf@ericabrahamsen.net>" "<kssifxl69f.fsf@luna.netfonds.no>" 5363 51 "news.gmane.org gmane.emacs.gnus.general:85406" nil]
   ([85407 "Re: Trouble viewing PDF attachments (with patches)" "peder@news.klingenberg.no (Peder O. Klingenberg)" "Wed, 31 Dec 2014 10:16:33 +0100" "<ks1tngji1a.fsf@luna.netfonds.no>" "<kssifxl69f.fsf@luna.netfonds.no> <87iogszkbt.fsf@ericabrahamsen.net>" 3807 22 "news.gmane.org gmane.emacs.gnus.general:85407" nil]
    ([85408 "Re: Trouble viewing PDF attachments (with patches)" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 31 Dec 2014 18:29:53 +0800" "<87a924xgbi.fsf@ericabrahamsen.net>" "<kssifxl69f.fsf@luna.netfonds.no> <87iogszkbt.fsf@ericabrahamsen.net> <ks1tngji1a.fsf@luna.netfonds.no>" 3941 24 "news.gmane.org gmane.emacs.gnus.general:85408" nil]
     ([85409 "Re: Trouble viewing PDF attachments (with patches)" "peder@news.klingenberg.no (Peder O. Klingenberg)" "Wed, 31 Dec 2014 15:04:18 +0100" "<kssifvj4pp.fsf@luna.netfonds.no>" "<kssifxl69f.fsf@luna.netfonds.no> <87iogszkbt.fsf@ericabrahamsen.net> <ks1tngji1a.fsf@luna.netfonds.no> <87a924xgbi.fsf@ericabrahamsen.net>" 3836 23 "news.gmane.org gmane.emacs.gnus.general:85409" nil]))))
  ([85509 "Re: Trouble viewing PDF attachments (with patches)" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:28:02 +1100" "<877fwakypp.fsf@building.gnus.org>" "<kssifxl69f.fsf@luna.netfonds.no>" 3759 23 "news.gmane.org gmane.emacs.gnus.general:85509" nil]))
 ([85412 "fancy splitting interactively" "Uwe Brauer <oub@mat.ucm.es>" "Sat, 03 Jan 2015 11:22:51 +0100" "<87fvbs6u4k.fsf@mat.ucm.es>" "" 13299 147 "news.gmane.org gmane.emacs.gnus.general:85412" nil]
  ([85413 "Re: fancy splitting interactively" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Sat, 3 Jan 2015 10:57:48 +0000" "<87lhlk168j.fsf@ucl.ac.uk>" "<87fvbs6u4k.fsf@mat.ucm.es>" 4955 24 "news.gmane.org gmane.emacs.gnus.general:85413" nil]
   ([85415 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Sat, 03 Jan 2015 21:53:28 +0800" "<871tncvulj.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk>" 3676 25 "news.gmane.org gmane.emacs.gnus.general:85415" nil]
    ([85418 "Re: fancy splitting interactively" "Uwe Brauer <oub@mat.ucm.es>" "Sat, 03 Jan 2015 18:43:06 +0100" "<877fx37ob9.fsf@mat.ucm.es>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net>" 12808 160 "news.gmane.org gmane.emacs.gnus.general:85418" nil]
     ([85425 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Sun, 04 Jan 2015 11:12:54 +0800" "<87k313utl5.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es>" 5219 59 "news.gmane.org gmane.emacs.gnus.general:85425" nil]
      ([85429 "Re: fancy splitting interactively" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Mon, 5 Jan 2015 12:31:53 +0000" "<874ms54ddy.fsf@ucl.ac.uk>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net>" 5706 30 "news.gmane.org gmane.emacs.gnus.general:85429" nil]
       ([85430 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Mon, 05 Jan 2015 22:34:15 +0800" "<87mw5x70uw.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk>" 4679 35 "news.gmane.org gmane.emacs.gnus.general:85430" nil]
        ([85431 "Re: fancy splitting interactively" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Mon, 5 Jan 2015 15:30:48 +0000" "<87mw5x2qjb.fsf@ucl.ac.uk>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net>" 5110 19 "news.gmane.org gmane.emacs.gnus.general:85431" nil]
         ([85432 "Re: fancy splitting interactively" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 05 Jan 2015 20:23:10 +0100" "<878uhhvxpd.fsf@topper.koldfront.dk>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk>" 4327 26 "news.gmane.org gmane.emacs.gnus.general:85432" nil]
          ([85433 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 06 Jan 2015 09:25:58 +0800" "<877fx07l95.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk>" 4623 36 "news.gmane.org gmane.emacs.gnus.general:85433" nil]
           ([85434 "Re: fancy splitting interactively" "Russ Allbery <eagle@eyrie.org>" "Mon, 05 Jan 2015 21:35:13 -0800" "<87r3v8o4j2.fsf@hope.eyrie.org>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <877fx07l95.fsf@ericabrahamsen.net>" 4008 22 "news.gmane.org gmane.emacs.gnus.general:85434" nil]
            ([85435 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 06 Jan 2015 14:34:20 +0800" "<87lhlgxvrn.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <877fx07l95.fsf@ericabrahamsen.net> <87r3v8o4j2.fsf@hope.eyrie.org>" 5260 43 "news.gmane.org gmane.emacs.gnus.general:85435" nil]
             ([85436 "Re: fancy splitting interactively" "Russ Allbery <eagle@eyrie.org>" "Mon, 05 Jan 2015 22:39:50 -0800" "<87zj9wmmyx.fsf@hope.eyrie.org>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <877fx07l95.fsf@ericabrahamsen.net> <87r3v8o4j2.fsf@hope.eyrie.org> <87lhlgxvrn.fsf@ericabrahamsen.net>" 5821 65 "news.gmane.org gmane.emacs.gnus.general:85436" nil]
              ([85437 "Re: fancy splitting interactively" "Glyn Millington <glyn.millington@gmail.com>" "Tue, 06 Jan 2015 07:27:14 +0000" "<87ppasgyi5.fsf@nowhere.org>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <877fx07l95.fsf@ericabrahamsen.net> <87r3v8o4j2.fsf@hope.eyrie.org> <87lhlgxvrn.fsf@ericabrahamsen.net> <87zj9wmmyx.fsf@hope.eyrie.org>" 6817 79 "news.gmane.org gmane.emacs.gnus.general:85437" nil]
               ([85457 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Fri, 09 Jan 2015 11:01:56 +0800" "<87y4pcmzbv.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <877fx07l95.fsf@ericabrahamsen.net> <87r3v8o4j2.fsf@hope.eyrie.org> <87lhlgxvrn.fsf@ericabrahamsen.net> <87zj9wmmyx.fsf@hope.eyrie.org> <87ppasgyi5.fsf@nowhere.org>" 6593 80 "news.gmane.org gmane.emacs.gnus.general:85457" nil]))
              ([85458 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Fri, 09 Jan 2015 11:00:39 +0800" "<87387kodyg.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <877fx07l95.fsf@ericabrahamsen.net> <87r3v8o4j2.fsf@hope.eyrie.org> <87lhlgxvrn.fsf@ericabrahamsen.net> <87zj9wmmyx.fsf@hope.eyrie.org>" 6534 73 "news.gmane.org gmane.emacs.gnus.general:85458" nil]))))
           ([85438 "Re: fancy splitting interactively" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 6 Jan 2015 18:05:25 +0000" "<87y4pfeqe2.fsf@ucl.ac.uk>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <877fx07l95.fsf@ericabrahamsen.net>" 5698 30 "news.gmane.org gmane.emacs.gnus.general:85438" nil]
            ([85439 "Re: fancy splitting interactively" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 6 Jan 2015 18:20:29 +0000" "<87lhlfepoy.fsf@ucl.ac.uk>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <877fx07l95.fsf@ericabrahamsen.net> <87y4pfeqe2.fsf@ucl.ac.uk>" 5114 16 "news.gmane.org gmane.emacs.gnus.general:85439" nil])
            ([85441 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 07 Jan 2015 09:28:30 +0800" "<87fvbnwf9d.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <877fx07l95.fsf@ericabrahamsen.net> <87y4pfeqe2.fsf@ucl.ac.uk>" 4516 34 "news.gmane.org gmane.emacs.gnus.general:85441" nil])))
          ([85442 "Re: fancy splitting interactively" "Julien Cubizolles <j.cubizolles@free.fr>" "Wed, 07 Jan 2015 07:21:57 +0100" "<87y4pfm7p6.fsf@free.fr>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk>" 3946 16 "news.gmane.org gmane.emacs.gnus.general:85442" nil]
           ([85443 "Re: fancy splitting interactively" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 07 Jan 2015 18:12:45 +0800" "<87iogiucf6.fsf@ericabrahamsen.net>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <87y4pfm7p6.fsf@free.fr>" 3975 21 "news.gmane.org gmane.emacs.gnus.general:85443" nil]
            ([85484 "Re: fancy splitting interactively" "Julien Cubizolles <j.cubizolles@free.fr>" "Wed, 14 Jan 2015 11:27:09 +0100" "<87egqx7j42.fsf@free.fr>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <87y4pfm7p6.fsf@free.fr> <87iogiucf6.fsf@ericabrahamsen.net>" 3584 10 "news.gmane.org gmane.emacs.gnus.general:85484" nil]))
           ([85447 "Re: fancy splitting interactively" "asjo@koldfront.dk (Adam Sjøgren)" "Wed, 07 Jan 2015 20:46:33 +0100" "<87wq4yjrvq.fsf@topper.koldfront.dk>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <87y4pfm7p6.fsf@free.fr>" 4481 29 "news.gmane.org gmane.emacs.gnus.general:85447" nil]
            ([85483 "Re: fancy splitting interactively" "Julien Cubizolles <j.cubizolles@free.fr>" "Wed, 14 Jan 2015 11:27:37 +0100" "<87a91l7j3a.fsf@free.fr>" "<87fvbs6u4k.fsf@mat.ucm.es> <87lhlk168j.fsf@ucl.ac.uk> <871tncvulj.fsf@ericabrahamsen.net> <877fx37ob9.fsf@mat.ucm.es> <87k313utl5.fsf@ericabrahamsen.net> <874ms54ddy.fsf@ucl.ac.uk> <87mw5x70uw.fsf@ericabrahamsen.net> <87mw5x2qjb.fsf@ucl.ac.uk> <878uhhvxpd.fsf@topper.koldfront.dk> <87y4pfm7p6.fsf@free.fr> <87wq4yjrvq.fsf@topper.koldfront.dk>" 3682 16 "news.gmane.org gmane.emacs.gnus.general:85483" nil])))))))))))
  ([85414 "Re: fancy splitting interactively" "Glyn Millington <glyn.millington@gmail.com>" "Sat, 03 Jan 2015 10:39:10 +0000" "<87k314up0x.fsf@nowhere.org>" "<87fvbs6u4k.fsf@mat.ucm.es>" 3926 34 "news.gmane.org gmane.emacs.gnus.general:85414" nil])
  ([85416 "Re: fancy splitting interactively" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 03 Jan 2015 15:48:24 +0100" "<87tx07j4xz.fsf@topper.koldfront.dk>" "<87fvbs6u4k.fsf@mat.ucm.es>" 5314 58 "news.gmane.org gmane.emacs.gnus.general:85416" nil]
   ([85417 "Re: fancy splitting interactively" "Uwe Brauer <oub@mat.ucm.es>" "Sat, 03 Jan 2015 18:38:24 +0100" "<87bnmf7oj3.fsf@mat.ucm.es>" "<87fvbs6u4k.fsf@mat.ucm.es> <87tx07j4xz.fsf@topper.koldfront.dk>" 13256 137 "news.gmane.org gmane.emacs.gnus.general:85417" nil]
    ([85419 "Re: fancy splitting interactively" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 03 Jan 2015 18:51:01 +0100" "<87lhljhhx6.fsf@topper.koldfront.dk>" "<87fvbs6u4k.fsf@mat.ucm.es> <87tx07j4xz.fsf@topper.koldfront.dk> <87bnmf7oj3.fsf@mat.ucm.es>" 3913 19 "news.gmane.org gmane.emacs.gnus.general:85419" nil]
     ([85423 "Re: fancy splitting interactively" "Uwe Brauer <oub@mat.ucm.es>" "Sat, 03 Jan 2015 23:49:49 +0100" "<87mw5zqy2a.fsf@mat.ucm.es>" "<87fvbs6u4k.fsf@mat.ucm.es> <87tx07j4xz.fsf@topper.koldfront.dk> <87bnmf7oj3.fsf@mat.ucm.es> <87lhljhhx6.fsf@topper.koldfront.dk>" 12215 142 "news.gmane.org gmane.emacs.gnus.general:85423" nil])
     ([85427 "[bug] (was: fancy splitting interactively)" "Uwe Brauer <oub@mat.ucm.es>" "Sun, 04 Jan 2015 15:56:58 +0100" "<878uhiiog5.fsf_-_@mat.ucm.es>" "<87fvbs6u4k.fsf@mat.ucm.es> <87tx07j4xz.fsf@topper.koldfront.dk> <87bnmf7oj3.fsf@mat.ucm.es> <87lhljhhx6.fsf@topper.koldfront.dk>" 15048 157 "news.gmane.org gmane.emacs.gnus.general:85427" nil]
      ([85508 "Re: [bug]" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 14:15:22 +1100" "<87iofukzat.fsf@building.gnus.org>" "<87fvbs6u4k.fsf@mat.ucm.es> <87tx07j4xz.fsf@topper.koldfront.dk> <87bnmf7oj3.fsf@mat.ucm.es> <87lhljhhx6.fsf@topper.koldfront.dk> <878uhiiog5.fsf_-_@mat.ucm.es>" 3569 20 "news.gmane.org gmane.emacs.gnus.general:85508" nil]))))))
 ([85424 "IMAP time out" "Kete Foy <kete@ninthfloor.org>" "Sat, 03 Jan 2015 20:24:01 -0500" "<54A89631.3090900@ninthfloor.org>" "" 2878 12 "news.gmane.org gmane.emacs.gnus.general:85424" nil]
  ([85426 "Re: IMAP time out" "Steinar Bang <sb@dod.no>" "Sun, 04 Jan 2015 09:23:49 +0100" "<upzck31354yy.fsf@dod.no>" "<54A89631.3090900@ninthfloor.org>" 3646 22 "news.gmane.org gmane.emacs.gnus.general:85426" nil]))
 ([85440 "Performance problem of imap move" "mremond@process-one.net (Mickaël Rémond)" "Tue, 06 Jan 2015 20:06:47 +0100" "<m2bnmbk9tk.fsf@process-one.net>" "" 5253 39 "news.gmane.org gmane.emacs.gnus.general:85440" nil]
  ([85496 "Re: Performance problem of imap move" "mremond@process-one.net (Mickaël Rémond)" "Wed, 21 Jan 2015 15:11:44 +0100" "<m2vbk0mden.fsf@process-one.net>" "<m2bnmbk9tk.fsf@process-one.net>" 4610 26 "news.gmane.org gmane.emacs.gnus.general:85496" nil]
   ([85506 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Sun, 25 Jan 2015 15:57:23 +1100" "<87oapn5ufg.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net>" 3767 25 "news.gmane.org gmane.emacs.gnus.general:85506" nil]
    ([85507 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 13:52:46 +1100" "<87vbjul0ch.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org>" 3130 13 "news.gmane.org gmane.emacs.gnus.general:85507" nil]
     ([85532 "Re: Performance problem of imap move" "Tassilo Horn <tsdh@gnu.org>" "Mon, 26 Jan 2015 13:11:24 +0100" "<87siex213n.fsf@gnu.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org>" 3789 27 "news.gmane.org gmane.emacs.gnus.general:85532" nil]
      ([85535 "Re: Performance problem of imap move" "Steinar Bang <sb@dod.no>" "Mon, 26 Jan 2015 17:55:25 +0100" "<upzc8ugpzdky.fsf@dod.no>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org>" 3470 10 "news.gmane.org gmane.emacs.gnus.general:85535" nil])
      ([85539 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 11:54:15 +1100" "<87mw55dow8.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org>" 3967 27 "news.gmane.org gmane.emacs.gnus.general:85539" nil]
       ([85579 "Re: Performance problem of imap move" "Tassilo Horn <tsdh@gnu.org>" "Tue, 27 Jan 2015 08:23:42 +0100" "<87mw54ptz5.fsf@gnu.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87mw55dow8.fsf@building.gnus.org>" 3867 28 "news.gmane.org gmane.emacs.gnus.general:85579" nil]
        ([85580 "Re: Performance problem of imap move" "Tassilo Horn <tsdh@gnu.org>" "Tue, 27 Jan 2015 08:28:52 +0100" "<87iofsptqj.fsf@gnu.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87mw55dow8.fsf@building.gnus.org> <87mw54ptz5.fsf@gnu.org>" 3526 20 "news.gmane.org gmane.emacs.gnus.general:85580" nil])
        ([85581 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 18:30:34 +1100" "<87mw547k9x.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87mw55dow8.fsf@building.gnus.org> <87mw54ptz5.fsf@gnu.org>" 3836 24 "news.gmane.org gmane.emacs.gnus.general:85581" nil]
         ([85584 "Re: Performance problem of imap move" "Tassilo Horn <tsdh@gnu.org>" "Tue, 27 Jan 2015 09:01:30 +0100" "<878ugops85.fsf@gnu.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87mw55dow8.fsf@building.gnus.org> <87mw54ptz5.fsf@gnu.org> <87mw547k9x.fsf@building.gnus.org>" 3953 31 "news.gmane.org gmane.emacs.gnus.general:85584" nil]
          ([85585 "Re: Performance problem of imap move" "Tassilo Horn <tsdh@gnu.org>" "Tue, 27 Jan 2015 09:05:37 +0100" "<874mrcps1a.fsf@gnu.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87mw55dow8.fsf@building.gnus.org> <87mw54ptz5.fsf@gnu.org> <87mw547k9x.fsf@building.gnus.org> <878ugops85.fsf@gnu.org>" 4473 40 "news.gmane.org gmane.emacs.gnus.general:85585" nil]
           ([85594 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 11:45:00 +1100" "<87r3uf20oj.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87mw55dow8.fsf@building.gnus.org> <87mw54ptz5.fsf@gnu.org> <87mw547k9x.fsf@building.gnus.org> <878ugops85.fsf@gnu.org> <874mrcps1a.fsf@gnu.org>" 4392 37 "news.gmane.org gmane.emacs.gnus.general:85594" nil]))))))
      ([85556 "Re: Performance problem of imap move" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 27 Jan 2015 11:46:11 +0800" "<87oapkrim4.fsf@ericabrahamsen.net>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org>" 6162 43 "news.gmane.org gmane.emacs.gnus.general:85556" nil]
       ([85559 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 15:48:00 +1100" "<874mrcbzi7.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net>" 3343 13 "news.gmane.org gmane.emacs.gnus.general:85559" nil]
        ([85561 "Re: Performance problem of imap move" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 27 Jan 2015 13:02:50 +0800" "<87ppa0q0hx.fsf@ericabrahamsen.net>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org>" 5152 18 "news.gmane.org gmane.emacs.gnus.general:85561" nil]
         ([85565 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 16:09:30 +1100" "<87lhkoajxx.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net>" 3587 18 "news.gmane.org gmane.emacs.gnus.general:85565" nil]
          ([85590 "Re: Performance problem of imap move" "Steinar Bang <sb@dod.no>" "Tue, 27 Jan 2015 15:41:57 +0100" "<upzc7fw8xp3e.fsf@dod.no>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org>" 3507 9 "news.gmane.org gmane.emacs.gnus.general:85590" nil]
           ([85598 "Re: Performance problem of imap move" "david.goldberg6@verizon.net (Dave Goldberg)" "Tue, 27 Jan 2015 21:06:06 -0500" "<84twzb64mp.fsf@davestoy.home>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org> <upzc7fw8xp3e.fsf@dod.no>" 5457 34 "news.gmane.org gmane.emacs.gnus.general:85598" nil]
            ([85651 "Re: Performance problem of imap move" "david.goldberg6@verizon.net (Dave Goldberg)" "Thu, 29 Jan 2015 00:11:33 -0500" "<841tme5fy2.fsf@davestoy.home>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org> <upzc7fw8xp3e.fsf@dod.no> <84twzb64mp.fsf@davestoy.home>" 5027 38 "news.gmane.org gmane.emacs.gnus.general:85651" nil])))
          ([85600 "Re: Performance problem of imap move" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 28 Jan 2015 10:29:20 +0800" "<87a913tz7j.fsf@ericabrahamsen.net>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org>" 7300 58 "news.gmane.org gmane.emacs.gnus.general:85600" nil]
           ([85603 "Re: Performance problem of imap move" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 28 Jan 2015 12:08:05 +0800" "<87fvavsg2i.fsf@ericabrahamsen.net>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org> <87a913tz7j.fsf@ericabrahamsen.net>" 6679 48 "news.gmane.org gmane.emacs.gnus.general:85603" nil]
            ([85604 "Re: Performance problem of imap move" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 28 Jan 2015 12:10:10 +0800" "<87bnljsfz1.fsf@ericabrahamsen.net>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org> <87a913tz7j.fsf@ericabrahamsen.net> <87fvavsg2i.fsf@ericabrahamsen.net>" 6915 51 "news.gmane.org gmane.emacs.gnus.general:85604" nil]
             ([85606 "Re: Performance problem of imap move" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 28 Jan 2015 12:32:58 +0800" "<877fw7sex1.fsf@ericabrahamsen.net>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org> <87a913tz7j.fsf@ericabrahamsen.net> <87fvavsg2i.fsf@ericabrahamsen.net> <87bnljsfz1.fsf@ericabrahamsen.net>" 8753 91 "news.gmane.org gmane.emacs.gnus.general:85606" nil]
              ([85607 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 16:08:10 +1100" "<87twzbxzk5.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org> <87a913tz7j.fsf@ericabrahamsen.net> <87fvavsg2i.fsf@ericabrahamsen.net> <87bnljsfz1.fsf@ericabrahamsen.net> <877fw7sex1.fsf@ericabrahamsen.net>" 3756 20 "news.gmane.org gmane.emacs.gnus.general:85607" nil]
               ([85608 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 16:13:18 +1100" "<87pp9zxzbl.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org> <87a913tz7j.fsf@ericabrahamsen.net> <87fvavsg2i.fsf@ericabrahamsen.net> <87bnljsfz1.fsf@ericabrahamsen.net> <877fw7sex1.fsf@ericabrahamsen.net> <87twzbxzk5.fsf@building.gnus.org>" 3643 13 "news.gmane.org gmane.emacs.gnus.general:85608" nil]
                ([85614 "Re: Performance problem of imap move" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 28 Jan 2015 13:52:35 +0800" "<87iofr8na4.fsf@ericabrahamsen.net>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org> <87a913tz7j.fsf@ericabrahamsen.net> <87fvavsg2i.fsf@ericabrahamsen.net> <87bnljsfz1.fsf@ericabrahamsen.net> <877fw7sex1.fsf@ericabrahamsen.net> <87twzbxzk5.fsf@building.gnus.org> <87pp9zxzbl.fsf@building.gnus.org>" 5311 15 "news.gmane.org gmane.emacs.gnus.general:85614" nil])
                ([85629 "Re: Performance problem of imap move" "Tassilo Horn <tsdh@gnu.org>" "Wed, 28 Jan 2015 15:22:07 +0100" "<87iofr0yuo.fsf@gnu.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org> <87a913tz7j.fsf@ericabrahamsen.net> <87fvavsg2i.fsf@ericabrahamsen.net> <87bnljsfz1.fsf@ericabrahamsen.net> <877fw7sex1.fsf@ericabrahamsen.net> <87twzbxzk5.fsf@building.gnus.org> <87pp9zxzbl.fsf@building.gnus.org>" 3660 16 "news.gmane.org gmane.emacs.gnus.general:85629" nil]
                 ([85639 "Re: Performance problem of imap move" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 12:08:05 +1100" "<874mrapf62.fsf@building.gnus.org>" "<m2bnmbk9tk.fsf@process-one.net> <m2vbk0mden.fsf@process-one.net> <87oapn5ufg.fsf@building.gnus.org> <87vbjul0ch.fsf@building.gnus.org> <87siex213n.fsf@gnu.org> <87oapkrim4.fsf@ericabrahamsen.net> <874mrcbzi7.fsf@building.gnus.org> <87ppa0q0hx.fsf@ericabrahamsen.net> <87lhkoajxx.fsf@building.gnus.org> <87a913tz7j.fsf@ericabrahamsen.net> <87fvavsg2i.fsf@ericabrahamsen.net> <87bnljsfz1.fsf@ericabrahamsen.net> <877fw7sex1.fsf@ericabrahamsen.net> <87twzbxzk5.fsf@building.gnus.org> <87pp9zxzbl.fsf@building.gnus.org> <87iofr0yuo.fsf@gnu.org>" 3931 21 "news.gmane.org gmane.emacs.gnus.general:85639" nil])))))))))))))))))
 ([85444 "saving \"sent\" to just one folder?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Wed, 07 Jan 2015 13:26:44 +0000" "<87lhleyb57.fsf@skimble.plus.com>" "" 4906 55 "news.gmane.org gmane.emacs.gnus.general:85444" nil]
  ([85446 "Re: saving \"sent\" to just one folder?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Wed, 7 Jan 2015 15:02:27 +0000" "<874ms2y6po.fsf@ucl.ac.uk>" "<87lhleyb57.fsf@skimble.plus.com>" 5290 25 "news.gmane.org gmane.emacs.gnus.general:85446" nil]))
 ([85448 "Sorting threaded articles on top of summary" "Ivan Kanis <ivan@kanis.fr>" "Thu, 08 Jan 2015 09:11:36 +0100" "<87a91tpu87.fsf@kanis.fr>" "" 5871 41 "news.gmane.org gmane.emacs.gnus.general:85448" nil]
  ([85451 "Re: Sorting threaded articles on top of summary" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Thu, 8 Jan 2015 16:20:41 +0000" "<87wq4xfdly.fsf@ucl.ac.uk>" "<87a91tpu87.fsf@kanis.fr>" 5289 21 "news.gmane.org gmane.emacs.gnus.general:85451" nil]))
 ([85449 "local mailing list? I think so, but how?" "Sharon Kimble <boudiccas@skimble.plus.com>" "Thu, 08 Jan 2015 15:22:38 +0000" "<871tn547r5.fsf@skimble.plus.com>" "" 5173 56 "news.gmane.org gmane.emacs.gnus.general:85449" nil]
  ([85452 "Re: local mailing list? I think so, but how?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Thu, 8 Jan 2015 16:26:27 +0000" "<87siflfdcc.fsf@ucl.ac.uk>" "<871tn547r5.fsf@skimble.plus.com>" 5009 16 "news.gmane.org gmane.emacs.gnus.general:85452" nil]))
 ([85450 "Gnus attempting to move mail from /var/spool/mail" "Harry Putnam <reader@newsguy.com>" "Thu, 08 Jan 2015 10:42:57 -0500" "<87wq4x9t32.fsf@reader.local.lan>" "" 8202 124 "news.gmane.org gmane.emacs.gnus.general:85450" nil]
  ([85453 "Re: Gnus attempting to move mail from /var/spool/mail" "Dan Christensen <jdc@uwo.ca>" "Thu, 08 Jan 2015 13:10:33 -0500" "<878uhdqh2e.fsf@uwo.ca>" "<87wq4x9t32.fsf@reader.local.lan>" 3355 13 "news.gmane.org gmane.emacs.gnus.general:85453" nil]
   ([85456 "Re: Gnus attempting to move mail from /var/spool/mail" "Harry Putnam <reader@newsguy.com>" "Thu, 08 Jan 2015 21:35:14 -0500" "<874ms0r89p.fsf@reader.local.lan>" "<87wq4x9t32.fsf@reader.local.lan> <878uhdqh2e.fsf@uwo.ca>" 3819 24 "news.gmane.org gmane.emacs.gnus.general:85456" nil]
    ([85460 "Re: Gnus attempting to move mail from /var/spool/mail" "asjo@koldfront.dk (Adam Sjøgren)" "Fri, 09 Jan 2015 20:19:47 +0100" "<87ppanvk18.fsf@topper.koldfront.dk>" "<87wq4x9t32.fsf@reader.local.lan> <878uhdqh2e.fsf@uwo.ca> <874ms0r89p.fsf@reader.local.lan>" 4360 30 "news.gmane.org gmane.emacs.gnus.general:85460" nil]
     ([85462 "Re: Gnus attempting to move mail from /var/spool/mail" "Harry Putnam <reader@newsguy.com>" "Sun, 11 Jan 2015 09:42:42 -0500" "<871tn1pee5.fsf@reader.local.lan>" "<87wq4x9t32.fsf@reader.local.lan> <878uhdqh2e.fsf@uwo.ca> <874ms0r89p.fsf@reader.local.lan> <87ppanvk18.fsf@topper.koldfront.dk>" 3973 25 "news.gmane.org gmane.emacs.gnus.general:85462" nil]
      ([85464 "Re: Gnus attempting to move mail from /var/spool/mail" "asjo@koldfront.dk (Adam Sjøgren)" "Sun, 11 Jan 2015 15:48:19 +0100" "<87vbkdnzkc.fsf@topper.koldfront.dk>" "<87wq4x9t32.fsf@reader.local.lan> <878uhdqh2e.fsf@uwo.ca> <874ms0r89p.fsf@reader.local.lan> <87ppanvk18.fsf@topper.koldfront.dk> <871tn1pee5.fsf@reader.local.lan>" 3895 17 "news.gmane.org gmane.emacs.gnus.general:85464" nil])))))
  ([85454 "Re: Gnus attempting to move mail from /var/spool/mail" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 08 Jan 2015 20:38:48 +0100" "<87mw5t3vw7.fsf@topper.koldfront.dk>" "<87wq4x9t32.fsf@reader.local.lan>" 3799 18 "news.gmane.org gmane.emacs.gnus.general:85454" nil]
   ([85455 "Re: Gnus attempting to move mail from /var/spool/mail" "Harry Putnam <reader@newsguy.com>" "Thu, 08 Jan 2015 21:22:38 -0500" "<87d26oae1d.fsf@reader.local.lan>" "<87wq4x9t32.fsf@reader.local.lan> <87mw5t3vw7.fsf@topper.koldfront.dk>" 3440 14 "news.gmane.org gmane.emacs.gnus.general:85455" nil]
    ([85459 "Re: Gnus attempting to move mail from /var/spool/mail" "asjo@koldfront.dk (Adam Sjøgren)" "Fri, 09 Jan 2015 20:11:15 +0100" "<871tn3wyzw.fsf@topper.koldfront.dk>" "<87wq4x9t32.fsf@reader.local.lan> <87mw5t3vw7.fsf@topper.koldfront.dk> <87d26oae1d.fsf@reader.local.lan>" 4099 27 "news.gmane.org gmane.emacs.gnus.general:85459" nil]
     ([85463 "Re: Gnus attempting to move mail from /var/spool/mail" "Harry Putnam <reader@newsguy.com>" "Sun, 11 Jan 2015 09:43:51 -0500" "<87wq4tnzrs.fsf@reader.local.lan>" "<87wq4x9t32.fsf@reader.local.lan> <87mw5t3vw7.fsf@topper.koldfront.dk> <87d26oae1d.fsf@reader.local.lan> <871tn3wyzw.fsf@topper.koldfront.dk>" 3782 24 "news.gmane.org gmane.emacs.gnus.general:85463" nil])))))
 ([85465 "[OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Harry Putnam <reader@newsguy.com>" "Sun, 11 Jan 2015 09:55:40 -0500" "<87sifhnz83.fsf@reader.local.lan>" "" 3810 24 "news.gmane.org gmane.emacs.gnus.general:85465" nil]
  ([85466 "Re: [OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Andreas Schwab <schwab@linux-m68k.org>" "Sun, 11 Jan 2015 17:12:41 +0100" "<87387hthxi.fsf@igel.home>" "<87sifhnz83.fsf@reader.local.lan>" 3773 14 "news.gmane.org gmane.emacs.gnus.general:85466" nil]
   ([85470 "Re: [OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Harry Putnam <reader@newsguy.com>" "Sun, 11 Jan 2015 16:31:02 -0500" "<87lhl9m2cp.fsf@reader.local.lan>" "<87sifhnz83.fsf@reader.local.lan> <87387hthxi.fsf@igel.home>" 3514 16 "news.gmane.org gmane.emacs.gnus.general:85470" nil])
   ([85471 "Re: [OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Harry Putnam <reader@newsguy.com>" "Sun, 11 Jan 2015 16:37:44 -0500" "<87h9vxm21j.fsf@reader.local.lan>" "<87sifhnz83.fsf@reader.local.lan> <87387hthxi.fsf@igel.home>" 5328 59 "news.gmane.org gmane.emacs.gnus.general:85471" nil]))
  ([85472 "Re: [OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Mike Kupfer <m.kupfer@acm.org>" "Sun, 11 Jan 2015 19:39:28 -0800" "<26348.1421033968@allegro.localdomain>" "<87sifhnz83.fsf@reader.local.lan>" 3885 32 "news.gmane.org gmane.emacs.gnus.general:85472" nil]
   ([85481 "Re: [OT ssh -Y] Attempting to start emacsclient .. unusual error?" "Harry Putnam <reader@newsguy.com>" "Mon, 12 Jan 2015 13:39:43 -0500" "<87k30r93k9.fsf@reader.local.lan>" "<87sifhnz83.fsf@reader.local.lan> <26348.1421033968@allegro.localdomain>" 4210 31 "news.gmane.org gmane.emacs.gnus.general:85481" nil])))
 ([85467 "Article mode for raw email message?" "Peter Davis <pfd@pfdstudio.com>" "Sun, 11 Jan 2015 14:10:36 -0500" "<m2ppal5e1f.fsf@PFDStudio-Air.home>" "" 3512 19 "news.gmane.org gmane.emacs.gnus.general:85467" nil]
  ([85468 "Re: Article mode for raw email message?" "david.goldberg6@verizon.net (Dave Goldberg)" "Sun, 11 Jan 2015 14:34:27 -0500" "<84mw5paz7g.fsf@davestoy.home>" "<m2ppal5e1f.fsf@PFDStudio-Air.home>" 3977 19 "news.gmane.org gmane.emacs.gnus.general:85468" nil]
   ([85474 "Re: Article mode for raw email message?" "Peter Davis <pfd@pfdstudio.com>" "Mon, 12 Jan 2015 07:20:19 -0500" "<m2iogc5gxo.fsf@PFDStudio-Air.home>" "<m2ppal5e1f.fsf@PFDStudio-Air.home> <84mw5paz7g.fsf@davestoy.home>" 4487 27 "news.gmane.org gmane.emacs.gnus.general:85474" nil]))
  ([85469 "Re: Article mode for raw email message?" "asjo@koldfront.dk (Adam Sjøgren)" "Sun, 11 Jan 2015 20:51:33 +0100" "<87iogdnliy.fsf@topper.koldfront.dk>" "<m2ppal5e1f.fsf@PFDStudio-Air.home>" 4395 40 "news.gmane.org gmane.emacs.gnus.general:85469" nil]
   ([85475 "Re: Article mode for raw email message?" "Peter Davis <pfd@pfdstudio.com>" "Mon, 12 Jan 2015 07:22:34 -0500" "<m2egr05gtx.fsf@PFDStudio-Air.home>" "<m2ppal5e1f.fsf@PFDStudio-Air.home> <87iogdnliy.fsf@topper.koldfront.dk>" 4581 39 "news.gmane.org gmane.emacs.gnus.general:85475" nil]
    ([85476 "Re: Article mode for raw email message?" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 12 Jan 2015 15:23:26 +0100" "<87k30s3wo1.fsf@topper.koldfront.dk>" "<m2ppal5e1f.fsf@PFDStudio-Air.home> <87iogdnliy.fsf@topper.koldfront.dk> <m2egr05gtx.fsf@PFDStudio-Air.home>" 4030 20 "news.gmane.org gmane.emacs.gnus.general:85476" nil]
     ([85477 "Re: Article mode for raw email message?" "Peter Davis <pfd@pfdstudio.com>" "Mon, 12 Jan 2015 09:34:12 -0500" "<m1fvbgjcez.fsf@pdavismbp15.iscinternal.com>" "<m2ppal5e1f.fsf@PFDStudio-Air.home> <87iogdnliy.fsf@topper.koldfront.dk> <m2egr05gtx.fsf@PFDStudio-Air.home> <87k30s3wo1.fsf@topper.koldfront.dk>" 4838 34 "news.gmane.org gmane.emacs.gnus.general:85477" nil]
      ([85478 "Re: Article mode for raw email message?" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 12 Jan 2015 18:43:46 +0100" "<87twzv3ne5.fsf@topper.koldfront.dk>" "<m2ppal5e1f.fsf@PFDStudio-Air.home> <87iogdnliy.fsf@topper.koldfront.dk> <m2egr05gtx.fsf@PFDStudio-Air.home> <87k30s3wo1.fsf@topper.koldfront.dk> <m1fvbgjcez.fsf@pdavismbp15.iscinternal.com>" 4229 23 "news.gmane.org gmane.emacs.gnus.general:85478" nil])))))
  ([85482 "Re: Article mode for raw email message?" "Peter Davis <pfd@pfdstudio.com>" "Tue, 13 Jan 2015 10:22:28 -0500" "<20150113152227.GB33607@pdavismbp15.iscinternal.com>" "<m2ppal5e1f.fsf@PFDStudio-Air.home>" 4625 35 "news.gmane.org gmane.emacs.gnus.general:85482" nil]))
 ([85486 "importing PGP keys" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 20 Jan 2015 18:45:57 +0800" "<87d269ohlm.fsf@ericabrahamsen.net>" "" 3447 15 "news.gmane.org gmane.emacs.gnus.general:85486" nil]
  ([85488 "Re: importing PGP keys" "Greg Troxel <gdt@lexort.com>" "Tue, 20 Jan 2015 05:49:41 -0500" "<smuzj9dhgl6.fsf@linuxpal.mit.edu>" "<87d269ohlm.fsf@ericabrahamsen.net>" 4014 41 "news.gmane.org gmane.emacs.gnus.general:85488" nil]
   ([85491 "Re: importing PGP keys" "Russ Allbery <eagle@eyrie.org>" "Tue, 20 Jan 2015 22:29:10 -0800" "<87mw5csl3d.fsf@hope.eyrie.org>" "<87d269ohlm.fsf@ericabrahamsen.net> <smuzj9dhgl6.fsf@linuxpal.mit.edu>" 3536 21 "news.gmane.org gmane.emacs.gnus.general:85491" nil]
    ([85492 "Re: importing PGP keys" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 21 Jan 2015 15:03:10 +0800" "<877fwghaz5.fsf@ericabrahamsen.net>" "<87d269ohlm.fsf@ericabrahamsen.net> <smuzj9dhgl6.fsf@linuxpal.mit.edu> <87mw5csl3d.fsf@hope.eyrie.org>" 4386 32 "news.gmane.org gmane.emacs.gnus.general:85492" nil]
     ([85493 "Re: importing PGP keys" "Jens Lechtenboerger <jens.lechtenboerger@fsfe.org>" "Wed, 21 Jan 2015 14:03:51 +0100" "<861tmo1e14.fsf@informationelle-selbstbestimmung-im-internet.de>" "<87d269ohlm.fsf@ericabrahamsen.net> <smuzj9dhgl6.fsf@linuxpal.mit.edu> <87mw5csl3d.fsf@hope.eyrie.org> <877fwghaz5.fsf@ericabrahamsen.net>" 4628 36 "news.gmane.org gmane.emacs.gnus.general:85493" nil]
      ([85494 "Re: importing PGP keys" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 21 Jan 2015 21:36:54 +0800" "<87lhkwfe6h.fsf@ericabrahamsen.net>" "<87d269ohlm.fsf@ericabrahamsen.net> <smuzj9dhgl6.fsf@linuxpal.mit.edu> <87mw5csl3d.fsf@hope.eyrie.org> <877fwghaz5.fsf@ericabrahamsen.net> <861tmo1e14.fsf@informationelle-selbstbestimmung-im-internet.de>" 4905 47 "news.gmane.org gmane.emacs.gnus.general:85494" nil]))))))
 ([85487 "problems in sending out emails" "Sharon Kimble <boudiccas@skimble.plus.com>" "Tue, 20 Jan 2015 13:12:26 +0000" "<87egqpy4sl.fsf@skimble.plus.com>" "" 5448 71 "news.gmane.org gmane.emacs.gnus.general:85487" nil]
  ([85489 "Re: problems in sending out emails" "Steinar Bang <sb@dod.no>" "Tue, 20 Jan 2015 18:21:14 +0100" "<upzc3875fjw5.fsf@dod.no>" "<87egqpy4sl.fsf@skimble.plus.com>" 3449 13 "news.gmane.org gmane.emacs.gnus.general:85489" nil])
  ([85490 "Re: problems in sending out emails" "<e.fraga@ucl.ac.uk>" "Tue, 20 Jan 2015 18:03:48 +0000" "<87ppa9qqgr.fsf@ucl.ac.uk>" "<87egqpy4sl.fsf@skimble.plus.com>" 4596 12 "news.gmane.org gmane.emacs.gnus.general:85490" nil]
   ([85502 "Re: problems in sending out emails" "Sharon Kimble <boudiccas@skimble.plus.com>" "Thu, 22 Jan 2015 18:45:02 +0000" "<87egqmac41.fsf@skimble.plus.com>" "<87egqpy4sl.fsf@skimble.plus.com> <87ppa9qqgr.fsf@ucl.ac.uk>" 4539 41 "news.gmane.org gmane.emacs.gnus.general:85502" nil])))
 ([85495 "nnimap: article list is not correct." "Uwe Brauer <oub@mat.ucm.es>" "Wed, 21 Jan 2015 15:07:47 +0100" "<87wq4gz0p8.fsf@mat.ucm.es>" "" 12311 146 "news.gmane.org gmane.emacs.gnus.general:85495" nil]
  ([85497 "Re: nnimap: article list is not correct." "<e.fraga@ucl.ac.uk>" "Wed, 21 Jan 2015 15:41:50 +0000" "<87bnlskuo1.fsf@ucl.ac.uk>" "<87wq4gz0p8.fsf@mat.ucm.es>" 4722 18 "news.gmane.org gmane.emacs.gnus.general:85497" nil]
   ([85498 "Re: nnimap: article list is not correct." "Uwe Brauer <oub@mat.ucm.es>" "Wed, 21 Jan 2015 18:39:53 +0100" "<87oapsc9sm.fsf@mat.ucm.es>" "<87wq4gz0p8.fsf@mat.ucm.es> <87bnlskuo1.fsf@ucl.ac.uk>" 12203 142 "news.gmane.org gmane.emacs.gnus.general:85498" nil]
    ([85500 "Re: nnimap: article list is not correct." "Steinar Bang <sb@dod.no>" "Wed, 21 Jan 2015 22:00:28 +0100" "<upzc61bz4zo3.fsf@dod.no>" "<87wq4gz0p8.fsf@mat.ucm.es> <87bnlskuo1.fsf@ucl.ac.uk> <87oapsc9sm.fsf@mat.ucm.es>" 4226 36 "news.gmane.org gmane.emacs.gnus.general:85500" nil]
     ([85501 "Re: nnimap: article list is not correct." "Uwe Brauer <oub@mat.ucm.es>" "Wed, 21 Jan 2015 23:22:37 +0100" "<87k30fhiz6.fsf@mat.ucm.es>" "<87wq4gz0p8.fsf@mat.ucm.es> <87bnlskuo1.fsf@ucl.ac.uk> <87oapsc9sm.fsf@mat.ucm.es> <upzc61bz4zo3.fsf@dod.no>" 12671 150 "news.gmane.org gmane.emacs.gnus.general:85501" nil])))))
 ([85499 "gmail: can't visited the starred group" "Uwe Brauer <oub@mat.ucm.es>" "Wed, 21 Jan 2015 18:41:46 +0100" "<87k30gc9ph.fsf@mat.ucm.es>" "" 13263 160 "news.gmane.org gmane.emacs.gnus.general:85499" nil]
  ([85505 "Re: gmail: can't visited the starred group" "Lars Ingebrigtsen <larsi@gnus.org>" "Sun, 25 Jan 2015 14:52:32 +1100" "<87wq4b5xfj.fsf@building.gnus.org>" "<87k30gc9ph.fsf@mat.ucm.es>" 3191 14 "news.gmane.org gmane.emacs.gnus.general:85505" nil]
   ([85591 "Re: gmail: can't visited the starred group" "Uwe Brauer <oub@mat.ucm.es>" "Tue, 27 Jan 2015 15:45:18 +0100" "<87egqg470h.fsf@mat.ucm.es>" "<87k30gc9ph.fsf@mat.ucm.es> <87wq4b5xfj.fsf@building.gnus.org>" 12713 156 "news.gmane.org gmane.emacs.gnus.general:85591" nil])))
 ([85503 "Outdated manual on www.gnus.org" "halimsrama@gmail.com (Naim, Halim.)" "Thu, 22 Jan 2015 18:38:20 -0430" "<87y4ouza57.fsf@gmail.com>" "" 3911 13 "news.gmane.org gmane.emacs.gnus.general:85503" nil]
  ([85504 "Re: Outdated manual on www.gnus.org" "Lars Ingebrigtsen <larsi@gnus.org>" "Sun, 25 Jan 2015 14:44:24 +1100" "<87386z7cdj.fsf@building.gnus.org>" "<87y4ouza57.fsf@gmail.com>" 3707 12 "news.gmane.org gmane.emacs.gnus.general:85504" nil]))
 ([85592 "How do I make a new message html washer?" "joakim@verona.se" "Tue, 27 Jan 2015 20:02:07 +0100" "<m361bsoxn4.fsf@exodia.verona.se>" "" 3232 10 "news.gmane.org gmane.emacs.gnus.general:85592" nil]
  ([85593 "Re: How do I make a new message html washer?" "Andreas Schwab <schwab@linux-m68k.org>" "Tue, 27 Jan 2015 22:20:48 +0100" "<87386v9az3.fsf@igel.home>" "<m361bsoxn4.fsf@exodia.verona.se>" 4083 18 "news.gmane.org gmane.emacs.gnus.general:85593" nil]
   ([85596 "Re: How do I make a new message html washer?" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 11:48:31 +1100" "<87iofr20io.fsf@building.gnus.org>" "<m361bsoxn4.fsf@exodia.verona.se> <87386v9az3.fsf@igel.home>" 3510 19 "news.gmane.org gmane.emacs.gnus.general:85596" nil])))
 ([85602 "git am/send-email support?" "Daiki Ueno <ueno@gnu.org>" "Wed, 28 Jan 2015 12:55:08 +0900" "<m3vbjreezn.fsf-ueno@gnu.org>" "" 2740 15 "news.gmane.org gmane.emacs.gnus.general:85602" nil]
  ([85648 "Re: git am/send-email support?" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 13:23:51 +1100" "<87vbjqmiiw.fsf@building.gnus.org>" "<m3vbjreezn.fsf-ueno@gnu.org>" 3169 13 "news.gmane.org gmane.emacs.gnus.general:85648" nil]
   ([85656 "Re: git am/send-email support?" "Daiki Ueno <ueno@gnu.org>" "Thu, 29 Jan 2015 18:05:57 +0900" "<m3k306ot1m.fsf-ueno@gnu.org>" "<m3vbjreezn.fsf-ueno@gnu.org> <87vbjqmiiw.fsf@building.gnus.org>" 3356 23 "news.gmane.org gmane.emacs.gnus.general:85656" nil]
    ([85666 "Re: git am/send-email support?" "David Engster <deng@randomsample.de>" "Thu, 29 Jan 2015 20:53:51 +0100" "<87386t9xdc.fsf@randomsample.de>" "<m3vbjreezn.fsf-ueno@gnu.org> <87vbjqmiiw.fsf@building.gnus.org> <m3k306ot1m.fsf-ueno@gnu.org>" 4759 55 "news.gmane.org gmane.emacs.gnus.general:85666" nil]
     ([85689 "Re: git am/send-email support?" "Daiki Ueno <ueno@gnu.org>" "Mon, 02 Feb 2015 17:11:29 +0900" "<877fw0lolq.fsf-ueno@gnu.org>" "<m3vbjreezn.fsf-ueno@gnu.org> <87vbjqmiiw.fsf@building.gnus.org> <m3k306ot1m.fsf-ueno@gnu.org> <87386t9xdc.fsf@randomsample.de>" 3538 34 "news.gmane.org gmane.emacs.gnus.general:85689" nil]))
    ([85672 "Re: git am/send-email support?" "Lars Ingebrigtsen <larsi@gnus.org>" "Fri, 30 Jan 2015 10:37:48 +1100" "<87r3udyx83.fsf@building.gnus.org>" "<m3vbjreezn.fsf-ueno@gnu.org> <87vbjqmiiw.fsf@building.gnus.org> <m3k306ot1m.fsf-ueno@gnu.org>" 3397 18 "news.gmane.org gmane.emacs.gnus.general:85672" nil]))))
 ([85631 "address and name from posting styles are ignored" "Vitalie Spinu <spinuvit@gmail.com>" "Wed, 28 Jan 2015 12:24:43 +0100" "<87twzbrvus.fsf@gmail.com>" "" 3387 23 "news.gmane.org gmane.emacs.gnus.general:85631" nil]
  ([85634 "Re: address and name from posting styles are ignored" "Robert Pluim <rpluim@gmail.com>" "Wed, 28 Jan 2015 18:19:47 +0100" "<82d25yoma4.fsf@gmail.com>" "<87twzbrvus.fsf@gmail.com>" 4012 34 "news.gmane.org gmane.emacs.gnus.general:85634" nil]))
 ([85652 "latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 09:02:40 +0100" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr>" "" 4699 57 "news.gmane.org gmane.emacs.gnus.general:85652" nil]
  ([85653 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 09:04:33 +0100" "<m2bnlixbam.fsf@charm-ecran.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr>" 4056 34 "news.gmane.org gmane.emacs.gnus.general:85653" nil])
  ([85654 "Re: latest imap changes break refiling" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 19:06:58 +1100" "<87a9123t99.fsf@building.gnus.org>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr>" 3698 25 "news.gmane.org gmane.emacs.gnus.general:85654" nil]
   ([85655 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 09:51:06 +0100" "<m27fw6x951.fsf@charm-ecran.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org>" 4897 53 "news.gmane.org gmane.emacs.gnus.general:85655" nil]
    ([85657 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 11:18:29 +0100" "<m2twz951qi.fsf@charm-wifi.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr>" 5007 55 "news.gmane.org gmane.emacs.gnus.general:85657" nil]
     ([85658 "Re: latest imap changes break refiling" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 22:08:18 +1100" "<87iofp3kv1.fsf@building.gnus.org>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr> <m2twz951qi.fsf@charm-wifi.irisa.fr>" 3473 18 "news.gmane.org gmane.emacs.gnus.general:85658" nil]
      ([85659 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 13:03:26 +0100" "<m2fvat94kx.fsf@charm-wifi.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr> <m2twz951qi.fsf@charm-wifi.irisa.fr> <87iofp3kv1.fsf@building.gnus.org>" 4560 47 "news.gmane.org gmane.emacs.gnus.general:85659" nil]
       ([85724 "Re: latest imap changes break refiling" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 13:29:34 +1100" "<87sielw0oh.fsf@building.gnus.org>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr> <m2twz951qi.fsf@charm-wifi.irisa.fr> <87iofp3kv1.fsf@building.gnus.org> <m2fvat94kx.fsf@charm-wifi.irisa.fr>" 3293 11 "news.gmane.org gmane.emacs.gnus.general:85724" nil]
        ([85748 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 05 Feb 2015 10:26:42 +0100" "<m2mw4szp2l.fsf@charm-ecran.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr> <m2twz951qi.fsf@charm-wifi.irisa.fr> <87iofp3kv1.fsf@building.gnus.org> <m2fvat94kx.fsf@charm-wifi.irisa.fr> <87sielw0oh.fsf@building.gnus.org>" 8357 108 "news.gmane.org gmane.emacs.gnus.general:85748" nil]
         ([85774 "Re: latest imap changes break refiling" "Lars Ingebrigtsen <larsi@gnus.org>" "Fri, 13 Feb 2015 17:23:36 +1100" "<87vbj6fhxz.fsf@building.gnus.org>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr> <m2twz951qi.fsf@charm-wifi.irisa.fr> <87iofp3kv1.fsf@building.gnus.org> <m2fvat94kx.fsf@charm-wifi.irisa.fr> <87sielw0oh.fsf@building.gnus.org> <m2mw4szp2l.fsf@charm-ecran.irisa.fr>" 3485 15 "news.gmane.org gmane.emacs.gnus.general:85774" nil]
          ([85779 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Fri, 13 Feb 2015 10:34:35 +0100" "<m2d25ew3x0.fsf@charm-ecran.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr> <m2twz951qi.fsf@charm-wifi.irisa.fr> <87iofp3kv1.fsf@building.gnus.org> <m2fvat94kx.fsf@charm-wifi.irisa.fr> <87sielw0oh.fsf@building.gnus.org> <m2mw4szp2l.fsf@charm-ecran.irisa.fr> <87vbj6fhxz.fsf@building.gnus.org>" 8064 121 "news.gmane.org gmane.emacs.gnus.general:85779" nil]
           ([85799 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Sat, 21 Feb 2015 10:40:29 +0100" "<m2r3tjzjoy.fsf@polytechnique.org>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr> <m2twz951qi.fsf@charm-wifi.irisa.fr> <87iofp3kv1.fsf@building.gnus.org> <m2fvat94kx.fsf@charm-wifi.irisa.fr> <87sielw0oh.fsf@building.gnus.org> <m2mw4szp2l.fsf@charm-ecran.irisa.fr> <87vbj6fhxz.fsf@building.gnus.org> <m2d25ew3x0.fsf@charm-ecran.irisa.fr>" 4849 48 "news.gmane.org gmane.emacs.gnus.general:85799" nil]))))))))
    ([85662 "Re: latest imap changes break refiling" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Thu, 29 Jan 2015 11:19:33 +0100" "<m2lhkl51oq.fsf@charm-wifi.irisa.fr>" "<m2fvauxbdr.fsf@charm-ecran.irisa.fr> <87a9123t99.fsf@building.gnus.org> <m27fw6x951.fsf@charm-ecran.irisa.fr>" 5009 55 "news.gmane.org gmane.emacs.gnus.general:85662" nil]))))
 ([85660 "[A bit OT] Text usenet server ?" "Xavier Maillard <xavier@maillard.im>" "Thu, 29 Jan 2015 13:18:50 +0100" "<m0zj91n5jp.fsf@kcals.intra.maillard.im>" "" 4370 28 "news.gmane.org gmane.emacs.gnus.general:85660" nil]
  ([85661 "Re: [A bit OT] Text usenet server ?" "Charles Philip Chan <cpchan@bell.net>" "Thu, 29 Jan 2015 08:01:56 -0500" "<87k305kaez.fsf@karnak.MagnumOpus.khem>" "<m0zj91n5jp.fsf@kcals.intra.maillard.im>" 3942 31 "news.gmane.org gmane.emacs.gnus.general:85661" nil]
   ([85667 "Re: [A bit OT] Text usenet server ?" "Xavier Maillard <xavier@maillard.im>" "Thu, 29 Jan 2015 22:17:00 +0100" "<m0wq45mgmr.fsf@kcals.intra.maillard.im>" "<m0zj91n5jp.fsf@kcals.intra.maillard.im> <87k305kaez.fsf@karnak.MagnumOpus.khem>" 4303 18 "news.gmane.org gmane.emacs.gnus.general:85667" nil]))
  ([85663 "Re: [A bit OT] Text usenet server ?" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 29 Jan 2015 18:57:06 +0100" "<87mw51pj0t.fsf@topper.koldfront.dk>" "<m0zj91n5jp.fsf@kcals.intra.maillard.im>" 4154 29 "news.gmane.org gmane.emacs.gnus.general:85663" nil])
  ([85664 "Re: [A bit OT] Text usenet server ?" "Harry Putnam <reader@newsguy.com>" "Thu, 29 Jan 2015 13:13:11 -0500" "<87k305e9qg.fsf@reader.local.lan>" "<m0zj91n5jp.fsf@kcals.intra.maillard.im>" 3406 14 "news.gmane.org gmane.emacs.gnus.general:85664" nil]))
 ([85678 "Why doesn't this render in gnus shr/eww?" "Steinar Bang <sb@dod.no>" "Fri, 30 Jan 2015 21:30:47 +0100" "<87k3043tag.fsf@dod.no>" "" 4120 27 "news.gmane.org gmane.emacs.gnus.general:85678" nil]
  ([85680 "Re: Why doesn't this render in gnus shr/eww?" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 31 Jan 2015 00:51:27 +0100" "<87wq43su80.fsf@topper.koldfront.dk>" "<87k3043tag.fsf@dod.no>" 3977 21 "news.gmane.org gmane.emacs.gnus.general:85680" nil])
  ([85681 "Re: Why doesn't this render in gnus shr/eww?" "Lars Ingebrigtsen <larsi@gnus.org>" "Sat, 31 Jan 2015 11:49:26 +1100" "<87zj8zu63t.fsf@building.gnus.org>" "<87k3043tag.fsf@dod.no>" 3125 15 "news.gmane.org gmane.emacs.gnus.general:85681" nil]
   ([85683 "Re: Why doesn't this render in gnus shr/eww?" "Steinar Bang <sb@dod.no>" "Sat, 31 Jan 2015 15:02:41 +0100" "<upzczj8zf3pa.fsf@dod.no>" "<87k3043tag.fsf@dod.no> <87zj8zu63t.fsf@building.gnus.org>" 4578 37 "news.gmane.org gmane.emacs.gnus.general:85683" nil]
    ([85733 "Re: Why doesn't this render in gnus shr/eww?" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:37:30 +1100" "<87fval111h.fsf@building.gnus.org>" "<87k3043tag.fsf@dod.no> <87zj8zu63t.fsf@building.gnus.org> <upzczj8zf3pa.fsf@dod.no>" 3909 33 "news.gmane.org gmane.emacs.gnus.general:85733" nil]
     ([85753 "Re: Why doesn't this render in gnus shr/eww?" "Steinar Bang <sb@dod.no>" "Thu, 05 Feb 2015 18:19:00 +0100" "<upzcfvak9szf.fsf@dod.no>" "<87k3043tag.fsf@dod.no> <87zj8zu63t.fsf@building.gnus.org> <upzczj8zf3pa.fsf@dod.no> <87fval111h.fsf@building.gnus.org>" 3363 9 "news.gmane.org gmane.emacs.gnus.general:85753" nil]
      ([85754 "Re: Why doesn't this render in gnus shr/eww?" "Steinar Bang <sb@dod.no>" "Thu, 05 Feb 2015 21:24:14 +0100" "<upzc61bg9kep.fsf@dod.no>" "<87k3043tag.fsf@dod.no> <87zj8zu63t.fsf@building.gnus.org> <upzczj8zf3pa.fsf@dod.no> <87fval111h.fsf@building.gnus.org> <upzcfvak9szf.fsf@dod.no>" 3507 14 "news.gmane.org gmane.emacs.gnus.general:85754" nil]
       ([85757 "Re: Why doesn't this render in gnus shr/eww?" "Lars Ingebrigtsen <larsi@gnus.org>" "Fri, 06 Feb 2015 21:03:35 +1100" "<87wq3vicg8.fsf@building.gnus.org>" "<87k3043tag.fsf@dod.no> <87zj8zu63t.fsf@building.gnus.org> <upzczj8zf3pa.fsf@dod.no> <87fval111h.fsf@building.gnus.org> <upzcfvak9szf.fsf@dod.no> <upzc61bg9kep.fsf@dod.no>" 3155 11 "news.gmane.org gmane.emacs.gnus.general:85757" nil])))))))
 ([85682 "Gnus gets terribly slow when exiting high-traffic groups" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Fri, 30 Jan 2015 19:54:08 -0600" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu>" "" 3688 24 "news.gmane.org gmane.emacs.gnus.general:85682" nil]
  ([85732 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:30:45 +1100" "<87k2zx11cq.fsf@building.gnus.org>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu>" 3547 17 "news.gmane.org gmane.emacs.gnus.general:85732" nil]
   ([85735 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Wed, 04 Feb 2015 21:38:19 -0600" "<ufa1tm5uixg.fsf@epithumia.math.uh.edu>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org>" 2962 10 "news.gmane.org gmane.emacs.gnus.general:85735" nil]
    ([85736 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:47:31 +1100" "<87sielyq7g.fsf@building.gnus.org>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu>" 3716 22 "news.gmane.org gmane.emacs.gnus.general:85736" nil]
     ([85737 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Wed, 04 Feb 2015 22:06:21 -0600" "<ufar3u5vw76.fsf@epithumia.math.uh.edu>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org>" 3862 36 "news.gmane.org gmane.emacs.gnus.general:85737" nil]
      ([85742 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 15:51:28 +1100" "<877fvxyn8v.fsf@building.gnus.org>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org> <ufar3u5vw76.fsf@epithumia.math.uh.edu>" 3957 35 "news.gmane.org gmane.emacs.gnus.general:85742" nil]
       ([85743 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Thu, 05 Feb 2015 00:12:39 -0600" "<ufasiek28fc.fsf@epithumia.math.uh.edu>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org> <ufar3u5vw76.fsf@epithumia.math.uh.edu> <877fvxyn8v.fsf@building.gnus.org>" 3690 24 "news.gmane.org gmane.emacs.gnus.general:85743" nil]
        ([85744 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Thu, 05 Feb 2015 00:18:05 -0600" "<ufak2zw51b6.fsf@epithumia.math.uh.edu>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org> <ufar3u5vw76.fsf@epithumia.math.uh.edu> <877fvxyn8v.fsf@building.gnus.org> <ufasiek28fc.fsf@epithumia.math.uh.edu>" 3210 8 "news.gmane.org gmane.emacs.gnus.general:85744" nil])
        ([85745 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 17:23:47 +1100" "<871tm4zxjg.fsf@building.gnus.org>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org> <ufar3u5vw76.fsf@epithumia.math.uh.edu> <877fvxyn8v.fsf@building.gnus.org> <ufasiek28fc.fsf@epithumia.math.uh.edu>" 3653 17 "news.gmane.org gmane.emacs.gnus.general:85745" nil]
         ([85747 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Thu, 05 Feb 2015 00:39:29 -0600" "<ufaa90s7tge.fsf@epithumia.math.uh.edu>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org> <ufar3u5vw76.fsf@epithumia.math.uh.edu> <877fvxyn8v.fsf@building.gnus.org> <ufasiek28fc.fsf@epithumia.math.uh.edu> <871tm4zxjg.fsf@building.gnus.org>" 4081 33 "news.gmane.org gmane.emacs.gnus.general:85747" nil]
          ([85755 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Lars Ingebrigtsen <larsi@gnus.org>" "Fri, 06 Feb 2015 11:42:53 +1100" "<878ugbvpiq.fsf@building.gnus.org>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org> <ufar3u5vw76.fsf@epithumia.math.uh.edu> <877fvxyn8v.fsf@building.gnus.org> <ufasiek28fc.fsf@epithumia.math.uh.edu> <871tm4zxjg.fsf@building.gnus.org> <ufaa90s7tge.fsf@epithumia.math.uh.edu>" 3963 27 "news.gmane.org gmane.emacs.gnus.general:85755" nil]
           ([85756 "Re: Gnus gets terribly slow when exiting high-traffic groups" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Thu, 05 Feb 2015 18:47:15 -0600" "<ufah9uzuar0.fsf@epithumia.math.uh.edu>" "<ufapp9v3ebj.fsf@epithumia.math.uh.edu> <87k2zx11cq.fsf@building.gnus.org> <ufa1tm5uixg.fsf@epithumia.math.uh.edu> <87sielyq7g.fsf@building.gnus.org> <ufar3u5vw76.fsf@epithumia.math.uh.edu> <877fvxyn8v.fsf@building.gnus.org> <ufasiek28fc.fsf@epithumia.math.uh.edu> <871tm4zxjg.fsf@building.gnus.org> <ufaa90s7tge.fsf@epithumia.math.uh.edu> <878ugbvpiq.fsf@building.gnus.org>" 3580 17 "news.gmane.org gmane.emacs.gnus.general:85756" nil])))))))))))
 ([85686 "Recent nnir update broke search on office365" "david.goldberg6@verizon.net (Dave Goldberg)" "Sat, 31 Jan 2015 11:53:28 -0500" "<84386qhoxj.fsf@davestoy.home>" "" 3524 20 "news.gmane.org gmane.emacs.gnus.general:85686" nil]
  ([85687 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Sun, 01 Feb 2015 09:40:28 +0800" "<87r3ua9zoz.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home>" 5421 28 "news.gmane.org gmane.emacs.gnus.general:85687" nil])
  ([85691 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Sun, 01 Feb 2015 14:22:44 +0800" "<871tma9mmj.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home>" 6590 67 "news.gmane.org gmane.emacs.gnus.general:85691" nil]
   ([85701 "Re: Recent nnir update broke search on office365" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 3 Feb 2015 11:49:00 +0000" "<87k2zzdxlf.fsf@pinto.chemeng.ucl.ac.uk>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net>" 5112 31 "news.gmane.org gmane.emacs.gnus.general:85701" nil]
    ([85702 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 03 Feb 2015 21:01:41 +0800" "<87egq79miy.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <87k2zzdxlf.fsf@pinto.chemeng.ucl.ac.uk>" 5712 33 "news.gmane.org gmane.emacs.gnus.general:85702" nil]
     ([85703 "Re: Recent nnir update broke search on office365" "<e.fraga@ucl.ac.uk>" "Tue, 3 Feb 2015 15:57:08 +0000" "<87iofj7zu3.fsf@ucl.ac.uk>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <87k2zzdxlf.fsf@pinto.chemeng.ucl.ac.uk> <87egq79miy.fsf@ericabrahamsen.net>" 4682 20 "news.gmane.org gmane.emacs.gnus.general:85703" nil]
      ([85705 "Re: Recent nnir update broke search on office365" "david.goldberg6@verizon.net (Dave Goldberg)" "Tue, 03 Feb 2015 18:21:36 -0500" "<84mw4utwcf.fsf@davestoy.home>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <87k2zzdxlf.fsf@pinto.chemeng.ucl.ac.uk> <87egq79miy.fsf@ericabrahamsen.net> <87iofj7zu3.fsf@ucl.ac.uk>" 3695 18 "news.gmane.org gmane.emacs.gnus.general:85705" nil]
       ([85707 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 04 Feb 2015 11:02:12 +0800" "<87oapa8jm3.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <87k2zzdxlf.fsf@pinto.chemeng.ucl.ac.uk> <87egq79miy.fsf@ericabrahamsen.net> <87iofj7zu3.fsf@ucl.ac.uk> <84mw4utwcf.fsf@davestoy.home>" 5179 19 "news.gmane.org gmane.emacs.gnus.general:85707" nil]
        ([85710 "Re: Recent nnir update broke search on office365" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Wed, 4 Feb 2015 10:30:31 +0000" "<87mw4uarzs.fsf@pinto.chemeng.ucl.ac.uk>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <87k2zzdxlf.fsf@pinto.chemeng.ucl.ac.uk> <87egq79miy.fsf@ericabrahamsen.net> <87iofj7zu3.fsf@ucl.ac.uk> <84mw4utwcf.fsf@davestoy.home> <87oapa8jm3.fsf@ericabrahamsen.net>" 4775 11 "news.gmane.org gmane.emacs.gnus.general:85710" nil]))))))
   ([85706 "Re: Recent nnir update broke search on office365" "Katsumi Yamaoka <yamaoka@jpl.org>" "Wed, 04 Feb 2015 09:15:19 +0900" "<b4mh9v2wmzs.fsf@jpl.org>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net>" 3969 20 "news.gmane.org gmane.emacs.gnus.general:85706" nil]
    ([85708 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 04 Feb 2015 11:30:52 +0800" "<87k2zy8iab.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <b4mh9v2wmzs.fsf@jpl.org>" 6166 44 "news.gmane.org gmane.emacs.gnus.general:85708" nil]
     ([85715 "Re: Recent nnir update broke search on office365" "Andreas Schwab <schwab@linux-m68k.org>" "Wed, 04 Feb 2015 19:28:24 +0100" "<87mw4ta5vb.fsf@igel.home>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <b4mh9v2wmzs.fsf@jpl.org> <87k2zy8iab.fsf@ericabrahamsen.net>" 4300 22 "news.gmane.org gmane.emacs.gnus.general:85715" nil]
      ([85723 "Re: Recent nnir update broke search on office365" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Thu, 05 Feb 2015 09:03:36 +0800" "<8761bhrwyf.fsf@ericabrahamsen.net>" "<84386qhoxj.fsf@davestoy.home> <871tma9mmj.fsf@ericabrahamsen.net> <b4mh9v2wmzs.fsf@jpl.org> <87k2zy8iab.fsf@ericabrahamsen.net> <87mw4ta5vb.fsf@igel.home>" 5244 20 "news.gmane.org gmane.emacs.gnus.general:85723" nil]))))))
 ([85692 "Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 00:18:54 +0100" "<m3r3u7aom9.fsf@neo.luffy.cx>" "" 3743 13 "news.gmane.org gmane.emacs.gnus.general:85692" nil]
  ([85694 "Re: Unable to get all messages in an IMAP group" "Steinar Bang <sb@dod.no>" "Tue, 03 Feb 2015 07:42:22 +0100" "<upzciofjfqcx.fsf@dod.no>" "<m3r3u7aom9.fsf@neo.luffy.cx>" 3550 14 "news.gmane.org gmane.emacs.gnus.general:85694" nil]
   ([85695 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 08:40:47 +0100" "<m3egq7a1ds.fsf@neo.luffy.cx>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no>" 4679 25 "news.gmane.org gmane.emacs.gnus.general:85695" nil]
    ([85696 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 08:44:31 +0100" "<m38ugfa17k.fsf@neo.luffy.cx>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx>" 5202 42 "news.gmane.org gmane.emacs.gnus.general:85696" nil])
    ([85697 "Re: Unable to get all messages in an IMAP group" "Steinar Bang <sb@dod.no>" "Tue, 03 Feb 2015 09:05:23 +0100" "<upzcegq7fmik.fsf@dod.no>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx>" 4008 30 "news.gmane.org gmane.emacs.gnus.general:85697" nil]
     ([85698 "Re: Unable to get all messages in an IMAP group" "Tassilo Horn <tsdh@gnu.org>" "Tue, 03 Feb 2015 09:17:47 +0100" "<87h9v38l3o.fsf@gnu.org>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no>" 3142 24 "news.gmane.org gmane.emacs.gnus.general:85698" nil])
     ([85699 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 10:09:56 +0100" "<87oapbe4yj.fsf@zoro.exoscale.ch>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no>" 4523 19 "news.gmane.org gmane.emacs.gnus.general:85699" nil]
      ([85700 "Re: Unable to get all messages in an IMAP group" "Steinar Bang <sb@dod.no>" "Tue, 03 Feb 2015 11:54:48 +0100" "<upzca90vfeo7.fsf@dod.no>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch>" 3619 15 "news.gmane.org gmane.emacs.gnus.general:85700" nil]
       ([85704 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 21:52:55 +0100" "<m3fvamzpi0.fsf@neo.luffy.cx>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no>" 4845 28 "news.gmane.org gmane.emacs.gnus.general:85704" nil]
        ([85709 "Re: Unable to get all messages in an IMAP group" "Steinar Bang <sb@dod.no>" "Wed, 04 Feb 2015 07:28:34 +0100" "<upzczj8uchrh.fsf@dod.no>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no> <m3fvamzpi0.fsf@neo.luffy.cx>" 3652 12 "news.gmane.org gmane.emacs.gnus.general:85709" nil]
         ([85716 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Wed, 04 Feb 2015 21:48:27 +0100" "<m3h9v17690.fsf@neo.luffy.cx>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no> <m3fvamzpi0.fsf@neo.luffy.cx> <upzczj8uchrh.fsf@dod.no>" 4769 34 "news.gmane.org gmane.emacs.gnus.general:85716" nil]
          ([85718 "Re: Unable to get all messages in an IMAP group" "Steinar Bang <sb@dod.no>" "Wed, 04 Feb 2015 22:10:14 +0100" "<upzcwq3xbcy1.fsf@dod.no>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no> <m3fvamzpi0.fsf@neo.luffy.cx> <upzczj8uchrh.fsf@dod.no> <m3h9v17690.fsf@neo.luffy.cx>" 3791 21 "news.gmane.org gmane.emacs.gnus.general:85718" nil])
          ([85719 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <bernat@luffy.cx>" "Wed, 04 Feb 2015 22:11:03 +0100" "<m3d25p757c.fsf@neo.luffy.cx>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no> <m3fvamzpi0.fsf@neo.luffy.cx> <upzczj8uchrh.fsf@dod.no> <m3h9v17690.fsf@neo.luffy.cx>" 6341 92 "news.gmane.org gmane.emacs.gnus.general:85719" nil]
           ([85720 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <vincent@bernat.im>" "Wed, 04 Feb 2015 22:19:35 +0100" "<m34mr174t4.fsf@neo.luffy.cx>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no> <m3fvamzpi0.fsf@neo.luffy.cx> <upzczj8uchrh.fsf@dod.no> <m3h9v17690.fsf@neo.luffy.cx> <m3d25p757c.fsf@neo.luffy.cx>" 4865 51 "news.gmane.org gmane.emacs.gnus.general:85720" nil]
            ([85721 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <vincent@bernat.im>" "Wed, 04 Feb 2015 22:35:00 +0100" "<m3zj8t5piz.fsf@neo.luffy.cx>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no> <m3fvamzpi0.fsf@neo.luffy.cx> <upzczj8uchrh.fsf@dod.no> <m3h9v17690.fsf@neo.luffy.cx> <m3d25p757c.fsf@neo.luffy.cx> <m34mr174t4.fsf@neo.luffy.cx>" 5246 56 "news.gmane.org gmane.emacs.gnus.general:85721" nil]
             ([85728 "Re: Unable to get all messages in an IMAP group" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:10:44 +1100" "<87a90tvyrv.fsf@building.gnus.org>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no> <m3fvamzpi0.fsf@neo.luffy.cx> <upzczj8uchrh.fsf@dod.no> <m3h9v17690.fsf@neo.luffy.cx> <m3d25p757c.fsf@neo.luffy.cx> <m34mr174t4.fsf@neo.luffy.cx> <m3zj8t5piz.fsf@neo.luffy.cx>" 3435 12 "news.gmane.org gmane.emacs.gnus.general:85728" nil]
              ([85746 "Re: Unable to get all messages in an IMAP group" "Vincent Bernat <vincent@bernat.im>" "Thu, 05 Feb 2015 07:27:58 +0100" "<m37fvwrhxt.fsf@neo.luffy.cx>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no> <m3fvamzpi0.fsf@neo.luffy.cx> <upzczj8uchrh.fsf@dod.no> <m3h9v17690.fsf@neo.luffy.cx> <m3d25p757c.fsf@neo.luffy.cx> <m34mr174t4.fsf@neo.luffy.cx> <m3zj8t5piz.fsf@neo.luffy.cx> <87a90tvyrv.fsf@building.gnus.org>" 4011 14 "news.gmane.org gmane.emacs.gnus.general:85746" nil]))))
           ([85727 "Re: Unable to get all messages in an IMAP group" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:06:20 +1100" "<87egq5vyz7.fsf@building.gnus.org>" "<m3r3u7aom9.fsf@neo.luffy.cx> <upzciofjfqcx.fsf@dod.no> <m3egq7a1ds.fsf@neo.luffy.cx> <upzcegq7fmik.fsf@dod.no> <87oapbe4yj.fsf@zoro.exoscale.ch> <upzca90vfeo7.fsf@dod.no> <m3fvamzpi0.fsf@neo.luffy.cx> <upzczj8uchrh.fsf@dod.no> <m3h9v17690.fsf@neo.luffy.cx> <m3d25p757c.fsf@neo.luffy.cx>" 3652 20 "news.gmane.org gmane.emacs.gnus.general:85727" nil])))))))))))
 ([85693 "Unable to see all messages since recent IMAP changes" "Vincent Bernat <bernat@luffy.cx>" "Tue, 03 Feb 2015 00:19:25 +0100" "<m3mw4vaole.fsf@neo.luffy.cx>" "" 3796 14 "news.gmane.org gmane.emacs.gnus.general:85693" nil])
 ([85758 "Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 10 Feb 2015 14:05:08 +0800" "<87iofawbcb.fsf@ericabrahamsen.net>" "" 5231 31 "news.gmane.org gmane.emacs.gnus.general:85758" nil]
  ([85759 "Re: Gnus Own-Cloudy?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 10 Feb 2015 09:17:25 +0000" "<87twyu6s7u.fsf@ucl.ac.uk>" "<87iofawbcb.fsf@ericabrahamsen.net>" 5221 23 "news.gmane.org gmane.emacs.gnus.general:85759" nil]
   ([85760 "Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 10 Feb 2015 18:20:48 +0800" "<87mw4mukxr.fsf@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk>" 5971 39 "news.gmane.org gmane.emacs.gnus.general:85760" nil]
    ([85761 "Re: Gnus Own-Cloudy?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 10 Feb 2015 10:48:37 +0000" "<87wq3qm48q.fsf@ucl.ac.uk>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net>" 6597 62 "news.gmane.org gmane.emacs.gnus.general:85761" nil]
     ([85762 "Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 10 Feb 2015 18:53:33 +0800" "<874mquujf6.fsf@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk>" 6996 69 "news.gmane.org gmane.emacs.gnus.general:85762" nil]
      ([85763 "Re: Gnus Own-Cloudy?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 10 Feb 2015 11:45:49 +0000" "<87lhk6kn0y.fsf@ucl.ac.uk>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net>" 5398 30 "news.gmane.org gmane.emacs.gnus.general:85763" nil]
       ([85766 "Re: Gnus Own-Cloudy?" "jorge.alfaro-murillo@yale.edu (Jorge A. Alfaro-Murillo)" "Tue, 10 Feb 2015 10:19:19 -0500" "<877fvpokug.fsf@yale.edu>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk>" 3552 17 "news.gmane.org gmane.emacs.gnus.general:85766" nil])
       ([85768 "Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 11 Feb 2015 10:12:03 +0800" "<87iof9tcwc.fsf@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk>" 5981 32 "news.gmane.org gmane.emacs.gnus.general:85768" nil]
        ([85769 "Re: Gnus Own-Cloudy?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Wed, 11 Feb 2015 11:12:40 +0000" "<87zj8kn1lj.fsf@pinto.chemeng.ucl.ac.uk>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk> <87iof9tcwc.fsf@ericabrahamsen.net>" 5070 22 "news.gmane.org gmane.emacs.gnus.general:85769" nil])
        ([85770 "Re: Gnus Own-Cloudy?" "Dan Christensen <jdc@uwo.ca>" "Wed, 11 Feb 2015 08:48:54 -0500" "<87vbj8tv7d.fsf@uwo.ca>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk> <87iof9tcwc.fsf@ericabrahamsen.net>" 4438 28 "news.gmane.org gmane.emacs.gnus.general:85770" nil]
         ([85772 "Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Fri, 13 Feb 2015 13:26:43 +0800" "<87a90i4c18.fsf@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk> <87iof9tcwc.fsf@ericabrahamsen.net> <87vbj8tv7d.fsf@uwo.ca>" 8015 72 "news.gmane.org gmane.emacs.gnus.general:85772" nil]
          ([85773 "Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Fri, 13 Feb 2015 13:52:35 +0800" "<87zj8ipdcs.fsf@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk> <87iof9tcwc.fsf@ericabrahamsen.net> <87vbj8tv7d.fsf@uwo.ca> <87a90i4c18.fsf@ericabrahamsen.net>" 9748 107 "news.gmane.org gmane.emacs.gnus.general:85773" nil])
          ([85780 "Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Fri, 13 Feb 2015 22:57:30 +0800" "<87k2zlq2p1.fsf@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk> <87iof9tcwc.fsf@ericabrahamsen.net> <87vbj8tv7d.fsf@uwo.ca> <87a90i4c18.fsf@ericabrahamsen.net>" 7340 57 "news.gmane.org gmane.emacs.gnus.general:85780" nil])
          ([85785 "Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Sat, 14 Feb 2015 21:48:01 +0800" "<874mqomwoe.fsf@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk> <87iof9tcwc.fsf@ericabrahamsen.net> <87vbj8tv7d.fsf@uwo.ca> <87a90i4c18.fsf@ericabrahamsen.net>" 7256 63 "news.gmane.org gmane.emacs.gnus.general:85785" nil]
           ([85787 "[PATCH] Re: Gnus Own-Cloudy?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 18 Feb 2015 19:12:45 +0800" "<878ufv79si.fsf_-_@ericabrahamsen.net>" "<87iofawbcb.fsf@ericabrahamsen.net> <87twyu6s7u.fsf@ucl.ac.uk> <87mw4mukxr.fsf@ericabrahamsen.net> <87wq3qm48q.fsf@ucl.ac.uk> <874mquujf6.fsf@ericabrahamsen.net> <87lhk6kn0y.fsf@ucl.ac.uk> <87iof9tcwc.fsf@ericabrahamsen.net> <87vbj8tv7d.fsf@uwo.ca> <87a90i4c18.fsf@ericabrahamsen.net> <874mqomwoe.fsf@ericabrahamsen.net>" 8853 89 "news.gmane.org gmane.emacs.gnus.general:85787" nil]))))))))))
  ([85767 "Re: Gnus Own-Cloudy?" "jorge.alfaro-murillo@yale.edu (Jorge A. Alfaro-Murillo)" "Tue, 10 Feb 2015 10:31:00 -0500" "<87386dokaz.fsf@yale.edu>" "<87iofawbcb.fsf@ericabrahamsen.net>" 3924 32 "news.gmane.org gmane.emacs.gnus.general:85767" nil]))
 ([85764 "Gnus mailing list support" "Erik Colson <eco@ecocode.net>" "Tue, 10 Feb 2015 15:43:01 +0100" "<m2pp9hhloq.fsf@ecocode.net>" "" 2753 16 "news.gmane.org gmane.emacs.gnus.general:85764" nil]
  ([85777 "Re: Gnus mailing list support" "Lars Ingebrigtsen <larsi@gnus.org>" "Fri, 13 Feb 2015 17:56:13 +1100" "<87iof6fgfm.fsf@building.gnus.org>" "<m2pp9hhloq.fsf@ecocode.net>" 3326 18 "news.gmane.org gmane.emacs.gnus.general:85777" nil]
   ([85782 "Re: Gnus mailing list support" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Fri, 13 Feb 2015 10:30:13 -0600" "<ufafva9pyei.fsf@epithumia.math.uh.edu>" "<m2pp9hhloq.fsf@ecocode.net> <87iof6fgfm.fsf@building.gnus.org>" 3008 11 "news.gmane.org gmane.emacs.gnus.general:85782" nil]
    ([85783 "Re: Gnus mailing list support" "Lars Ingebrigtsen <larsi@gnus.org>" "Sat, 14 Feb 2015 15:23:13 +1100" "<87twypglzi.fsf@building.gnus.org>" "<m2pp9hhloq.fsf@ecocode.net> <87iof6fgfm.fsf@building.gnus.org> <ufafva9pyei.fsf@epithumia.math.uh.edu>" 3462 18 "news.gmane.org gmane.emacs.gnus.general:85783" nil]
     ([85784 "Re: Gnus mailing list support" "Erik Colson <eco@ecocode.net>" "Sat, 14 Feb 2015 08:52:26 +0100" "<m2vbj5ylol.fsf@ecocode.net>" "<m2pp9hhloq.fsf@ecocode.net> <87iof6fgfm.fsf@building.gnus.org> <ufafva9pyei.fsf@epithumia.math.uh.edu> <87twypglzi.fsf@building.gnus.org>" 2954 10 "news.gmane.org gmane.emacs.gnus.general:85784" nil])))))
 ([85765 "moving a group from one Imap backend to another" "Erik Colson <eco@ecocode.net>" "Tue, 10 Feb 2015 15:44:24 +0100" "<m2lhk5hlmf.fsf@ecocode.net>" "" 2585 11 "news.gmane.org gmane.emacs.gnus.general:85765" nil]
  ([85776 "Re: moving a group from one Imap backend to another" "Lars Ingebrigtsen <larsi@gnus.org>" "Fri, 13 Feb 2015 17:57:39 +1100" "<87egpufgd8.fsf@building.gnus.org>" "<m2lhk5hlmf.fsf@ecocode.net>" 3303 16 "news.gmane.org gmane.emacs.gnus.general:85776" nil]
   ([85778 "Re: moving a group from one Imap backend to another" "Erik Colson <eco@ecocode.net>" "Fri, 13 Feb 2015 09:25:08 +0100" "<m2386arzff.fsf@ecocode.net>" "<m2lhk5hlmf.fsf@ecocode.net> <87egpufgd8.fsf@building.gnus.org>" 3898 17 "news.gmane.org gmane.emacs.gnus.general:85778" nil]
    ([85781 "Re: moving a group from one Imap backend to another" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Fri, 13 Feb 2015 10:29:14 -0600" "<ufak2zlpyg5.fsf@epithumia.math.uh.edu>" "<m2lhk5hlmf.fsf@ecocode.net> <87egpufgd8.fsf@building.gnus.org> <m2386arzff.fsf@ecocode.net>" 3327 15 "news.gmane.org gmane.emacs.gnus.general:85781" nil]
     ([85808 "Re: moving a group from one Imap backend to another" "Alexander Baier <alexander.baier@mailbox.org>" "Tue, 24 Feb 2015 10:38:41 +0100" "<87y4nnps2m.fsf@mailbox.org>" "<m2lhk5hlmf.fsf@ecocode.net> <87egpufgd8.fsf@building.gnus.org> <m2386arzff.fsf@ecocode.net> <ufak2zlpyg5.fsf@epithumia.math.uh.edu>" 5094 20 "news.gmane.org gmane.emacs.gnus.general:85808" nil])))))
 ([85789 "shr output unreadable" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Wed, 18 Feb 2015 12:12:21 -0600" "<ufatwyjhywq.fsf@epithumia.math.uh.edu>" "" 3023 14 "news.gmane.org gmane.emacs.gnus.general:85789" nil]
  ([85790 "Re: shr output unreadable" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Wed, 18 Feb 2015 12:17:00 -0600" "<ufapp97hyoz.fsf@epithumia.math.uh.edu>" "<ufatwyjhywq.fsf@epithumia.math.uh.edu>" 2816 6 "news.gmane.org gmane.emacs.gnus.general:85790" nil])
  ([85792 "Re: shr output unreadable" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 19 Feb 2015 16:55:42 +1100" "<87egpmjvhd.fsf@building.gnus.org>" "<ufatwyjhywq.fsf@epithumia.math.uh.edu>" 3463 17 "news.gmane.org gmane.emacs.gnus.general:85792" nil]
   ([85794 "Re: shr output unreadable" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Thu, 19 Feb 2015 00:27:45 -0600" "<ufalhjua00u.fsf@epithumia.math.uh.edu>" "<ufatwyjhywq.fsf@epithumia.math.uh.edu> <87egpmjvhd.fsf@building.gnus.org>" 206433 3777 "news.gmane.org gmane.emacs.gnus.general:85794" nil]
    ([85795 "Re: shr output unreadable" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 19 Feb 2015 10:29:45 +0100" "<87a90a1c6u.fsf@topper.koldfront.dk>" "<ufatwyjhywq.fsf@epithumia.math.uh.edu> <87egpmjvhd.fsf@building.gnus.org> <ufalhjua00u.fsf@epithumia.math.uh.edu>" 3963 20 "news.gmane.org gmane.emacs.gnus.general:85795" nil]
     ([85796 "Re: shr output unreadable" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Thu, 19 Feb 2015 09:52:59 -0600" "<ufah9uhaof8.fsf@epithumia.math.uh.edu>" "<ufatwyjhywq.fsf@epithumia.math.uh.edu> <87egpmjvhd.fsf@building.gnus.org> <ufalhjua00u.fsf@epithumia.math.uh.edu> <87a90a1c6u.fsf@topper.koldfront.dk>" 3173 10 "news.gmane.org gmane.emacs.gnus.general:85796" nil]
      ([85797 "Re: shr output unreadable" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Thu, 19 Feb 2015 10:54:12 -0600" "<ufa1tllall7.fsf@epithumia.math.uh.edu>" "<ufatwyjhywq.fsf@epithumia.math.uh.edu> <87egpmjvhd.fsf@building.gnus.org> <ufalhjua00u.fsf@epithumia.math.uh.edu> <87a90a1c6u.fsf@topper.koldfront.dk> <ufah9uhaof8.fsf@epithumia.math.uh.edu>" 3048 7 "news.gmane.org gmane.emacs.gnus.general:85797" nil]))))))
 ([85798 "is nnrss backend searchable?" "Melleus <melleus@openmailbox.org>" "Thu, 19 Feb 2015 23:22:46 +0200" "<87zj89a95l.fsf@hornet.workgroup>" "" 4671 9 "news.gmane.org gmane.emacs.gnus.general:85798" nil])
 ([85801 "Invalid face attribute" "Peter Münster <pmlists@free.fr>" "Sun, 22 Feb 2015 18:19:56 +0100" "<87385xq2wz.fsf@free.fr>" "" 3489 25 "news.gmane.org gmane.emacs.gnus.general:85801" nil]
  ([85805 "Re: Invalid face attribute" "Katsumi Yamaoka <yamaoka@jpl.org>" "Mon, 23 Feb 2015 11:42:00 +0900" "<b4mk2z9uz5z.fsf@jpl.org>" "<87385xq2wz.fsf@free.fr>" 4460 43 "news.gmane.org gmane.emacs.gnus.general:85805" nil]
   ([85806 "Re: Invalid face attribute" "Peter Münster <pmlists@free.fr>" "Mon, 23 Feb 2015 08:50:34 +0100" "<87fv9xjcc5.fsf@free.fr>" "<87385xq2wz.fsf@free.fr> <b4mk2z9uz5z.fsf@jpl.org>" 4230 36 "news.gmane.org gmane.emacs.gnus.general:85806" nil]
    ([85807 "Re: Invalid face attribute" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Mon, 23 Feb 2015 16:39:43 +0000" "<87vbistwds.fsf@delle7240.chemeng.ucl.ac.uk>" "<87385xq2wz.fsf@free.fr> <b4mk2z9uz5z.fsf@jpl.org> <87fv9xjcc5.fsf@free.fr>" 5410 22 "news.gmane.org gmane.emacs.gnus.general:85807" nil]))))
 ([85802 "quote chars in article mode" "Clemens Schüller <cs.mlists+gnus@mailbox.org>" "Sun, 22 Feb 2015 20:25:32 +0100" "<87vbit92ab.fsf@cougar.home.aneadesign.com>" "" 4510 15 "news.gmane.org gmane.emacs.gnus.general:85802" nil]
  ([85803 "Re: quote chars in article mode" "Peter Münster <pmlists@free.fr>" "Sun, 22 Feb 2015 21:09:50 +0100" "<87lhjpk8s1.fsf@free.fr>" "<87vbit92ab.fsf@cougar.home.aneadesign.com>" 3356 13 "news.gmane.org gmane.emacs.gnus.general:85803" nil]
   ([85804 "Re: quote chars in article mode" "Clemens Schüller <cs.mlists+gnus@mailbox.org>" "Sun, 22 Feb 2015 21:47:01 +0100" "<87h9ud4qt6.fsf@cougar.home.aneadesign.com>" "<87vbit92ab.fsf@cougar.home.aneadesign.com> <87lhjpk8s1.fsf@free.fr>" 5007 26 "news.gmane.org gmane.emacs.gnus.general:85804" nil])))
 ([85809 "Downloading large numbers of unwanted k, so sitting and waiting" "Sharon Kimble <boudiccas@skimble.plus.com>" "Tue, 24 Feb 2015 10:27:18 +0000" "<87bnkjy589.fsf@skimble.plus.com>" "" 5928 42 "news.gmane.org gmane.emacs.gnus.general:85809" nil])
 ([85810 "problem when extracting MIME parts" "Adrian Lanz <lanz@wsl.ch>" "Tue, 24 Feb 2015 23:06:39 +0100" "<87a9030xsg.fsf@inventur.wsl.ch>" "" 8086 97 "news.gmane.org gmane.emacs.gnus.general:85810" nil]
  ([85811 "Re: problem when extracting MIME parts" "Katsumi Yamaoka <yamaoka@jpl.org>" "Wed, 25 Feb 2015 11:40:05 +0900" "<b4mk2z6u322.fsf@jpl.org>" "<87a9030xsg.fsf@inventur.wsl.ch>" 3848 15 "news.gmane.org gmane.emacs.gnus.general:85811" nil]))
 ([85812 "message-citation-line-format - should %F have a fall back?" "asjo@koldfront.dk (Adam Sjøgren)" "Wed, 25 Feb 2015 21:34:24 +0100" "<87k2z5rar3.fsf@topper.koldfront.dk>" "" 5322 57 "news.gmane.org gmane.emacs.gnus.general:85812" nil]
  ([85813 "Re: message-citation-line-format - should %F have a fall back?" "Katsumi Yamaoka <yamaoka@jpl.org>" "Thu, 26 Feb 2015 09:41:01 +0900" "<b4m4mq9pkrm.fsf@jpl.org>" "<87k2z5rar3.fsf@topper.koldfront.dk>" 3816 17 "news.gmane.org gmane.emacs.gnus.general:85813" nil]
   ([85816 "Re: message-citation-line-format - should %F have a fall back?" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 26 Feb 2015 23:38:29 +0100" "<87oaog70yi.fsf@topper.koldfront.dk>" "<87k2z5rar3.fsf@topper.koldfront.dk> <b4m4mq9pkrm.fsf@jpl.org>" 5168 54 "news.gmane.org gmane.emacs.gnus.general:85816" nil])))
 ([85814 "deleting instead of expiring mail" "Adrian Lanz <lanz@wsl.ch>" "Thu, 26 Feb 2015 15:17:06 +0100" "<yovaoaogdafx.fsf@sampling.wsl.ch>" "" 6151 52 "news.gmane.org gmane.emacs.gnus.general:85814" nil]
  ([85815 "Re: deleting instead of expiring mail" "Adrian Lanz <lanz@wsl.ch>" "Thu, 26 Feb 2015 17:25:50 +0100" "<yovatwy88ws1.fsf@sampling.wsl.ch>" "<yovaoaogdafx.fsf@sampling.wsl.ch>" 6845 70 "news.gmane.org gmane.emacs.gnus.general:85815" nil]
   ([85817 "Re: deleting instead of expiring mail" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Fri, 27 Feb 2015 17:29:31 +0000" "<87ioen1cw4.fsf@pinto.chemeng.ucl.ac.uk>" "<yovaoaogdafx.fsf@sampling.wsl.ch> <yovatwy88ws1.fsf@sampling.wsl.ch>" 4811 17 "news.gmane.org gmane.emacs.gnus.general:85817" nil])))
 ([85818 "Best method to disable TAB in topic-mode?" "Igor Sosa Mayor <joseleopoldo1792@gmail.com>" "Sat, 28 Feb 2015 15:10:36 +0100" "<87ioem5dpf.fsf@pedroche.home>" "" 3607 24 "news.gmane.org gmane.emacs.gnus.general:85818" nil]
  ([85819 "Re: Best method to disable TAB in topic-mode?" "Andreas Schwab <schwab@linux-m68k.org>" "Sat, 28 Feb 2015 15:29:22 +0100" "<87wq32w1ml.fsf@igel.home>" "<87ioem5dpf.fsf@pedroche.home>" 3736 14 "news.gmane.org gmane.emacs.gnus.general:85819" nil]
   ([85820 "Re: Best method to disable TAB in topic-mode?" "Igor Sosa Mayor <joseleopoldo1792@gmail.com>" "Sat, 28 Feb 2015 18:49:49 +0100" "<87a8zy53k2.fsf@pedroche.home>" "<87ioem5dpf.fsf@pedroche.home> <87wq32w1ml.fsf@igel.home>" 3130 8 "news.gmane.org gmane.emacs.gnus.general:85820" nil]
    ([85821 "Re: Best method to disable TAB in topic-mode?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Sun, 01 Mar 2015 11:03:42 +0800" "<87d24tpgfl.fsf@ericabrahamsen.net>" "<87ioem5dpf.fsf@pedroche.home> <87wq32w1ml.fsf@igel.home> <87a8zy53k2.fsf@pedroche.home>" 3459 19 "news.gmane.org gmane.emacs.gnus.general:85821" nil]
     ([85822 "Re: Best method to disable TAB in topic-mode?" "Igor Sosa Mayor <joseleopoldo1792@gmail.com>" "Sun, 01 Mar 2015 08:05:04 +0100" "<87zj7x42qn.fsf@pedroche.home>" "<87ioem5dpf.fsf@pedroche.home> <87wq32w1ml.fsf@igel.home> <87a8zy53k2.fsf@pedroche.home> <87d24tpgfl.fsf@ericabrahamsen.net>" 3392 15 "news.gmane.org gmane.emacs.gnus.general:85822" nil])))))
 ([85514 "Re: Couldn't store article in group" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:07:42 +1100" "<87lhkqjib5.fsf@building.gnus.org>" "<87d2888b57.fsf@grothesque.org> <874mtjh7n6.fsf@grothesque.org>" 3737 24 "news.gmane.org gmane.emacs.gnus.general:85514" nil]
  ([85537 "Re: Couldn't store article in group" "Christoph Groth <christoph@grothesque.org>" "Mon, 26 Jan 2015 23:13:18 +0100" "<878ugpp4w1.fsf@grothesque.org>" "<87d2888b57.fsf@grothesque.org> <874mtjh7n6.fsf@grothesque.org> <87lhkqjib5.fsf@building.gnus.org>" 4741 70 "news.gmane.org gmane.emacs.gnus.general:85537" nil]
   ([85538 "Re: Couldn't store article in group" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 11:50:59 +1100" "<87twzddp1o.fsf@building.gnus.org>" "<87d2888b57.fsf@grothesque.org> <874mtjh7n6.fsf@grothesque.org> <87lhkqjib5.fsf@building.gnus.org> <878ugpp4w1.fsf@grothesque.org>" 3942 31 "news.gmane.org gmane.emacs.gnus.general:85538" nil]
    ([85628 "Re: Couldn't store article in group" "Alan Schmitt <alan.schmitt@polytechnique.org>" "Wed, 28 Jan 2015 13:56:05 +0100" "<m2lhknnjx6.fsf@polytechnique.org>" "<87d2888b57.fsf@grothesque.org> <874mtjh7n6.fsf@grothesque.org> <87lhkqjib5.fsf@building.gnus.org> <878ugpp4w1.fsf@grothesque.org> <87twzddp1o.fsf@building.gnus.org>" 4577 47 "news.gmane.org gmane.emacs.gnus.general:85628" nil]
     ([85641 "Re: Couldn't store article in group" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 12:37:19 +1100" "<87r3uenz8w.fsf@building.gnus.org>" "<87d2888b57.fsf@grothesque.org> <874mtjh7n6.fsf@grothesque.org> <87lhkqjib5.fsf@building.gnus.org> <878ugpp4w1.fsf@grothesque.org> <87twzddp1o.fsf@building.gnus.org> <m2lhknnjx6.fsf@polytechnique.org>" 3447 14 "news.gmane.org gmane.emacs.gnus.general:85641" nil])))))
 ([85552 "Re: bug: S/MIME and gnus-message-replyencrypt" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 14:07:55 +1100" "<87ppa0c450.fsf@building.gnus.org>" "<87fvfh71pi.fsf@grothesque.org>" 3602 19 "news.gmane.org gmane.emacs.gnus.general:85552" nil])
 ([85553
   #("Re: Verbose “security buttons”" 12 30
     (charset windows-1252))
   "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 14:05:43 +1100" "<87twzcc48o.fsf@building.gnus.org>" "<87mw9p6nsq.fsf@grothesque.org>" 3486 22 "news.gmane.org gmane.emacs.gnus.general:85553" nil])
 ([85554 "Re: [PATCH] Re: SMIME: intermediate certificates are not sent" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 14:11:49 +1100" "<87lhkoc3yi.fsf@building.gnus.org>" "<87vbof6f2o.fsf@grothesque.org> <87oau7q0al.fsf@grothesque.org>" 3523 18 "news.gmane.org gmane.emacs.gnus.general:85554" nil])
 ([85567 "Re: Soft-wrapping HTML messages" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 16:23:17 +1100" "<87a914ajay.fsf@building.gnus.org>" "<874mwp888s.fsf@grothesque.org>" 3289 14 "news.gmane.org gmane.emacs.gnus.general:85567" nil])
 ([85601 "Re: move article painfully slow over imap" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 14:48:30 +1100" "<87fvavzhtd.fsf@building.gnus.org>" "<87silhgmif.fsf@gmail.com>" 3563 18 "news.gmane.org gmane.emacs.gnus.general:85601" nil])
 ([85615 "Re: mail-header-separator starting with whitespace fails" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 16:49:25 +1100" "<87y4onwj2y.fsf@building.gnus.org>" "<87r43xvdx3.fsf@windlord.stanford.edu> <b4mfvkdb399.fsf@jpl.org>" 4045 31 "news.gmane.org gmane.emacs.gnus.general:85615" nil]
  ([85624 "Re: mail-header-separator starting with whitespace fails" "Katsumi Yamaoka <yamaoka@jpl.org>" "Wed, 28 Jan 2015 17:33:53 +0900" "<b4mh9vbjocu.fsf@jpl.org>" "<87r43xvdx3.fsf@windlord.stanford.edu> <b4mfvkdb399.fsf@jpl.org> <87y4onwj2y.fsf@building.gnus.org>" 3946 17 "news.gmane.org gmane.emacs.gnus.general:85624" nil]
   ([85645 "Re: mail-header-separator starting with whitespace fails" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 12:47:30 +1100" "<87bnlinyrx.fsf@building.gnus.org>" "<87r43xvdx3.fsf@windlord.stanford.edu> <b4mfvkdb399.fsf@jpl.org> <87y4onwj2y.fsf@building.gnus.org> <b4mh9vbjocu.fsf@jpl.org>" 3533 20 "news.gmane.org gmane.emacs.gnus.general:85645" nil]
    ([85649 "Re: mail-header-separator starting with whitespace fails" "Katsumi Yamaoka <yamaoka@jpl.org>" "Thu, 29 Jan 2015 11:31:26 +0900" "<b4mbnlil3lt.fsf@jpl.org>" "<87r43xvdx3.fsf@windlord.stanford.edu> <b4mfvkdb399.fsf@jpl.org> <87y4onwj2y.fsf@building.gnus.org> <b4mh9vbjocu.fsf@jpl.org> <87bnlinyrx.fsf@building.gnus.org>" 3707 11 "news.gmane.org gmane.emacs.gnus.general:85649" nil]))))
 ([85358 "Re: Capturing outgoing gnus e-mail" "Uwe Brauer <oub@mat.ucm.es>" "Sun, 14 Dec 2014 23:58:36 +0100" "<87wq5trg83.fsf@mat.ucm.es>" "<8761k3rivi.fsf@kanis.fr> <87ppekk9wc.fsf@lifelogs.com>" 12278 147 "news.gmane.org gmane.emacs.gnus.general:85358 gmane.emacs.orgmode:93468" nil])
 ([85543 "Re: check mtime of newsrc.eld before saving it" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 12:40:40 +1100" "<87twzdc86f.fsf@building.gnus.org>" "<m2sij060b7.fsf@lifelogs.com>" 3604 27 "news.gmane.org gmane.emacs.gnus.general:85543" nil]
  ([85711 "Re: check mtime of newsrc.eld before saving it" "Ted Zlatanov <tzz@lifelogs.com>" "Wed, 04 Feb 2015 06:39:44 -0500" "<8761bhzz0f.fsf@lifelogs.com>" "<m2sij060b7.fsf@lifelogs.com> <87twzdc86f.fsf@building.gnus.org>" 4735 37 "news.gmane.org gmane.emacs.gnus.general:85711" nil]
   ([85717 "Re: check mtime of newsrc.eld before saving it" "Steinar Bang <sb@dod.no>" "Wed, 04 Feb 2015 22:05:11 +0100" "<upzc1tm5crqw.fsf@dod.no>" "<m2sij060b7.fsf@lifelogs.com> <87twzdc86f.fsf@building.gnus.org> <8761bhzz0f.fsf@lifelogs.com>" 3266 10 "news.gmane.org gmane.emacs.gnus.general:85717" nil]
    ([85722 "Re: check mtime of newsrc.eld before saving it" "Ted Zlatanov <tzz@lifelogs.com>" "Wed, 04 Feb 2015 17:40:43 -0500" "<878ugdxpuc.fsf@lifelogs.com>" "<m2sij060b7.fsf@lifelogs.com> <87twzdc86f.fsf@building.gnus.org> <8761bhzz0f.fsf@lifelogs.com> <upzc1tm5crqw.fsf@dod.no>" 3691 13 "news.gmane.org gmane.emacs.gnus.general:85722" nil]))
   ([85730 "Re: check mtime of newsrc.eld before saving it" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:13:09 +1100" "<8761bhvynu.fsf@building.gnus.org>" "<m2sij060b7.fsf@lifelogs.com> <87twzdc86f.fsf@building.gnus.org> <8761bhzz0f.fsf@lifelogs.com>" 3560 19 "news.gmane.org gmane.emacs.gnus.general:85730" nil]
    ([85738 "Re: check mtime of newsrc.eld before saving it" "Ted Zlatanov <tzz@lifelogs.com>" "Wed, 04 Feb 2015 23:08:21 -0500" "<87zj8tvw3u.fsf@lifelogs.com>" "<m2sij060b7.fsf@lifelogs.com> <87twzdc86f.fsf@building.gnus.org> <8761bhzz0f.fsf@lifelogs.com> <8761bhvynu.fsf@building.gnus.org>" 4289 24 "news.gmane.org gmane.emacs.gnus.general:85738" nil]
     ([85740 "Re: check mtime of newsrc.eld before saving it" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 15:40:53 +1100" "<87fvalynqi.fsf@building.gnus.org>" "<m2sij060b7.fsf@lifelogs.com> <87twzdc86f.fsf@building.gnus.org> <8761bhzz0f.fsf@lifelogs.com> <8761bhvynu.fsf@building.gnus.org> <87zj8tvw3u.fsf@lifelogs.com>" 3275 13 "news.gmane.org gmane.emacs.gnus.general:85740" nil]
      ([85749 "Re: check mtime of newsrc.eld before saving it" "Steinar Bang <sb@dod.no>" "Thu, 05 Feb 2015 11:49:56 +0100" "<upzcwq3waazv.fsf@dod.no>" "<m2sij060b7.fsf@lifelogs.com> <87twzdc86f.fsf@building.gnus.org> <8761bhzz0f.fsf@lifelogs.com> <8761bhvynu.fsf@building.gnus.org> <87zj8tvw3u.fsf@lifelogs.com> <87fvalynqi.fsf@building.gnus.org>" 3585 13 "news.gmane.org gmane.emacs.gnus.general:85749" nil])))))
  ([85751 "Re: check mtime of newsrc.eld before saving it" "Ted Zlatanov <tzz@lifelogs.com>" "Thu, 05 Feb 2015 05:59:43 -0500" "<87k2zwwrmo.fsf@lifelogs.com>" "<m2sij060b7.fsf@lifelogs.com> <87twzdc86f.fsf@building.gnus.org>" 3943 21 "news.gmane.org gmane.emacs.gnus.general:85751" nil]
   ([85775 "Re: check mtime of newsrc.eld before saving it" "Lars Ingebrigtsen <larsi@gnus.org>" "Fri, 13 Feb 2015 17:25:58 +1100" "<87r3tufhu1.fsf@building.gnus.org>" "<m2sij060b7.fsf@lifelogs.com> <87twzdc86f.fsf@building.gnus.org> <87k2zwwrmo.fsf@lifelogs.com>" 3280 16 "news.gmane.org gmane.emacs.gnus.general:85775" nil])))
 ([85445 "Re: Performance problem of IMAP move (Gmail)" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Wed, 7 Jan 2015 14:58:34 +0000" "<878uhey6w5.fsf@ucl.ac.uk>" "<b64e5c67-1659-4d47-b7bd-216a0f6ddb54@googlegroups.com> <m3zj9v3vrc.fsf@example.com>" 5593 43 "news.gmane.org gmane.emacs.gnus.general:85445" nil])
 ([85786 "Re: anti top-posting gnus-article-outlook-rearrange-citation fails for gmail. II" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 18 Feb 2015 12:07:14 +1100" "<87zj8cauyl.fsf@building.gnus.org>" "<874mvp9rcf.fsf@mat.ucm.es> <87y4opapse.fsf@building.gnus.org> <87wq3kpkir.fsf@mat.ucm.es>" 3725 26 "news.gmane.org gmane.emacs.gnus.general:85786" nil])
 ([85359 "Re: Capturing outgoing gnus e-mail" "Uwe Brauer <oub@mat.ucm.es>" "Mon, 15 Dec 2014 13:08:29 +0100" "<87a92pxgi5.fsf@mat.ucm.es>" "<8761k3rivi.fsf@kanis.fr> <87mwdfg8tt.fsf@bzg.ath.cx>" 13565 152 "news.gmane.org gmane.emacs.orgmode:93474 gmane.emacs.gnus.general:85359" nil])
 ([85522 "Re: gnus-delay fails partially" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 16:03:26 +1100" "<87k30ai15t.fsf@building.gnus.org>" "<87iojma2iu.fsf@gmail.com>" 3233 15 "news.gmane.org gmane.emacs.gnus.general:85522" nil])
 ([85516 "Re: autoloads only generated on every 2nd make" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:13:28 +1100" "<87bnlmji1j.fsf@building.gnus.org>" "<87wq6qfidr.fsf@thinkpad-t440p.tsdh.org>" 3545 23 "news.gmane.org gmane.emacs.gnus.general:85516" nil]
  ([85528 "Re: autoloads only generated on every 2nd make" "Tassilo Horn <tsdh@gnu.org>" "Mon, 26 Jan 2015 08:15:56 +0100" "<87twze2es3.fsf@gnu.org>" "<87wq6qfidr.fsf@thinkpad-t440p.tsdh.org> <87bnlmji1j.fsf@building.gnus.org>" 4773 52 "news.gmane.org gmane.emacs.gnus.general:85528" nil]
   ([85534 "Re: autoloads only generated on every 2nd make" "Tassilo Horn <tsdh@gnu.org>" "Mon, 26 Jan 2015 16:14:10 +0100" "<87oapl1sn1.fsf@gnu.org>" "<87wq6qfidr.fsf@thinkpad-t440p.tsdh.org> <87bnlmji1j.fsf@building.gnus.org> <87twze2es3.fsf@gnu.org>" 3429 21 "news.gmane.org gmane.emacs.gnus.general:85534" nil])))
 ([85521 "Re: Non-integer score nil in /home/horn/.gnus.d/News/nntp+Gmane:gmane.emacs.auctex.general.SCORE" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:58:09 +1100" "<87oapmi1em.fsf@building.gnus.org>" "<874mv514kd.fsf@thinkpad-t440p.tsdh.org>" 3667 26 "news.gmane.org gmane.emacs.gnus.general:85521" nil]
  ([85526 "Re: Non-integer score nil in /home/horn/.gnus.d/News/nntp+Gmane:gmane.emacs.auctex.general.SCORE" "Tassilo Horn <tsdh@gnu.org>" "Mon, 26 Jan 2015 07:59:33 +0100" "<87y4oq2fje.fsf@gnu.org>" "<874mv514kd.fsf@thinkpad-t440p.tsdh.org> <87oapmi1em.fsf@building.gnus.org>" 3917 40 "news.gmane.org gmane.emacs.gnus.general:85526" nil]))
 ([85623 "Re: Need help: Where to debug \"Server closed connection\" opening Gmane NNTP groups with many unread articles on Windows?" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 17:29:46 +1100" "<871tmfwh7p.fsf@building.gnus.org>" "<864n1tzrb6.fsf@dod.no>" 3328 17 "news.gmane.org gmane.emacs.gnus.general:85623" nil]
  ([85626 "Re: Need help: Where to debug \"Server closed connection\" opening Gmane NNTP groups with many unread articles on Windows?" "Steinar Bang <sb@dod.no>" "Wed, 28 Jan 2015 11:46:37 +0100" "<upzch9vb18tu.fsf@dod.no>" "<864n1tzrb6.fsf@dod.no> <871tmfwh7p.fsf@building.gnus.org>" 4023 25 "news.gmane.org gmane.emacs.gnus.general:85626" nil]))
 ([85517 "Re: [PATCH] Accept new TLDs when validating FQDNs" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:16:13 +1100" "<877fwajhwy.fsf@building.gnus.org>" "<1416048795-30803-1-git-send-email-albert+gnus@zeitkraut.de> <m2oas6p6jv.fsf@danjou.info>" 3565 21 "news.gmane.org gmane.emacs.gnus.general:85517" nil])
 ([85327 "Re: merging monthly post-out directories." "asjo@koldfront.dk (Adam Sjøgren)" "Tue, 09 Dec 2014 19:39:54 +0100" "<87vblkacqt.fsf@koldfront.dk>" "<8761dmasht.fsf@skimble.plus.com>" 3771 25 "news.gmane.org gmane.emacs.gnus.general:85327" nil]
  ([85332 "Re: merging monthly post-out directories." "Xavier Maillard <xavier@maillard.im>" "Tue, 09 Dec 2014 22:30:29 +0100" "<m0zjaw5x56.fsf@kcals.intra.maillard.im>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk>" 4223 20 "news.gmane.org gmane.emacs.gnus.general:85332" nil])
  ([85338 "Re: merging monthly post-out directories." "Sharon Kimble <boudiccas@skimble.plus.com>" "Wed, 10 Dec 2014 02:36:35 +0000" "<87388o2pp0.fsf@skimble.plus.com>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk>" 5046 49 "news.gmane.org gmane.emacs.gnus.general:85338" nil]
   ([85339 "Re: merging monthly post-out directories." "asjo@koldfront.dk (Adam Sjøgren)" "Wed, 10 Dec 2014 11:25:10 +0100" "<87vblj94zd.fsf@topper.koldfront.dk>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com>" 4189 26 "news.gmane.org gmane.emacs.gnus.general:85339" nil]
    ([85340 "Re: merging monthly post-out directories." "Sharon Kimble <boudiccas@skimble.plus.com>" "Wed, 10 Dec 2014 14:20:42 +0000" "<87ppbrwpqd.fsf@skimble.plus.com>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com> <87vblj94zd.fsf@topper.koldfront.dk>" 5276 58 "news.gmane.org gmane.emacs.gnus.general:85340" nil]
     ([85341 "Re: merging monthly post-out directories." "asjo@koldfront.dk (Adam Sjøgren)" "Wed, 10 Dec 2014 15:32:55 +0100" "<87ppbr8tig.fsf@topper.koldfront.dk>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com> <87vblj94zd.fsf@topper.koldfront.dk> <87ppbrwpqd.fsf@skimble.plus.com>" 4505 36 "news.gmane.org gmane.emacs.gnus.general:85341" nil]
      ([85342 "Re: merging monthly post-out directories." "Sharon Kimble <boudiccas@skimble.plus.com>" "Thu, 11 Dec 2014 02:53:03 +0000" "<87d27qq4mo.fsf@skimble.plus.com>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com> <87vblj94zd.fsf@topper.koldfront.dk> <87ppbrwpqd.fsf@skimble.plus.com> <87ppbr8tig.fsf@topper.koldfront.dk>" 5773 74 "news.gmane.org gmane.emacs.gnus.general:85342" nil]
       ([85343 "Re: merging monthly post-out directories." "Xavier Maillard <xavier@maillard.im>" "Thu, 11 Dec 2014 06:57:00 +0100" "<m0tx12685v.fsf@kcals.intra.maillard.im>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com> <87vblj94zd.fsf@topper.koldfront.dk> <87ppbrwpqd.fsf@skimble.plus.com> <87ppbr8tig.fsf@topper.koldfront.dk> <87d27qq4mo.fsf@skimble.plus.com>" 4729 44 "news.gmane.org gmane.emacs.gnus.general:85343" nil])
       ([85349 "Re: merging monthly post-out directories." "asjo@koldfront.dk (Adam Sjøgren)" "Fri, 12 Dec 2014 23:02:13 +0100" "<87mw6sfrx6.fsf@topper.koldfront.dk>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com> <87vblj94zd.fsf@topper.koldfront.dk> <87ppbrwpqd.fsf@skimble.plus.com> <87ppbr8tig.fsf@topper.koldfront.dk> <87d27qq4mo.fsf@skimble.plus.com>" 4939 42 "news.gmane.org gmane.emacs.gnus.general:85349" nil]))))
    ([85428 "Re: merging monthly post-out directories." "Sharon Kimble <boudiccas@skimble.plus.com>" "Sun, 04 Jan 2015 18:04:25 +0000" "<87d26u5snq.fsf@skimble.plus.com>" "<8761dmasht.fsf@skimble.plus.com> <87vblkacqt.fsf@koldfront.dk> <87388o2pp0.fsf@skimble.plus.com> <87vblj94zd.fsf@topper.koldfront.dk>" 5435 37 "news.gmane.org gmane.emacs.gnus.general:85428" nil]))))
 ([85575 "Re: unwanted html in email/feeds" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 18:14:19 +1100" "<87iofs8zlg.fsf@building.gnus.org>" "<87y4u4v80n.fsf@skimble.plus.com>" 3433 16 "news.gmane.org gmane.emacs.gnus.general:85575" nil])
 ([85577 "Re: nnrss.el brokem" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 18:16:23 +1100" "<87a9148zi0.fsf@building.gnus.org>" "<87vbpfry65.fsf@skimble.plus.com>" 3430 16 "news.gmane.org gmane.emacs.gnus.general:85577" nil])
 ([85360 "Re: [PATCH] Two issues with the gnus-registry" "Ted Zlatanov <tzz@lifelogs.com>" "Thu, 18 Dec 2014 05:07:17 -0500" "<87fvcdtgoa.fsf@lifelogs.com>" "<87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> <8761ej8fvx.fsf@ericabrahamsen.net>" 3837 11 "news.gmane.org gmane.emacs.gnus.general:85360" nil]
  ([85361 "Re: [PATCH] Two issues with the gnus-registry" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Thu, 18 Dec 2014 23:00:25 +0800" "<87r3vxq9yu.fsf@ericabrahamsen.net>" "<87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> <8761ej8fvx.fsf@ericabrahamsen.net> <87fvcdtgoa.fsf@lifelogs.com>" 4940 17 "news.gmane.org gmane.emacs.gnus.general:85361" nil]
   ([85362 "Re: [PATCH] Two issues with the gnus-registry" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Thu, 18 Dec 2014 23:09:41 +0800" "<87mw6lq9je.fsf@ericabrahamsen.net>" "<87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> <8761ej8fvx.fsf@ericabrahamsen.net> <87fvcdtgoa.fsf@lifelogs.com> <87r3vxq9yu.fsf@ericabrahamsen.net>" 5228 24 "news.gmane.org gmane.emacs.gnus.general:85362" nil]
    ([85368 "Re: [PATCH] Two issues with the gnus-registry" "Katsumi Yamaoka <yamaoka@jpl.org>" "Fri, 19 Dec 2014 09:44:49 +0900" "<b4mh9wsii2m.fsf@jpl.org>" "<87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> <8761ej8fvx.fsf@ericabrahamsen.net> <87fvcdtgoa.fsf@lifelogs.com> <87r3vxq9yu.fsf@ericabrahamsen.net> <87mw6lq9je.fsf@ericabrahamsen.net>" 5177 34 "news.gmane.org gmane.emacs.gnus.general:85368" nil]
     ([85370 "Re: [PATCH] Two issues with the gnus-registry" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Fri, 19 Dec 2014 10:08:56 +0800" "<8761d8qtl3.fsf@ericabrahamsen.net>" "<87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> <8761ej8fvx.fsf@ericabrahamsen.net> <87fvcdtgoa.fsf@lifelogs.com> <87r3vxq9yu.fsf@ericabrahamsen.net> <87mw6lq9je.fsf@ericabrahamsen.net> <b4mh9wsii2m.fsf@jpl.org>" 6493 45 "news.gmane.org gmane.emacs.gnus.general:85370" nil])
     ([85376 "Re: [PATCH] Two issues with the gnus-registry" "Ted Zlatanov <tzz@lifelogs.com>" "Fri, 19 Dec 2014 22:09:34 -0500" "<877fxnt3td.fsf@lifelogs.com>" "<87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> <8761ej8fvx.fsf@ericabrahamsen.net> <87fvcdtgoa.fsf@lifelogs.com> <87r3vxq9yu.fsf@ericabrahamsen.net> <87mw6lq9je.fsf@ericabrahamsen.net> <b4mh9wsii2m.fsf@jpl.org>" 4053 14 "news.gmane.org gmane.emacs.gnus.general:85376" nil]
      ([85380 "Re: [PATCH] Two issues with the gnus-registry" "Katsumi Yamaoka <yamaoka@jpl.org>" "Sat, 20 Dec 2014 20:22:33 +0900" "<b4mbnmysgzq.fsf@jpl.org>" "<87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> <8761ej8fvx.fsf@ericabrahamsen.net> <87fvcdtgoa.fsf@lifelogs.com> <87r3vxq9yu.fsf@ericabrahamsen.net> <87mw6lq9je.fsf@ericabrahamsen.net> <b4mh9wsii2m.fsf@jpl.org> <877fxnt3td.fsf@lifelogs.com>" 3683 8 "news.gmane.org gmane.emacs.gnus.general:85380" nil]
       ([85382 "Older Emacsen (was: [PATCH] Two issues with the gnus-registry)" "Ted Zlatanov <tzz@lifelogs.com>" "Sat, 20 Dec 2014 08:53:03 -0500" "<87ppbesa0w.fsf_-_@lifelogs.com>" "<87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> <8761ej8fvx.fsf@ericabrahamsen.net> <87fvcdtgoa.fsf@lifelogs.com> <87r3vxq9yu.fsf@ericabrahamsen.net> <87mw6lq9je.fsf@ericabrahamsen.net> <b4mh9wsii2m.fsf@jpl.org> <877fxnt3td.fsf@lifelogs.com> <b4mbnmysgzq.fsf@jpl.org>" 4073 13 "news.gmane.org gmane.emacs.gnus.general:85382" nil]))))
    ([85369 "Re: [PATCH] Two issues with the gnus-registry" "Ted Zlatanov <tzz@lifelogs.com>" "Thu, 18 Dec 2014 20:30:27 -0500" "<m2h9wso28c.fsf@lifelogs.com>" "<87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> <8761ej8fvx.fsf@ericabrahamsen.net> <87fvcdtgoa.fsf@lifelogs.com> <87r3vxq9yu.fsf@ericabrahamsen.net> <87mw6lq9je.fsf@ericabrahamsen.net>" 4110 15 "news.gmane.org gmane.emacs.gnus.general:85369" nil]))))
 ([85583 "Re: [gmane.emacs.gnus.user] Re: One folder in local imap not seen" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 18:34:36 +1100" "<87egqg7k37.fsf@building.gnus.org>" "<m2fvh1n83a.fsf@krugs.de> <87mwb9wb4o.fsf@ericabrahamsen.net> <m2iolw7p8m.fsf@krugs.de> <87vbpwvjj0.fsf@ericabrahamsen.net> <m2egwk7li2.fsf@krugs.de> <87a978vfdl.fsf@ericabrahamsen.net>" 3618 16 "news.gmane.org gmane.emacs.gnus.general:85583" nil]
  ([85589 "Re: [gmane.emacs.gnus.user] Re: One folder in local imap not seen" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 27 Jan 2015 22:37:05 +0800" "<87d260e1da.fsf@ericabrahamsen.net>" "<m2fvh1n83a.fsf@krugs.de> <87mwb9wb4o.fsf@ericabrahamsen.net> <m2iolw7p8m.fsf@krugs.de> <87vbpwvjj0.fsf@ericabrahamsen.net> <m2egwk7li2.fsf@krugs.de> <87a978vfdl.fsf@ericabrahamsen.net> <87egqg7k37.fsf@building.gnus.org>" 5224 17 "news.gmane.org gmane.emacs.gnus.general:85589" nil]
   ([85595 "Re: [gmane.emacs.gnus.user] Re: One folder in local imap not seen" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 11:45:35 +1100" "<87mw5320nk.fsf@building.gnus.org>" "<m2fvh1n83a.fsf@krugs.de> <87mwb9wb4o.fsf@ericabrahamsen.net> <m2iolw7p8m.fsf@krugs.de> <87vbpwvjj0.fsf@ericabrahamsen.net> <m2egwk7li2.fsf@krugs.de> <87a978vfdl.fsf@ericabrahamsen.net> <87egqg7k37.fsf@building.gnus.org> <87d260e1da.fsf@ericabrahamsen.net>" 3902 24 "news.gmane.org gmane.emacs.gnus.general:85595" nil])))
 ([85570 "Re: nnir imap with gmail: query encoding" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 16:37:36 +1100" "<87vbjs942n.fsf@building.gnus.org>" "<8761h7z19s.fsf@gmail.com> <87iol7w6uv.fsf@gmail.com> <87zjehh36x.fsf@ericabrahamsen.net> <877g1kkdnh.fsf@andy.bu.edu> <87mwadjrwb.fsf@ericabrahamsen.net>" 4310 32 "news.gmane.org gmane.emacs.gnus.general:85570" nil]
  ([85571 "Re: nnir imap with gmail: query encoding" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 27 Jan 2015 14:01:51 +0800" "<87bnlkpxrk.fsf@ericabrahamsen.net>" "<8761h7z19s.fsf@gmail.com> <87iol7w6uv.fsf@gmail.com> <87zjehh36x.fsf@ericabrahamsen.net> <877g1kkdnh.fsf@andy.bu.edu> <87mwadjrwb.fsf@ericabrahamsen.net> <87vbjs942n.fsf@building.gnus.org>" 6196 40 "news.gmane.org gmane.emacs.gnus.general:85571" nil]
   ([85572 "Re: nnir imap with gmail: query encoding" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 17:24:26 +1100" "<87r3ug91wl.fsf@building.gnus.org>" "<8761h7z19s.fsf@gmail.com> <87iol7w6uv.fsf@gmail.com> <87zjehh36x.fsf@ericabrahamsen.net> <877g1kkdnh.fsf@andy.bu.edu> <87mwadjrwb.fsf@ericabrahamsen.net> <87vbjs942n.fsf@building.gnus.org> <87bnlkpxrk.fsf@ericabrahamsen.net>" 3534 17 "news.gmane.org gmane.emacs.gnus.general:85572" nil]
    ([85573 "Re: nnir imap with gmail: query encoding" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 17:32:53 +1100" "<87mw5491ii.fsf@building.gnus.org>" "<8761h7z19s.fsf@gmail.com> <87iol7w6uv.fsf@gmail.com> <87zjehh36x.fsf@ericabrahamsen.net> <877g1kkdnh.fsf@andy.bu.edu> <87mwadjrwb.fsf@ericabrahamsen.net> <87vbjs942n.fsf@building.gnus.org> <87bnlkpxrk.fsf@ericabrahamsen.net> <87r3ug91wl.fsf@building.gnus.org>" 3301 9 "news.gmane.org gmane.emacs.gnus.general:85573" nil]
     ([85574 "Re: nnir imap with gmail: query encoding" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 27 Jan 2015 14:48:11 +0800" "<877fw8pvmc.fsf@ericabrahamsen.net>" "<8761h7z19s.fsf@gmail.com> <87iol7w6uv.fsf@gmail.com> <87zjehh36x.fsf@ericabrahamsen.net> <877g1kkdnh.fsf@andy.bu.edu> <87mwadjrwb.fsf@ericabrahamsen.net> <87vbjs942n.fsf@building.gnus.org> <87bnlkpxrk.fsf@ericabrahamsen.net> <87r3ug91wl.fsf@building.gnus.org> <87mw5491ii.fsf@building.gnus.org>" 4863 10 "news.gmane.org gmane.emacs.gnus.general:85574" nil])))))
 ([85609 "Re: nnml-active-number: no such function" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 16:15:59 +1100" "<87lhknxz74.fsf@building.gnus.org>" "<87lhsq18nu.fsf@ericabrahamsen.net>" 3790 24 "news.gmane.org gmane.emacs.gnus.general:85609" nil]
  ([85616 "Re: nnml-active-number: no such function" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 28 Jan 2015 13:58:17 +0800" "<87egqf8n0m.fsf@ericabrahamsen.net>" "<87lhsq18nu.fsf@ericabrahamsen.net> <87lhknxz74.fsf@building.gnus.org>" 4872 28 "news.gmane.org gmane.emacs.gnus.general:85616" nil]))
 ([85613 "Re: Strip signature on reply" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 16:39:49 +1100" "<87386vxy3e.fsf@building.gnus.org>" "<87zji2phm3.fsf@atmarama.net>" 3745 30 "news.gmane.org gmane.emacs.gnus.general:85613" nil])
 ([85617 "Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 17:02:54 +1100" "<87pp9zwigh.fsf@building.gnus.org>" "<87mweubcp5.fsf@ericabrahamsen.net>" 3511 17 "news.gmane.org gmane.emacs.gnus.general:85617" nil]
  ([85619 "Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Wed, 28 Jan 2015 14:22:21 +0800" "<877fw78lwi.fsf@ericabrahamsen.net>" "<87mweubcp5.fsf@ericabrahamsen.net> <87pp9zwigh.fsf@building.gnus.org>" 4412 17 "news.gmane.org gmane.emacs.gnus.general:85619" nil]
   ([85621 "Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 17:19:39 +1100" "<87a913whok.fsf@building.gnus.org>" "<87mweubcp5.fsf@ericabrahamsen.net> <87pp9zwigh.fsf@building.gnus.org> <877fw78lwi.fsf@ericabrahamsen.net>" 3143 11 "news.gmane.org gmane.emacs.gnus.general:85621" nil])))
 ([85564 "Re: gnus uses a cache?  And how it affects mairix searches..." "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 16:03:25 +1100" "<87r3ugak82.fsf@building.gnus.org>" "<87oaus4brr.fsf@skimble.plus.com> <m3lhpvwlwa.fsf@carbon.jhcloos.org> <8761gyvr67.fsf_-_@uwo.ca> <87y4saicdd.fsf@uwo.ca> <87vbn9h55q.fsf@ericabrahamsen.net> <87k33kuux3.fsf@uwo.ca> <874muonktk.fsf@igel.home> <878ujhnqco.fsf@ericabrahamsen.net> <87vbmlm7yq.fsf@ericabrahamsen.net> <87oasc5csk.fsf@uwo.ca> <87r3x8q71r.fsf@ericabrahamsen.net> <87fvdkyn62.fsf@uwo.ca> <87vbmf3jfx.fsf@ericabrahamsen.net>" 3425 11 "news.gmane.org gmane.emacs.gnus.general:85564" nil])
 ([85618 "Re: eval'ing message-use-idna defcustom hangs emacs" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 17:12:03 +1100" "<87lhknwi18.fsf@building.gnus.org>" "<87zjjcdcn1.fsf@ericabrahamsen.net>" 4783 31 "news.gmane.org gmane.emacs.help:102329 gmane.emacs.gnus.general:85618" nil]
  ([85632 "Re: eval'ing message-use-idna defcustom hangs emacs" "Eli Zaretskii <eliz@gnu.org>" "Wed, 28 Jan 2015 17:32:43 +0200" "<83pp9yor8k.fsf@gnu.org>" "<87zjjcdcn1.fsf@ericabrahamsen.net> <87lhknwi18.fsf@building.gnus.org>" 3860 11 "news.gmane.org gmane.emacs.help:102333 gmane.emacs.gnus.general:85632" nil]
   ([85670 "Re: eval'ing message-use-idna defcustom hangs emacs" "Jason L Tibbitts III <tibbs@math.uh.edu>" "Thu, 29 Jan 2015 16:36:37 -0600" "<ufaa9112ozu.fsf@epithumia.math.uh.edu>" "<87zjjcdcn1.fsf@ericabrahamsen.net> <87lhknwi18.fsf@building.gnus.org> <83pp9yor8k.fsf@gnu.org>" 3394 19 "news.gmane.org gmane.emacs.gnus.general:85670 gmane.emacs.help:102372" nil])))
 ([85578 "Re: nnml group has move messages than gnus sees" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 18:19:40 +1100" "<8761bs8zcj.fsf@building.gnus.org>" "<87lhqd4n67.fsf@reader.local.lan>" 3405 24 "news.gmane.org gmane.emacs.gnus.general:85578" nil])
 ([85518 "Re: Extend nnimap to request Gmail labels with message headers" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:31:40 +1100" "<87386yjh77.fsf@building.gnus.org>" "<1415668163-29280-1-git-send-email-trevor.m.murphy@gmail.com>" 3573 24 "news.gmane.org gmane.emacs.gnus.general:85518" nil]
  ([85524 "Re: Extend nnimap to request Gmail labels with message headers" "Trevor Murphy <trevor.m.murphy@gmail.com>" "Mon, 26 Jan 2015 00:44:35 -0500" "<87ppa2t7ss.fsf@gmail.com>" "<1415668163-29280-1-git-send-email-trevor.m.murphy@gmail.com> <87386yjh77.fsf@building.gnus.org>" 3967 12 "news.gmane.org gmane.emacs.gnus.general:85524" nil]
   ([85527 "Re: Extend nnimap to request Gmail labels with message headers" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 18:12:38 +1100" "<87lhkqggm1.fsf@building.gnus.org>" "<1415668163-29280-1-git-send-email-trevor.m.murphy@gmail.com> <87386yjh77.fsf@building.gnus.org> <87ppa2t7ss.fsf@gmail.com>" 3318 17 "news.gmane.org gmane.emacs.gnus.general:85527" nil]
    ([85530 "Re: Extend nnimap to request Gmail labels with message headers" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 20:41:00 +1100" "<87ppa1hob7.fsf@building.gnus.org>" "<1415668163-29280-1-git-send-email-trevor.m.murphy@gmail.com> <87386yjh77.fsf@building.gnus.org> <87ppa2t7ss.fsf@gmail.com> <87lhkqggm1.fsf@building.gnus.org>" 3552 22 "news.gmane.org gmane.emacs.gnus.general:85530" nil]
     ([85665 "Re: Extend nnimap to request Gmail labels with message headers" "Trevor Murphy <trevor.m.murphy@gmail.com>" "Thu, 29 Jan 2015 13:13:42 -0500" "<87zj91a209.fsf@gmail.com>" "<1415668163-29280-1-git-send-email-trevor.m.murphy@gmail.com> <87386yjh77.fsf@building.gnus.org> <87ppa2t7ss.fsf@gmail.com> <87lhkqggm1.fsf@building.gnus.org> <87ppa1hob7.fsf@building.gnus.org>" 6096 31 "news.gmane.org gmane.emacs.gnus.general:85665" nil]
      ([85712 "Re: Extend nnimap to request Gmail labels with message headers" "Ted Zlatanov <tzz@lifelogs.com>" "Wed, 04 Feb 2015 06:40:48 -0500" "<871tm5zyyn.fsf@lifelogs.com>" "<1415668163-29280-1-git-send-email-trevor.m.murphy@gmail.com> <87386yjh77.fsf@building.gnus.org> <87ppa2t7ss.fsf@gmail.com> <87lhkqggm1.fsf@building.gnus.org> <87ppa1hob7.fsf@building.gnus.org> <87zj91a209.fsf@gmail.com>" 4186 20 "news.gmane.org gmane.emacs.gnus.general:85712" nil]
       ([85726 "Re: Extend nnimap to request Gmail labels with message headers" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 13:38:41 +1100" "<87k2zxw09a.fsf@building.gnus.org>" "<1415668163-29280-1-git-send-email-trevor.m.murphy@gmail.com> <87386yjh77.fsf@building.gnus.org> <87ppa2t7ss.fsf@gmail.com> <87lhkqggm1.fsf@building.gnus.org> <87ppa1hob7.fsf@building.gnus.org> <87zj91a209.fsf@gmail.com> <871tm5zyyn.fsf@lifelogs.com>" 3751 28 "news.gmane.org gmane.emacs.gnus.general:85726" nil]
        ([85739 "Re: Extend nnimap to request Gmail labels with message headers" "Ted Zlatanov <tzz@lifelogs.com>" "Wed, 04 Feb 2015 23:09:14 -0500" "<87vbjhvw2d.fsf@lifelogs.com>" "<1415668163-29280-1-git-send-email-trevor.m.murphy@gmail.com> <87386yjh77.fsf@building.gnus.org> <87ppa2t7ss.fsf@gmail.com> <87lhkqggm1.fsf@building.gnus.org> <87ppa1hob7.fsf@building.gnus.org> <87zj91a209.fsf@gmail.com> <871tm5zyyn.fsf@lifelogs.com> <87k2zxw09a.fsf@building.gnus.org>" 4008 16 "news.gmane.org gmane.emacs.gnus.general:85739" nil]
         ([85741 "Re: Extend nnimap to request Gmail labels with message headers" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 15:42:37 +1100" "<87bnl9ynnm.fsf@building.gnus.org>" "<1415668163-29280-1-git-send-email-trevor.m.murphy@gmail.com> <87386yjh77.fsf@building.gnus.org> <87ppa2t7ss.fsf@gmail.com> <87lhkqggm1.fsf@building.gnus.org> <87ppa1hob7.fsf@building.gnus.org> <87zj91a209.fsf@gmail.com> <871tm5zyyn.fsf@lifelogs.com> <87k2zxw09a.fsf@building.gnus.org> <87vbjhvw2d.fsf@lifelogs.com>" 3686 21 "news.gmane.org gmane.emacs.gnus.general:85741" nil]))))
      ([85725 "Re: Extend nnimap to request Gmail labels with message headers" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 13:36:06 +1100" "<87oap9w0dl.fsf@building.gnus.org>" "<1415668163-29280-1-git-send-email-trevor.m.murphy@gmail.com> <87386yjh77.fsf@building.gnus.org> <87ppa2t7ss.fsf@gmail.com> <87lhkqggm1.fsf@building.gnus.org> <87ppa1hob7.fsf@building.gnus.org> <87zj91a209.fsf@gmail.com>" 3529 16 "news.gmane.org gmane.emacs.gnus.general:85725" nil]))))))
 ([85620 "Re: spell checking message buffer" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 17:16:23 +1100" "<87h9vbwhu0.fsf@building.gnus.org>" "<874n1n9urz.fsf@micropit.couberia.selfip.net> <b4mha5nz1gh.fsf@jpl.org> <87sip65wk2.fsf@micropit.couberia.selfip.net> <87zjdoisvf.fsf@lifelogs.com> <87lhp7icea.fsf@micropit.roche-blanche.homenet.org>" 3535 16 "news.gmane.org gmane.emacs.gnus.general:85620" nil]
  ([85633 "Re: spell checking message buffer" "Peter Münster <pmlists@free.fr>" "Wed, 28 Jan 2015 17:45:11 +0100" "<87vbjqx3ag.fsf@roche-blanche.net>" "<874n1n9urz.fsf@micropit.couberia.selfip.net> <b4mha5nz1gh.fsf@jpl.org> <87sip65wk2.fsf@micropit.couberia.selfip.net> <87zjdoisvf.fsf@lifelogs.com> <87lhp7icea.fsf@micropit.roche-blanche.homenet.org> <87h9vbwhu0.fsf@building.gnus.org>" 3950 19 "news.gmane.org gmane.emacs.gnus.general:85633" nil]))
 ([85544 "Re: gnus-icalendar-identities and message-alternative-emails" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 12:44:06 +1100" "<87mw55c80p.fsf@building.gnus.org>" "<87wq8hfj2c.fsf@micropit.roche-blanche.homenet.org>" 3827 23 "news.gmane.org gmane.emacs.gnus.general:85544" nil])
 ([85562 "Re: Showing for certain groups the number of emails instead of the number of unread emails?" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 15:56:09 +1100" "<87vbjsakk6.fsf@building.gnus.org>" "<m2ppf1pb0g.fsf@krugs.de>" 3397 18 "news.gmane.org gmane.emacs.gnus.general:85562" nil])
 ([85688 "Re: Why do we need a number of different terminal modes in Emacs?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Sun, 1 Feb 2015 10:38:07 +0000" "<87pp9tzzlc.fsf@ucl.ac.uk>" "<m2egqa6sqt.fsf@gmail.com> <m2386qm7pm.fsf@gmail.com>" 4421 12 "news.gmane.org gmane.emacs.gnus.general:85688" nil]
  ([85690 "Re: Why do we need a number of different terminal modes in Emacs?" "Andrey Lisin <andrey.lisin@gmail.com>" "Sun, 01 Feb 2015 18:22:26 +0600" "<m2y4ohstx9.fsf@gmail.com>" "<m2egqa6sqt.fsf@gmail.com> <m2386qm7pm.fsf@gmail.com> <87pp9tzzlc.fsf@ucl.ac.uk>" 4045 12 "news.gmane.org gmane.emacs.gnus.general:85690" nil]))
 ([85523 "Re: Changes from gnus 5.13 (emacs 24.3) til now (git master)" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 16:08:12 +1100" "<87fvayi0xv.fsf@building.gnus.org>" "<87d2a0dl58.fsf@gmail.com>" 3391 15 "news.gmane.org gmane.emacs.gnus.general:85523" nil]
  ([85800 "Re: Changes from gnus 5.13 (emacs 24.3) til now (git master)" "Igor Sosa Mayor <joseleopoldo1792@gmail.com>" "Sun, 22 Feb 2015 09:14:35 +0100" "<87vbiupdlg.fsf@gmail.com>" "<87d2a0dl58.fsf@gmail.com> <87fvayi0xv.fsf@building.gnus.org>" 5646 21 "news.gmane.org gmane.emacs.gnus.general:85800" nil]))
 ([85550 "Re: anti top-posting gnus-article-outlook-rearrange-citation fails for gmail. II" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 14:03:13 +1100" "<87y4opapse.fsf@building.gnus.org>" "<874mvp9rcf.fsf@mat.ucm.es>" 3209 19 "news.gmane.org gmane.emacs.gnus.general:85550" nil])
 ([85788 "Re: flyspell in messages" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Wed, 18 Feb 2015 14:51:38 +0000" "<87zj8b8e85.fsf@ucl.ac.uk>" "<878ufvi9d1.fsf@engels.histomat.net>" 4990 18 "news.gmane.org gmane.emacs.gnus.general:85788" nil])
 ([85515 "Re: Prevent mails from being expired" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:11:34 +1100" "<87fvayji4p.fsf@building.gnus.org>" "<m1r3wuuys5.fsf@nobis-it.eu>" 4036 33 "news.gmane.org gmane.emacs.gnus.general:85515" nil])
 ([85546 "Re: Recent Emacs doesn't respect my mailcap" "Lars Magne Ingebrigtsen <lmi@gnus.org>" "Tue, 27 Jan 2015 12:58:32 +1100" "<87h9vdc7cn.fsf@building.gnus.org>" "<mailman.18666.1422291069.1147.help-gnu-emacs@gnu.org> <87386xf5gx.fsf@building.gnus.org> <mailman.18710.1422322318.1147.help-gnu-emacs@gnu.org> <87386xdmzp.fsf@building.gnus.org> <mailman.18712.1422322837.1147.help-gnu-emacs@gnu.org>" 4614 27 "news.gmane.org gmane.emacs.help:102304 gmane.emacs.gnus.general:85546" nil]
  ([85547 "Re: Recent Emacs doesn't respect my mailcap" "Rasmus <rasmus@gmx.us>" "Tue, 27 Jan 2015 03:11:32 +0100" "<87egqhrmzv.fsf@gmx.us>" "<mailman.18666.1422291069.1147.help-gnu-emacs@gnu.org> <87386xf5gx.fsf@building.gnus.org> <mailman.18710.1422322318.1147.help-gnu-emacs@gnu.org> <87386xdmzp.fsf@building.gnus.org> <mailman.18712.1422322837.1147.help-gnu-emacs@gnu.org> <87h9vdc7cn.fsf@building.gnus.org>" 6129 45 "news.gmane.org gmane.emacs.help:102305 gmane.emacs.gnus.general:85547" nil]
   ([85548 "Re: Recent Emacs doesn't respect my mailcap" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 13:42:56 +1100" "<87a915c5an.fsf@building.gnus.org>" "<mailman.18666.1422291069.1147.help-gnu-emacs@gnu.org> <87386xf5gx.fsf@building.gnus.org> <mailman.18710.1422322318.1147.help-gnu-emacs@gnu.org> <87386xdmzp.fsf@building.gnus.org> <mailman.18712.1422322837.1147.help-gnu-emacs@gnu.org> <87h9vdc7cn.fsf@building.gnus.org> <87egqhrmzv.fsf@gmx.us>" 3669 21 "news.gmane.org gmane.emacs.gnus.general:85548" nil]
    ([85549 "Re: Recent Emacs doesn't respect my mailcap" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 27 Jan 2015 11:01:08 +0800" "<87ppa1rkp7.fsf@ericabrahamsen.net>" "<mailman.18666.1422291069.1147.help-gnu-emacs@gnu.org> <87386xf5gx.fsf@building.gnus.org> <mailman.18710.1422322318.1147.help-gnu-emacs@gnu.org> <87386xdmzp.fsf@building.gnus.org> <mailman.18712.1422322837.1147.help-gnu-emacs@gnu.org> <87h9vdc7cn.fsf@building.gnus.org> <87egqhrmzv.fsf@gmx.us> <87a915c5an.fsf@building.gnus.org>" 5598 26 "news.gmane.org gmane.emacs.gnus.general:85549" nil]
     ([85555 "Re: Recent Emacs doesn't respect my mailcap" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 14:01:38 +1100" "<87386xc4fh.fsf@building.gnus.org>" "<mailman.18666.1422291069.1147.help-gnu-emacs@gnu.org> <87386xf5gx.fsf@building.gnus.org> <mailman.18710.1422322318.1147.help-gnu-emacs@gnu.org> <87386xdmzp.fsf@building.gnus.org> <mailman.18712.1422322837.1147.help-gnu-emacs@gnu.org> <87h9vdc7cn.fsf@building.gnus.org> <87egqhrmzv.fsf@gmx.us> <87a915c5an.fsf@building.gnus.org> <87ppa1rkp7.fsf@ericabrahamsen.net>" 3789 16 "news.gmane.org gmane.emacs.gnus.general:85555" nil]
      ([85557 "Re: Recent Emacs doesn't respect my mailcap" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 27 Jan 2015 11:59:24 +0800" "<87fvawri03.fsf@ericabrahamsen.net>" "<mailman.18666.1422291069.1147.help-gnu-emacs@gnu.org> <87386xf5gx.fsf@building.gnus.org> <mailman.18710.1422322318.1147.help-gnu-emacs@gnu.org> <87386xdmzp.fsf@building.gnus.org> <mailman.18712.1422322837.1147.help-gnu-emacs@gnu.org> <87h9vdc7cn.fsf@building.gnus.org> <87egqhrmzv.fsf@gmx.us> <87a915c5an.fsf@building.gnus.org> <87ppa1rkp7.fsf@ericabrahamsen.net> <87386xc4fh.fsf@building.gnus.org>" 5632 22 "news.gmane.org gmane.emacs.gnus.general:85557" nil]
       ([85558 "Re: Recent Emacs doesn't respect my mailcap" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 15:47:03 +1100" "<878ugobzjs.fsf@building.gnus.org>" "<mailman.18666.1422291069.1147.help-gnu-emacs@gnu.org> <87386xf5gx.fsf@building.gnus.org> <mailman.18710.1422322318.1147.help-gnu-emacs@gnu.org> <87386xdmzp.fsf@building.gnus.org> <mailman.18712.1422322837.1147.help-gnu-emacs@gnu.org> <87h9vdc7cn.fsf@building.gnus.org> <87egqhrmzv.fsf@gmx.us> <87a915c5an.fsf@building.gnus.org> <87ppa1rkp7.fsf@ericabrahamsen.net> <87386xc4fh.fsf@building.gnus.org> <87fvawri03.fsf@ericabrahamsen.net>" 4636 33 "news.gmane.org gmane.emacs.gnus.general:85558" nil]
        ([85563 "Re: Recent Emacs doesn't respect my mailcap" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 27 Jan 2015 13:08:46 +0800" "<87lhkoq081.fsf@ericabrahamsen.net>" "<mailman.18666.1422291069.1147.help-gnu-emacs@gnu.org> <87386xf5gx.fsf@building.gnus.org> <mailman.18710.1422322318.1147.help-gnu-emacs@gnu.org> <87386xdmzp.fsf@building.gnus.org> <mailman.18712.1422322837.1147.help-gnu-emacs@gnu.org> <87h9vdc7cn.fsf@building.gnus.org> <87egqhrmzv.fsf@gmx.us> <87a915c5an.fsf@building.gnus.org> <87ppa1rkp7.fsf@ericabrahamsen.net> <87386xc4fh.fsf@building.gnus.org> <87fvawri03.fsf@ericabrahamsen.net> <878ugobzjs.fsf@building.gnus.org>" 6592 43 "news.gmane.org gmane.emacs.gnus.general:85563" nil]
         ([85597 "Re: Recent Emacs doesn't respect my mailcap" "david.goldberg6@verizon.net (Dave Goldberg)" "Tue, 27 Jan 2015 20:54:54 -0500" "<841tmf7jpt.fsf@davestoy.home>" "<mailman.18666.1422291069.1147.help-gnu-emacs@gnu.org> <87386xf5gx.fsf@building.gnus.org> <mailman.18710.1422322318.1147.help-gnu-emacs@gnu.org> <87386xdmzp.fsf@building.gnus.org> <mailman.18712.1422322837.1147.help-gnu-emacs@gnu.org> <87h9vdc7cn.fsf@building.gnus.org> <87egqhrmzv.fsf@gmx.us> <87a915c5an.fsf@building.gnus.org> <87ppa1rkp7.fsf@ericabrahamsen.net> <87386xc4fh.fsf@building.gnus.org> <87fvawri03.fsf@ericabrahamsen.net> <878ugobzjs.fsf@building.gnus.org> <87lhkoq081.fsf@ericabrahamsen.net>" 5300 36 "news.gmane.org gmane.emacs.gnus.general:85597" nil]
          ([85646 "Re: Recent Emacs doesn't respect my mailcap" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 13:21:29 +1100" "<874mranx7a.fsf@building.gnus.org>" "<mailman.18666.1422291069.1147.help-gnu-emacs@gnu.org> <87386xf5gx.fsf@building.gnus.org> <mailman.18710.1422322318.1147.help-gnu-emacs@gnu.org> <87386xdmzp.fsf@building.gnus.org> <mailman.18712.1422322837.1147.help-gnu-emacs@gnu.org> <87h9vdc7cn.fsf@building.gnus.org> <87egqhrmzv.fsf@gmx.us> <87a915c5an.fsf@building.gnus.org> <87ppa1rkp7.fsf@ericabrahamsen.net> <87386xc4fh.fsf@building.gnus.org> <87fvawri03.fsf@ericabrahamsen.net> <878ugobzjs.fsf@building.gnus.org> <87lhkoq081.fsf@ericabrahamsen.net> <841tmf7jpt.fsf@davestoy.home>" 5408 54 "news.gmane.org gmane.emacs.gnus.general:85646" nil]))))))))))
 ([85350 "Re: nnir-run-gmane produces empty results" "Frank <kulugox@gmail.com>" "Sat, 13 Dec 2014 03:05:20 +0000 (UTC)" "<loom.20141213T040034-382@post.gmane.org>" "<87ionqgh5n.fsf@fastmail.fm>" 4193 46 "news.gmane.org gmane.emacs.gnus.general:85350" nil])
 ([85351 "Re: nnir-run-gmane produces empty results" "Frank <kulugox@gmail.com>" "Sat, 13 Dec 2014 09:35:09 +0800" "<87zjaswcvm.fsf@gmail.com>" "<87ionqgh5n.fsf@fastmail.fm>" 3813 37 "news.gmane.org gmane.emacs.gnus.general:85351" nil])
 ([85352 "Re: nnir-run-gmane produces empty results" "Frank <kulugox@gmail.com>" "Sat, 13 Dec 2014 03:59:18 +0000 (UTC)" "<loom.20141213T045748-135@post.gmane.org>" "<87ionqgh5n.fsf@fastmail.fm>" 4172 44 "news.gmane.org gmane.emacs.gnus.general:85352" nil])
 ([85354 "Re: nnir-run-gmane produces empty results" "Frank <kulugox@gmail.com>" "Sat, 13 Dec 2014 12:03:46 +0800" "<87zjastcv1.fsf@gmail.com>" "<87ionqgh5n.fsf@fastmail.fm>" 4061 43 "news.gmane.org gmane.emacs.gnus.general:85354" nil])
 ([85355 "Re: nnir-run-gmane produces empty results" "Frank <kulugox@gmail.com>" "Sat, 13 Dec 2014 10:03:28 +0800" "<87bnn8wbkf.fsf@gmail.com>" "<87ionqgh5n.fsf@fastmail.fm>" 4068 44 "news.gmane.org gmane.emacs.gnus.general:85355" nil]
  ([85356 "Re: nnir-run-gmane produces empty results" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 13 Dec 2014 09:17:27 +0100" "<87oar82cbs.fsf@topper.koldfront.dk>" "<87ionqgh5n.fsf@fastmail.fm> <87bnn8wbkf.fsf@gmail.com>" 3840 18 "news.gmane.org gmane.emacs.gnus.general:85356" nil]))
 ([85582 "Re: How do I view the entire-article thread?" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 18:31:34 +1100" "<87iofs7k89.fsf@building.gnus.org>" "<877g2auzyq.fsf@gmail.com>" 3454 19 "news.gmane.org gmane.emacs.gnus.general:85582" nil])
 ([85771 "Re: color of transient-mark-mode" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Thu, 12 Feb 2015 08:19:48 +0000" "<874mqrlexn.fsf@ucl.ac.uk>" "<87bnl01gnk.fsf@engels.histomat.net>" 4656 15 "news.gmane.org gmane.emacs.gnus.general:85771" nil])
 ([85569 "Re: IMAP connection goes to the wrong port" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 16:33:47 +1100" "<87zj949490.fsf@building.gnus.org>" "<ltut2g$erf$1@ger.gmane.org>" 4265 23 "news.gmane.org gmane.emacs.gnus.general:85569" nil])
 ([85566 "Re: forward/insert a message in a reply message buffer" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 16:20:29 +1100" "<87egqgajfm.fsf@building.gnus.org>" "<87ppfbr2ag.fsf@mat.ucm.es> <84ha0mn7rs.fsf@davestoy.home> <87oauuwa99.fsf@mat.ucm.es>" 3770 25 "news.gmane.org gmane.emacs.gnus.general:85566" nil]
  ([85599 "Re: forward/insert a message in a reply message buffer" "david.goldberg6@verizon.net (Dave Goldberg)" "Tue, 27 Jan 2015 21:20:34 -0500" "<84lhkn63yl.fsf@davestoy.home>" "<87ppfbr2ag.fsf@mat.ucm.es> <84ha0mn7rs.fsf@davestoy.home> <87oauuwa99.fsf@mat.ucm.es> <87egqgajfm.fsf@building.gnus.org>" 4259 30 "news.gmane.org gmane.emacs.gnus.general:85599" nil]
   ([85647 "Re: forward/insert a message in a reply message buffer" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 13:22:46 +1100" "<87zj92mikp.fsf@building.gnus.org>" "<87ppfbr2ag.fsf@mat.ucm.es> <84ha0mn7rs.fsf@davestoy.home> <87oauuwa99.fsf@mat.ucm.es> <87egqgajfm.fsf@building.gnus.org> <84lhkn63yl.fsf@davestoy.home>" 3594 18 "news.gmane.org gmane.emacs.gnus.general:85647" nil]
    ([85685 "Re: forward/insert a message in a reply message buffer" "david.goldberg6@verizon.net (Dave Goldberg)" "Sat, 31 Jan 2015 11:47:01 -0500" "<84a90yhp8a.fsf@davestoy.home>" "<87ppfbr2ag.fsf@mat.ucm.es> <84ha0mn7rs.fsf@davestoy.home> <87oauuwa99.fsf@mat.ucm.es> <87egqgajfm.fsf@building.gnus.org> <84lhkn63yl.fsf@davestoy.home> <87zj92mikp.fsf@building.gnus.org>" 3833 22 "news.gmane.org gmane.emacs.gnus.general:85685" nil]
     ([85734 "Re: forward/insert a message in a reply message buffer" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:37:52 +1100" "<87bnl9110v.fsf@building.gnus.org>" "<87ppfbr2ag.fsf@mat.ucm.es> <84ha0mn7rs.fsf@davestoy.home> <87oauuwa99.fsf@mat.ucm.es> <87egqgajfm.fsf@building.gnus.org> <84lhkn63yl.fsf@davestoy.home> <87zj92mikp.fsf@building.gnus.org> <84a90yhp8a.fsf@davestoy.home>" 3267 11 "news.gmane.org gmane.emacs.gnus.general:85734" nil])))))
 ([85568 "Re: Extracting all videos attached to emails from emails?" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 16:25:01 +1100" "<8761bsaj82.fsf@building.gnus.org>" "<m261h6curi.fsf@krugs.de>" 3364 17 "news.gmane.org gmane.emacs.gnus.general:85568" nil])
 ([85324 "Re: Mutt/Gnus hybrid for mail?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Tue, 9 Dec 2014 16:15:51 +0000" "<87r3w8x0i0.fsf@ucl.ac.uk>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home>" 6678 71 "news.gmane.org gmane.emacs.gnus.general:85324" nil]
  ([85325 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Tue, 09 Dec 2014 12:42:44 -0500" "<m2vblkbtyj.fsf@PFDStudio-Air.home>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home> <87r3w8x0i0.fsf@ucl.ac.uk>" 6203 72 "news.gmane.org gmane.emacs.gnus.general:85325" nil]
   ([85326 "Re: Mutt/Gnus hybrid for mail?" "asjo@koldfront.dk (Adam Sjøgren)" "Tue, 09 Dec 2014 19:26:22 +0100" "<878uig8ysx.fsf@topper.koldfront.dk>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home> <87r3w8x0i0.fsf@ucl.ac.uk> <m2vblkbtyj.fsf@PFDStudio-Air.home>" 4937 37 "news.gmane.org gmane.emacs.gnus.general:85326" nil]
    ([85328 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Tue, 09 Dec 2014 14:56:39 -0500" "<m2r3w8bnrc.fsf@PFDStudio-Air.home>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home> <87r3w8x0i0.fsf@ucl.ac.uk> <m2vblkbtyj.fsf@PFDStudio-Air.home> <878uig8ysx.fsf@topper.koldfront.dk>" 4377 22 "news.gmane.org gmane.emacs.gnus.general:85328" nil]
     ([85329 "Re: Mutt/Gnus hybrid for mail?" "asjo@koldfront.dk (Adam Sjøgren)" "Tue, 09 Dec 2014 21:16:50 +0100" "<87zjaw7f4d.fsf@topper.koldfront.dk>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home> <87r3w8x0i0.fsf@ucl.ac.uk> <m2vblkbtyj.fsf@PFDStudio-Air.home> <878uig8ysx.fsf@topper.koldfront.dk> <m2r3w8bnrc.fsf@PFDStudio-Air.home>" 4511 29 "news.gmane.org gmane.emacs.gnus.general:85329" nil]
      ([85331 "Re: Mutt/Gnus hybrid for mail?" "Peter Münster <pmlists@free.fr>" "Tue, 09 Dec 2014 22:21:05 +0100" "<87lhmgzfi6.fsf@micropit.roche-blanche.homenet.org>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home> <87r3w8x0i0.fsf@ucl.ac.uk> <m2vblkbtyj.fsf@PFDStudio-Air.home> <878uig8ysx.fsf@topper.koldfront.dk> <m2r3w8bnrc.fsf@PFDStudio-Air.home> <87zjaw7f4d.fsf@topper.koldfront.dk>" 3966 23 "news.gmane.org gmane.emacs.gnus.general:85331" nil]))))))
 ([85330 "Re: Mutt/Gnus hybrid for mail?" "Charles Philip Chan <cpchan@bell.net>" "Tue, 09 Dec 2014 16:20:57 -0500" "<87mw6wjz9i.fsf@karnak.MagnumOpus.khem>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home>" 5191 51 "news.gmane.org gmane.emacs.gnus.general:85330" nil]
  ([85333 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Tue, 09 Dec 2014 17:46:35 -0500" "<m2mw6wbfw4.fsf@PFDStudio-Air.home>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home> <87mw6wjz9i.fsf@karnak.MagnumOpus.khem>" 4348 25 "news.gmane.org gmane.emacs.gnus.general:85333" nil]
   ([85334 "Re: Mutt/Gnus hybrid for mail?" "Charles Philip Chan <cpchan@bell.net>" "Tue, 09 Dec 2014 19:19:37 -0500" "<87iohkjqzq.fsf@karnak.MagnumOpus.khem>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home> <87mw6wjz9i.fsf@karnak.MagnumOpus.khem> <m2mw6wbfw4.fsf@PFDStudio-Air.home>" 4335 32 "news.gmane.org gmane.emacs.gnus.general:85334" nil]
    ([85335 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Tue, 09 Dec 2014 19:25:45 -0500" "<m2iohkbbau.fsf@PFDStudio-Air.home>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home> <87mw6wjz9i.fsf@karnak.MagnumOpus.khem> <m2mw6wbfw4.fsf@PFDStudio-Air.home> <87iohkjqzq.fsf@karnak.MagnumOpus.khem>" 3965 17 "news.gmane.org gmane.emacs.gnus.general:85335" nil]
     ([85336 "Re: Mutt/Gnus hybrid for mail?" "Charles Philip Chan <cpchan@bell.net>" "Tue, 09 Dec 2014 20:35:03 -0500" "<87egs8jni0.fsf@karnak.MagnumOpus.khem>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home> <87mw6wjz9i.fsf@karnak.MagnumOpus.khem> <m2mw6wbfw4.fsf@PFDStudio-Air.home> <87iohkjqzq.fsf@karnak.MagnumOpus.khem> <m2iohkbbau.fsf@PFDStudio-Air.home>" 4358 36 "news.gmane.org gmane.emacs.gnus.general:85336" nil]
      ([85337 "Re: Mutt/Gnus hybrid for mail?" "Peter Davis <pfd@pfdstudio.com>" "Tue, 09 Dec 2014 21:01:37 -0500" "<m2egs8b6v2.fsf@PFDStudio-Air.home>" "<m2sigqcm7u.fsf@PFDStudio-Air.home> <87egs952jy.fsf@micropit.roche-blanche.homenet.org> <m2oarddajf.fsf@PFDStudio-Air.home> <8761dl3xth.fsf@pinto.chemeng.ucl.ac.uk> <m24mt5c7ji.fsf@PFDStudio-Air.home> <87ppbsgbi7.fsf@ucl.ac.uk> <m2zjawc2ot.fsf@PFDStudio-Air.home> <87mw6wjz9i.fsf@karnak.MagnumOpus.khem> <m2mw6wbfw4.fsf@PFDStudio-Air.home> <87iohkjqzq.fsf@karnak.MagnumOpus.khem> <m2iohkbbau.fsf@PFDStudio-Air.home> <87egs8jni0.fsf@karnak.MagnumOpus.khem>" 4117 21 "news.gmane.org gmane.emacs.gnus.general:85337" nil]))))))
 ([85610 "Re: Diffie-Hellman key exchange has been lowered to 256 bits" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 16:18:07 +1100" "<87h9vbxz3k.fsf@building.gnus.org>" "<m3zjh6h4gq.fsf@carbon.jhcloos.org>" 3490 23 "news.gmane.org gmane.emacs.gnus.general:85610" nil]
  ([85627 "Re: Diffie-Hellman key exchange has been lowered to 256 bits" "Greg Troxel <gdt@lexort.com>" "Wed, 28 Jan 2015 07:32:02 -0500" "<smuvbjrqe65.fsf@linuxpal.mit.edu>" "<m3zjh6h4gq.fsf@carbon.jhcloos.org> <87h9vbxz3k.fsf@building.gnus.org>" 3854 39 "news.gmane.org gmane.emacs.gnus.general:85627" nil]
   ([85642 "Re: Diffie-Hellman key exchange has been lowered to 256 bits" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 12:39:53 +1100" "<87mw52nz4m.fsf@building.gnus.org>" "<m3zjh6h4gq.fsf@carbon.jhcloos.org> <87h9vbxz3k.fsf@building.gnus.org> <smuvbjrqe65.fsf@linuxpal.mit.edu>" 3537 19 "news.gmane.org gmane.emacs.gnus.general:85642" nil])))
 ([85542 "Re: default binding of M-& in group and summary buffers" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 12:36:39 +1100" "<87y4opc8d4.fsf@building.gnus.org>" "<m2y4ssdqmp.fsf@fastmail.fm>" 3352 16 "news.gmane.org gmane.emacs.gnus.general:85542" nil])
 ([85622 "Re: Scaling stuff for high dpi screens" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 17:23:00 +1100" "<8761brwhiz.fsf@building.gnus.org>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk>" 3569 17 "news.gmane.org gmane.emacs.gnus.general:85622 gmane.emacs.devel:181878" nil]
  ([85625 "Re: Scaling stuff for high dpi screens" "David Kastrup <dak@gnu.org>" "Wed, 28 Jan 2015 09:46:56 +0100" "<878ugncmwv.fsf@fencepost.gnu.org>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk> <8761brwhiz.fsf@building.gnus.org>" 4200 20 "news.gmane.org gmane.emacs.devel:181888 gmane.emacs.gnus.general:85625" nil]
   ([85637 "Re: Scaling stuff for high dpi screens" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 12:02:04 +1100" "<87fvaupfg3.fsf@building.gnus.org>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk> <8761brwhiz.fsf@building.gnus.org> <878ugncmwv.fsf@fencepost.gnu.org>" 4196 16 "news.gmane.org gmane.emacs.devel:181954 gmane.emacs.gnus.general:85637" nil])
   ([85668 "Re: Scaling stuff for high dpi screens" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 29 Jan 2015 23:26:14 +0100" "<87y4olnrzt.fsf@topper.koldfront.dk>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk> <8761brwhiz.fsf@building.gnus.org> <878ugncmwv.fsf@fencepost.gnu.org>" 4930 24 "news.gmane.org gmane.emacs.devel:182012 gmane.emacs.gnus.general:85668" nil])
   ([85673 "Re: Scaling stuff for high dpi screens" "asjo@koldfront.dk (Adam Sjøgren)" "Fri, 30 Jan 2015 00:57:14 +0100" "<87siet3ztx.fsf@topper.koldfront.dk>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk> <8761brwhiz.fsf@building.gnus.org> <878ugncmwv.fsf@fencepost.gnu.org>" 6910 65 "news.gmane.org gmane.emacs.devel:182013 gmane.emacs.gnus.general:85673" nil]
    ([85675 "Re: Scaling stuff for high dpi screens" "Eli Zaretskii <eliz@gnu.org>" "Fri, 30 Jan 2015 08:26:28 +0200" "<8361bon5rf.fsf@gnu.org>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk> <8761brwhiz.fsf@building.gnus.org> <878ugncmwv.fsf@fencepost.gnu.org> <87siet3ztx.fsf@topper.koldfront.dk>" 4325 18 "news.gmane.org gmane.emacs.devel:182020 gmane.emacs.gnus.general:85675" nil])
    ([85676 "Re: Scaling stuff for high dpi screens" "David Kastrup <dak@gnu.org>" "Fri, 30 Jan 2015 11:05:55 +0100" "<87egqcbn24.fsf@fencepost.gnu.org>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk> <8761brwhiz.fsf@building.gnus.org> <878ugncmwv.fsf@fencepost.gnu.org> <87siet3ztx.fsf@topper.koldfront.dk>" 5976 58 "news.gmane.org gmane.emacs.devel:182035 gmane.emacs.gnus.general:85676" nil]
     ([85677 "Re: Scaling stuff for high dpi screens" "Vincent Bernat <bernat@luffy.cx>" "Fri, 30 Jan 2015 16:19:43 +0100" "<877fw4b8j4.fsf@zoro.exoscale.ch>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk> <8761brwhiz.fsf@building.gnus.org> <878ugncmwv.fsf@fencepost.gnu.org> <87siet3ztx.fsf@topper.koldfront.dk> <87egqcbn24.fsf@fencepost.gnu.org>" 5507 45 "news.gmane.org gmane.emacs.gnus.general:85677 gmane.emacs.devel:182059" nil]
      ([85679 "Re: Scaling stuff for high dpi screens" "asjo@koldfront.dk (Adam Sjøgren)" "Sat, 31 Jan 2015 00:38:28 +0100" "<8761bnu9e3.fsf@topper.koldfront.dk>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk> <8761brwhiz.fsf@building.gnus.org> <878ugncmwv.fsf@fencepost.gnu.org> <87siet3ztx.fsf@topper.koldfront.dk> <87egqcbn24.fsf@fencepost.gnu.org> <877fw4b8j4.fsf@zoro.exoscale.ch>" 4777 31 "news.gmane.org gmane.emacs.gnus.general:85679 gmane.emacs.devel:182103" nil]
       ([85684 "Re: Scaling stuff for high dpi screens" "Vincent Bernat <bernat@luffy.cx>" "Sat, 31 Jan 2015 16:59:14 +0100" "<m3bnlfndpp.fsf@neo.luffy.cx>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk> <8761brwhiz.fsf@building.gnus.org> <878ugncmwv.fsf@fencepost.gnu.org> <87siet3ztx.fsf@topper.koldfront.dk> <87egqcbn24.fsf@fencepost.gnu.org> <877fw4b8j4.fsf@zoro.exoscale.ch> <8761bnu9e3.fsf@topper.koldfront.dk>" 4478 15 "news.gmane.org gmane.emacs.gnus.general:85684 gmane.emacs.devel:182137" nil])))))))
 ([85630 "Re: Scaling stuff for high dpi screens" "Andreas Schwab <schwab@suse.de>" "Wed, 28 Jan 2015 10:39:50 +0100" "<mvmr3ufjlax.fsf@hawking.suse.de>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk>" 3236 17 "news.gmane.org gmane.emacs.gnus.general:85630" nil]
  ([85669 "Re: Scaling stuff for high dpi screens" "asjo@koldfront.dk (Adam Sjøgren)" "Thu, 29 Jan 2015 23:28:32 +0100" "<87twz9nrvz.fsf@topper.koldfront.dk>" "<87vbu5m25o.fsf@topper.koldfront.dk> <b4ma9bfzbny.fsf@jpl.org> <871twqefd6.fsf@topper.koldfront.dk> <87lhulyz7g.fsf@topper.koldfront.dk> <mvmr3ufjlax.fsf@hawking.suse.de>" 4195 26 "news.gmane.org gmane.emacs.gnus.general:85669" nil]))
 ([85551 "Re: how to delete a virtual group" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 14:15:28 +1100" "<87h9vcc3sf.fsf@building.gnus.org>" "<87r3zakngm.fsf@mat.ucm.es>" 3133 17 "news.gmane.org gmane.emacs.gnus.general:85551" nil])
 ([85525 "Re: shr and colspan?" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 17:08:15 +1100" "<878ugqhy5s.fsf@building.gnus.org>" "<8761fvsyxg.fsf@topper.koldfront.dk> <87vbnvrjzx.fsf@topper.koldfront.dk>" 3718 25 "news.gmane.org gmane.emacs.gnus.general:85525" nil]
  ([85536 "Re: shr and colspan?" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 26 Jan 2015 21:15:28 +0100" "<87egqhqowv.fsf@topper.koldfront.dk>" "<8761fvsyxg.fsf@topper.koldfront.dk> <87vbnvrjzx.fsf@topper.koldfront.dk> <878ugqhy5s.fsf@building.gnus.org>" 4433 37 "news.gmane.org gmane.emacs.gnus.general:85536" nil]))
 ([85373 "Re: gnus-calendar / gnus-icalendar in Emacs24?" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Fri, 19 Dec 2014 16:47:12 +0000" "<87y4q3a8of.fsf@ucl.ac.uk>" "<87vbldf2yt.fsf@hornfels.zedat.fu-berlin.de> <mailman.16136.1418658867.1147.info-gnus-english@gnu.org> <87oar0dhr2.fsf@hillenius.net>" 5115 24 "news.gmane.org gmane.emacs.gnus.general:85373" nil]
  ([85377 "Re: gnus-calendar / gnus-icalendar in Emacs24?" "Gijs Hillenius <gijs@hillenius.net>" "Sat, 20 Dec 2014 08:57:47 +0100" "<87y4q2vjlw.fsf@hillenius.net>" "<87vbldf2yt.fsf@hornfels.zedat.fu-berlin.de> <mailman.16136.1418658867.1147.info-gnus-english@gnu.org> <87oar0dhr2.fsf@hillenius.net> <87y4q3a8of.fsf@ucl.ac.uk>" 5131 20 "news.gmane.org gmane.emacs.gnus.general:85377" nil]))
 ([85410 "Re: gnus-calendar / gnus-icalendar in Emacs24?" "Jan Tatarik <jan.tatarik@gmail.com>" "Wed, 31 Dec 2014 16:53:41 +0100" "<87y4pnzugq.fsf@nb-jtatarik2.xing.hh>" "<87vbldf2yt.fsf@hornfels.zedat.fu-berlin.de> <mailman.16136.1418658867.1147.info-gnus-english@gnu.org> <87oar0dhr2.fsf@hillenius.net>" 4826 34 "news.gmane.org gmane.emacs.gnus.general:85410" nil])
 ([85323 "Re: virtual groups based on subjects" "Glyn Millington <glyn.millington@gmail.com>" "Tue, 09 Dec 2014 14:34:59 +0000" "<87zjaw99ik.fsf@nowhere.org>" "<87k322zdiz.fsf@mat.ucm.es> <87k321j1wa.fsf@nowhere.org> <8761dl6lk7.fsf@mat.ucm.es>" 4694 47 "news.gmane.org gmane.emacs.gnus.general:85323" nil])
 ([85365 "Re: Some imap accounts not updating in 24.4" "Alberto Luaces <aluaces@udc.es>" "Thu, 18 Dec 2014 21:24:12 +0100" "<87r3vw4sgj.fsf@eps142.cdf.udc.es>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com>" 3683 21 "news.gmane.org gmane.emacs.gnus.general:85365" nil]
  ([85375 "Re: Some imap accounts not updating in 24.4" "Ted Zlatanov <tzz@lifelogs.com>" "Fri, 19 Dec 2014 22:07:25 -0500" "<87bnmzt3wy.fsf@lifelogs.com>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com> <87r3vw4sgj.fsf@eps142.cdf.udc.es>" 4433 30 "news.gmane.org gmane.emacs.gnus.general:85375" nil]
   ([85396 "Re: Some imap accounts not updating in 24.4" "Alberto Luaces <aluaces@udc.es>" "Mon, 22 Dec 2014 20:48:37 +0100" "<87y4pza2ju.fsf@eps142.cdf.udc.es>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com> <87r3vw4sgj.fsf@eps142.cdf.udc.es> <87bnmzt3wy.fsf@lifelogs.com>" 4910 58 "news.gmane.org gmane.emacs.gnus.general:85396" nil]
    ([85714 "Re: Some imap accounts not updating in 24.4" "Ted Zlatanov <tzz@lifelogs.com>" "Wed, 04 Feb 2015 06:48:27 -0500" "<87sielyk1g.fsf@lifelogs.com>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com> <87r3vw4sgj.fsf@eps142.cdf.udc.es> <87bnmzt3wy.fsf@lifelogs.com> <87y4pza2ju.fsf@eps142.cdf.udc.es>" 4273 28 "news.gmane.org gmane.emacs.gnus.general:85714" nil])
    ([85731 "Re: Some imap accounts not updating in 24.4" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 05 Feb 2015 14:14:49 +1100" "<87wq3xuk0m.fsf@building.gnus.org>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com> <87r3vw4sgj.fsf@eps142.cdf.udc.es> <87bnmzt3wy.fsf@lifelogs.com> <87y4pza2ju.fsf@eps142.cdf.udc.es>" 3274 12 "news.gmane.org gmane.emacs.gnus.general:85731" nil]
     ([85791 "Re: Some imap accounts not updating in 24.4" "Alberto Luaces <aluaces@udc.es>" "Wed, 18 Feb 2015 20:39:38 +0100" "<87oaort3et.fsf@eps142.cdf.udc.es>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com> <87r3vw4sgj.fsf@eps142.cdf.udc.es> <87bnmzt3wy.fsf@lifelogs.com> <87y4pza2ju.fsf@eps142.cdf.udc.es> <87wq3xuk0m.fsf@building.gnus.org>" 4079 33 "news.gmane.org gmane.emacs.gnus.general:85791" nil]
      ([85793 "Re: Some imap accounts not updating in 24.4" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 19 Feb 2015 16:56:20 +1100" "<87a90ajvgb.fsf@building.gnus.org>" "<87bnnuao0x.fsf@eps142.cdf.udc.es> <m261dmrsl4.fsf@lifelogs.com> <87r3vw4sgj.fsf@eps142.cdf.udc.es> <87bnmzt3wy.fsf@lifelogs.com> <87y4pza2ju.fsf@eps142.cdf.udc.es> <87wq3xuk0m.fsf@building.gnus.org> <87oaort3et.fsf@eps142.cdf.udc.es>" 3231 14 "news.gmane.org gmane.emacs.gnus.general:85793" nil]))))))
 ([85520 "Re: fetching old headers" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:45:05 +1100" "<87twzei20e.fsf@building.gnus.org>" "<m2r3y1dxb2.fsf@pfdstudio-air.home>" 3477 20 "news.gmane.org gmane.emacs.gnus.general:85520" nil]
  ([85533 "Re: fetching old headers" "Peter Davis <pfd@pfdstudio.com>" "Mon, 26 Jan 2015 08:10:04 -0500" "<m2egqhlmc3.fsf@PFDStudio-Air.home>" "<m2r3y1dxb2.fsf@pfdstudio-air.home> <87twzei20e.fsf@building.gnus.org>" 4334 33 "news.gmane.org gmane.emacs.gnus.general:85533" nil]
   ([85636 "Re: fetching old headers" "Peter Davis <pfd@pfdstudio.com>" "Wed, 28 Jan 2015 18:48:57 -0500" "<m2k306jwk6.fsf@PFDStudio-Air.home>" "<m2r3y1dxb2.fsf@pfdstudio-air.home> <87twzei20e.fsf@building.gnus.org> <m2egqhlmc3.fsf@PFDStudio-Air.home>" 4617 40 "news.gmane.org gmane.emacs.gnus.general:85636" nil]
    ([85640 "Re: fetching old headers" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 12:35:23 +1100" "<87vbjqnzc4.fsf@building.gnus.org>" "<m2r3y1dxb2.fsf@pfdstudio-air.home> <87twzei20e.fsf@building.gnus.org> <m2egqhlmc3.fsf@PFDStudio-Air.home> <m2k306jwk6.fsf@PFDStudio-Air.home>" 3297 15 "news.gmane.org gmane.emacs.gnus.general:85640" nil]
     ([85644 "Re: fetching old headers" "Peter Davis <pfd@pfdstudio.com>" "Wed, 28 Jan 2015 20:44:43 -0500" "<m2k3062wdw.fsf@PFDStudio-Air.home>" "<m2r3y1dxb2.fsf@pfdstudio-air.home> <87twzei20e.fsf@building.gnus.org> <m2egqhlmc3.fsf@PFDStudio-Air.home> <m2k306jwk6.fsf@PFDStudio-Air.home> <87vbjqnzc4.fsf@building.gnus.org>" 4237 25 "news.gmane.org gmane.emacs.gnus.general:85644" nil]
      ([85650 "Re: fetching old headers" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 13:34:40 +1100" "<87oapimi0v.fsf@building.gnus.org>" "<m2r3y1dxb2.fsf@pfdstudio-air.home> <87twzei20e.fsf@building.gnus.org> <m2egqhlmc3.fsf@PFDStudio-Air.home> <m2k306jwk6.fsf@PFDStudio-Air.home> <87vbjqnzc4.fsf@building.gnus.org> <m2k3062wdw.fsf@PFDStudio-Air.home>" 3446 14 "news.gmane.org gmane.emacs.gnus.general:85650" nil]))))))
 ([85671 "Re: eval'ing message-use-idna defcustom hangs emacs" "Lars Magne Ingebrigtsen <lmi@gnus.org>" "Fri, 30 Jan 2015 10:36:08 +1100" "<87vbjpyxav.fsf@building.gnus.org>" "<87zjjcdcn1.fsf@ericabrahamsen.net> <87lhknwi18.fsf@building.gnus.org> <83pp9yor8k.fsf@gnu.org> <mailman.18939.1422571379.1147.help-gnu-emacs@gnu.org>" 3511 14 "news.gmane.org gmane.emacs.gnus.general:85671 gmane.emacs.help:102374" nil]
  ([85674 "Re: eval'ing message-use-idna defcustom hangs emacs" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Fri, 30 Jan 2015 10:42:23 +0800" "<87vbjpat0w.fsf@ericabrahamsen.net>" "<87zjjcdcn1.fsf@ericabrahamsen.net> <87lhknwi18.fsf@building.gnus.org> <83pp9yor8k.fsf@gnu.org> <mailman.18939.1422571379.1147.help-gnu-emacs@gnu.org> <87vbjpyxav.fsf@building.gnus.org>" 5426 18 "news.gmane.org gmane.emacs.help:102375 gmane.emacs.gnus.general:85674" nil]))
 ([85461 "Re: All non-marked messages unread" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Sun, 11 Jan 2015 14:04:45 +0000" "<87vbkd8lc2.fsf@ucl.ac.uk>" "<87387iad7o.fsf@Equus.decebal.nl>" 5336 26 "news.gmane.org gmane.emacs.gnus.general:85461" nil]
  ([85473 "Re: All non-marked messages unread" "Steinar Bang <sb@dod.no>" "Mon, 12 Jan 2015 08:55:17 +0100" "<upzcmw5o302i.fsf@dod.no>" "<87387iad7o.fsf@Equus.decebal.nl> <87vbkd8lc2.fsf@ucl.ac.uk>" 3525 13 "news.gmane.org gmane.emacs.gnus.general:85473" nil]
   ([85479 "Re: All non-marked messages unread" "Eric S Fraga <e.fraga@ucl.ac.uk>" "Mon, 12 Jan 2015 18:14:53 +0000" "<87h9vvg92a.fsf@ucl.ac.uk>" "<87387iad7o.fsf@Equus.decebal.nl> <87vbkd8lc2.fsf@ucl.ac.uk> <upzcmw5o302i.fsf@dod.no>" 5571 33 "news.gmane.org gmane.emacs.gnus.general:85479" nil]
    ([85480 "Re: All non-marked messages unread" "asjo@koldfront.dk (Adam Sjøgren)" "Mon, 12 Jan 2015 20:52:50 +0100" "<87lhl73hf1.fsf@topper.koldfront.dk>" "<87387iad7o.fsf@Equus.decebal.nl> <87vbkd8lc2.fsf@ucl.ac.uk> <upzcmw5o302i.fsf@dod.no> <87h9vvg92a.fsf@ucl.ac.uk>" 4284 23 "news.gmane.org gmane.emacs.gnus.general:85480" nil]
     ([85485 "Re: All non-marked messages unread" "<e.fraga@ucl.ac.uk>" "Thu, 15 Jan 2015 08:08:23 +0000" "<87a91ktqiw.fsf@ucl.ac.uk>" "<87387iad7o.fsf@Equus.decebal.nl> <87vbkd8lc2.fsf@ucl.ac.uk> <upzcmw5o302i.fsf@dod.no> <87h9vvg92a.fsf@ucl.ac.uk> <87lhl73hf1.fsf@topper.koldfront.dk>" 5176 20 "news.gmane.org gmane.emacs.gnus.general:85485" nil])))))
 ([85611 "Re: [PATCH] Fix handling of test clauses in mailcap entries" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 16:25:25 +1100" "<87bnljxyre.fsf@building.gnus.org>" "<874mzqsesg.fsf@denkblock.local>" 3362 15 "news.gmane.org gmane.emacs.gnus.general:85611" nil])
 ([85612 "Re: (expiry-wait . never) not properly handled by nnimap backend" "Lars Ingebrigtsen <larsi@gnus.org>" "Wed, 28 Jan 2015 16:30:26 +1100" "<877fw7xyj1.fsf@building.gnus.org>" "<871tvat80p.fsf@denkblock.local>" 3591 18 "news.gmane.org gmane.emacs.gnus.general:85612" nil]
  ([85635 "Re: (expiry-wait . never) not properly handled by nnimap backend" "Katsumi Yamaoka <yamaoka@jpl.org>" "Thu, 29 Jan 2015 07:22:39 +0900" "<b4m1tmebl5c.fsf@jpl.org>" "<871tvat80p.fsf@denkblock.local> <877fw7xyj1.fsf@building.gnus.org>" 3658 10 "news.gmane.org gmane.emacs.gnus.general:85635" nil]
   ([85638 "Re: (expiry-wait . never) not properly handled by nnimap backend" "Lars Ingebrigtsen <larsi@gnus.org>" "Thu, 29 Jan 2015 12:06:21 +1100" "<878ugmpf8y.fsf@building.gnus.org>" "<871tvat80p.fsf@denkblock.local> <877fw7xyj1.fsf@building.gnus.org> <b4m1tmebl5c.fsf@jpl.org>" 3550 18 "news.gmane.org gmane.emacs.gnus.general:85638" nil]
    ([85643 "Re: (expiry-wait . never) not properly handled by nnimap backend" "Katsumi Yamaoka <yamaoka@jpl.org>" "Thu, 29 Jan 2015 10:44:39 +0900" "<b4mmw52l5rs.fsf@jpl.org>" "<871tvat80p.fsf@denkblock.local> <877fw7xyj1.fsf@building.gnus.org> <b4m1tmebl5c.fsf@jpl.org> <878ugmpf8y.fsf@building.gnus.org>" 3559 9 "news.gmane.org gmane.emacs.gnus.general:85643" nil]))))
 ([85560 "Re: IMAP Folder hierarchy -> Topics" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 15:53:08 +1100" "<87zj94akp7.fsf@building.gnus.org>" "<1spq3462vw.fsf@voll.uninett.no> <yb0mwy838aj.fsf@dod.no> <1sk3tc60en.fsf@voll.uninett.no> <874njb7395.fsf@gnus.org> <87fw2v8hpe.fsf@lifelogs.com> <1s4mw9886m.fsf@voll2.uninett.no>" 3846 20 "news.gmane.org gmane.emacs.gnus.general:85560" nil])
 ([85576 "Re: Gnus Digest Mode and Google Groups" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 18:15:07 +1100" "<87egqg8zk4.fsf@building.gnus.org>" "<878um6wf51.fsf@mat.ucm.es>" 3248 17 "news.gmane.org gmane.emacs.gnus.general:85576" nil])
 ([85519 "Re: Snoozing a message in gnus?" "Lars Ingebrigtsen <larsi@gnus.org>" "Mon, 26 Jan 2015 15:34:02 +1100" "<87y4oqi2it.fsf@building.gnus.org>" "<m21tpfs8nu.fsf@krugs.de>" 3461 19 "news.gmane.org gmane.emacs.gnus.general:85519" nil]
  ([85529 "Re: Snoozing a message in gnus?" "Rainer M Krug <Rainer@krugs.de>" "Mon, 26 Jan 2015 09:39:06 +0100" "<m2iofu7x79.fsf@krugs.de>" "<m21tpfs8nu.fsf@krugs.de> <87y4oqi2it.fsf@building.gnus.org>" 5203 53 "news.gmane.org gmane.emacs.gnus.general:85529" nil]
   ([85541 "Re: Snoozing a message in gnus?" "Lars Ingebrigtsen <larsi@gnus.org>" "Tue, 27 Jan 2015 11:56:37 +1100" "<87egqhdosa.fsf@building.gnus.org>" "<m21tpfs8nu.fsf@krugs.de> <87y4oqi2it.fsf@building.gnus.org> <m2iofu7x79.fsf@krugs.de>" 3308 16 "news.gmane.org gmane.emacs.gnus.general:85541" nil]
    ([85545 "Re: Snoozing a message in gnus?" "Eric Abrahamsen <eric@ericabrahamsen.net>" "Tue, 27 Jan 2015 09:53:45 +0800" "<87k309t2dy.fsf@ericabrahamsen.net>" "<m21tpfs8nu.fsf@krugs.de> <87y4oqi2it.fsf@building.gnus.org> <m2iofu7x79.fsf@krugs.de> <87egqhdosa.fsf@building.gnus.org>" 4912 17 "news.gmane.org gmane.emacs.gnus.general:85545" nil]
     ([85586 "Re: Snoozing a message in gnus?" "Rainer M Krug <Rainer@krugs.de>" "Tue, 27 Jan 2015 09:12:13 +0100" "<m2lhko7ici.fsf@krugs.de>" "<m21tpfs8nu.fsf@krugs.de> <87y4oqi2it.fsf@building.gnus.org> <m2iofu7x79.fsf@krugs.de> <87egqhdosa.fsf@building.gnus.org> <87k309t2dy.fsf@ericabrahamsen.net>" 5280 57 "news.gmane.org gmane.emacs.gnus.general:85586" nil]))))))

^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2015-03-02 14:34                       ` Peter Münster
@ 2015-07-20 12:52                         ` Peter Münster
  2016-02-07  6:31                         ` Lars Ingebrigtsen
  1 sibling, 0 replies; 84+ messages in thread
From: Peter Münster @ 2015-07-20 12:52 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 18522

Hi,

Is there anything, that I could do, for further debugging?
Emacs uptime is 17 days, and entering groups is really *very* slow now.

Info from "ps":

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
peter     3508  2.0  4.2 919932 170548 ?       Sl   Jul03 502:40 emacs --iconic

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2015-03-02 14:34                       ` Peter Münster
  2015-07-20 12:52                         ` Peter Münster
@ 2016-02-07  6:31                         ` Lars Ingebrigtsen
  2016-02-17 16:00                           ` Peter Münster
  1 sibling, 1 reply; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-07  6:31 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

Peter Münster <pmlists@free.fr> writes:

> On Sat, Feb 14 2015, Lars Ingebrigtsen wrote:
>
>> After you enter the debugger, can you go to the *scratch* buffer and
>>
>> `M-: (pp threads (current-buffer)) RET'
>
> Hi,
>
> `threads' is not defined then... Instead I've modified
> `gnus-sort-threads' to print `threads' into the buffer.
>
> In both cases it's the same. Please find attached an example.

Hm.  That looks totally normal, I think.

So our supposition here is: The time is spent in parse-time-string.  The
data it's running on is the same.  But after Emacs has run a significant
amount of time, parse-time-string becomes slower.

To test that, does 

(benchmark-run 1
 (dotimes (i 10000)
  (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))

run faster in a newly started Emacs than in one that has been running
for a long time?

An alternative explanation might be that you're inadvertently loading an
alternative version of parse-time.el somewhere, and getting an
uncompiled version of the function.  What does `C-h f parse-time-string'
say in a slow and a fast Emacs?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-07  6:31                         ` Lars Ingebrigtsen
@ 2016-02-17 16:00                           ` Peter Münster
  2016-02-19  5:15                             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-17 16:00 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 18522

On Sun, Feb 07 2016, Lars Ingebrigtsen wrote:

> So our supposition here is: The time is spent in parse-time-string.  The
> data it's running on is the same.  But after Emacs has run a significant
> amount of time, parse-time-string becomes slower.
>
> To test that, does 
>
> (benchmark-run 1
>  (dotimes (i 10000)
>   (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))
>
> run faster in a newly started Emacs than in one that has been running
> for a long time?

Hi Lars,

It becomes slower and slower:

emacs -Q:
(1.901298604 63 0.7084347450000001)
(1.872230076 62 0.6968837490000003)
(1.875635069 62 0.6954687450000001)

emacs:
(1.717632996 14 0.49240735300000005)
(1.709202998 14 0.49144767599999994)
(1.743671899 15 0.5327712409999996)

just after starting Gnus:
(2.388075413 18 1.118860780999999)
(2.317841377 17 1.056383110000001)
(2.372941828 18 1.1168076720000002)

just after starting org-notify:
(2.573931109 19 1.2253276549999992)
(2.605375629 19 1.2394917619999992)
(2.560276964 19 1.2212755360000003)

after 1 day uptime:
(3.744592118 19 1.5007945239999572)
(3.741772863 19 1.5062292100001287)
(3.744434861 19 1.4990475370001377)

after 2 days uptime:
(5.104874753 18 1.5796559729999444)
(5.244741606 20 1.7344523149997713)
(5.166454389 19 1.6512688520001575)

after 3 days uptime:
(7.111809223 17 1.6411146469995401)
(7.200519214 17 1.6629621439999482)
(7.086889831 18 1.7155860500001836)


> An alternative explanation might be that you're inadvertently loading an
> alternative version of parse-time.el somewhere, and getting an
> uncompiled version of the function.  What does `C-h f parse-time-string'
> say in a slow and a fast Emacs?

In both cases: parse-time-string is an autoloaded compiled Lisp function in ‘parse-time.el’.

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-17 16:00                           ` Peter Münster
@ 2016-02-19  5:15                             ` Lars Ingebrigtsen
  2016-02-19  8:27                               ` Peder O. Klingenberg
  2016-02-19  8:38                               ` Eli Zaretskii
  0 siblings, 2 replies; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-19  5:15 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

Peter Münster <pmlists@free.fr> writes:

>> (benchmark-run 1
>>  (dotimes (i 10000)
>>   (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))
>>
>> run faster in a newly started Emacs than in one that has been running
>> for a long time?
>
> Hi Lars,
>
> It becomes slower and slower:


[...]

> after 1 day uptime:
> (3.744592118 19 1.5007945239999572)
> (3.741772863 19 1.5062292100001287)
> (3.744434861 19 1.4990475370001377)
>
> after 2 days uptime:
> (5.104874753 18 1.5796559729999444)
> (5.244741606 20 1.7344523149997713)
> (5.166454389 19 1.6512688520001575)
>
> after 3 days uptime:
> (7.111809223 17 1.6411146469995401)
> (7.200519214 17 1.6629621439999482)
> (7.086889831 18 1.7155860500001836)

Cool!  Then at least we've found the culprit.  :-)

Now we just have to find out why.  Does anybody have any idea?  Could
somebody else also try running the benchmark form up there in a newly
started Emacs and one that's been running for a while to see if they can
reproduce this bug?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-19  5:15                             ` Lars Ingebrigtsen
@ 2016-02-19  8:27                               ` Peder O. Klingenberg
  2016-02-19  8:38                               ` Eli Zaretskii
  1 sibling, 0 replies; 84+ messages in thread
From: Peder O. Klingenberg @ 2016-02-19  8:27 UTC (permalink / raw)
  To: 18522

On Fri, Feb 19 2016 at 16:15, Lars Ingebrigtsen wrote:

> Could somebody else also try running the benchmark form up there in a
> newly started Emacs and one that's been running for a while to see if
> they can reproduce this bug?

Reproducible for me, on a fairly old build from master.

GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars) of 2015-02-10 on luna

emacs -Q:
(0.486050254 62 0.14596531899999993)
(0.476148629 62 0.14965575099999995)
(0.48096619 62 0.15016140600000039)
(0.475289574 62 0.14931084599999966)

emacs:
(0.756362151 41 0.4092070400000001)
(0.705364164 40 0.36777845200000003)
(0.706183625 41 0.3791851149999994)
(0.709007708 40 0.37037735199999977)

emacs with 38 days uptime, lots of buffers, gnus running, etc:
(33.491108001 3 0.5502189609999277)
(33.388318264 2 0.3723178949999806)
(34.000763018 3 0.5643239880000124)

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.






^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-19  5:15                             ` Lars Ingebrigtsen
  2016-02-19  8:27                               ` Peder O. Klingenberg
@ 2016-02-19  8:38                               ` Eli Zaretskii
  2016-02-19 10:06                                 ` Nicolas Richard
                                                   ` (2 more replies)
  1 sibling, 3 replies; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-19  8:38 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: pmlists, 18522

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 19 Feb 2016 16:15:08 +1100
> Cc: 18522@debbugs.gnu.org
> 
> Peter Münster <pmlists@free.fr> writes:
> 
> >> (benchmark-run 1
> >>  (dotimes (i 10000)
> >>   (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))
> >>
> >> run faster in a newly started Emacs than in one that has been running
> >> for a long time?
> >
> > Hi Lars,
> >
> > It becomes slower and slower:
> 
> [...]
> 
> Cool!  Then at least we've found the culprit.  :-)
> 
> Now we just have to find out why.  Does anybody have any idea?  Could
> somebody else also try running the benchmark form up there in a newly
> started Emacs and one that's been running for a while to see if they can
> reproduce this bug?

IMO, the benchmark needs to be changed to factor out GC, because the
time a GC takes depends on the number and structure of objects you
have in your session, and that has nothing to do with the issue at
hand.

So a better benchmark is this:

  (let ((gc-cons-threshold most-positive-fixnum))
    (benchmark-run 1
      (dotimes (i 10000)
	(parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000"))))

FWIW, this takes 1.2 sec in a fresh "emacs -Q", and 2.0 sec in a
full-blown session running for 5 days.  That's clearly different from
the data presented by Peter (but I don't use Gnus).





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-19  8:38                               ` Eli Zaretskii
@ 2016-02-19 10:06                                 ` Nicolas Richard
  2016-02-19 10:12                                 ` Peder O. Klingenberg
  2016-02-19 22:46                                 ` Lars Ingebrigtsen
  2 siblings, 0 replies; 84+ messages in thread
From: Nicolas Richard @ 2016-02-19 10:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, pmlists, 18522

Eli Zaretskii <eliz@gnu.org> writes:
> So a better benchmark is this:
>
>   (let ((gc-cons-threshold most-positive-fixnum))
>     (benchmark-run 1
>       (dotimes (i 10000)
> 	(parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000"))))
>
> FWIW, this takes 1.2 sec in a fresh "emacs -Q", and 2.0 sec in a
> full-blown session running for 5 days.  That's clearly different from
> the data presented by Peter (but I don't use Gnus).

in my 9 days uptime session, I get (18.433154005 0 0.0)

from -Q I get : (7.823626407 0 0.0)

from a fresh emacs session where I forcibly loaded libraries similar to
my 9-days-old one, I get: (8.661741842 0 0.0)

Perhaps I should go back to optimized builds instead... other than that,
it seems that there is indeed a problem with the older session.

-- 
Nicolas





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-19  8:38                               ` Eli Zaretskii
  2016-02-19 10:06                                 ` Nicolas Richard
@ 2016-02-19 10:12                                 ` Peder O. Klingenberg
  2016-02-19 22:46                                 ` Lars Ingebrigtsen
  2 siblings, 0 replies; 84+ messages in thread
From: Peder O. Klingenberg @ 2016-02-19 10:12 UTC (permalink / raw)
  To: 18522

On Fri, Feb 19 2016 at 10:38, Eli Zaretskii wrote:

> So a better benchmark is this:
>
>   (let ((gc-cons-threshold most-positive-fixnum))
>     (benchmark-run 1
>       (dotimes (i 10000)
> 	(parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000"))))

In my case, the timings are similar to the runs without GC suppression.

emacs -Q:
(0.376852402 0 0.0)
(0.359729575 0 0.0)
(0.351677433 0 0.0)

My 38-day uptime workhorse-emacs:

(33.980759168 0 0.0)
(33.741870707 0 0.0)
(33.947532796 0 0.0)


...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.






^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-19  8:38                               ` Eli Zaretskii
  2016-02-19 10:06                                 ` Nicolas Richard
  2016-02-19 10:12                                 ` Peder O. Klingenberg
@ 2016-02-19 22:46                                 ` Lars Ingebrigtsen
  2016-02-20  8:14                                   ` Eli Zaretskii
  2 siblings, 1 reply; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-19 22:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: pmlists, 18522

Eli Zaretskii <eliz@gnu.org> writes:

>   (let ((gc-cons-threshold most-positive-fixnum))
>     (benchmark-run 1
>       (dotimes (i 10000)
> 	(parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000"))))
>
> FWIW, this takes 1.2 sec in a fresh "emacs -Q", and 2.0 sec in a
> full-blown session running for 5 days.  That's clearly different from
> the data presented by Peter (but I don't use Gnus).

Well, it's almost twice as slow in a five day old Emacs...  doesn't that
show that something weird is going on somewhere?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-19 22:46                                 ` Lars Ingebrigtsen
@ 2016-02-20  8:14                                   ` Eli Zaretskii
  2016-02-20  8:33                                     ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-20  8:14 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: pmlists, 18522

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: pmlists@free.fr,  18522@debbugs.gnu.org
> Date: Sat, 20 Feb 2016 09:46:23 +1100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   (let ((gc-cons-threshold most-positive-fixnum))
> >     (benchmark-run 1
> >       (dotimes (i 10000)
> > 	(parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000"))))
> >
> > FWIW, this takes 1.2 sec in a fresh "emacs -Q", and 2.0 sec in a
> > full-blown session running for 5 days.  That's clearly different from
> > the data presented by Peter (but I don't use Gnus).
> 
> Well, it's almost twice as slow in a five day old Emacs...  doesn't that
> show that something weird is going on somewhere?

2.0 divided by 1.2 is 1.7, not 2.  And Peter's data shows a 3.7-fold
slowdown after only 3 days.  So the difference is IMO striking.

Nevertheless, profiling parse-time-string on a more fine-grained level
seems the way to go.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-20  8:14                                   ` Eli Zaretskii
@ 2016-02-20  8:33                                     ` Peter Münster
  2016-02-20  9:51                                       ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-20  8:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 18522

On Sat, Feb 20 2016, Eli Zaretskii wrote:

> 2.0 divided by 1.2 is 1.7, not 2.  And Peter's data shows a 3.7-fold
> slowdown after only 3 days.  So the difference is IMO striking.

Hi,

It seems, that the slow-down depends on user activity, not really on
uptime. I've 3 running emacs now: one instance that has loaded my
personal configuration, another with "emacs -Q" and my normal emacs
session with user activity. I observe the slow-down only with the
latter.


> Nevertheless, profiling parse-time-string on a more fine-grained level
> seems the way to go.

How please?

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-20  8:33                                     ` Peter Münster
@ 2016-02-20  9:51                                       ` Eli Zaretskii
  2016-02-21 11:00                                         ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-20  9:51 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  18522@debbugs.gnu.org
> Date: Sat, 20 Feb 2016 09:33:20 +0100
> 
> > Nevertheless, profiling parse-time-string on a more fine-grained level
> > seems the way to go.
> 
> How please?

I'd start with profiler.el, to profile the Lisp portions of the
function.  It's probably best to load the .el file first and profile
that, although this could skew the profile (because the byte-compiled
version behaves differently).

Another possibility is to add calls to float-time to time portions of
parse-time-string.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-20  9:51                                       ` Eli Zaretskii
@ 2016-02-21 11:00                                         ` Peter Münster
  2016-02-21 11:08                                           ` Andreas Schwab
  2016-02-21 11:09                                           ` martin rudalics
  0 siblings, 2 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-21 11:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Sat, Feb 20 2016, Eli Zaretskii wrote:

> I'd start with profiler.el, to profile the Lisp portions of the
> function.  It's probably best to load the .el file first and profile
> that, although this could skew the profile (because the byte-compiled
> version behaves differently).

Here are 2 profiler reports. The first one, where parse-time-string is
very slow:

--8<---------------cut here---------------start------------->8---
- command-execute                                                8396  93%
 - call-interactively                                            8396  93%
  - funcall-interactively                                        7881  88%
   - eval-expression                                             7848  87%
    - eval                                                       7848  87%
     - let                                                       7848  87%
      - while                                                    7848  87%
       - parse-time-string                                       7840  87%
        - let                                                    7836  87%
         - parse-time-tokenize                                   7089  79%
          - let                                                  7073  79%
           - while                                               7057  78%
            - while                                              6959  77%
             - and                                               6891  77%
              - setq                                             4445  49%
               - parse-time-string-chars                         4413  49%
                - let                                            4301  48%
                 - unwind-protect                                4189  46%
                  - progn                                        4141  46%
                   - let                                          436   4%
                    - cond                                        408   4%
                     - string-match                                96   1%
                        setq                                       68   0%
                    set-match-data                                  4   0%
              - not                                              2338  26%
               - setq                                            2310  25%
                - parse-time-string-chars                        2282  25%
                 - let                                           2258  25%
                  - unwind-protect                               2170  24%
                   - progn                                       2126  23%
                    - let                                         176   1%
                     - cond                                       160   1%
                      - string-match                               24   0%
                         setq                                      16   0%
--8<---------------cut here---------------end--------------->8---

And this one from "emacs -Q":

--8<---------------cut here---------------start------------->8---
- command-execute                                                2643  90%
 - call-interactively                                            2643  90%
  - funcall-interactively                                        2221  75%
   - eval-expression                                             2013  68%
    - eval                                                       2013  68%
     - let                                                       2013  68%
      - while                                                    2013  68%
       - parse-time-string                                       2002  68%
        - let                                                    2002  68%
         - parse-time-tokenize                                   1291  44%
          - let                                                  1283  43%
           - while                                               1272  43%
            - while                                              1112  38%
             - and                                               1044  35%
              - setq                                              640  21%
               - parse-time-string-chars                          608  20%
                - let                                             557  19%
                 - unwind-protect                                 461  15%
                  - progn                                         401  13%
                   - let                                          345  11%
                    - cond                                        285   9%
                     - string-match                                56   1%
                        setq                                       40   1%
                    set-match-data                                 16   0%
              - not                                               288   9%
               - setq                                             268   9%
                - parse-time-string-chars                         244   8%
                 - let                                            208   7%
                  - unwind-protect                                192   6%
                   - progn                                        152   5%
                    - let                                         120   4%
                     - cond                                       112   3%
                      - string-match                               32   1%
                         setq                                      32   1%
                     set-match-data                                 4   0%
--8<---------------cut here---------------end--------------->8---

It seems to me, that there is a problem with "progn":

Slow emacs:
                  - progn                                        4141  46%
                   - let                                          436   4%

Fast emacs:
                  - progn                                         401  13%
                   - let                                          345  11%


What do you think?

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 11:00                                         ` Peter Münster
@ 2016-02-21 11:08                                           ` Andreas Schwab
  2016-02-21 11:09                                           ` martin rudalics
  1 sibling, 0 replies; 84+ messages in thread
From: Andreas Schwab @ 2016-02-21 11:08 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

Peter Münster <pmlists@free.fr> writes:

> It seems to me, that there is a problem with "progn":
>
> Slow emacs:
>                   - progn                                        4141  46%
>                    - let                                          436   4%
>
> Fast emacs:
>                   - progn                                         401  13%
>                    - let                                          345  11%
>
>
> What do you think?

progn is very simple, all its time is spent in evaluating the
arguments.  Does profile actually work for primitives?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 11:00                                         ` Peter Münster
  2016-02-21 11:08                                           ` Andreas Schwab
@ 2016-02-21 11:09                                           ` martin rudalics
  2016-02-21 11:30                                             ` Peter Münster
  1 sibling, 1 reply; 84+ messages in thread
From: martin rudalics @ 2016-02-21 11:09 UTC (permalink / raw)
  To: Peter Münster, Eli Zaretskii; +Cc: larsi, 18522

 > It seems to me, that there is a problem with "progn":

What do you get when you remove the ‘save-match-data’ in
‘parse-time-string-chars’?

martin






^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 11:09                                           ` martin rudalics
@ 2016-02-21 11:30                                             ` Peter Münster
  2016-02-21 13:41                                               ` Michael Heerdegen
  2016-02-21 14:36                                               ` Peter Münster
  0 siblings, 2 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-21 11:30 UTC (permalink / raw)
  To: martin rudalics; +Cc: larsi, 18522

On Sun, Feb 21 2016, martin rudalics wrote:

> What do you get when you remove the ‘save-match-data’ in
> ‘parse-time-string-chars’?

Fast emacs:

               - parse-time-string-chars                          386  19%
                - let                                             342  17%

Slow emacs:

               - parse-time-string-chars                         4122  20%
                - let                                             404   1%


-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 11:30                                             ` Peter Münster
@ 2016-02-21 13:41                                               ` Michael Heerdegen
  2016-02-21 14:02                                                 ` Peter Münster
  2016-02-21 14:36                                               ` Peter Münster
  1 sibling, 1 reply; 84+ messages in thread
From: Michael Heerdegen @ 2016-02-21 13:41 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

Hi,

just a shot in the dark: does (length parse-time-rules) increase when
the thing gets slower?


Michael.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 13:41                                               ` Michael Heerdegen
@ 2016-02-21 14:02                                                 ` Peter Münster
  0 siblings, 0 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-21 14:02 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: larsi, 18522

On Sun, Feb 21 2016, Michael Heerdegen wrote:

> just a shot in the dark: does (length parse-time-rules) increase when
> the thing gets slower?

No. In all cases it's 13.

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 11:30                                             ` Peter Münster
  2016-02-21 13:41                                               ` Michael Heerdegen
@ 2016-02-21 14:36                                               ` Peter Münster
  2016-02-21 14:54                                                 ` Peter Münster
  1 sibling, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-21 14:36 UTC (permalink / raw)
  To: martin rudalics; +Cc: larsi, 18522

The problem seems to be string-match:

(defun my-parse-time-string-test ()
  (let (case-fold-search)
    (string-match "x" "x")))

(let ((gc-cons-threshold most-positive-fixnum))
  (benchmark-run 1
    (dotimes (i 100000) (my-parse-time-string-test))))

Fast emacs: (0.094749241 0 0.0)
Slow emacs: (1.802927531 0 0.0)

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 14:36                                               ` Peter Münster
@ 2016-02-21 14:54                                                 ` Peter Münster
  2016-02-21 16:14                                                   ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-21 14:54 UTC (permalink / raw)
  To: martin rudalics; +Cc: larsi, 18522

On Sun, Feb 21 2016, Peter Münster wrote:

> The problem seems to be string-match:

Sorry, I was wrong. The problem seems to be the binding of
case-fold-search:

(defun my-parse-time-string-test ()
  (let (case-fold-search)
    t))

(let ((gc-cons-threshold most-positive-fixnum))
  (benchmark-run 1
    (dotimes (i 100000) (my-parse-time-string-test))))

Fast emacs: (0.054105733 0 0.0)
Slow emacs: (1.754813882 0 0.0)

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 14:54                                                 ` Peter Münster
@ 2016-02-21 16:14                                                   ` Eli Zaretskii
  2016-02-21 18:03                                                     ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-21 16:14 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: Eli Zaretskii <eliz@gnu.org>,  larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Sun, 21 Feb 2016 15:54:43 +0100
> 
> Sorry, I was wrong. The problem seems to be the binding of
> case-fold-search:
> 
> (defun my-parse-time-string-test ()
>   (let (case-fold-search)
>     t))
> 
> (let ((gc-cons-threshold most-positive-fixnum))
>   (benchmark-run 1
>     (dotimes (i 100000) (my-parse-time-string-test))))
> 
> Fast emacs: (0.054105733 0 0.0)
> Slow emacs: (1.754813882 0 0.0)

Does this happen only with this particular symbol, or binding any
symbol slows down?





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 16:14                                                   ` Eli Zaretskii
@ 2016-02-21 18:03                                                     ` Peter Münster
  2016-02-21 20:45                                                       ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-21 18:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Sun, Feb 21 2016, Eli Zaretskii wrote:

> Does this happen only with this particular symbol, or binding any
> symbol slows down?

It depends on the symbol:

case-fold-search:     slow
fill-column:          slow
just-a-symbol:        fast
custom-file:          fast

Can you reproduce it?

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 18:03                                                     ` Peter Münster
@ 2016-02-21 20:45                                                       ` Eli Zaretskii
  2016-02-22  7:37                                                         ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-21 20:45 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: rudalics@gmx.at,  larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Sun, 21 Feb 2016 19:03:49 +0100
> 
> On Sun, Feb 21 2016, Eli Zaretskii wrote:
> 
> > Does this happen only with this particular symbol, or binding any
> > symbol slows down?
> 
> It depends on the symbol:
> 
> case-fold-search:     slow
> fill-column:          slow
> just-a-symbol:        fast
> custom-file:          fast
> 
> Can you reproduce it?

I see a 5-fold slow-down with case-fold-search, not a 30-fold as you
reported.

It sounds like the difference is between buffer-local variables and
global variables.  Setting the former will potentially loop over all
the buffers and set the value for every buffer that doesn't have a
local value.  See data.c around line 1517.  How many buffers do you
have in the "slow" version?  I have 230.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-21 20:45                                                       ` Eli Zaretskii
@ 2016-02-22  7:37                                                         ` Peter Münster
  2016-02-22 16:22                                                           ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-22  7:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Sun, Feb 21 2016, Eli Zaretskii wrote:

> How many buffers do you have in the "slow" version? I have 230.

12. (Because regularly I kill unused buffers...)

What happens, if you kill 90% of your buffers?
Does my-parse-time-string-test get faster?

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-22  7:37                                                         ` Peter Münster
@ 2016-02-22 16:22                                                           ` Eli Zaretskii
  2016-02-22 20:41                                                             ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-22 16:22 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: rudalics@gmx.at,  larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Mon, 22 Feb 2016 08:37:29 +0100
> 
> On Sun, Feb 21 2016, Eli Zaretskii wrote:
> 
> > How many buffers do you have in the "slow" version? I have 230.
> 
> 12. (Because regularly I kill unused buffers...)

Curiouser and curiouser...

I just tried this in another, larger session (with more than 500
buffers), and got a 10-fold slowdown there.  So this is definitely
correlated to some measure of the session's size, although perhaps
not the number of the buffers.  Plus, it sounds like symbols that can
be buffer-local share this problem.  Can you try several more
buffer-local and not buffer-local symbols, to see if indeed the
conclusion is valid?

> What happens, if you kill 90% of your buffers?

Sorry, I can't: this is my main session where I do everything.  And
chances are killing them won't change the results, judging by your
measurements.

I think the next step is to profile the code below "let".  Can you try
using 'perf' for that purpose?





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-22 16:22                                                           ` Eli Zaretskii
@ 2016-02-22 20:41                                                             ` Peter Münster
  2016-02-22 20:56                                                               ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-22 20:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Mon, Feb 22 2016, Eli Zaretskii wrote:

> I think the next step is to profile the code below "let".  Can you try
> using 'perf' for that purpose?

Slow emacs: almost all time is spent in Fset_default (96%)

Fast emacs:
  25.36%  emacs         emacs                          [.] eval_sub
  10.73%  emacs         emacs                          [.] Fset_default
   9.63%  emacs         emacs                          [.] Flength
   6.54%  emacs         emacs                          [.] unbind_to
   5.44%  emacs         emacs                          [.] hash_lookup
   4.53%  emacs         emacs                          [.] Flet

You can try it too on your running sessions: "perf record -p PID" and
then "perf report". (just use something like "dotimes (i 1000000000)")

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-22 20:41                                                             ` Peter Münster
@ 2016-02-22 20:56                                                               ` Eli Zaretskii
  2016-02-23 11:19                                                                 ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-22 20:56 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: rudalics@gmx.at,  larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Mon, 22 Feb 2016 21:41:11 +0100
> 
> On Mon, Feb 22 2016, Eli Zaretskii wrote:
> 
> > I think the next step is to profile the code below "let".  Can you try
> > using 'perf' for that purpose?
> 
> Slow emacs: almost all time is spent in Fset_default (96%)
> 
> Fast emacs:
>   25.36%  emacs         emacs                          [.] eval_sub
>   10.73%  emacs         emacs                          [.] Fset_default
>    9.63%  emacs         emacs                          [.] Flength
>    6.54%  emacs         emacs                          [.] unbind_to
>    5.44%  emacs         emacs                          [.] hash_lookup
>    4.53%  emacs         emacs                          [.] Flet

So now the question becomes: which part of Fset_default?  I thought it
was the loop over all the buffers, but your session seems to say it
couldn't be.  Then what is it?

> You can try it too on your running sessions: "perf record -p PID" and
> then "perf report". (just use something like "dotimes (i 1000000000)")

Alas, there's no 'perf' on MS-Windows (nor anything like it, AFAIK).





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-22 20:56                                                               ` Eli Zaretskii
@ 2016-02-23 11:19                                                                 ` Peter Münster
  2016-02-23 16:23                                                                   ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-23 11:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Mon, Feb 22 2016, Eli Zaretskii wrote:

> So now the question becomes: which part of Fset_default?  I thought it
> was the loop over all the buffers, but your session seems to say it
> couldn't be.

Why?

This is what I read in buffer.h:

--8<---------------cut here---------------start------------->8---
/* Chain of all buffers, including killed ones.  */

extern struct buffer *all_buffers;

/* Used to iterate over the chain above.  */

#define FOR_EACH_BUFFER(b) \
  for ((b) = all_buffers; (b); (b) = (b)->next)
--8<---------------cut here---------------end--------------->8---

"including killed ones" !

That means, the chain gets bigger and bigger, whenever I read an article
or I reply or I send a new message or whatever.

I've added a small patch to Fset_default:

--8<---------------cut here---------------start------------->8---
		struct buffer *b;
                int i = 0;
		FOR_EACH_BUFFER (b) {
                  i++;
		  if (!PER_BUFFER_VALUE_P (b, idx))
		    set_per_buffer_value (b, offset, value);
                }
                fprintf(stderr, "length of all_buffers: %d\n", i);
--8<---------------cut here---------------end--------------->8---

Let's see, how the chain grows... (or not)

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-23 11:19                                                                 ` Peter Münster
@ 2016-02-23 16:23                                                                   ` Eli Zaretskii
  2016-02-23 16:35                                                                     ` Peter Münster
  2016-02-24 10:15                                                                     ` martin rudalics
  0 siblings, 2 replies; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-23 16:23 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: rudalics@gmx.at,  larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Tue, 23 Feb 2016 12:19:30 +0100
> 
> On Mon, Feb 22 2016, Eli Zaretskii wrote:
> 
> > So now the question becomes: which part of Fset_default?  I thought it
> > was the loop over all the buffers, but your session seems to say it
> > couldn't be.
> 
> Why?

Because your session has very few buffers, and yet you see a much more
massive slowdown.

> This is what I read in buffer.h:
> 
> --8<---------------cut here---------------start------------->8---
> /* Chain of all buffers, including killed ones.  */
> 
> extern struct buffer *all_buffers;
> 
> /* Used to iterate over the chain above.  */
> 
> #define FOR_EACH_BUFFER(b) \
>   for ((b) = all_buffers; (b); (b) = (b)->next)
> --8<---------------cut here---------------end--------------->8---
> 
> "including killed ones" !

You interpret that comment too literally: it means killed buffers that
were not yet GC'ed.  You will see in alloc.c that sweep_buffers
removes killed buffers from all_buffers and recycles their memory.

> That means, the chain gets bigger and bigger, whenever I read an article
> or I reply or I send a new message or whatever.

If Emacs did that, it would have been a very serious bug and a huge
memory sink.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-23 16:23                                                                   ` Eli Zaretskii
@ 2016-02-23 16:35                                                                     ` Peter Münster
  2016-02-23 16:48                                                                       ` Andreas Schwab
  2016-02-23 17:47                                                                       ` Eli Zaretskii
  2016-02-24 10:15                                                                     ` martin rudalics
  1 sibling, 2 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-23 16:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Tue, Feb 23 2016, Eli Zaretskii wrote:

> You interpret that comment too literally: it means killed buffers that
> were not yet GC'ed.  You will see in alloc.c that sweep_buffers
> removes killed buffers from all_buffers and recycles their memory.

Ok, thanks for the explanation.

My current emacs session is running now since 5 hours. The length of the
chain is 131. And this is my buffer list:

.%* *Article inbox*        1592 Article          
 %* *Summary inbox*          85 Summary          
 %  *Group*                  41 Group            
 %* *Completions*           180 Completion List  
    *scratch*               141 Lisp Interaction 
 %* *Messages*           446718 Messages         
  * todo.org             147282 Org              ~/todo/todo.org

I guess, that the slow-down is related to the chain-length. What do you think?

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-23 16:35                                                                     ` Peter Münster
@ 2016-02-23 16:48                                                                       ` Andreas Schwab
  2016-02-24 10:22                                                                         ` Peter Münster
  2016-02-23 17:47                                                                       ` Eli Zaretskii
  1 sibling, 1 reply; 84+ messages in thread
From: Andreas Schwab @ 2016-02-23 16:48 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

Peter Münster <pmlists@free.fr> writes:

> My current emacs session is running now since 5 hours. The length of the
> chain is 131. And this is my buffer list:
>
> .%* *Article inbox*        1592 Article          
>  %* *Summary inbox*          85 Summary          
>  %  *Group*                  41 Group            
>  %* *Completions*           180 Completion List  
>     *scratch*               141 Lisp Interaction 
>  %* *Messages*           446718 Messages         
>   * todo.org             147282 Org              ~/todo/todo.org

Note that buffers starting with a space are hidden from C-x C-b.  You
can only see them in (buffer-list), or by completing a space in C-x b.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-23 16:35                                                                     ` Peter Münster
  2016-02-23 16:48                                                                       ` Andreas Schwab
@ 2016-02-23 17:47                                                                       ` Eli Zaretskii
  2016-02-24 10:25                                                                         ` Peter Münster
  1 sibling, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-23 17:47 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: rudalics@gmx.at,  larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Tue, 23 Feb 2016 17:35:50 +0100
> 
> My current emacs session is running now since 5 hours. The length of the
> chain is 131. And this is my buffer list:
> 
> .%* *Article inbox*        1592 Article          
>  %* *Summary inbox*          85 Summary          
>  %  *Group*                  41 Group            
>  %* *Completions*           180 Completion List  
>     *scratch*               141 Lisp Interaction 
>  %* *Messages*           446718 Messages         
>   * todo.org             147282 Org              ~/todo/todo.org
> 
> I guess, that the slow-down is related to the chain-length. What do you think?

We need to time that loop to be sure.  Can you do that with 'perf', or
add a call to gettimeofday before and after, and see how much time it
takes as the list of buffers grows?

Thanks.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-23 16:23                                                                   ` Eli Zaretskii
  2016-02-23 16:35                                                                     ` Peter Münster
@ 2016-02-24 10:15                                                                     ` martin rudalics
  2016-02-24 17:42                                                                       ` Eli Zaretskii
  1 sibling, 1 reply; 84+ messages in thread
From: martin rudalics @ 2016-02-24 10:15 UTC (permalink / raw)
  To: Eli Zaretskii, Peter Münster; +Cc: larsi, 18522

 > You interpret that comment too literally: it means killed buffers that
 > were not yet GC'ed.  You will see in alloc.c that sweep_buffers
 > removes killed buffers from all_buffers and recycles their memory.

Doesn't that remove unmarked buffers only?

 >> That means, the chain gets bigger and bigger, whenever I read an article
 >> or I reply or I send a new message or whatever.
 >
 > If Emacs did that, it would have been a very serious bug and a huge
 > memory sink.

One potential hole are window configurations.  Each window maintains two
lists for navigating the buffers previously shown in that window.  For
live windows, these lists are hopefully updated when killing a buffer.
But if you store such a window in a window configuration and forget
about that configuration, the buffers from those lists are not reclaimed
IIUC.

BTW, I have no idea why FOR_EACH_BUFFER should be used outside alloc.c.

martin





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-23 16:48                                                                       ` Andreas Schwab
@ 2016-02-24 10:22                                                                         ` Peter Münster
  0 siblings, 0 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-24 10:22 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: larsi, 18522

On Tue, Feb 23 2016, Andreas Schwab wrote:

> Note that buffers starting with a space are hidden from C-x C-b.  You
> can only see them in (buffer-list), or by completing a space in C-x b.

Ok. There are some hidden buffers (from Gnus).
(length (buffer-list)) -> 27
length of all_buffers  -> 162

What do you think about the difference? Bug or not?
Any explanation?

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-23 17:47                                                                       ` Eli Zaretskii
@ 2016-02-24 10:25                                                                         ` Peter Münster
  2016-02-24 17:39                                                                           ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-24 10:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Tue, Feb 23 2016, Eli Zaretskii wrote:

> We need to time that loop to be sure.  Can you do that with 'perf', 

How please?


> or add a call to gettimeofday before and after, and see how much time
> it takes as the list of buffers grows?

Then, I would need to restart emacs. If it's possible to measure the
time without restarting it, that would be better.

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 10:25                                                                         ` Peter Münster
@ 2016-02-24 17:39                                                                           ` Eli Zaretskii
  2016-02-24 18:00                                                                             ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-24 17:39 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: rudalics@gmx.at,  larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Wed, 24 Feb 2016 11:25:10 +0100
> 
> On Tue, Feb 23 2016, Eli Zaretskii wrote:
> 
> > We need to time that loop to be sure.  Can you do that with 'perf', 
> 
> How please?

"perf annotate", perhaps?

> > or add a call to gettimeofday before and after, and see how much time
> > it takes as the list of buffers grows?
> 
> Then, I would need to restart emacs. If it's possible to measure the
> time without restarting it, that would be better.

Yes, of course.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 10:15                                                                     ` martin rudalics
@ 2016-02-24 17:42                                                                       ` Eli Zaretskii
  2016-02-24 18:16                                                                         ` martin rudalics
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-24 17:42 UTC (permalink / raw)
  To: martin rudalics; +Cc: larsi, pmlists, 18522

> Date: Wed, 24 Feb 2016 11:15:28 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: larsi@gnus.org, 18522@debbugs.gnu.org
> 
>  > You interpret that comment too literally: it means killed buffers that
>  > were not yet GC'ed.  You will see in alloc.c that sweep_buffers
>  > removes killed buffers from all_buffers and recycles their memory.
> 
> Doesn't that remove unmarked buffers only?

Of course.  But why would killed buffers be marked?

>  >> That means, the chain gets bigger and bigger, whenever I read an article
>  >> or I reply or I send a new message or whatever.
>  >
>  > If Emacs did that, it would have been a very serious bug and a huge
>  > memory sink.
> 
> One potential hole are window configurations.  Each window maintains two
> lists for navigating the buffers previously shown in that window.  For
> live windows, these lists are hopefully updated when killing a buffer.
> But if you store such a window in a window configuration and forget
> about that configuration, the buffers from those lists are not reclaimed
> IIUC.

What do you mean by "forget"?  Forgetting a Lisp object means it is
not referenced by any other object, so it will be GCed, together with
the buffers it references.  Right?

> BTW, I have no idea why FOR_EACH_BUFFER should be used outside alloc.c.

What would you use instead?





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 17:39                                                                           ` Eli Zaretskii
@ 2016-02-24 18:00                                                                             ` Peter Münster
  2016-02-24 18:23                                                                               ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-24 18:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Wed, Feb 24 2016, Eli Zaretskii wrote:

> "perf annotate", perhaps?

Thanks, what a great tool!

perf report:

  33.17%  emacs         emacs                          [.] Fset_default

Uptime is only about 1 day now. Length of all_buffers is 207.

perf annotate:

--8<---------------cut here---------------start------------->8---
       │     Fset_default():
       │                    set it in the buffers that don't nominally have a local value.  */
       │                 if (idx > 0)
       │                   {
       │                     struct buffer *b;
       │                     int i = 0;
       │                     FOR_EACH_BUFFER (b)
 15.68 │101:   mov    0x2d8(%rcx),%rcx
 19.34 │       test   %rcx,%rcx
  5.39 │     ↑ jne    f0
       │                     {
       │                       i++;
       │                       if (!PER_BUFFER_VALUE_P (b, idx))
       │                         set_per_buffer_value (b, offset, value);
       │                     }
       │                     fprintf(stderr, "XXXXX: %d\n", i);
  0.07 │10d:   mov    stderr@@GLIBC_2.2.5,%rdi
  2.49 │       mov    $0x5e90e5,%esi
       │       xor    %eax,%eax
--8<---------------cut here---------------end--------------->8---


-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 17:42                                                                       ` Eli Zaretskii
@ 2016-02-24 18:16                                                                         ` martin rudalics
  2016-02-24 18:49                                                                           ` martin rudalics
  0 siblings, 1 reply; 84+ messages in thread
From: martin rudalics @ 2016-02-24 18:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, pmlists, 18522

 > Of course.  But why would killed buffers be marked?

Because they are still referenced from somewhere else.

 > What do you mean by "forget"?  Forgetting a Lisp object means it is
 > not referenced by any other object, so it will be GCed, together with
 > the buffers it references.  Right?

Each window in a window configuration stores all the buffers it has ever
shown.  Now window configurations are sometimes stored in registers.  I
could imagine users that store a couple of configurations in registers
and "forget" about them in the sense that they do not restore from some
of those stored configurations for quite some time or the rest of the
session.

 >> BTW, I have no idea why FOR_EACH_BUFFER should be used outside alloc.c.
 >
 > What would you use instead?

A macro that excludes killed buffers.  What's the purpose of

		  if (!PER_BUFFER_VALUE_P (b, idx))
		    set_per_buffer_value (b, offset, value);

in a killed buffer?

martin





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 18:00                                                                             ` Peter Münster
@ 2016-02-24 18:23                                                                               ` Eli Zaretskii
  2016-02-24 20:03                                                                                 ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-24 18:23 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: rudalics@gmx.at,  larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Wed, 24 Feb 2016 19:00:07 +0100
> 
> perf report:
> 
>   33.17%  emacs         emacs                          [.] Fset_default
> 
> Uptime is only about 1 day now. Length of all_buffers is 207.
> 
> perf annotate:
> 
> --8<---------------cut here---------------start------------->8---
>        │     Fset_default():
>        │                    set it in the buffers that don't nominally have a local value.  */
>        │                 if (idx > 0)
>        │                   {
>        │                     struct buffer *b;
>        │                     int i = 0;
>        │                     FOR_EACH_BUFFER (b)
>  15.68 │101:   mov    0x2d8(%rcx),%rcx
>  19.34 │       test   %rcx,%rcx
>   5.39 │     ↑ jne    f0
>        │                     {
>        │                       i++;
>        │                       if (!PER_BUFFER_VALUE_P (b, idx))
>        │                         set_per_buffer_value (b, offset, value);
>        │                     }
>        │                     fprintf(stderr, "XXXXX: %d\n", i);
>   0.07 │10d:   mov    stderr@@GLIBC_2.2.5,%rdi
>   2.49 │       mov    $0x5e90e5,%esi
>        │       xor    %eax,%eax
> --8<---------------cut here---------------end--------------->8---

What is that "f0" there?  Can you annotate it as well?  Otherwise,
this makes no sense to me: the part that takes most of the time is 2
simple instructions.  Sounds like we are looking at too small portion
of the code, so these are percents of a very small fraction of the
total running time.






^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 18:16                                                                         ` martin rudalics
@ 2016-02-24 18:49                                                                           ` martin rudalics
  2016-02-24 20:27                                                                             ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: martin rudalics @ 2016-02-24 18:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, pmlists, 18522

 > Each window in a window configuration stores all the buffers it has ever
 > shown.  Now window configurations are sometimes stored in registers.  I
 > could imagine users that store a couple of configurations in registers
 > and "forget" about them in the sense that they do not restore from some
 > of those stored configurations for quite some time or the rest of the
 > session.

I just noticed that Stefan fixed that scenario back in 2012.  Anyway,
something similar seems to happen on Peter's machine.  162 buffers with
only 27 live ones cannot be explained by large GC intervals.

martin





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 18:23                                                                               ` Eli Zaretskii
@ 2016-02-24 20:03                                                                                 ` Peter Münster
  2016-02-24 20:26                                                                                   ` Eli Zaretskii
  2016-02-24 23:53                                                                                   ` Lars Ingebrigtsen
  0 siblings, 2 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-24 20:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Wed, Feb 24 2016, Eli Zaretskii wrote:

> What is that "f0" there?  Can you annotate it as well?

Sorry, I thought, that only the part after "Fset_default():" was
important. Here something more complete:

--8<---------------cut here---------------start------------->8---
       │                 /* If this variable is not always local in all buffers,
       │                    set it in the buffers that don't nominally have a local value.  */
       │                 if (idx > 0)
       │     ↑ jle    95
       │                   {
       │                     struct buffer *b;
       │                     int i = 0;
       │                     FOR_EACH_BUFFER (b)
  0.08 │       mov    all_buffers,%rcx
       │       test   %rcx,%rcx
       │     ↓ je     180
       │                     {
       │                       i++;
       │                       if (!PER_BUFFER_VALUE_P (b, idx))
  0.02 │       cmp    last_per_buffer_idx,%edx
       │     ↓ jge    160
       │                   {
       │                     struct buffer *b;
       │                     int i = 0;
       │                     FOR_EACH_BUFFER (b)
       │                     {
       │                       i++;
       │       mov    $0x1,%edx
  0.02 │     ↓ jmp    f3
       │       nop
 15.24 │ f0:   add    $0x1,%edx
       │                       if (!PER_BUFFER_VALUE_P (b, idx))
 14.02 │ f3:   cmpb   $0x0,0x320(%rcx,%rax,1)
 10.65 │     ↓ jne    101
       │     set_per_buffer_value():
       │     }
       │
       │     INLINE void
       │     set_per_buffer_value (struct buffer *b, int offset, Lisp_Object value)
       │     {
       │       *(Lisp_Object *)(offset + (char *) b) = value;
 14.11 │       mov    %rbp,(%rcx,%rsi,1)
       │     Fset_default():
       │                    set it in the buffers that don't nominally have a local value.  */
       │                 if (idx > 0)
       │                   {
       │                     struct buffer *b;
       │                     int i = 0;
       │                     FOR_EACH_BUFFER (b)
 14.36 │101:   mov    0x2d8(%rcx),%rcx
 21.80 │       test   %rcx,%rcx
  5.16 │     ↑ jne    f0
       │                     {
       │                       i++;
       │                       if (!PER_BUFFER_VALUE_P (b, idx))
       │                         set_per_buffer_value (b, offset, value);
       │                     }
       │                     fprintf(stderr, "XXXXX: %d\n", i);
  0.00 │10d:   mov    stderr@@GLIBC_2.2.5,%rdi
  2.18 │       mov    $0x5e90e5,%esi
       │       xor    %eax,%eax
       │     → callq  fprintf@plt
       │     ↑ jmpq   95
       │       nop
--8<---------------cut here---------------end--------------->8---

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 20:03                                                                                 ` Peter Münster
@ 2016-02-24 20:26                                                                                   ` Eli Zaretskii
  2016-02-25  8:06                                                                                     ` Peter Münster
  2016-02-24 23:53                                                                                   ` Lars Ingebrigtsen
  1 sibling, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-24 20:26 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: rudalics@gmx.at,  larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Wed, 24 Feb 2016 21:03:41 +0100
> 
> --8<---------------cut here---------------start------------->8---
>        │                 /* If this variable is not always local in all buffers,
>        │                    set it in the buffers that don't nominally have a local value.  */
>        │                 if (idx > 0)
>        │     ↑ jle    95
>        │                   {
>        │                     struct buffer *b;
>        │                     int i = 0;
>        │                     FOR_EACH_BUFFER (b)
>   0.08 │       mov    all_buffers,%rcx
>        │       test   %rcx,%rcx
>        │     ↓ je     180
>        │                     {
>        │                       i++;
>        │                       if (!PER_BUFFER_VALUE_P (b, idx))
>   0.02 │       cmp    last_per_buffer_idx,%edx
>        │     ↓ jge    160
>        │                   {
>        │                     struct buffer *b;
>        │                     int i = 0;
>        │                     FOR_EACH_BUFFER (b)
>        │                     {
>        │                       i++;
>        │       mov    $0x1,%edx
>   0.02 │     ↓ jmp    f3
>        │       nop
>  15.24 │ f0:   add    $0x1,%edx
>        │                       if (!PER_BUFFER_VALUE_P (b, idx))
>  14.02 │ f3:   cmpb   $0x0,0x320(%rcx,%rax,1)
>  10.65 │     ↓ jne    101
>        │     set_per_buffer_value():
>        │     }
>        │
>        │     INLINE void
>        │     set_per_buffer_value (struct buffer *b, int offset, Lisp_Object value)
>        │     {
>        │       *(Lisp_Object *)(offset + (char *) b) = value;
>  14.11 │       mov    %rbp,(%rcx,%rsi,1)
>        │     Fset_default():
>        │                    set it in the buffers that don't nominally have a local value.  */
>        │                 if (idx > 0)
>        │                   {
>        │                     struct buffer *b;
>        │                     int i = 0;
>        │                     FOR_EACH_BUFFER (b)
>  14.36 │101:   mov    0x2d8(%rcx),%rcx
>  21.80 │       test   %rcx,%rcx
>   5.16 │     ↑ jne    f0
>        │                     {
>        │                       i++;
>        │                       if (!PER_BUFFER_VALUE_P (b, idx))
>        │                         set_per_buffer_value (b, offset, value);
>        │                     }
>        │                     fprintf(stderr, "XXXXX: %d\n", i);
>   0.00 │10d:   mov    stderr@@GLIBC_2.2.5,%rdi
>   2.18 │       mov    $0x5e90e5,%esi
>        │       xor    %eax,%eax
>        │     → callq  fprintf@plt
>        │     ↑ jmpq   95
>        │       nop
> --8<---------------cut here---------------end--------------->8---

Most of the time is spent in the loop over the buffers.

So I guess avoiding binding case-fold-search in parse-time-string
should make the problem go away?





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 18:49                                                                           ` martin rudalics
@ 2016-02-24 20:27                                                                             ` Eli Zaretskii
  2016-02-25  8:07                                                                               ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-24 20:27 UTC (permalink / raw)
  To: martin rudalics; +Cc: larsi, pmlists, 18522

> Date: Wed, 24 Feb 2016 19:49:37 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: larsi@gnus.org, pmlists@free.fr, 18522@debbugs.gnu.org
> 
> something similar seems to happen on Peter's machine.  162 buffers with
> only 27 live ones cannot be explained by large GC intervals.

Perhaps showing the names of those extra buffers will give a clue.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 20:03                                                                                 ` Peter Münster
  2016-02-24 20:26                                                                                   ` Eli Zaretskii
@ 2016-02-24 23:53                                                                                   ` Lars Ingebrigtsen
  2016-02-25  8:08                                                                                     ` Peter Münster
  1 sibling, 1 reply; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-24 23:53 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

Just on a hunch -- what's the value of your `gnus-buffers' variable?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no






^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 20:26                                                                                   ` Eli Zaretskii
@ 2016-02-25  8:06                                                                                     ` Peter Münster
  0 siblings, 0 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-25  8:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Wed, Feb 24 2016, Eli Zaretskii wrote:

> So I guess avoiding binding case-fold-search in parse-time-string
> should make the problem go away?

Yes, it does.

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 20:27                                                                             ` Eli Zaretskii
@ 2016-02-25  8:07                                                                               ` Peter Münster
  2016-02-25 10:06                                                                                 ` martin rudalics
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-25  8:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Wed, Feb 24 2016, Eli Zaretskii wrote:

> Perhaps showing the names of those extra buffers will give a clue.

Could you provide some code please, to show the names?

TIA,
-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-24 23:53                                                                                   ` Lars Ingebrigtsen
@ 2016-02-25  8:08                                                                                     ` Peter Münster
  2016-02-25 15:59                                                                                       ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-25  8:08 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 18522

On Thu, Feb 25 2016, Lars Ingebrigtsen wrote:

> Just on a hunch -- what's the value of your `gnus-buffers' variable?

(#<buffer *unsent mail*> #<buffer *sent mail to Eli Zaretskii*<2>> #<buffer *sent mail to Eli Zaretskii*> #<buffer *Article nndraft:drafts*> #<buffer  *Original Article nndraft:drafts*> #<buffer *Summary nndraft:drafts*> #<killed buffer> #<buffer  *nnmail message-id cache*> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<buffer  *MML2015 Result*> #<killed buffer> #<buffer  *gnus article copy*> #<buffer  *Gnus Backlog*> #<buffer  *gnus work*> #<buffer  *Gnus agent over
 view*> #<buffer *Group*>)

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-25  8:07                                                                               ` Peter Münster
@ 2016-02-25 10:06                                                                                 ` martin rudalics
  0 siblings, 0 replies; 84+ messages in thread
From: martin rudalics @ 2016-02-25 10:06 UTC (permalink / raw)
  To: Peter Münster, Eli Zaretskii; +Cc: larsi, 18522

[-- Attachment #1: Type: text/plain, Size: 127 bytes --]

 > Could you provide some code please, to show the names?

Try ‘killed-buffer-names’ from the attached patch.

martin

[-- Attachment #2: killed-buffer-names.diff --]
[-- Type: text/plain, Size: 2391 bytes --]

diff --git a/src/buffer.c b/src/buffer.c
index 653e3fe..c8cec8c 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -287,6 +287,8 @@ static void
 bset_name (struct buffer *b, Lisp_Object val)
 {
   b->name_ = val;
+  if (!NILP (val))
+    b->live_name_ = val;
 }
 static void
 bset_overwrite_mode (struct buffer *b, Lisp_Object val)
@@ -415,6 +417,21 @@ followed by the rest of the buffers.  */)
     return general;
 }

+DEFUN ("killed-buffer-names", Fkilled_buffer_names, Skilled_buffers_names, 0, 0, 0,
+       doc: /* Return list of names of killed buffers that have not been recycled yet.  */)
+  ()
+{
+  struct buffer *b;
+  Lisp_Object val = Qnil;
+
+  FOR_EACH_BUFFER (b)
+    if (NILP (b->name_))
+      val = Fcons (b->live_name_, val);
+
+  return val;
+}
+
+
 /* Like Fassoc, but use Fstring_equal to compare
    (which ignores text properties),
    and don't ever QUIT.  */
@@ -1103,6 +1120,14 @@ Return nil if BUFFER has been killed.  */)
   return BVAR (decode_buffer (buffer), name);
 }

+DEFUN ("buffer-live-name", Fbuffer_live_name, Sbuffer_live_name, 0, 1, 0,
+       doc: /* Return the name of BUFFER when it was live, as a string.
+	       BUFFER defaults to the current buffer.  */)
+  (register Lisp_Object buffer)
+{
+  return BVAR (decode_buffer (buffer), live_name);
+}
+
 DEFUN ("buffer-file-name", Fbuffer_file_name, Sbuffer_file_name, 0, 1, 0,
        doc: /* Return name of file BUFFER is visiting, or nil if none.
 No argument or nil as argument means use the current buffer.  */)
@@ -6278,12 +6303,14 @@ Functions running this hook are, `get-buffer-create',

   defsubr (&Sbuffer_live_p);
   defsubr (&Sbuffer_list);
+  defsubr (&Skilled_buffers_names);
   defsubr (&Sget_buffer);
   defsubr (&Sget_file_buffer);
   defsubr (&Sget_buffer_create);
   defsubr (&Smake_indirect_buffer);
   defsubr (&Sgenerate_new_buffer_name);
   defsubr (&Sbuffer_name);
+  defsubr (&Sbuffer_live_name);
   defsubr (&Sbuffer_file_name);
   defsubr (&Sbuffer_base_buffer);
   defsubr (&Sbuffer_local_value);
diff --git a/src/buffer.h b/src/buffer.h
index 5783bfb..24bbcb3 100644
--- a/src/buffer.h
+++ b/src/buffer.h
@@ -500,6 +500,9 @@ struct buffer
   /* The name of this buffer.  */
   Lisp_Object name_;

+  /* The name of this buffer when it was live.  */
+  Lisp_Object live_name_;
+
   /* The name of the file visited in this buffer, or nil.  */
   Lisp_Object filename_;



^ permalink raw reply related	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-25  8:08                                                                                     ` Peter Münster
@ 2016-02-25 15:59                                                                                       ` Eli Zaretskii
  2016-02-25 18:10                                                                                         ` Peter Münster
  2016-02-26  3:13                                                                                         ` Lars Ingebrigtsen
  0 siblings, 2 replies; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-25 15:59 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: Eli Zaretskii <eliz@gnu.org>,  18522@debbugs.gnu.org
> Date: Thu, 25 Feb 2016 09:08:44 +0100
> 
> > Just on a hunch -- what's the value of your `gnus-buffers' variable?
> 
> (#<buffer *unsent mail*> #<buffer *sent mail to Eli Zaretskii*<2>> #<buffer 
> *sent mail to Eli Zaretskii*> #<buffer *Article nndraft:drafts*> #<buffer  
> *Original Article nndraft:drafts*> #<buffer *Summary nndraft:drafts*> #<killed 
> buffer> #<buffer  *nnmail message-id cache*> #<killed buffer> #<killed buffer> 
> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed 
> buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> 
> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed 
> buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> 
> #<killed buffer> #<killed buffer> #<buffer  *MML2015 Result*> #<killed buffer> 
> #<buffer  *gnus article copy*> #<buffer  *Gnus Backlog*> #<buffer  *gnus work*> 
> #<buffer  *Gnus agent overview*> #<buffer *Group*>)

OK, so is the following summary of this long discussion accurate?

 . Peter noticed that Gnus is very slow entering a group
 . Gnus is slow because parse-time-string takes a lot of time
 . parse-time-string is slow because it let-binds case-fold-search
 . binding case-fold-search is slow because Peter has a lot of
   buffers, which set-default loops over to change the value of
   case-fold-search in each one of them
 . most of the buffers over which set-default loops were actually
   killed, but they are still in all_buffers list which set-default
   traverses, although they were supposed to be removed by GC
 . killed buffers are not removed from all_buffers by GC because
   they are referenced by gnus-buffers
 . gnus-buffers references killed buffers because Peter kills buffers
   behind Gnus back, instead of letting them be killed through
   gnus-kill-buffer, which would have removed them from gnus-buffers

If the above is an accurate account of what we've discovered, then we
have several factors here that conspire to make Peter's Gnus slow:

 . parse-time-string should try to avoid binding case-fold-search
   globally, or at all
 . set-default should skip killed buffers
 . Peter should stop killing Gnus buffers behind Gnus back

For the first issue, I propose to modify parse-time-string to use
upcase and downcase instead of string-match.  E.g., this:

  (/= (downcase char) char)

can be used to detect upper-case characters, and similarly with
lower-case.

For the second issue, I propose to modify set-default to use
FOR_EACH_LIVE_BUFFER instead of FOR_EACH_BUFFER.  Does anyone see a
problem with that?

For the third issue, Peter should make his buffer-killing code look in
gnus-buffers, and kill any buffers referenced by it through
gnus-kill-buffer.  If this involves some standard Emacs features (like
'midnight', perhaps), then those features should also be adapted to
gnus-buffers.

Comments?





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-25 15:59                                                                                       ` Eli Zaretskii
@ 2016-02-25 18:10                                                                                         ` Peter Münster
  2016-02-25 18:25                                                                                           ` Eli Zaretskii
  2016-02-26  3:18                                                                                           ` Lars Ingebrigtsen
  2016-02-26  3:13                                                                                         ` Lars Ingebrigtsen
  1 sibling, 2 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-25 18:10 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Thu, Feb 25 2016, Eli Zaretskii wrote:

>  . gnus-buffers references killed buffers because Peter kills buffers
>    behind Gnus back, instead of letting them be killed through
>    gnus-kill-buffer, which would have removed them from gnus-buffers

This point is perhaps not 100% accurate. After 6h running, here some
more details about the situation:

- length of all_buffers:         74
- length of buffer-list:         45
- length of killed-buffer-names: 28
- length of gnus-buffers:        17

Content of killed-buffer-names:

Name                                            Details
-----------------------------------------------------------------------------
" *mm*"                                         ???
" *mm*-292588"                                  ???
" *mm*-331546"                                  ???
" *mm*-391449"                                  ???
" *mm*-531130"                                  ???
" *mm*-59524"                                   ???
" *mm*-705438"                                  ???
" *mm*-971636"                                  ???
" *nnmail message-id cache*"                    ???
" *nnml overview inbox*"                        ???
" *server news.gmane.org nntp  *nntpd**"        ???
" *server news.gmane.org nntp  *nntpd**"        ???
" *server news.povray.org nntp  *nntpd**"       ???
" *server news.povray.org nntp  *nntpd**"       ???
"*Backtrace*"                                   killed by me with kill-buffer
"*Completions*"                                 killed by me with kill-buffer
"*Completions*"                                 killed by me with kill-buffer
"*Help*"                                        killed by me with kill-buffer
"*Summary nndraft:drafts*"                      killed by gnus-summary-exit
"*Summary nntp+news.gmane.org:gmane.comp.
                     embedded.openwrt.user*"    killed by gnus-summary-exit
"*sent mail to SAV*"                            killed by me with kill-buffer
"*sent mail to XXX*"                            killed by me with kill-buffer
"*sent mail to YYY*"                            killed by me with kill-buffer
"*unsent wide reply to Eli Zaretskii*"          killed by me with kill-buffer
"*unsent wide reply to SAV*"                    killed by me with kill-buffer
"*unsent wide reply to ZZZ*"                    killed by me with kill-buffer
"gnus-util.el"                                  killed by me with kill-buffer
"jl-encrypt.el"                                 killed by me with kill-buffer

There are 6 "#<killed buffer>" in gnus-buffers. That means, that I
should have killed the 6 buffers "*sent ..." and "*unsent ..." with
gnus-kill-buffer. I'll do that in the future. But what about the other buffers?

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-25 18:10                                                                                         ` Peter Münster
@ 2016-02-25 18:25                                                                                           ` Eli Zaretskii
  2016-02-26 11:05                                                                                             ` Peter Münster
  2016-02-26  3:18                                                                                           ` Lars Ingebrigtsen
  1 sibling, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-25 18:25 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Thu, 25 Feb 2016 19:10:58 +0100
> 
> On Thu, Feb 25 2016, Eli Zaretskii wrote:
> 
> >  . gnus-buffers references killed buffers because Peter kills buffers
> >    behind Gnus back, instead of letting them be killed through
> >    gnus-kill-buffer, which would have removed them from gnus-buffers
> 
> This point is perhaps not 100% accurate. After 6h running, here some
> more details about the situation:
> 
> - length of all_buffers:         74
> - length of buffer-list:         45
> - length of killed-buffer-names: 28
> - length of gnus-buffers:        17
> 
> Content of killed-buffer-names:
> 
> Name                                            Details
> -----------------------------------------------------------------------------
> " *mm*"                                         ???
> " *mm*-292588"                                  ???
> " *mm*-331546"                                  ???
> " *mm*-391449"                                  ???
> " *mm*-531130"                                  ???
> " *mm*-59524"                                   ???
> " *mm*-705438"                                  ???
> " *mm*-971636"                                  ???
> " *nnmail message-id cache*"                    ???
> " *nnml overview inbox*"                        ???
> " *server news.gmane.org nntp  *nntpd**"        ???
> " *server news.gmane.org nntp  *nntpd**"        ???
> " *server news.povray.org nntp  *nntpd**"       ???
> " *server news.povray.org nntp  *nntpd**"       ???
> "*Backtrace*"                                   killed by me with kill-buffer
> "*Completions*"                                 killed by me with kill-buffer
> "*Completions*"                                 killed by me with kill-buffer
> "*Help*"                                        killed by me with kill-buffer
> "*Summary nndraft:drafts*"                      killed by gnus-summary-exit
> "*Summary nntp+news.gmane.org:gmane.comp.
>                      embedded.openwrt.user*"    killed by gnus-summary-exit
> "*sent mail to SAV*"                            killed by me with kill-buffer
> "*sent mail to XXX*"                            killed by me with kill-buffer
> "*sent mail to YYY*"                            killed by me with kill-buffer
> "*unsent wide reply to Eli Zaretskii*"          killed by me with kill-buffer
> "*unsent wide reply to SAV*"                    killed by me with kill-buffer
> "*unsent wide reply to ZZZ*"                    killed by me with kill-buffer
> "gnus-util.el"                                  killed by me with kill-buffer
> "jl-encrypt.el"                                 killed by me with kill-buffer
> 
> There are 6 "#<killed buffer>" in gnus-buffers. That means, that I
> should have killed the 6 buffers "*sent ..." and "*unsent ..." with
> gnus-kill-buffer. I'll do that in the future. But what about the other buffers?

The *mm*-NNN buffers sound like something related to Gnus mail, so I
defer to you and Lars for describing their life cycle.

Likewise with *nnmail...*" and *server news....* buffers.

(It's quite possible that these were also killed by you at some
inopportune moment, btw, and that's why they are still around.  Can
you describe in more detail how you kill buffers?  Or maybe try
running for a few days without killing buffers, except manually when
you are done with visiting some file, and see what winds up in the
list of killed buffers?)

*Completions*, *Help*, and *Backtrace* -- simply don't kill them, it's
useless.  They will pop up again soon enough.

In any case, the other 2 measures should fix the original problem.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-25 15:59                                                                                       ` Eli Zaretskii
  2016-02-25 18:10                                                                                         ` Peter Münster
@ 2016-02-26  3:13                                                                                         ` Lars Ingebrigtsen
  2016-02-26  8:48                                                                                           ` Eli Zaretskii
  2016-02-26  9:28                                                                                           ` Eli Zaretskii
  1 sibling, 2 replies; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-26  3:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Peter Münster, 18522

Eli Zaretskii <eliz@gnu.org> writes:

>  . most of the buffers over which set-default loops were actually
>    killed, but they are still in all_buffers list which set-default
>    traverses, although they were supposed to be removed by GC
>  . killed buffers are not removed from all_buffers by GC because
>    they are referenced by gnus-buffers
>  . gnus-buffers references killed buffers because Peter kills buffers
>    behind Gnus back, instead of letting them be killed through
>    gnus-kill-buffer, which would have removed them from gnus-buffers

It's probably not just Peter, but...  code somewhere.  My gnus-buffers
is currently:

(#<buffer *unsent wide reply to Eli Zaretskii*> #<buffer *Article nnimap+hermes.netfonds.no:emacs-devel*> #<buffer  *Original Article nnimap+hermes.netfonds.no:emacs-devel*> #<buffer *Summary nnimap+hermes.netfonds.no:emacs-devel*> #<buffer *sent wide reply to Eli Zaretskii*> #<buffer *sent wide reply to Richard Stallman*> #<killed buffer> #<buffer *sent wide reply to Thierry Volpiatto*> #<buffer *sent wide reply to Lars Magne Ingebrigtsen*> #<buffer *sent wide reply to Matthew Styskal*> #<buffer *sent wide reply to Paul Eggert*<3>> #<buffer *sent wide reply to Zachary Kanfer*> #<buffer *sent wide reply to David Engster*> #<buffer *sent wide reply to Paul Eggert*<2>> #<buffer *sent wide reply to Paul Eggert*> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<buffer  *gnus article copy*> #<killed buffer> #<buffer  *nnmail message-id cache*> #<buffer  *nnimap hermes.netfonds.no nil  *nntpd**> #<buffer  *gnus work*> #<buffer .newsrc-dribble> #<buffer  *Gnus agent overview*> #<buffer *Group*>)

I'll fix the gnus-{add,kill}-buffer functions so that they remove all
the killed buffers.  That should help keep that list down to a
reasonable length, and let all the killed buffers be GC'd.

> If the above is an accurate account of what we've discovered, then we
> have several factors here that conspire to make Peter's Gnus slow:
>
>  . parse-time-string should try to avoid binding case-fold-search
>    globally, or at all

It's kinda weird.  This starts with:

(defun parse-time-string (string)

[...]

	(temp (parse-time-tokenize (downcase string))))

which calls

(defsubst parse-time-string-chars (char)
  (save-match-data
    (let (case-fold-search str)
      (cond ((eq char ?+) 1)
	    ((eq char ?-) -1)
	    ((eq char ?:) ?d)
	    ((string-match "[[:upper:]]" (setq str (string char))) ?A)
	    ((string-match "[[:lower:]]" str) ?a)
	    ((string-match "[[:digit:]]" str) ?0)))))

!?

Since we've already downcased the entire string, both the
`case-fold-search' and the match to [[:upper:]] seem rather
nonsensical?  So that should be fixed, but:

>  . set-default should skip killed buffers

Yes.  I think that would be a win in general.

> For the second issue, I propose to modify set-default to use
> FOR_EACH_LIVE_BUFFER instead of FOR_EACH_BUFFER.  Does anyone see a
> problem with that?

Hm...  If a buffer is killed, do the local variables still have an
effect?  I'm thinking of code like:

(with-temp-buffer
  (setq-local foo 'bar)
  (kill-buffer (current-buffer))
  (let ((buf (current-buffer)))
    (with-temp-buffer
      (let ((foo 'zot))
        (set-buffer buf)
        foo))))

Well, that answered itself.  :-) It returns zot.  (If we don't kill it
returns bar.)  So I don't see any reason not to use FOR_EACH_LIVE_BUFFER
here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-25 18:10                                                                                         ` Peter Münster
  2016-02-25 18:25                                                                                           ` Eli Zaretskii
@ 2016-02-26  3:18                                                                                           ` Lars Ingebrigtsen
  1 sibling, 0 replies; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-26  3:18 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

Peter Münster <pmlists@free.fr> writes:

> Name                                            Details
> -----------------------------------------------------------------------------
> " *mm*"                                         ???
> " *mm*-292588"                                  ???
> " *mm*-331546"                                  ???
> " *mm*-391449"                                  ???
> " *mm*-531130"                                  ???
> " *mm*-59524"                                   ???
> " *mm*-705438"                                  ???
> " *mm*-971636"                                  ???

Hm...  could these be from `mml-buffer-list'?   Which is a list I've
just discovered.  No, that's something else...  I wonder where these are
coming from.  That is, Gnus creates " *mm*" buffers a lot, but I can't
see where Gnus is keeping them in a list...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-26  3:13                                                                                         ` Lars Ingebrigtsen
@ 2016-02-26  8:48                                                                                           ` Eli Zaretskii
  2016-02-28  4:02                                                                                             ` Lars Ingebrigtsen
  2016-02-26  9:28                                                                                           ` Eli Zaretskii
  1 sibling, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-26  8:48 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: pmlists, 18522

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Peter Münster <pmlists@free.fr>,
>   18522@debbugs.gnu.org
> Date: Fri, 26 Feb 2016 13:43:44 +1030
> 
> >  . parse-time-string should try to avoid binding case-fold-search
> >    globally, or at all
> 
> It's kinda weird.  This starts with:
> 
> (defun parse-time-string (string)
> 
> [...]
> 
> 	(temp (parse-time-tokenize (downcase string))))
> 
> which calls
> 
> (defsubst parse-time-string-chars (char)
>   (save-match-data
>     (let (case-fold-search str)
>       (cond ((eq char ?+) 1)
> 	    ((eq char ?-) -1)
> 	    ((eq char ?:) ?d)
> 	    ((string-match "[[:upper:]]" (setq str (string char))) ?A)
> 	    ((string-match "[[:lower:]]" str) ?a)
> 	    ((string-match "[[:digit:]]" str) ?0)))))
> 
> !?
> 
> Since we've already downcased the entire string, both the
> `case-fold-search' and the match to [[:upper:]] seem rather
> nonsensical?

Yes, weird.  And even if someone thought of using
parse-time-string-chars in other places that don't necessarily
downcase the string, I don't understand why we should test a character
by making it a string, then matching against [:upper:].  Maybe I'm
missing something.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-26  3:13                                                                                         ` Lars Ingebrigtsen
  2016-02-26  8:48                                                                                           ` Eli Zaretskii
@ 2016-02-26  9:28                                                                                           ` Eli Zaretskii
  2016-02-28  4:04                                                                                             ` Lars Ingebrigtsen
  1 sibling, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-26  9:28 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: pmlists, 18522

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Peter Münster <pmlists@free.fr>,
>   18522@debbugs.gnu.org
> Date: Fri, 26 Feb 2016 13:43:44 +1030
> 
> Since we've already downcased the entire string, both the
> `case-fold-search' and the match to [[:upper:]] seem rather
> nonsensical?  So that should be fixed, but:
> 
> >  . set-default should skip killed buffers
> 
> Yes.  I think that would be a win in general.
> 
> > For the second issue, I propose to modify set-default to use
> > FOR_EACH_LIVE_BUFFER instead of FOR_EACH_BUFFER.  Does anyone see a
> > problem with that?
> 
> Hm...  If a buffer is killed, do the local variables still have an
> effect?  I'm thinking of code like:
> 
> (with-temp-buffer
>   (setq-local foo 'bar)
>   (kill-buffer (current-buffer))
>   (let ((buf (current-buffer)))
>     (with-temp-buffer
>       (let ((foo 'zot))
>         (set-buffer buf)
>         foo))))
> 
> Well, that answered itself.  :-) It returns zot.  (If we don't kill it
> returns bar.)  So I don't see any reason not to use FOR_EACH_LIVE_BUFFER
> here.

Btw, why did you fix all those on master?  I think this should be
fixed on emacs-25 instead.

Thanks.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-25 18:25                                                                                           ` Eli Zaretskii
@ 2016-02-26 11:05                                                                                             ` Peter Münster
  2016-02-26 11:13                                                                                               ` Eli Zaretskii
  0 siblings, 1 reply; 84+ messages in thread
From: Peter Münster @ 2016-02-26 11:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Thu, Feb 25 2016, Eli Zaretskii wrote:

> Can you describe in more detail how you kill buffers?

In summary buffers, I press "q" (gnus-summary-exit).
In other buffers, I press M-k (bound to kill-this-buffer).


> Or maybe try running for a few days without killing buffers, except
> manually when you are done with visiting some file, and see what winds
> up in the list of killed buffers?)

Ok.


> *Completions*, *Help*, and *Backtrace* -- simply don't kill them, it's
> useless.  They will pop up again soon enough.

I know, but the habit to kill useless buffers is in my fingers already
for a long time...


> In any case, the other 2 measures should fix the original problem.

If the case really doesn't matter in a time-string, then of course just
down-case the string and then parse it.

But I think, that we have found another issue (just a very tiny one):
the number of killed buffers, that are not GCed, keeps growing.

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-26 11:05                                                                                             ` Peter Münster
@ 2016-02-26 11:13                                                                                               ` Eli Zaretskii
  2016-02-26 11:35                                                                                                 ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-26 11:13 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: larsi@gnus.org,  18522@debbugs.gnu.org
> Date: Fri, 26 Feb 2016 12:05:12 +0100
> 
> If the case really doesn't matter in a time-string, then of course just
> down-case the string and then parse it.

I proposed a change there that will support mixed case, but won't need
to bind case-fold-search.  We could use that instead.

> But I think, that we have found another issue (just a very tiny one):
> the number of killed buffers, that are not GCed, keeps growing.

Indeed.  I believe Lars is working on this.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-26 11:13                                                                                               ` Eli Zaretskii
@ 2016-02-26 11:35                                                                                                 ` Peter Münster
  2016-02-28  4:10                                                                                                   ` Lars Ingebrigtsen
  2016-02-28  5:12                                                                                                   ` bug#18522: 24.4.50; mapcar is very slow Lars Ingebrigtsen
  0 siblings, 2 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-26 11:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 18522

On Fri, Feb 26 2016, Eli Zaretskii wrote:

>> But I think, that we have found another issue (just a very tiny one):
>> the number of killed buffers, that are not GCed, keeps growing.
>
> Indeed.  I believe Lars is working on this.

It's not only about Gnus buffers. Here some buffer names from my current
killed-buffer-names list:
"*Completions*" "*Backtrace*" "gnus-util.el" "jl-encrypt.el"
"*Completions*" "*Help*" "*Choices*" "misc" "quittance-greenever.tex"
"*~/ctx/misc/quittance-greenever output*" "*Choices*" "custom.el"

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-26  8:48                                                                                           ` Eli Zaretskii
@ 2016-02-28  4:02                                                                                             ` Lars Ingebrigtsen
  0 siblings, 0 replies; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-28  4:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: pmlists, 18522

Eli Zaretskii <eliz@gnu.org> writes:

>> (defsubst parse-time-string-chars (char)
>>   (save-match-data
>>     (let (case-fold-search str)
>>       (cond ((eq char ?+) 1)
>> 	    ((eq char ?-) -1)
>> 	    ((eq char ?:) ?d)
>> 	    ((string-match "[[:upper:]]" (setq str (string char))) ?A)
>> 	    ((string-match "[[:lower:]]" str) ?a)
>> 	    ((string-match "[[:digit:]]" str) ?0)))))

[...]

> Yes, weird.  And even if someone thought of using
> parse-time-string-chars in other places that don't necessarily
> downcase the string, I don't understand why we should test a character
> by making it a string, then matching against [:upper:].  Maybe I'm
> missing something.

No, that's also rather puzzling.  Looking at the rest of the code, we
don't really handle anything other than [a-z] and [0-9] here, so using a
regexp instead of a (<= ?0 char ?9) (etc.) also seems odd.  And losing
those `string-match' calls would also mean we could get rid of the
`save-match-data' call.

I think I'll put together a test harness for `parse-time' and then clean
up this function further.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-26  9:28                                                                                           ` Eli Zaretskii
@ 2016-02-28  4:04                                                                                             ` Lars Ingebrigtsen
  2017-01-25 20:09                                                                                               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-28  4:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: pmlists, 18522

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, why did you fix all those on master?  I think this should be
> fixed on emacs-25 instead.

I didn't consider this a bug, really, but an optimisation.  Besides, no
test harness.

But after more testing, I think we could backport the resulting version
of parse-time.el.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-26 11:35                                                                                                 ` Peter Münster
@ 2016-02-28  4:10                                                                                                   ` Lars Ingebrigtsen
  2016-02-28  8:07                                                                                                     ` Peter Münster
  2016-02-28  5:12                                                                                                   ` bug#18522: 24.4.50; mapcar is very slow Lars Ingebrigtsen
  1 sibling, 1 reply; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-28  4:10 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

Peter Münster <pmlists@free.fr> writes:

> On Fri, Feb 26 2016, Eli Zaretskii wrote:
>
>>> But I think, that we have found another issue (just a very tiny one):
>>> the number of killed buffers, that are not GCed, keeps growing.
>>
>> Indeed.  I believe Lars is working on this.
>
> It's not only about Gnus buffers. Here some buffer names from my current
> killed-buffer-names list:
> "*Completions*" "*Backtrace*" "gnus-util.el" "jl-encrypt.el"
> "*Completions*" "*Help*" "*Choices*" "misc" "quittance-greenever.tex"
> "*~/ctx/misc/quittance-greenever output*" "*Choices*" "custom.el"

There may be other lists that keep track of those buffers...

Try evaling the following and post the list appearing in *Messages*:

(mapatoms
 (lambda (symbol)
   (when (boundp symbol)
     (let ((value (symbol-value symbol)))
       (while (consp value)
	 (let ((elem (car value)))
	   (when (bufferp elem)
	     (message "%s has a buffer %s"
		      symbol (buffer-name elem))))
	 (setq value (cdr value))))))
 obarray)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-26 11:35                                                                                                 ` Peter Münster
  2016-02-28  4:10                                                                                                   ` Lars Ingebrigtsen
@ 2016-02-28  5:12                                                                                                   ` Lars Ingebrigtsen
  1 sibling, 0 replies; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-28  5:12 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

I've now rewritten that function to not use all those regexp and stuff,
and I'm pleased to say that

(benchmark-run 1
  (dotimes (i 100000)
    (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))

went from approx 9 seconds on my computer to 3.5 seconds (in fresh -Q
Emacsen).  :-)  (I haven't measured whether that's because it's creating
less garbage or just because it's ... faster.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no






^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-28  4:10                                                                                                   ` Lars Ingebrigtsen
@ 2016-02-28  8:07                                                                                                     ` Peter Münster
  2016-02-28 15:48                                                                                                       ` Eli Zaretskii
  2016-02-29  2:21                                                                                                       ` Lars Ingebrigtsen
  0 siblings, 2 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-28  8:07 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 18522

On Sun, Feb 28 2016, Lars Ingebrigtsen wrote:

> Try evaling the following and post the list appearing in *Messages*:
>
> (mapatoms
>  (lambda (symbol)
>    (when (boundp symbol)
>      (let ((value (symbol-value symbol)))
>        (while (consp value)
> 	 (let ((elem (car value)))
> 	   (when (bufferp elem)
> 	     (message "%s has a buffer %s"
> 		      symbol (buffer-name elem))))
> 	 (setq value (cdr value))))))
>  obarray)

multi-web-global-mode-buffers has a buffer  *Minibuf-1*
rfn-eshadow-frobbed-minibufs has a buffer  *Minibuf-1*
gnus-buffers has a buffer *Article nndraft:drafts*
gnus-buffers has a buffer  *Original Article nndraft:drafts*
gnus-buffers has a buffer *Summary nndraft:drafts*
gnus-buffers has a buffer nil
gnus-buffers has a buffer *unsent wide reply to Lars Ingebrigtsen*
gnus-buffers has a buffer  *gnus article copy*
gnus-buffers has a buffer  *nnmail message-id cache*
gnus-buffers has a buffer  *Gnus Backlog*
gnus-buffers has a buffer  *gnus work*
gnus-buffers has a buffer  *Gnus agent overview*
gnus-buffers has a buffer *Group*

And then I have to stop it with C-g because it hangs...

I had to restart emacs this morning, there are no more *Help* and
*Completions* buffers in the killed list. But there is "gnus-util.el".
 
-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-28  8:07                                                                                                     ` Peter Münster
@ 2016-02-28 15:48                                                                                                       ` Eli Zaretskii
  2016-02-29  2:21                                                                                                       ` Lars Ingebrigtsen
  1 sibling, 0 replies; 84+ messages in thread
From: Eli Zaretskii @ 2016-02-28 15:48 UTC (permalink / raw)
  To: Peter Münster; +Cc: larsi, 18522

> From: Peter Münster <pmlists@free.fr>
> Cc: Eli Zaretskii <eliz@gnu.org>,  18522@debbugs.gnu.org
> Date: Sun, 28 Feb 2016 09:07:08 +0100
> 
> On Sun, Feb 28 2016, Lars Ingebrigtsen wrote:
> 
> > Try evaling the following and post the list appearing in *Messages*:
> >
> > (mapatoms
> >  (lambda (symbol)
> >    (when (boundp symbol)
> >      (let ((value (symbol-value symbol)))
> >        (while (consp value)
> > 	 (let ((elem (car value)))
> > 	   (when (bufferp elem)
> > 	     (message "%s has a buffer %s"
> > 		      symbol (buffer-name elem))))
> > 	 (setq value (cdr value))))))
> >  obarray)
> 
> multi-web-global-mode-buffers has a buffer  *Minibuf-1*
> rfn-eshadow-frobbed-minibufs has a buffer  *Minibuf-1*
> gnus-buffers has a buffer *Article nndraft:drafts*
> gnus-buffers has a buffer  *Original Article nndraft:drafts*
> gnus-buffers has a buffer *Summary nndraft:drafts*
> gnus-buffers has a buffer nil
> gnus-buffers has a buffer *unsent wide reply to Lars Ingebrigtsen*
> gnus-buffers has a buffer  *gnus article copy*
> gnus-buffers has a buffer  *nnmail message-id cache*
> gnus-buffers has a buffer  *Gnus Backlog*
> gnus-buffers has a buffer  *gnus work*
> gnus-buffers has a buffer  *Gnus agent overview*
> gnus-buffers has a buffer *Group*
> 
> And then I have to stop it with C-g because it hangs...

So there's a symbol-value there whose cdr equal's itself?  That should
be easy to protect against, no?

Also, I'd suggest disabling GCC during the time this runs.





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-28  8:07                                                                                                     ` Peter Münster
  2016-02-28 15:48                                                                                                       ` Eli Zaretskii
@ 2016-02-29  2:21                                                                                                       ` Lars Ingebrigtsen
  2016-02-29 10:33                                                                                                         ` bug#18522: killed buffers not GCed (was: bug#18522: 24.4.50; mapcar is very slow) Peter Münster
  1 sibling, 1 reply; 84+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-29  2:21 UTC (permalink / raw)
  To: Peter Münster; +Cc: 18522

Peter Münster <pmlists@free.fr> writes:

> And then I have to stop it with C-g because it hangs...

Probably a circular list somewhere.  Try the following:

(let ((table (make-hash-table :test 'eq)))
  (mapatoms
   (lambda (symbol)
     (when (boundp symbol)
       (let ((value (symbol-value symbol)))
	 (while (and (consp value)
		     (not (gethash value table)))
	   (let ((elem (car value)))
	     (when (bufferp elem)
	       (message "%s has a buffer %s"
			symbol (buffer-name elem))))
	   (setf (gethash value table) t)
	   (setq value (cdr value))))))
   obarray))


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: killed buffers not GCed (was: bug#18522: 24.4.50; mapcar is very slow)
  2016-02-29  2:21                                                                                                       ` Lars Ingebrigtsen
@ 2016-02-29 10:33                                                                                                         ` Peter Münster
  0 siblings, 0 replies; 84+ messages in thread
From: Peter Münster @ 2016-02-29 10:33 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 18522

On Mon, Feb 29 2016, Lars Ingebrigtsen wrote:

> Probably a circular list somewhere.  Try the following:

Output:

multi-web-global-mode-buffers has a buffer  *Minibuf-1*
message-buffer-list has a buffer *sent mail to XXX*
rfn-eshadow-frobbed-minibufs has a buffer  *Minibuf-1*
gnus-buffers has a buffer *Article nndraft:drafts*
gnus-buffers has a buffer  *Original Article nndraft:drafts*
gnus-buffers has a buffer *Summary nndraft:drafts*
gnus-buffers has a buffer *unsent mail*
gnus-buffers has a buffer  *nnmail message-id cache*
gnus-buffers has a buffer *sent mail to XXX*
gnus-buffers has a buffer  *MML2015 Result*
gnus-buffers has a buffer nil
gnus-buffers has a buffer *unsent wide reply to Lars Ingebrigtsen*
gnus-buffers has a buffer  *gnus article copy*
gnus-buffers has a buffer  *Gnus Backlog*
gnus-buffers has a buffer  *gnus work*
gnus-buffers has a buffer  *Gnus agent overview*
gnus-buffers has a buffer *Group*
undo-auto--undoably-changed-buffers has a buffer  *Minibuf-1*
global-font-lock-mode-buffers has a buffer  *Minibuf-1*
eval-buffer-list has a buffer hugo.el

And here the names of killed buffers:

"*Messages*"
"*GNU Emacs*"
"*Article inbox*"
"*unsent mail*"
"*Summary nndraft:drafts*"
"*Summary nndraft:drafts*"
"*Article nndraft:drafts*"
"gnus-util.el"
"quittance-samson.tex"

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2016-02-28  4:04                                                                                             ` Lars Ingebrigtsen
@ 2017-01-25 20:09                                                                                               ` Lars Ingebrigtsen
  2017-01-25 20:39                                                                                                 ` Peter Münster
  0 siblings, 1 reply; 84+ messages in thread
From: Lars Ingebrigtsen @ 2017-01-25 20:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: pmlists, 18522

I think the conclusion from this mega-thread was that this was fixed.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no






^ permalink raw reply	[flat|nested] 84+ messages in thread

* bug#18522: 24.4.50; mapcar is very slow
  2017-01-25 20:09                                                                                               ` Lars Ingebrigtsen
@ 2017-01-25 20:39                                                                                                 ` Peter Münster
  0 siblings, 0 replies; 84+ messages in thread
From: Peter Münster @ 2017-01-25 20:39 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 18522

On Wed, Jan 25 2017, Lars Ingebrigtsen wrote:

> I think the conclusion from this mega-thread was that this was fixed.

Yes, thanks.

-- 
           Peter





^ permalink raw reply	[flat|nested] 84+ messages in thread

end of thread, other threads:[~2017-01-25 20:39 UTC | newest]

Thread overview: 84+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-22 10:37 bug#18522: 24.4.50; mapcar is very slow Peter Münster
2014-09-22 10:43 ` bug#18522: further information Peter Münster
2014-09-22 12:49 ` bug#18522: 24.4.50; mapcar is very slow Stefan Monnier
2014-09-22 13:47   ` Peter Münster
2014-09-25 21:36     ` Peter Münster
2014-09-26  6:57       ` Eli Zaretskii
2014-09-26  7:15         ` Peter Münster
2014-09-26  7:36           ` Eli Zaretskii
2014-10-01 19:55             ` Peter Münster
2014-10-01 19:58             ` Glenn Morris
2014-10-01 20:25               ` Peter Münster
2015-02-13  8:26                 ` Lars Ingebrigtsen
2015-02-13 14:39                   ` Peter Münster
2015-02-14  4:19                     ` Lars Ingebrigtsen
2015-03-02 14:34                       ` Peter Münster
2015-07-20 12:52                         ` Peter Münster
2016-02-07  6:31                         ` Lars Ingebrigtsen
2016-02-17 16:00                           ` Peter Münster
2016-02-19  5:15                             ` Lars Ingebrigtsen
2016-02-19  8:27                               ` Peder O. Klingenberg
2016-02-19  8:38                               ` Eli Zaretskii
2016-02-19 10:06                                 ` Nicolas Richard
2016-02-19 10:12                                 ` Peder O. Klingenberg
2016-02-19 22:46                                 ` Lars Ingebrigtsen
2016-02-20  8:14                                   ` Eli Zaretskii
2016-02-20  8:33                                     ` Peter Münster
2016-02-20  9:51                                       ` Eli Zaretskii
2016-02-21 11:00                                         ` Peter Münster
2016-02-21 11:08                                           ` Andreas Schwab
2016-02-21 11:09                                           ` martin rudalics
2016-02-21 11:30                                             ` Peter Münster
2016-02-21 13:41                                               ` Michael Heerdegen
2016-02-21 14:02                                                 ` Peter Münster
2016-02-21 14:36                                               ` Peter Münster
2016-02-21 14:54                                                 ` Peter Münster
2016-02-21 16:14                                                   ` Eli Zaretskii
2016-02-21 18:03                                                     ` Peter Münster
2016-02-21 20:45                                                       ` Eli Zaretskii
2016-02-22  7:37                                                         ` Peter Münster
2016-02-22 16:22                                                           ` Eli Zaretskii
2016-02-22 20:41                                                             ` Peter Münster
2016-02-22 20:56                                                               ` Eli Zaretskii
2016-02-23 11:19                                                                 ` Peter Münster
2016-02-23 16:23                                                                   ` Eli Zaretskii
2016-02-23 16:35                                                                     ` Peter Münster
2016-02-23 16:48                                                                       ` Andreas Schwab
2016-02-24 10:22                                                                         ` Peter Münster
2016-02-23 17:47                                                                       ` Eli Zaretskii
2016-02-24 10:25                                                                         ` Peter Münster
2016-02-24 17:39                                                                           ` Eli Zaretskii
2016-02-24 18:00                                                                             ` Peter Münster
2016-02-24 18:23                                                                               ` Eli Zaretskii
2016-02-24 20:03                                                                                 ` Peter Münster
2016-02-24 20:26                                                                                   ` Eli Zaretskii
2016-02-25  8:06                                                                                     ` Peter Münster
2016-02-24 23:53                                                                                   ` Lars Ingebrigtsen
2016-02-25  8:08                                                                                     ` Peter Münster
2016-02-25 15:59                                                                                       ` Eli Zaretskii
2016-02-25 18:10                                                                                         ` Peter Münster
2016-02-25 18:25                                                                                           ` Eli Zaretskii
2016-02-26 11:05                                                                                             ` Peter Münster
2016-02-26 11:13                                                                                               ` Eli Zaretskii
2016-02-26 11:35                                                                                                 ` Peter Münster
2016-02-28  4:10                                                                                                   ` Lars Ingebrigtsen
2016-02-28  8:07                                                                                                     ` Peter Münster
2016-02-28 15:48                                                                                                       ` Eli Zaretskii
2016-02-29  2:21                                                                                                       ` Lars Ingebrigtsen
2016-02-29 10:33                                                                                                         ` bug#18522: killed buffers not GCed (was: bug#18522: 24.4.50; mapcar is very slow) Peter Münster
2016-02-28  5:12                                                                                                   ` bug#18522: 24.4.50; mapcar is very slow Lars Ingebrigtsen
2016-02-26  3:18                                                                                           ` Lars Ingebrigtsen
2016-02-26  3:13                                                                                         ` Lars Ingebrigtsen
2016-02-26  8:48                                                                                           ` Eli Zaretskii
2016-02-28  4:02                                                                                             ` Lars Ingebrigtsen
2016-02-26  9:28                                                                                           ` Eli Zaretskii
2016-02-28  4:04                                                                                             ` Lars Ingebrigtsen
2017-01-25 20:09                                                                                               ` Lars Ingebrigtsen
2017-01-25 20:39                                                                                                 ` Peter Münster
2016-02-24 10:15                                                                     ` martin rudalics
2016-02-24 17:42                                                                       ` Eli Zaretskii
2016-02-24 18:16                                                                         ` martin rudalics
2016-02-24 18:49                                                                           ` martin rudalics
2016-02-24 20:27                                                                             ` Eli Zaretskii
2016-02-25  8:07                                                                               ` Peter Münster
2016-02-25 10:06                                                                                 ` martin rudalics

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).