From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24392 invoked from network); 27 May 2020 22:04:20 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with ESMTPUTF8; 27 May 2020 22:04:20 -0000 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.92.3) (envelope-from ) id 1je49L-0002zS-Dl; Wed, 27 May 2020 17:03:47 -0500 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1je49I-0002wi-3s for ding@lists.math.uh.edu; Wed, 27 May 2020 17:03:44 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1je49F-0000JF-Sn for ding@lists.math.uh.edu; Wed, 27 May 2020 17:03:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=i9ILDKUQqfYEIUURUvtXFpROYpBW8DDL3m+0mFETmGI=; b=PN8WMFdS6M/E9aQYle4rme98ef klRTRwDuw2JVPIi5l/dVkvSHsMNbzA3v6HOxuwShYgtL11iCgnPKX7rU6Msd/h+MbYOS7R0p31D9l sgZIKKmXoSbtRt5r0FfVCuHNLV/0zyWW4G8W7lFJwdsWbB4Mv+dnMxVHvjsa67rM6kZc=; Received: from ericabrahamsen.net ([52.70.2.18] helo=mail.ericabrahamsen.net) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1je497-00046C-IJ for ding@gnus.org; Thu, 28 May 2020 00:03:37 +0200 Received: from localhost (c-73-254-86-141.hsd1.wa.comcast.net [73.254.86.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id E5690FA086; Wed, 27 May 2020 22:03:30 +0000 (UTC) From: Eric Abrahamsen To: Harry Putnam Cc: ding@gnus.org Subject: Re: Remove Ghost groups References: <87imgqy8f4.fsf@local.lan> <87a722a7e7.fsf@ericabrahamsen.net> <878shhe1jn.fsf@local.lan> <87pnatuhzd.fsf@ericabrahamsen.net> <87v9khe3vz.fsf@local.lan> Date: Wed, 27 May 2020 15:03:29 -0700 In-Reply-To: <87v9khe3vz.fsf@local.lan> (Harry Putnam's message of "Wed, 27 May 2020 12:31:12 -0400") Message-ID: <875zch593i.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain List-ID: Precedence: bulk Harry Putnam writes: > Eric Abrahamsen writes: > >> Harry Putnam writes: >> >>> Eric Abrahamsen writes: >>> >>>> Harry Putnam writes: >>>> >>>>> [NOTE: this message is probably a duplicate of a previous post where I >>>>> forget to include the Image I intended to attach] >>>>> >>>>> I have developed a number of what might be called ghost groups. Some >>>>> (most) are as the result of removing groups behind gnus back. Others, >>>>> I'm not sure of their origin. >>>>> >>>>> These groups now appear in gnus -> groups buffer with an asterisk >>>>> before them as in the included image below. >>>>> >>>>> They do not respond to simple C-k nor do they respond to C-u G del >>>> >>>> Can you tell us the backend of the groups, and also what happens when >>>> you hit C-k? Is there a message of any kind? >>> >>> When I hit C-k the pointer goes into `working' mode and never >>> returns. When I force it with C-g all but one nntp group disappears >>> and I have to press `l' to get the full setup back >>> >>> checking the Messages-buffer it only shows >>> >>> *beep* >>> Quit >> >> Can you `toggle-debug-on-quit', do it again, and post the backtrace? > > Sorry for making you work too hard to help. I should have included > backtraces from the start ... And I should have asked -- also your Emacs version, as that's relevant. > Included below: > Backtrace from quiting with C-k on nnml and nnimap. Also backtrace > from quitting on C-u G on nnimap > > ------- ------- ---=--- ------- ------- > > Backtrace from nnml group with C-k . . . followed by C-g > > Debugger entered--Lisp error: (quit) > gnus-group-goto-group("nnml: AdamSj\303\270gren") This makes me think you're using an Emacs/Gnus from before my hash-table changes (six months or so ago?), as the group strings should always be fully decoded strings (ie there shouldn't be the escapes in the group name). IIRC, `gnus-group-goto-group' can sometimes enter an infloop if it can't find the group (which is a bug). > gnus-topic-change-level("nnml: AdamSj\303\270gren" 9 3 nil) > gnus-group-change-level((nil ("nnml: AdamSj\303\270gren" 3 nil nil "nnml:")) 9 nil) > gnus-group-kill-group(nil nil) > gnus-topic-kill-group(nil) > funcall-interactively(gnus-topic-kill-group nil) > call-interactively(gnus-topic-kill-group nil nil) > command-execute(gnus-topic-kill-group) > > ------- --------- ---=--- --------- -------- > > Backtrace from nnimap group with C-k . . . followed by C-g > > Debugger entered--Lisp error: (quit) > gnus-group-goto-group("nnimap+hput3:INBOX.Gas-South") That doesn't really explain why this would infloop, though, as the group name is not multibyte. > gnus-topic-change-level("nnimap+hput3:INBOX.Gas-South" 9 3 nil) > gnus-group-change-level((nil ("nnimap+hput3:INBOX.Gas-South" 3 ((1 . > 2)) ((unexist)) "nnimap:hput3" ((modseq . "37742") (uidvalidity . > "1495544836") (active 1 . 2) (permanent-flags %Answered %Flagged > %Draft %Deleted %Seen $X-ME-Annot-2 $IsMailingList $IsNotification > $HasAttachment $HasTD %*)))) 9 nil) > gnus-group-kill-group(nil nil) > gnus-topic-kill-group(nil) > funcall-interactively(gnus-topic-kill-group nil) > call-interactively(gnus-topic-kill-group nil nil) > command-execute(gnus-topic-kill-group) > > ------- --------- ---=--- --------- -------- > > Backtrace from C-u G on nnimap group followed by C-g > > Debugger entered: ("Quit") > nnimap-wait-for-response(93) This appears to be a completely different problem? At least, I can't immediately think of why it would be related to the two errors above. Let's put this one aside until we figure out the previous issue.