bug#35130: 27.0.50; gnus cannot save

bug#35130: 27.0.50; gnus cannot save

[James Cloos]

As of master commit 39c0795ef2d592d4632516ee57f1cf51a2159608 gnus is
unable to save.

The error (w/ debug-on-error t) is:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  gnus-gnus-to-newsrc-format()
  gnus-save-newsrc-file(nil)
  gnus-group-save-newsrc(nil)
  funcall-interactively(gnus-group-save-newsrc nil)
  call-interactively(gnus-group-save-newsrc nil nil)
  command-execute(gnus-group-save-newsrc)

I also got that error a few times while trying to sort the *Group*
buffer, but then that started working.

Saving has not started working.

At a quick look of the recent history, commits
a09306d53ba86b4596219b2be723659f7c0f2669 and
a8efdd4c62fbf9c275a57f71cc8a3ca845ad3b1f look relevant.


In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2019-04-03 built on carbon.jhcloos.org
Repository revision: 39c0795ef2d592d4632516ee57f1cf51a2159608
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11699901
System Description: Gentoo/Linux

Recent messages:
Proceeding, will debug on next eval or call.
Entering debugger...
Proceeding, will debug on next eval or call.
Entering debugger...
Continuing.
Entering debugger...
Continuing.
Entering debugger...
Continuing.
Auto-saving...

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --disable-silent-rules
 --docdir=/usr/share/doc/emacs-vcs-27.0.9999
 --htmldir=/usr/share/doc/emacs-vcs-27.0.9999/html --libdir=/usr/lib64
 --program-suffix=-emacs-27-vcs --includedir=/usr/include/emacs-27-vcs
 --infodir=/usr/share/info/emacs-27-vcs --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-file-notification=inotify --enable-acl --with-dbus
 --without-modules --with-gameuser=:gamestat --with-gpm --with-json
 --with-kerberos --with-kerberos5 --with-lcms2 --with-xml2
 --without-mailutils --without-selinux --with-gnutls
 --without-libsystemd --with-threads --without-wide-int --with-zlib
 --with-sound=alsa --with-x --without-ns --without-gconf --with-libgmp
 --without-gsettings --with-toolkit-scroll-bars --with-gif --with-jpeg
 --with-png --with-rsvg --with-tiff --with-xpm --with-imagemagick
 --with-xft --without-cairo --with-libotf --with-m17n-flt
 --with-x-toolkit=lucid --with-xaw3d 'CFLAGS=-pipe -O2 -g3
 -march=native' CPPFLAGS= LDFLAGS=-Wl,-O1'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LC_COLLATE: C
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_TIME: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  gnus-undo-mode: t
  show-paren-mode: t
  display-time-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-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

Load-path shadows:
/usr/share/emacs/site-lisp/graphviz-dot-mode/graphviz-dot-mode hides /home/cloos/elisp/graphviz-dot-mode
/usr/share/emacs/site-lisp/git/git hides /home/cloos/elisp/git
/usr/share/emacs/site-lisp/git/git-blame hides /home/cloos/elisp/git-blame
/usr/share/emacs/site-lisp/fricas/fricas hides /home/cloos/elisp/fricas
/usr/share/emacs/site-lisp/auctex/context hides /home/cloos/elisp/context
/home/cloos/elisp/json hides /usr/share/emacs/27.0.50/lisp/json
/home/cloos/elisp/doc-view hides /usr/share/emacs/27.0.50/lisp/doc-view

Features:
(shadow emacsbug two-column iso-transl macros kmacro misearch
multi-isearch cl-print cus-edit help-fns radix-tree flow-fill sendmail
gnus-fun nnir qp cl-extra sort url-util shr-color color shr svg xml dom
gnus-cite mm-archive mail-extr face-remap gnus-async quilt gnus-kill
gnus-ml disp-table nndraft nnmh utf-7 nnml gnutls nnmaildir vc-filewise
vc-rcs network-stream nsm gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig
mailcap nntp gnus-cache gnus-sum gnus-group gnus-undo gnus-start
gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int
gnus-range message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa
derived epg mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader gnus-win gnus nnheader gnus-util rmail
rmail-loaddefs rfc2047 rfc2045 ietf-drums text-property-search time-date
mail-utils wid-edit elec-pair jka-compr mm-util mail-prsvr paren time
delsel cus-start cus-load jhc-backend-xft-fonts w3m-load preview-latex
mmm-auto mmm-vars mmm-compat ido ess-toolbar ess-mouse mouseme thingatpt
browse-url ess-swv ess-noweb ess-noweb-font-lock-mode ess-bugs-l
ess-sas-d ess-sas-l ess-sas-a ess-stata-mode ess-stata-lang cc-vars
cc-defs make-regexp essd-els ess-sp6-d ess-dde ess-sp3-d ess-julia
julia-mode ert pp ewoc debug backtrace help-mode find-func ess-r-mode
ess-r-package ess-r-syntax ess-r-completion ess-roxy essddr ess-rd
noutline outline easy-mmode hideshow ess-s-lang ess-help ess ess-mode
ess-noweb-mode ess-inf ess-tracebug compile tramp tramp-loaddefs
trampver tramp-integration files-x tramp-compat ucs-normalize shell
pcomplete comint ansi-color ring parse-time format-spec advice
ess-generics cl ess-custom executable ess-compat ess-utils ess-site
bbdb-loaddefs auto-loads tex-site finder-inf package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded 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 threads dbusbind inotify lcms2 dynamic-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 4468393 10534538)
 (symbols 48 31753 855)
 (strings 32 573556 221935)
 (string-bytes 1 20861193)
 (vectors 16 60725)
 (vector-slots 8 1473206 158906)
 (floats 8 431 504)
 (intervals 56 5852 779)
 (buffers 992 52))

bug#35130: 27.0.50; gnus cannot save

[Basil L. Contovounesios]

James Cloos <cloos@jhcloos.com> writes:

> As of master commit 39c0795ef2d592d4632516ee57f1cf51a2159608 gnus is
> unable to save.
>
> The error (w/ debug-on-error t) is:
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   gnus-gnus-to-newsrc-format()
>   gnus-save-newsrc-file(nil)
>   gnus-group-save-newsrc(nil)
>   funcall-interactively(gnus-group-save-newsrc nil)
>   call-interactively(gnus-group-save-newsrc nil nil)
>   command-execute(gnus-group-save-newsrc)
>
> I also got that error a few times while trying to sort the *Group*
> buffer, but then that started working.
>
> Saving has not started working.
>
> At a quick look of the recent history, commits
> a09306d53ba86b4596219b2be723659f7c0f2669 and
> a8efdd4c62fbf9c275a57f71cc8a3ca845ad3b1f look relevant.

Could this be related to bug#34983?
Does the error still occur after a 'make bootstrap'?

https://debbugs.gnu.org/34983

Thanks,

-- 
Basil

bug#35130: 27.0.50; gnus cannot save

[Eric Abrahamsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> James Cloos <cloos@jhcloos.com> writes:
>
>> As of master commit 39c0795ef2d592d4632516ee57f1cf51a2159608 gnus is
>> unable to save.
>>
>> The error (w/ debug-on-error t) is:
>>
>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>>   gnus-gnus-to-newsrc-format()
>>   gnus-save-newsrc-file(nil)
>>   gnus-group-save-newsrc(nil)
>>   funcall-interactively(gnus-group-save-newsrc nil)
>>   call-interactively(gnus-group-save-newsrc nil nil)
>>   command-execute(gnus-group-save-newsrc)
>>
>> I also got that error a few times while trying to sort the *Group*
>> buffer, but then that started working.
>>
>> Saving has not started working.
>>
>> At a quick look of the recent history, commits
>> a09306d53ba86b4596219b2be723659f7c0f2669 and
>> a8efdd4c62fbf9c275a57f71cc8a3ca845ad3b1f look relevant.
>
> Could this be related to bug#34983?
> Does the error still occur after a 'make bootstrap'?
>
> https://debbugs.gnu.org/34983

This sounds more similar to something that Bastien Guerry reported -- I
think it's all part of the same basic error, but probably won't be
solved by a "make bootstrap" (though it can't hurt to try)...

Eric

bug#35130: 27.0.50; gnus cannot save

[James Cloos]

>>>>> "BC" == Basil L Contovounesios <contovob@tcd.ie> writes:

BC> Could this be related to bug#34983?
BC> https://debbugs.gnu.org/34983

It is likely related.  Not exactly the same, but similar.

BC> Does the error still occur after a 'make bootstrap'?

All of my builds are done from fresh clones, so bootstrap occurs every
time.


I was unable to find a working commit near tip, so fell back to my lask
known working commit (5f640bfdf84753322763be23ebaa8ded92dc1c5d) to get
a working gnus.

Given how long gnus requires to start, I won't be able to attempt a
bisect until the weekend.  And even then it might take multiple weekends.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

bug#35130: 27.0.50; gnus cannot save

[Eric Abrahamsen]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "BC" == Basil L Contovounesios <contovob@tcd.ie> writes:
>
> BC> Could this be related to bug#34983?
> BC> https://debbugs.gnu.org/34983
>
> It is likely related.  Not exactly the same, but similar.
>
> BC> Does the error still occur after a 'make bootstrap'?
>
> All of my builds are done from fresh clones, so bootstrap occurs every
> time.
>
>
> I was unable to find a working commit near tip, so fell back to my lask
> known working commit (5f640bfdf84753322763be23ebaa8ded92dc1c5d) to get
> a working gnus.
>
> Given how long gnus requires to start, I won't be able to attempt a
> bisect until the weekend.  And even then it might take multiple weekends.

When you have time, would you pull from master and try again? I think
this ought to be fixed now.

Thanks,
Eric

bug#35130: 27.0.50; gnus cannot save

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> When you have time, would you pull from master and try again? I think
EA> this ought to be fixed now.

I'll give it a try this weekend.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

bug#35130: 27.0.50; gnus cannot save

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
EA> When you have time, would you pull from master and try again? I think
EA> this ought to be fixed now.

As of commit f9694a713824d402bcba01064ac2f95156bf4161 gnus remains unusable.

It was OK at first, but after adding the latest new imap group and
trying to sort everything broke.

It is completely unable to sort.  Not by name, level, method, etc.  The
results look like they follow a hash order rather than the required
alphabetic order.

And after "sorting" it cannot save.

Gnus suffers greatly from inefficiency.  If your ideas can make it
faster I am all for them.  But it seems the changes need to be backed
out and done in a branch before they are ready for consumption.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

bug#35130: 27.0.50; gnus cannot save

[Eric Abrahamsen]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> EA> When you have time, would you pull from master and try again? I think
> EA> this ought to be fixed now.
>
> As of commit f9694a713824d402bcba01064ac2f95156bf4161 gnus remains unusable.
>
> It was OK at first, but after adding the latest new imap group and
> trying to sort everything broke.
>
> It is completely unable to sort.  Not by name, level, method, etc.  The
> results look like they follow a hash order rather than the required
> alphabetic order.
>
> And after "sorting" it cannot save.

Would you try this again? I've installed some relevant fixes, including
to sorting, and it's behaving stably for me now.

> Gnus suffers greatly from inefficiency. If your ideas can make it
> faster I am all for them.  But it seems the changes need to be backed
> out and done in a branch before they are ready for consumption.

I think it may be a bit too late for that. It needed more testing,
that's for sure, and I apologize for making Gnus unresponsive. But what
appears to be fairly catastrophic failure at this point is actually
caused by fairly small bugs. The changes were done in a branch; my
mistake was in not getting more volunteer road-testers. I won't make
that mistake again.

Eric

bug#35130: 27.0.50; gnus cannot save

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> Would you try this again? I've installed some relevant fixes,
EA> including to sorting, and it's behaving stably for me now.

I'll (try to :) try it out next weekend.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

bug#35130: 27.0.50; gnus cannot save

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> Would you try this again? I've installed some relevant fixes, including
EA> to sorting, and it's behaving stably for me now.

I'm running it now.

The only remaining issue I've spotted is when grabbing new groups from
the imap server.

Given:

  (setq gnus-level-default-subscribed 1)
  
and this:

(fset 'gnus-group-get-new-groups
   "1LFs1g1Ls")

(I never got around to replacing the saved keyboard macro with proper lisp.)

Then after running (gnus-group-get-new-groups) in the Groups buffer the
new groups should all be level 1 and sorted alphabetically.

That no longer works.  They still are level 1, but now are sorted randomly.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

bug#35130: 27.0.50; gnus cannot save

[Eric Abrahamsen]

On 04/30/19 14:32 PM, James Cloos wrote:
>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> EA> Would you try this again? I've installed some relevant fixes, including
> EA> to sorting, and it's behaving stably for me now.
>
> I'm running it now.
>
> The only remaining issue I've spotted is when grabbing new groups from
> the imap server.
>
> Given:
>
>   (setq gnus-level-default-subscribed 1)
>   
> and this:
>
> (fset 'gnus-group-get-new-groups
>    "1LFs1g1Ls")
>
> (I never got around to replacing the saved keyboard macro with proper lisp.)

Hang on, what is that supposed to do? That symbol has neither a function
nor a variable definition for me here, on master.

bug#35130: 27.0.50; gnus cannot save

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> (fset 'gnus-group-get-new-groups
>> "1LFs1g1Ls")
>> 
>> (I never got around to replacing the saved keyboard macro with proper lisp.)

EA> Hang on, what is that supposed to do? That symbol has neither a function
EA> nor a variable definition for me here, on master.

Sorry.  I though that was enough to show that it is a named keyboard macro.

Just type those characters at the *Group* buffer.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

bug#35130: 27.0.50; gnus cannot save

[Eric Abrahamsen]

On 04/30/19 18:54 PM, James Cloos wrote:
>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>> (fset 'gnus-group-get-new-groups
>>> "1LFs1g1Ls")
>>> 
>>> (I never got around to replacing the saved keyboard macro with proper lisp.)
>
> EA> Hang on, what is that supposed to do? That symbol has neither a function
> EA> nor a variable definition for me here, on master.
>
> Sorry.  I though that was enough to show that it is a named keyboard macro.
>
> Just type those characters at the *Group* buffer.

Well, I typed that sequence, and nothing special happened. I saw several
groups I hadn't looked at in a decade or so, caught them up, and nothing
happened after that. I'm not sure what I was supposed to see...

bug#35130: 27.0.50; gnus cannot save

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> Well, I typed that sequence, and nothing special happened. I saw several
EA> groups I hadn't looked at in a decade or so, caught them up, and nothing
EA> happened after that. I'm not sure what I was supposed to see...

Perhaps it is specific to nnimap?

In any case, it is a regression.  And a bug.

The new groups were always sorted alphabetically by name when they were added.
You changes should not break that.

Out of order makes it vastly more difficult to set them all to their new
levels.

(Each mailing list is its own group; things like general bug and commit
lists are separated per component. That makes it easy to read and ignore
what is interesting or not.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

bug#35130: 27.0.50; gnus cannot save

[Eric Abrahamsen]

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


On 05/01/19 10:58 AM, James Cloos wrote:
>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> EA> Well, I typed that sequence, and nothing special happened. I saw several
> EA> groups I hadn't looked at in a decade or so, caught them up, and nothing
> EA> happened after that. I'm not sure what I was supposed to see...
>
> Perhaps it is specific to nnimap?
>
> In any case, it is a regression.  And a bug.
>
> The new groups were always sorted alphabetically by name when they were added.
> You changes should not break that.
>
> Out of order makes it vastly more difficult to set them all to their new
> levels.

Yes, I wasn't saying this wasn't a bug, I was trying to figure out
exactly what was going on. Would you try the attached patch and see if
it fixes the problem?

Eric



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gnus-subscribe-alpha.diff --]
[-- Type: text/x-patch, Size: 684 bytes --]

diff --git a/lisp/gnus/gnus-start.el b/lisp/gnus/gnus-start.el
index 2f8a260bf1..17ee4357e8 100644
--- a/lisp/gnus/gnus-start.el
+++ b/lisp/gnus/gnus-start.el
@@ -583,11 +583,11 @@ gnus-subscribe-randomly
 
 (defun gnus-subscribe-alphabetically (newgroup)
   "Subscribe new NEWGROUP and insert it in alphabetical order."
-  (let ((groups (cdr gnus-newsrc-alist))
+  (let ((groups (cdr gnus-group-list))
 	before)
     (while (and (not before) groups)
-      (if (string< newgroup (caar groups))
-	  (setq before (caar groups))
+      (if (string< newgroup (car groups))
+	  (setq before (car groups))
 	(setq groups (cdr groups))))
     (gnus-subscribe-newsgroup newgroup before)))
 

bug#35130: 27.0.50; gnus cannot save

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Yes, I wasn't saying this wasn't a bug, I was trying to figure out
> exactly what was going on. Would you try the attached patch and see if
> it fixes the problem?

James, did you try the patch and did it fix the sorting-new-imap-groups
problem?

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

bug#35130: 27.0.50; gnus cannot save

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Yes, I wasn't saying this wasn't a bug, I was trying to figure out
>> exactly what was going on. Would you try the attached patch and see if
>> it fixes the problem?
>
> James, did you try the patch and did it fix the sorting-new-imap-groups
> problem?

More information was requested, but no response was given within a few
months, so I'm closing this bug report.  If the problem still exists,
please reopen this bug report.

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

bug#35130: 27.0.50; gnus cannot save

[James Cloos]

I found another bug from this change.

(gnus-group-list-level) (A l or A L in the *Group* buffer) has become
horribly slow and cpu intensive.

It used to be simple and nearly instantaneous.

All of the group-list functions MUST be fast.  None of them should
require any significant work.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

bug#35130: 27.0.50; gnus cannot save

[Eric Abrahamsen]

On 04/30/19 17:23 PM, James Cloos wrote:
> I found another bug from this change.
>
> (gnus-group-list-level) (A l or A L in the *Group* buffer) has become
> horribly slow and cpu intensive.
>
> It used to be simple and nearly instantaneous.
>
> All of the group-list functions MUST be fast.  None of them should
> require any significant work.

I'm not able to reproduce this, the list-level command is pretty much
instantaneous for me. Are you doing this with topic mode on or off? If
it's off, could you edebug `gnus-group-prepare-flat' and see if anything
is obviously taking a bunch of time?

I can't guess what would be slowing the process down that much.

bug#35130: 27.0.50; gnus cannot save

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> Are you doing this with topic mode on or off?

Off


EA> ... could you edebug `gnus-group-prepare-flat' and see if anything
EA> is obviously taking a bunch of time?

I've not used edebug.  And nothing I tried at M-x did anything.

How does one edebug gnus-group-prepare-flat?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

bug#35130: 27.0.50; gnus cannot save

[Eric Abrahamsen]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> EA> Are you doing this with topic mode on or off?
>
> Off
>
>
> EA> ... could you edebug `gnus-group-prepare-flat' and see if anything
> EA> is obviously taking a bunch of time?
>
> I've not used edebug.  And nothing I tried at M-x did anything.
>
> How does one edebug gnus-group-prepare-flat?

You find the location of `gnus-group-prepare-flat' by running "C-h f",
entering that function name, and hitting "RET". The resulting *Help*
buffer will have a hyperlink to the "gnus-group.el" file -- follow that
hyperlink. Once you've got the source file open and point is somewhere
within the definition of `gnus-group-prepare-flat', hit "C-u C-M-x" to
edebug the function. Now when you go back to Gnus's *Group* buffer and
try re-sorting, Emacs should jump you into `gnus-group-prepare-flat',
and you can "step" through that function using the space bar. You'll see
variable values displayed in the message area, and you can also hit "e"
and type in expressions to see their value.

Hopefully you will see something suspicious that will lead to our
solution.

Eric

bug#35130: 27.0.50; gnus cannot save

[Basil L. Contovounesios]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> You find the location of `gnus-group-prepare-flat' by running "C-h f",
> entering that function name, and hitting "RET". The resulting *Help*
> buffer will have a hyperlink to the "gnus-group.el" file -- follow that
> hyperlink.

FWIW, this can also be achieved via M-x find-function RET
gnus-group-prepare-flat RET in general, though in this case Gnus must
first be loaded before this will work.

-- 
Basil