bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Pankaj Jangid]

I am on an IMAP group in the group buffer, and my debug is on. The
following steps produces error:

1. Started search with ‘G G’ with search term "keyword from:manager".

2. In the transient buffer press ‘q’ to exit i.e. (gnus-summary-exit)

3. It produces following error and I am stuck in the buffer. I had to
   kill the buffer to come out. This is a recent thing. It was working
   fine a couple of days back, when I last tried search.

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (cl-no-applicable-method map-into nil list)
  signal(cl-no-applicable-method (map-into nil list))
  cl-no-applicable-method(#s(cl--generic :name map-into :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-eql-generalizer :priority 100 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1cba953f414e437c>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0xc2b528c28560f5a>)) #s(cl--generic-generalizer :name cl--generic-head-generalizer :priority 80 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x3a14bb8a384edb5>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0xc2b528d3218c09a>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1cba9713a96764e4>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x2b7bed08469105e>))) (0 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1cba9713a96764e4>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x2b7bed08469105e>)))) :method-table (#s(cl--generic-method :specializers (t (head hash-table)) :qualifiers nil :uses-cnm nil :function #f(compiled-function (map type) "Convert MAP into a hash-table.\nTYPE is a list whose car is `hash-table' and cdr a list of\nkeyword-args forwarded to `make-hash-table'.\n\nExample:\n    (map-into '((1 . 3)) '(hash-table :test eql))" #<bytecode -0x8a04544b3b280eb>)) #s(cl--generic-method :specializers (t (eql 'hash-table)) :qualifiers nil :uses-cnm nil :function #f(compiled-function (map type) "Convert MAP into a hash-table with keys compared with `equal'." #<bytecode 0x766b33f91b1b4f2>)) #s(cl--generic-method :specializers (t (eql 'plist)) :qualifiers nil :uses-cnm nil :function #f(compiled-function (map type) "Convert MAP into a plist." #<bytecode -0x1c77c5758ca6b1e4>)) #s(cl--generic-method :specializers (t (eql 'alist)) :qualifiers nil :uses-cnm nil :function #f(compiled-function (map type) "Convert MAP into an alist." #<bytecode -0x9f7e2b35156d6bc>)) #s(cl--generic-method :specializers (t (eql 'list)) :qualifiers nil :uses-cnm nil :function #f(compiled-function (map type) "Convert MAP into an alist." #<bytecode -0x9f7e2b35156d6bc>))) :options nil) nil list)
  apply(cl-no-applicable-method #s(cl--generic :name map-into :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-eql-generalizer :priority 100 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1cba953f414e437c>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0xc2b528c28560f5a>)) #s(cl--generic-generalizer :name cl--generic-head-generalizer :priority 80 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x3a14bb8a384edb5>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0xc2b528d3218c09a>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1cba9713a96764e4>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x2b7bed08469105e>))) (0 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1cba9713a96764e4>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x2b7bed08469105e>)))) :method-table (#s(cl--generic-method :specializers (t (head hash-table)) :qualifiers nil :uses-cnm nil :function #f(compiled-function (map type) "Convert MAP into a hash-table.\nTYPE is a list whose car is `hash-table' and cdr a list of\nkeyword-args forwarded to `make-hash-table'.\n\nExample:\n    (map-into '((1 . 3)) '(hash-table :test eql))" #<bytecode -0x8a04544b3b280eb>)) #s(cl--generic-method :specializers (t (eql 'hash-table)) :qualifiers nil :uses-cnm nil :function #f(compiled-function (map type) "Convert MAP into a hash-table with keys compared with `equal'." #<bytecode 0x766b33f91b1b4f2>)) #s(cl--generic-method :specializers (t (eql 'plist)) :qualifiers nil :uses-cnm nil :function #f(compiled-function (map type) "Convert MAP into a plist." #<bytecode -0x1c77c5758ca6b1e4>)) #s(cl--generic-method :specializers (t (eql 'alist)) :qualifiers nil :uses-cnm nil :function #f(compiled-function (map type) "Convert MAP into an alist." #<bytecode -0x9f7e2b35156d6bc>)) #s(cl--generic-method :specializers (t (eql 'list)) :qualifiers nil :uses-cnm nil :function #f(compiled-function (map type) "Convert MAP into an alist." #<bytecode -0x9f7e2b35156d6bc>))) :options nil) (nil list))
  #f(compiled-function (&rest args) #<bytecode -0x4b82e932922e70a>)(nil list)
  apply(#f(compiled-function (&rest args) #<bytecode -0x4b82e932922e70a>) nil list nil)
  map-into(nil list)
  map-merge(list nil nil)
  nnselect-push-info("nnselect:nnselect-m2r1f97m8c.fsf")
  nnselect-close-group("nnselect-m2r1f97m8c.fsf" "nnselect-ephemeral")
  gnus-close-group("nnselect:nnselect-m2r1f97m8c.fsf")
  gnus-summary-exit()
  funcall-interactively(gnus-summary-exit)
  call-interactively(gnus-summary-exit nil nil)
  command-execute(gnus-summary-exit)
--8<---------------cut here---------------end--------------->8---



In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.6.0, NS appkit-2022.60 Version 11.5 (Build 20G71))
 of 2021-08-04 built on mb2.local
Repository revision: b0d07396e8d970407a17388cdc207b9f3608f90e
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.5

Configured features:
ACL DBUS GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
KQUEUE NS PDUMPER PNG RSVG THREADS TIFF TOOLKIT_SCROLL_BARS XIM ZLIB

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

Major mode: Group

Minor modes in effect:
  cursor-sensor-mode: t
  global-company-mode: t
  company-mode: t
  shell-dirtrack-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  gnus-undo-mode: t
  savehist-mode: t
  desktop-save-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-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
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
/Users/pankaj/.emacs.d/elpa/transient-20210723.1601/transient hides /Users/pankaj/Applications/Emacs.app/Contents/Resources/lisp/transient

Features:
(shadow shortdoc emacsbug mailalias smtpmail qp flyspell ispell
gnus-html url-cache flow-fill mm-archive help-fns radix-tree cl-print
misearch multi-isearch sort smiley gnus-cite mail-extr gnus-async
gnus-bcklg gnus-ml hl-line disp-table cursor-sensor nndraft nnmh utf-7
nnml nnfolder epa-file gnutls network-stream nsm gnus-agent gnus-srvr
gnus-score score-mode nnvirtual nntp gnus-cache .gnus find-dired grep
diary-lib diary-loaddefs dired-aux markdown-mode color hideshow vc-mtn
vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc eglot array jsonrpc
ert pp ewoc debug backtrace imenu haskell-mode haskell-cabal
haskell-utils haskell-font-lock haskell-indentation haskell-string
haskell-sort-imports haskell-lexeme rx haskell-align-imports
haskell-complete-module haskell-ghc-support dabbrev haskell-customize
sh-script smie executable checkdoc lisp-mnt flymake-proc flymake compile
warnings elec-pair autorevert filenotify vc-git diff-mode vc-dispatcher
ol-eww eww xdg url-queue thingatpt mm-url ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect gnus-search ol-docview doc-view jka-compr image-mode
exif ol-bibtex bibtex ol-bbdb ol-w3m company-oddmuse company-keywords
company-etags etags fileloop xref project company-gtags
company-dabbrev-code company-dabbrev company-files company-clang
company-capf company-cmake company-semantic company-template
company-bbdb company init my-init enet org-element avl-tree generator
org org-macro org-footnote org-pcomplete org-list org-faces org-entities
noutline outline easy-mmode org-version ob-plantuml ob-sql ob-css ob-js
ob-java ob-C cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs ob-python python tramp-sh tramp
tramp-loaddefs trampver tramp-integration files-x tramp-compat shell
pcomplete ls-lisp ob-R ob ob-tangle org-src ob-ref ob-lob ob-table
ob-exp ob-comint comint ansi-color ring ob-emacs-lisp ob-core ob-eval
org-table ol org-keys org-compat advice org-macs org-loaddefs
format-spec server edmacro kmacro modus-operandi-theme modus-themes
exec-path-from-shell yasnippet-snippets yasnippet delight ebdb-message
sendmail ebdb-gnus gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime dig gnus-sum shr kinsoku svg dom gnus-group gnus-undo gnus-start
gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo
parse-time iso8601 gnus-spec gnus-int gnus-range message rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config mm-decode
mm-bodies mm-encode mail-parse rfc2231 gmm-utils mailheader gnus-win
gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums
text-property-search time-date mail-utils mm-util mail-prsvr wid-edit
ebdb-mua ebdb-com crm ebdb-format ebdb mailabbrev eieio-opt cl-extra
help-mode speedbar ezimage dframe find-func eieio-base pcase cal-menu
calendar cal-loaddefs timezone savehist desktop frameset avoid paren
cus-load finder-inf tex-site info package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util mailcap 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
early-init iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer 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 cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 863493 82979)
 (symbols 48 45134 33)
 (strings 32 197031 16063)
 (string-bytes 1 6218849)
 (vectors 16 87203)
 (vector-slots 8 2000154 87024)
 (floats 8 536 516)
 (intervals 56 5966 1996)
 (buffers 992 80))

-- 
Regards ~Pankaj

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Lars Ingebrigtsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> I am on an IMAP group in the group buffer, and my debug is on. The
> following steps produces error:
>
> 1. Started search with ‘G G’ with search term "keyword from:manager".
>
> 2. In the transient buffer press ‘q’ to exit i.e. (gnus-summary-exit)
>
> 3. It produces following error and I am stuck in the buffer. I had to
>    kill the buffer to come out. This is a recent thing. It was working
>    fine a couple of days back, when I last tried search.
>
> Debugger entered--Lisp error: (cl-no-applicable-method map-into nil list)

I'm unable to reproduce this on the current trunk -- exiting from `G G'
groups works fine here.

Your backtrace seems to imply that 

(gnus-info-marks group-info)

is nil -- is there anything special about the group you're searching?

(Are you setting "Mail-Followup-To: bug-gnu-emacs@gnu.org"?  That makes
the CC not contain "49866@debbugs.gnu.org", which is confusing.)

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

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Pankaj Jangid]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm unable to reproduce this on the current trunk -- exiting from `G G'
> groups works fine here.
>
> Your backtrace seems to imply that 
>
> (gnus-info-marks group-info)
>
> is nil -- is there anything special about the group you're searching?

Nothing that I know of. It is a normal nnimap INBOX from Gmail.

I have not configured search engines for nnml and nntp. So I cannot
comment about those groups. But on any nnimap group, I am getting this
error.

What is this ‘gnus-info-marks’ thing? Is there a way I can isolate the
cause by evaluating some elisp code inside the ephemeral group create by
search?

> (Are you setting "Mail-Followup-To: bug-gnu-emacs@gnu.org"?  That makes
> the CC not contain "49866@debbugs.gnu.org", which is confusing.)

Sorry. That was an error in my ‘message-subscribed-regexp’. Fixed it.

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Lars Ingebrigtsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> What is this ‘gnus-info-marks’ thing? Is there a way I can isolate the
> cause by evaluating some elisp code inside the ephemeral group create by
> search?

(gnus-info-marks (gnus-get-info "GROUP NAME"))

should return the marks.  Mine is:

(gnus-info-marks (gnus-get-info "nnimap+quimby.gnus.org:INBOX"))
=> ((unexist (1 . 2116984)) (seen 331060 878343 1715697 1715709 1715739 1717614 (1718488 . 1718489) 1738492 1738502 (1738711 . 1738726) 1747392 1747399 1747420 1747424 1747483 1747517 1747539 1747550 1747568 1756531 1756534 (1756538 . 1756541) 1756544 (1756546 . 1756548) (1756550 . 1756552) 1765290 1766018 1769839 (1771530 . 1771531) 1774893 1777263 1793994 1811741 1811743 (1825935 . 1825936) 1852251 1895653 (1895678 . 1895679) 1927692 1943029 1961089 (1968136 . 1968996) (2061204 . 2061221) (2066102 . 2066105) 2112433))

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

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Pankaj Jangid]

I think I have isolated the cause. And the error is cause by these lines
in my ~/.emacs.d/init.el (only if ebdb package is installed):

--8<---------------cut here---------------start------------->8---
(when (package-installed-p 'ebdb)
  (require 'ebdb-gnus)
  (require 'ebdb-message))
--8<---------------cut here---------------end--------------->8---

If I remove the package ebdb then the error goes away.

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (gnus-info-marks (gnus-get-info "GROUP NAME"))
>
> should return the marks.  Mine is:
>
> (gnus-info-marks (gnus-get-info "nnimap+quimby.gnus.org:INBOX"))
> => ((unexist (1 . 2116984)) (seen 331060 878343 1715697 1715709
> 1715739 1717614 (1718488 . 1718489) 1738492 1738502 (1738711
> . 1738726) 1747392 1747399 1747420 1747424 1747483 1747517 1747539
> 1747550 1747568 1756531 1756534 (1756538 . 1756541) 1756544 (1756546
> . 1756548) (1756550 . 1756552) 1765290 1766018 1769839 (1771530
> . 1771531) 1774893 1777263 1793994 1811741 1811743 (1825935 . 1825936)
> 1852251 1895653 (1895678 . 1895679) 1927692 1943029 1961089 (1968136
> . 1968996) (2061204 . 2061221) (2066102 . 2066105) 2112433))

On my system it returns this:

--8<---------------cut here---------------start------------->8---
(gnus-info-marks (gnus-get-info "nnimap+codeisgreat:INBOX"))
=> ((expire 17838 18175 18339 18352 18398 18554 18641 18646 18817 18956 18971 18977 18983 18985 18990)
 (reply 17527 18258 18270 18297
		(18924 . 18925)
		18931 18933 18935 18989 18991)
 (tick 18137 18935 18986)
 (unexist
  (1 . 17402)
  (17404 . 17526)
  (17528 . 17562)
  (17564 . 17837)
  (17839 . 18135)
  18138
  (18140 . 18174)
  (18176 . 18225)
  (18227 . 18257)
  (18259 . 18269)
  (18271 . 18296)
  (18298 . 18338)
  (18340 . 18351)
  (18353 . 18397)
  (18399 . 18553)
  (18555 . 18640)
  (18642 . 18645)
  (18647 . 18786)
  (18788 . 18816)
  (18818 . 18833)
  (18835 . 18923))
 (seen
  (8039 . 8056)
  (8059 . 8064)
  (8066 . 8282)
  (8290 . 8382)
  (8402 . 8538)
  8543 8552 8555 8557
  (8566 . 8567)
  (8571 . 8572)
  8574 8579
  (8583 . 8593)
  (8595 . 8682)
  8694
  (8703 . 8704)
  8717 8724 8729 8733
  (8758 . 8760)
  8773
  (8775 . 8777)
  (8784 . 8785)
  8787
  (8790 . 8791)
  (8794 . 8795)
  8798 8813 8828
  (8830 . 8831)
  8841 8863 8899 8914 8931 8951 8969 9001
  (9008 . 9010)
  9012 9043 9077
  (9089 . 9090)
  9108 9157
  (9176 . 9177)
  9180 9184 9206 9210 9212 9219 9221 9227 9234 9245 9256 9259 9263 9270 9303 9315 9319 9321 9349 9353 9373 9376 9379 9397 9402
  (9411 . 9412)
  9419 9423
  (9425 . 9426)
  9430
  (9436 . 9437)
  9454
  (9461 . 9469)
  (9478 . 9479)
  9509 9526 9533 9536 9543 9601 9609 9635 9639 9686 9703 9708 9749 9754 9785 9788 9871 9898
  (9900 . 9911)
  (9913 . 10250)
  (10252 . 10256)
  (10258 . 10279)
  (10281 . 10283)
  (10285 . 10298)
  (10304 . 10426)
  (10437 . 10440)
  (10444 . 10458)
  (10462 . 10463)
  (10466 . 10692)
  (10694 . 10860)
  (10870 . 10930)
  (10933 . 10958)
  10960
  (10963 . 10984)
  (10986 . 11110)
  (11112 . 11116)
  (11125 . 11129)
  (11131 . 11137)
  (11140 . 11270)
  (11281 . 11292)
  (11300 . 11303)
  (11308 . 11325)
  (11328 . 11427)
  (11430 . 11448)
  (11465 . 11692)
  (11694 . 11821)
  11830 11866 11886
  (12079 . 12080)
  12094 12155 12326
  (12402 . 12403)
  12420
  (12472 . 12473)
  12475 12478
  (12481 . 12482)
  (12485 . 12486)
  12488 12490
  (12492 . 12497)
  (12499 . 12503)
  12505 12508
  (12510 . 12511)
  12517
  (12526 . 12527)
  12531 12534 12536 12572 12581
  (12587 . 12589)
  12595 12600
  (12609 . 12610)
  12796
  (12870 . 12871)
  12899
  (12946 . 12948)
  13041 13238 13246 13353 13504 13564 13770
  (13856 . 13876)
  (13897 . 13902)
  14081 14107 14117 14135 14148 14235
  (14426 . 14429)
  14454 14558
  (14567 . 14572)
  14605
  (14730 . 14731)
  (14759 . 14761)
  14777 14805 14816
  (14862 . 14863)
  (14948 . 14949)
  14952 15041 15106 15207 15222 15249 15272 15275 15360
  (15371 . 15372)
  15376
  (15381 . 15382)
  15401 15419 15446 15475 15511
  (15518 . 15519)
  15523 15528
  (15542 . 15543)
  15564 15589 15645 15665 15822 15962
  (15964 . 15965)
  16098
  (16161 . 16162)
  16169 16301 16307 16324 16374 16376
  (16378 . 16379)
  16392
  (16405 . 16408)
  16412
  (16415 . 16416)
  16418 16420 16425
  (16433 . 16435)
  (16437 . 16438)
  16446
  (16449 . 16455)
  (16457 . 16462)
  (16464 . 16466)
  16468 16472 16478
  (16484 . 16487)
  (16489 . 16491)
  16493
  (16496 . 16497)
  16549
  (16556 . 16559)
  16562
  (16566 . 16572)
  (16574 . 16577)
  (16580 . 16582)
  (16584 . 16587)
  (16591 . 16592)
  16596 16604
  (16619 . 16621)
  (16623 . 16624)
  16630
  (16633 . 16636)
  (16640 . 16642)
  (16644 . 16648)
  16651 16676 16679
  (16683 . 16684)
  (16689 . 16690)
  (16702 . 16704)
  16713 16719 16722 16735 16738
  (16744 . 16746)
  (16748 . 16749)
  (16752 . 16753)
  (16756 . 16758)
  (16760 . 16762)
  16764
  (16766 . 16769)
  16771
  (16773 . 16780)
  (16782 . 16792)
  (16794 . 16798)
  (16801 . 16803)
  16810
  (16818 . 16819)
  16821 16835
  (16837 . 16838)
  16843 16846
  (16848 . 16850)
  (16854 . 16855)
  (16857 . 16860)
  (16862 . 16871)
  (16873 . 16876)
  (16878 . 16932)
  (16934 . 16938)
  (16941 . 16944)
  (16946 . 16958)
  (16960 . 16977)
  (16979 . 17042)
  (17044 . 17045)
  (17047 . 17050)
  (17053 . 17082)
  (17084 . 17089)
  (17093 . 17098)
  (17100 . 17108)
  (17110 . 17117)
  (17121 . 17136)
  (17138 . 17147)
  (17151 . 17197)
  (17199 . 17223)
  (17229 . 17234)
  (17236 . 17238)
  (17242 . 17261)
  (17263 . 17299)
  17403 17469 17527 17563 17572 17694 17775 17784 17792 17795 17797 17799 17813
  (17815 . 17817)
  17838
  (17869 . 17872)
  17884 17937
  (17944 . 17945)
  (18023 . 18024)
  18081 18107
  (18136 . 18137)
  18139 18153 18165 18175
  (18226 . 18227)
  18249 18258 18270 18290 18297 18339 18352 18398 18554 18641 18646 18787 18817 18834
  (18861 . 18954)
  (18956 . 18991)))
--8<---------------cut here---------------end--------------->8---

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> I think I have isolated the cause. And the error is cause by these lines
> in my ~/.emacs.d/init.el (only if ebdb package is installed):
>
> (when (package-installed-p 'ebdb)
>   (require 'ebdb-gnus)
>   (require 'ebdb-message))
>
>
> If I remove the package ebdb then the error goes away.

That's pretty weird, as EBDB doesn't mess with Gnus marks at all.
Perhaps it is raising an error at some point, which is interrupting
nnselect's normal buffer setup? That's a completely wild guess.

Maybe try setting `ebdb-mua-auto-update-p' to nil and try again?
Whatever damage EBDB might be doing to Gnus should be done in the auto
update process.

But again, I can't even begin to guess why this would be happening.

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Pankaj Jangid]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>
>> I think I have isolated the cause. And the error is cause by these lines
>> in my ~/.emacs.d/init.el (only if ebdb package is installed):
>>
>> (when (package-installed-p 'ebdb)
>>   (require 'ebdb-gnus)
>>   (require 'ebdb-message))
>>
>>
>> If I remove the package ebdb then the error goes away.
>
> That's pretty weird, as EBDB doesn't mess with Gnus marks at all.
> Perhaps it is raising an error at some point, which is interrupting
> nnselect's normal buffer setup? That's a completely wild guess.
>
> Maybe try setting `ebdb-mua-auto-update-p' to nil and try again?
> Whatever damage EBDB might be doing to Gnus should be done in the auto
> update process.
>
> But again, I can't even begin to guess why this would be happening.

more weird things happening here.

I have ‘ebdb-mua-auto-update-p’ set to nil in my config. This was
already the case.

But calling (describe-variable) on ‘ebdb-mua-auto-update’ shows this
error with the following steps:

Steps:

1. Start emacs afresh

2. (setq debug-on-error t)

3. Launch gnus

4. C-h v ebdb-mua-auto-update-p RET

Result:

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or directory" "vm-autoloads")
  require(vm-autoloads)
  byte-code("\300\301!\210\300\302!\210\300\303!\210\304\305\306\307\310\301%\210\311\305\312\313#\210\314\315\316\317\320DD\321\322\323%\207" [require ebdb-mua vm-autoloads vm custom-declare-group ebdb-mua-vm nil "VM-specific EBDB customizations" :group put custom-loads (ebdb-vm) custom-declare-variable ebdb-vm-auto-update-p funcall function #f(compiled-function () #<bytecode 0x1ffc1295d0cfd>) "VM-specific value of `ebdb-mua-auto-update-p'." :type (choice (const :tag "do nothing" nil) (const :tag "search for existing records" existing) (const :tag "update existing records" update) (const :tag "query for update or record creation" query) (const :tag "update or create automatically" create) (function :tag "User-defined function"))] 6)
  load("ebdb-vm" noerror nomessage)
  help--load-prefixes((("ebdb" "ebdb-vm" "ebdb-rmail" "ebdb-mhe" "ebdb-gnus" "ebdb-vm" "ebdb-rmail" "ebdb-mhe" "ebdb-gnus")))
  help--symbol-completion-table("ebdb-mua-auto-update-p" #f(compiled-function (vv) #<bytecode 0x1a0ef9ccbe7e4fb>) lambda)
  test-completion("ebdb-mua-auto-update-p" help--symbol-completion-table #f(compiled-function (vv) #<bytecode 0x1a0ef9ccbe7e4fb>))
  completion--complete-and-exit(20 42 exit-minibuffer #f(compiled-function () #<bytecode 0x1a43f3bf3badb7b6>))
  completion-complete-and-exit(20 42 exit-minibuffer)
  minibuffer-complete-and-exit()
  funcall-interactively(minibuffer-complete-and-exit)
  call-interactively(minibuffer-complete-and-exit nil nil)
  command-execute(minibuffer-complete-and-exit)
  read-from-minibuffer("Describe variable: " nil (keymap (10 . minibuffer-complete-and-exit) (13 . minibuffer-complete-and-exit) keymap (menu-bar keymap (minibuf "Minibuf" keymap (tab menu-item "Complete" minibuffer-complete :help "Complete as far as possible") (space menu-item "Complete Word" minibuffer-complete-word :help "Complete at most one word") (63 menu-item "List Completions" minibuffer-completion-help :help "Display all possible completions") "Minibuf")) (27 keymap (103 keymap (27 keymap (99 . switch-to-completions))) (118 . switch-to-completions)) (prior . switch-to-completions) (63 . minibuffer-completion-help) (32 . minibuffer-complete-word) (9 . minibuffer-complete) keymap (menu-bar keymap (minibuf "Minibuf" keymap (previous menu-item "Previous History Item" previous-history-element :help "Put previous minibuffer history element in the min...") (next menu-item "Next History Item" next-history-element :help "Put next minibuffer history element in the minibuf...") (isearch-backward menu-item "Isearch History Backward" isearch-backward :help "Incrementally search minibuffer history backward") (isearch-forward menu-item "Isearch History Forward" isearch-forward :help "Incrementally search minibuffer history forward") (return menu-item "Enter" exit-minibuffer :key-sequence "\15" :help "Terminate input and exit minibuffer") (quit menu-item "Quit" abort-recursive-edit :help "Abort input and exit minibuffer") "Minibuf")) (13 . exit-minibuffer) (10 . exit-minibuffer) (7 . abort-minibuffers) (C-tab . file-cache-minibuffer-complete) (9 . self-insert-command) (XF86Back . previous-history-element) (up . previous-line-or-history-element) (prior . previous-history-element) (XF86Forward . next-history-element) (down . next-line-or-history-element) (next . next-history-element) (27 keymap (60 . minibuffer-beginning-of-buffer) (114 . previous-matching-history-element) (115 . next-matching-history-element) (112 . previous-history-element) (110 . next-history-element))) nil nil nil nil)
  completing-read-default("Describe variable: " help--symbol-completion-table #f(compiled-function (vv) #<bytecode 0x1a0ef9ccbe7e4fb>) t nil nil nil nil)
  completing-read("Describe variable: " help--symbol-completion-table #f(compiled-function (vv) #<bytecode 0x1a0ef9ccbe7e4fb>) t nil nil nil)
  byte-code("\301 \302p\303\2\30\304\305\306\6\69\205\22\0\6\6\"\307\310\311\6\6\"\302\303\211\6\n9\205&\0\312\6\13!&\7\262\1\211\313\232\2034\0\3\202..." [enable-recursive-minibuffers variable-at-point t nil completing-read format-prompt "Describe variable" help--symbol-completion-table make-closure #f(compiled-function (vv) #<bytecode -0x1f9230fa89c11b08>) symbol-name "" intern] 13)
  call-interactively(describe-variable nil nil)
  command-execute(describe-variable)
--8<---------------cut here---------------end--------------->8---

If you enter any group and open an article, then the above error goes
away i.e. describe-variable works fine.

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>>
>>> I think I have isolated the cause. And the error is cause by these lines
>>> in my ~/.emacs.d/init.el (only if ebdb package is installed):
>>>
>>> (when (package-installed-p 'ebdb)
>>>   (require 'ebdb-gnus)
>>>   (require 'ebdb-message))
>>>
>>>
>>> If I remove the package ebdb then the error goes away.
>>
>> That's pretty weird, as EBDB doesn't mess with Gnus marks at all.
>> Perhaps it is raising an error at some point, which is interrupting
>> nnselect's normal buffer setup? That's a completely wild guess.
>>
>> Maybe try setting `ebdb-mua-auto-update-p' to nil and try again?
>> Whatever damage EBDB might be doing to Gnus should be done in the auto
>> update process.
>>
>> But again, I can't even begin to guess why this would be happening.
>
> more weird things happening here.
>
> I have ‘ebdb-mua-auto-update-p’ set to nil in my config. This was
> already the case.
>
> But calling (describe-variable) on ‘ebdb-mua-auto-update’ shows this
> error with the following steps:
>
> Steps:
>
> 1. Start emacs afresh
>
> 2. (setq debug-on-error t)
>
> 3. Launch gnus
>
> 4. C-h v ebdb-mua-auto-update-p RET
>
> Result:
>
> Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or directory" "vm-autoloads")
>   require(vm-autoloads)

Still weird, but different weird! Nothing should attempt to load ebdb-vm
at all, so long as you're not requiring it, and I'm not sure why
scanning for variable docstrings would try to load it.

The top of ebdb-vm.el has:

(when t
  (require 'vm-autoloads)
  (require 'vm))

TBH I don't quite remember the point of the (when t) (did I inherit this
code?), but I seem to recall it prevents the requires from running
during compilation, they only run at load-time. At least, I think that
might be it.

Again I have no idea why that code would cause an error in your
situation, but I also wonder if it could just be removed: there's a pile
of declare-functions and defvars after that, that look like they should
be sufficient to cover all the code used in the file, maybe the
requires aren't needed at all.

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>>>
>>>> I think I have isolated the cause. And the error is cause by these lines
>>>> in my ~/.emacs.d/init.el (only if ebdb package is installed):
>>>>
>>>> (when (package-installed-p 'ebdb)
>>>>   (require 'ebdb-gnus)
>>>>   (require 'ebdb-message))
>>>>
>>>>
>>>> If I remove the package ebdb then the error goes away.
>>>
>>> That's pretty weird, as EBDB doesn't mess with Gnus marks at all.
>>> Perhaps it is raising an error at some point, which is interrupting
>>> nnselect's normal buffer setup? That's a completely wild guess.
>>>
>>> Maybe try setting `ebdb-mua-auto-update-p' to nil and try again?
>>> Whatever damage EBDB might be doing to Gnus should be done in the auto
>>> update process.
>>>
>>> But again, I can't even begin to guess why this would be happening.
>>
>> more weird things happening here.
>>
>> I have ‘ebdb-mua-auto-update-p’ set to nil in my config. This was
>> already the case.
>>
>> But calling (describe-variable) on ‘ebdb-mua-auto-update’ shows this
>> error with the following steps:
>>
>> Steps:
>>
>> 1. Start emacs afresh
>>
>> 2. (setq debug-on-error t)
>>
>> 3. Launch gnus
>>
>> 4. C-h v ebdb-mua-auto-update-p RET
>>
>> Result:
>>
>> Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or directory" "vm-autoloads")
>>   require(vm-autoloads)

Okay, after going into ebdb-vm.el and provoking the above error by
eval-ling the (when t ...) statement, I'm now seeing the same bug when
exiting search groups. In my case I'm seeing it when
`nnselect-push-info' is cycling over mark types, and reaches "bookmark",
which is of type 'tuple: the first mark of that type.

That puts us into the (eq mark-type 'tuple) branch of the cond for the
first time, which is also the first time it runs:

(map-merge
  'list list
  (alist-get type (gnus-info-marks group-info)))

There are no bookmark marks in this group, so naturally we get the
no-applicable-method error for "nil".

This does nothing to explain how this code doesn't error normally, or
how on earth raising a `require'-based error would change its behavior.

I'm out for the rest of the afternoon, but I'll restart Gnus and look at
how it works in a non-broken setup later in the day.

Eric

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>>
>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>
>>>> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>>>>
>>>>> I think I have isolated the cause. And the error is cause by these lines
>>>>> in my ~/.emacs.d/init.el (only if ebdb package is installed):
>>>>>
>>>>> (when (package-installed-p 'ebdb)
>>>>>   (require 'ebdb-gnus)
>>>>>   (require 'ebdb-message))
>>>>>
>>>>>
>>>>> If I remove the package ebdb then the error goes away.
>>>>
>>>> That's pretty weird, as EBDB doesn't mess with Gnus marks at all.
>>>> Perhaps it is raising an error at some point, which is interrupting
>>>> nnselect's normal buffer setup? That's a completely wild guess.
>>>>
>>>> Maybe try setting `ebdb-mua-auto-update-p' to nil and try again?
>>>> Whatever damage EBDB might be doing to Gnus should be done in the auto
>>>> update process.
>>>>
>>>> But again, I can't even begin to guess why this would be happening.
>>>
>>> more weird things happening here.
>>>
>>> I have ‘ebdb-mua-auto-update-p’ set to nil in my config. This was
>>> already the case.
>>>
>>> But calling (describe-variable) on ‘ebdb-mua-auto-update’ shows this
>>> error with the following steps:
>>>
>>> Steps:
>>>
>>> 1. Start emacs afresh
>>>
>>> 2. (setq debug-on-error t)
>>>
>>> 3. Launch gnus
>>>
>>> 4. C-h v ebdb-mua-auto-update-p RET
>>>
>>> Result:
>>>
>>> Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or directory" "vm-autoloads")
>>>   require(vm-autoloads)
>
> Okay, after going into ebdb-vm.el and provoking the above error by
> eval-ling the (when t ...) statement, I'm now seeing the same bug when
> exiting search groups. In my case I'm seeing it when
> `nnselect-push-info' is cycling over mark types, and reaches "bookmark",
> which is of type 'tuple: the first mark of that type.
>
> That puts us into the (eq mark-type 'tuple) branch of the cond for the
> first time, which is also the first time it runs:
>
> (map-merge
>   'list list
>   (alist-get type (gnus-info-marks group-info)))
>
> There are no bookmark marks in this group, so naturally we get the
> no-applicable-method error for "nil".
>
> This does nothing to explain how this code doesn't error normally, or
> how on earth raising a `require'-based error would change its behavior.

Well I had to restart Emacs anyway in order to get a working Gnus back,
so I just checked this now. Apparently edebugging `nnselect-push-info'
was enough to raise the error.

A little while ago I changed the `condition-case' inside `nnselect-run'
into a `condition-case-unless-debug', because it was swallowing useful
errors. I guess both Pankaj's `require' error and my edebugging put
Emacs into a "debug" mode, so an error that was being swallowed was now
raised.

Andy I know you're pretty time-limited now, but what do you think about
this? I've always felt that the `condition-case' inside `nnselect-run'
was kind of dangerous, and it looks like it has been swallowing bugs.
It's not a hard bug to fix, but I'd sure like to address the bigger
issue of raising errors from `nnselect-run'. Do you have any feelings
about it?

(Pankaj, in the meantime I'll do away with the `require' statements in
ebdb-vm.el, thanks for that report.)

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

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

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>>>
>>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>>
>>>>> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>>>>>
>>>>>> I think I have isolated the cause. And the error is cause by these lines
>>>>>> in my ~/.emacs.d/init.el (only if ebdb package is installed):
>>>>>>
>>>>>> (when (package-installed-p 'ebdb)
>>>>>>   (require 'ebdb-gnus)
>>>>>>   (require 'ebdb-message))
>>>>>>
>>>>>>
>>>>>> If I remove the package ebdb then the error goes away.
>>>>>
>>>>> That's pretty weird, as EBDB doesn't mess with Gnus marks at all.
>>>>> Perhaps it is raising an error at some point, which is interrupting
>>>>> nnselect's normal buffer setup? That's a completely wild guess.
>>>>>
>>>>> Maybe try setting `ebdb-mua-auto-update-p' to nil and try again?
>>>>> Whatever damage EBDB might be doing to Gnus should be done in the auto
>>>>> update process.
>>>>>
>>>>> But again, I can't even begin to guess why this would be happening.
>>>>
>>>> more weird things happening here.
>>>>
>>>> I have ‘ebdb-mua-auto-update-p’ set to nil in my config. This was
>>>> already the case.
>>>>
>>>> But calling (describe-variable) on ‘ebdb-mua-auto-update’ shows this
>>>> error with the following steps:
>>>>
>>>> Steps:
>>>>
>>>> 1. Start emacs afresh
>>>>
>>>> 2. (setq debug-on-error t)
>>>>
>>>> 3. Launch gnus
>>>>
>>>> 4. C-h v ebdb-mua-auto-update-p RET
>>>>
>>>> Result:
>>>>
>>>> Debugger entered--Lisp error: (file-missing "Cannot open load
>>>> file" "No such file or directory" "vm-autoloads")
>>>>   require(vm-autoloads)
>>
>> Okay, after going into ebdb-vm.el and provoking the above error by
>> eval-ling the (when t ...) statement, I'm now seeing the same bug when
>> exiting search groups. In my case I'm seeing it when
>> `nnselect-push-info' is cycling over mark types, and reaches "bookmark",
>> which is of type 'tuple: the first mark of that type.
>>
>> That puts us into the (eq mark-type 'tuple) branch of the cond for the
>> first time, which is also the first time it runs:
>>
>> (map-merge
>>   'list list
>>   (alist-get type (gnus-info-marks group-info)))
>>
>> There are no bookmark marks in this group, so naturally we get the
>> no-applicable-method error for "nil".
>>
>> This does nothing to explain how this code doesn't error normally, or
>> how on earth raising a `require'-based error would change its behavior.
>
> Well I had to restart Emacs anyway in order to get a working Gnus back,
> so I just checked this now. Apparently edebugging `nnselect-push-info'
> was enough to raise the error.
>
> A little while ago I changed the `condition-case' inside `nnselect-run'
> into a `condition-case-unless-debug', because it was swallowing useful
> errors. I guess both Pankaj's `require' error and my edebugging put
> Emacs into a "debug" mode, so an error that was being swallowed was now
> raised.

And of course this is complete nonsense because none of this group
exiting code is called from within `nnselect-run' at all. I have no idea
what I was thinking. I need to stop trying to squeeze debugging sessions
into little ten-minute spaces.

Of course, now I have no theory as to why the bug is swallowed until
debugging conditions are triggered. I've attached a patch that I think
solves the root problem, but given my track record today it should be
taken with a grain of salt.

(This doesn't mean I don't still think the `condition-case' in
`nnselect-run' should be removed though!)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nnselect-update-marks.diff --]
[-- Type: text/x-patch, Size: 791 bytes --]

diff --git a/lisp/gnus/nnselect.el b/lisp/gnus/nnselect.el
index ecec705b32..f3537376db 100644
--- a/lisp/gnus/nnselect.el
+++ b/lisp/gnus/nnselect.el
@@ -899,12 +899,12 @@ nnselect-push-info
 		    (setq list (cdr all))))
 		;; now merge with the original list and sort just to
 		;; make sure
-		(setq list
-		      (sort (map-merge
-			     'list list
-			     (alist-get type (gnus-info-marks group-info)))
-			    (lambda (elt1 elt2)
-			      (< (car elt1) (car elt2))))))
+                (when-let ((marked (alist-get
+                                    type (gnus-info-marks group-info))))
+		 (setq list
+		       (sort (map-merge 'list list marked)
+			     (lambda (elt1 elt2)
+			       (< (car elt1) (car elt2)))))))
 	       (t
 		(setq list
 		      (gnus-compress-sequence

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>>
>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>
>>>> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>>>>
>>>>> I think I have isolated the cause. And the error is cause by these lines
>>>>> in my ~/.emacs.d/init.el (only if ebdb package is installed):
>>>>>
>>>>> (when (package-installed-p 'ebdb)
>>>>>   (require 'ebdb-gnus)
>>>>>   (require 'ebdb-message))
>>>>>
>>>>>
>>>>> If I remove the package ebdb then the error goes away.
>>>>
>>>> That's pretty weird, as EBDB doesn't mess with Gnus marks at all.
>>>> Perhaps it is raising an error at some point, which is interrupting
>>>> nnselect's normal buffer setup? That's a completely wild guess.
>>>>
>>>> Maybe try setting `ebdb-mua-auto-update-p' to nil and try again?
>>>> Whatever damage EBDB might be doing to Gnus should be done in the auto
>>>> update process.
>>>>
>>>> But again, I can't even begin to guess why this would be happening.
>>>
>>> more weird things happening here.
>>>
>>> I have ‘ebdb-mua-auto-update-p’ set to nil in my config. This was
>>> already the case.
>>>
>>> But calling (describe-variable) on ‘ebdb-mua-auto-update’ shows this
>>> error with the following steps:
>>>
>>> Steps:
>>>
>>> 1. Start emacs afresh
>>>
>>> 2. (setq debug-on-error t)
>>>
>>> 3. Launch gnus
>>>
>>> 4. C-h v ebdb-mua-auto-update-p RET
>>>
>>> Result:
>>>
>>> Debugger entered--Lisp error: (file-missing "Cannot open load file"
>>> "No such file or directory" "vm-autoloads")
>>>   require(vm-autoloads)
>
> Okay, after going into ebdb-vm.el and provoking the above error by
> eval-ling the (when t ...) statement, I'm now seeing the same bug when
> exiting search groups. In my case I'm seeing it when
> `nnselect-push-info' is cycling over mark types, and reaches "bookmark",
> which is of type 'tuple: the first mark of that type.
>
> That puts us into the (eq mark-type 'tuple) branch of the cond for the
> first time, which is also the first time it runs:
>
> (map-merge
>   'list list
>   (alist-get type (gnus-info-marks group-info)))

Andy points out that the code above should not, by default, raise an
error if the `alist-get' call returns nil. Something in both Pankaj and
my installation has messed with the map functions so that this returns
an error:

(map-merge 'list '(1 2 3) nil)

I couldn't raise an error with "emacs -Q", instead it returned:

((1 . 2) (3))

which also seems wrong, but at least isn't an error.

I'm officially stumped.

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Of course, now I have no theory as to why the bug is swallowed until
> debugging conditions are triggered. I've attached a patch that I think
> solves the root problem, but given my track record today it should be
> taken with a grain of salt.

Te patch looks good to me.

> (This doesn't mean I don't still think the `condition-case' in
> `nnselect-run' should be removed though!)

Yes, I think so too.

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

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Andy points out that the code above should not, by default, raise an
> error if the `alist-get' call returns nil. Something in both Pankaj and
> my installation has messed with the map functions so that this returns
> an error:
>
> (map-merge 'list '(1 2 3) nil)
>
> I couldn't raise an error with "emacs -Q", instead it returned:
>
> ((1 . 2) (3))
>
> which also seems wrong, but at least isn't an error.

Oh!

I assumed that map-merge didn't work on nil arguments, too, but didn't
actually check.  And indeed:

(map-merge 'list nil nil)
=> nil

So...  do you have an older version of map.el from ELPA/MELPA or
something?

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

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Pankaj Jangid]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Of course, now I have no theory as to why the bug is swallowed until
> debugging conditions are triggered. I've attached a patch that I think
> solves the root problem, but given my track record today it should be
> taken with a grain of salt.

The patch solves the gnus-summary-exit issue.

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Andrew Cohen]

Sorry, I communicated with Eric this morning but failed to copy everyone
else :(

The patch is hiding the problem---note that map-merge (should) handle
nil lists perfectly fine. And indeed it does! Except something loaded in
Eric and Pnakaj's environment makes it fail, which is...odd.


If you try with emacs -Q it works correctly, and it also works correctly
in my environment. When map-merge is working properly Eric's new code
just adds a no-op (and I think obscures the code and hides the real
bug). The real question is how loading whatever it is that is causing
map-merge to fail is, err, doing that. Looking at the map-merge code its
hard to see what has happened, but this seems kind of important to
understand.

Best,
Andy

>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

    LI> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
    >> Of course, now I have no theory as to why the bug is swallowed
    >> until debugging conditions are triggered. I've attached a patch
    >> that I think solves the root problem, but given my track record
    >> today it should be taken with a grain of salt.

    LI> Te patch looks good to me.

    >> (This doesn't mean I don't still think the `condition-case' in
    >> `nnselect-run' should be removed though!)

    LI> Yes, I think so too.

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

-- 
Andrew Cohen

Director, HKUST Jockey Club Institute for Advanced Study
Lam Woo Foundation Professor and Chair Professor of Physics

The Hong Kong University of Science and Technology

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> +		       (sort (map-merge 'list list marked)
> +			     (lambda (elt1 elt2)
> +			       (< (car elt1) (car elt2)))))))

If you prefer, there's the niche function car-less-than-car for this :).

Thanks,

-- 
Basil

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Andy points out that the code above should not, by default, raise an
>> error if the `alist-get' call returns nil. Something in both Pankaj and
>> my installation has messed with the map functions so that this returns
>> an error:
>>
>> (map-merge 'list '(1 2 3) nil)
>>
>> I couldn't raise an error with "emacs -Q", instead it returned:
>>
>> ((1 . 2) (3))
>>
>> which also seems wrong, but at least isn't an error.
>
> Oh!
>
> I assumed that map-merge didn't work on nil arguments, too, but didn't
> actually check.  And indeed:
>
> (map-merge 'list nil nil)
> => nil
>
> So...  do you have an older version of map.el from ELPA/MELPA or
> something?

The problem isn't nil, it's '(1 2 3).  That is neither an alist, plist,
nor array, so what is map-merge meant to do with it?  Which are the keys
of the map, and which the values?  Note that a map type of 'list is a
synonym for 'alist.

-- 
Basil

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Lars Ingebrigtsen]

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

> Note that a map type of 'list is a synonym for 'alist.

Oh.  That's...  confusing.  :-/

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

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Lars Ingebrigtsen]

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

> The problem isn't nil, it's '(1 2 3). 

The original backtrace was

Debugger entered--Lisp error: (cl-no-applicable-method map-into nil list)
  signal(cl-no-applicable-method (map-into nil list))
[...]
  map-into(nil list)
  map-merge(list nil nil)

though.  So Eric's patch is the right thing for the '(1 2 3) nil case?
But the map-merge mystery still remains.

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

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Andrew Cohen]

I love niche! (Which, honestly, map-merge is already kind of niche)

Does this just do the sort or does it merge also?

Aug 6, 2021 6:21:40 PM Basil L. Contovounesios <contovob@tcd.ie>:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> +          (sort (map-merge 'list list marked)
>> +          (lambda (elt1 elt2)
>> +            (< (car elt1) (car elt2)))))))
>
> If you prefer, there's the niche function car-less-than-car for this 
> :).
>
> Thanks,
>

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Andrew Cohen]

Sorry, I decided to not be lazy and just looked it up:-)

So it can replace the lambda in the sort function. Which is very clear 
and shortens the code. I like it.

Aug 6, 2021 7:01:33 PM Andrew Cohen <cohen@andy.bu.edu>:

> I love niche! (Which, honestly, map-merge is already kind of niche)
>
> Does this just do the sort or does it merge also?
>
> Aug 6, 2021 6:21:40 PM Basil L. Contovounesios <contovob@tcd.ie>:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> +          (sort (map-merge 'list list marked)
>>> +          (lambda (elt1 elt2)
>>> +            (< (car elt1) (car elt2)))))))
>>
>> If you prefer, there's the niche function car-less-than-car for this 
>> :).
>>
>> Thanks,
>>

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Note that a map type of 'list is a synonym for 'alist.
>
> Oh.  That's...  confusing.  :-/

Yes, it's unfortunate.  I guess the historical accident happened because
map.el only recently started supporting plists.

-- 
Basil

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> The problem isn't nil, it's '(1 2 3). 
>
> The original backtrace was
>
> Debugger entered--Lisp error: (cl-no-applicable-method map-into nil list)
>   signal(cl-no-applicable-method (map-into nil list))
> [...]
>   map-into(nil list)
>   map-merge(list nil nil)

This reminds me of https://bugs.gnu.org/46722, although I can't
reproduce the error with (map-into () 'list).

> though.  So Eric's patch is the right thing for the '(1 2 3) nil case?

I don't see how Eric's patch addresses the '(1 2 3) case, since '(1 2 3)
is not a valid map that map-merge can usefully operate on.

> But the map-merge mystery still remains.

:(

-- 
Basil

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

On 08/06/21 12:25 PM, Basil L. Contovounesios wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>>
>>> The problem isn't nil, it's '(1 2 3). 
>>
>> The original backtrace was
>>
>> Debugger entered--Lisp error: (cl-no-applicable-method map-into nil list)
>>   signal(cl-no-applicable-method (map-into nil list))
>> [...]
>>   map-into(nil list)
>>   map-merge(list nil nil)
>
> This reminds me of https://bugs.gnu.org/46722, although I can't
> reproduce the error with (map-into () 'list).
>
>> though.  So Eric's patch is the right thing for the '(1 2 3) nil case?
>
> I don't see how Eric's patch addresses the '(1 2 3) case, since '(1 2 3)
> is not a valid map that map-merge can usefully operate on.

I've provided unhelpful examples here, because I didn't really know what
`map-merge' was supposed to do.

Reloading map.el or map.elc is enough to fix the problem here. So that's
another data point.

I realized that I was lying when I told Andy that EBDB doesn't use
map.el! In fact it does require it at the top ebdb.el, but then doesn't
make use of any of the functions. Maybe at some point I thought I'd use
it for something?

I'll remove the require, but it would be pretty amazing if that were the
source of the problem.

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On 08/06/21 12:25 PM, Basil L. Contovounesios wrote:
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>>>
>>>> The problem isn't nil, it's '(1 2 3). 
>>>
>>> The original backtrace was
>>>
>>> Debugger entered--Lisp error: (cl-no-applicable-method map-into nil list)
>>>   signal(cl-no-applicable-method (map-into nil list))
>>> [...]
>>>   map-into(nil list)
>>>   map-merge(list nil nil)
>>
>> This reminds me of https://bugs.gnu.org/46722, although I can't
>> reproduce the error with (map-into () 'list).
>>
>>> though.  So Eric's patch is the right thing for the '(1 2 3) nil case?
>>
>> I don't see how Eric's patch addresses the '(1 2 3) case, since '(1 2 3)
>> is not a valid map that map-merge can usefully operate on.
>
> I've provided unhelpful examples here, because I didn't really know what
> `map-merge' was supposed to do.
>
> Reloading map.el or map.elc is enough to fix the problem here. So that's
> another data point.
>
> I realized that I was lying when I told Andy that EBDB doesn't use
> map.el! In fact it does require it at the top ebdb.el, but then doesn't
> make use of any of the functions. Maybe at some point I thought I'd use
> it for something?

I am further lying! Apparently I was using it, in ebdb-com.el, for alist
mapping in a pcase-lambda. My apologies to Andy for dismissing the
possibility that it was EBDB -- I have no recollection of writing that
code!

ANYWAY the real problem seems to have something to do with the recent
change to the "eql" specializer for method definitions, done in
6535fd1fa9. That patch added quotes to eg the 'list in:

(cl-defmethod map-into (map (_type (eql 'list)))
  "Convert MAP into an alist."
  (map-pairs map))

And removing those quotes removes the error for me. Again, simply
reloading either map.el or map.elc (with quotes still in place) also
removes the error, so there must be something tricky going on in
compilation. I'm cc'ing akater, the author of that patch, in hopes
they'll have some light to shed.

Eric

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> And removing those quotes removes the error for me. Again, simply
> reloading either map.el or map.elc (with quotes still in place) also
> removes the error, so there must be something tricky going on in
> compilation. I'm cc'ing akater, the author of that patch, in hopes
> they'll have some light to shed.

Ah, so this is basically the same as bug#49877 (but a different eql
specialiser). 

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

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[akater]

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

Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> ANYWAY the real problem seems to have something to do with the recent
> change to the "eql" specializer for method definitions, done in
> 6535fd1fa9. That patch added quotes to eg the 'list in:
>
> (cl-defmethod map-into (map (_type (eql 'list)))
>   "Convert MAP into an alist."
>   (map-pairs map))
>
> And removing those quotes removes the error for me. Again, simply
> reloading either map.el or map.elc (with quotes still in place) also
> removes the error, so there must be something tricky going on in
> compilation. I'm cc'ing akater, the author of that patch, in hopes
> they'll have some light to shed.
>
> Eric

Curiously, for me (map-into nil 'list) is an error when run in emacs
(until redefined) but not in emacs -Q.

Still more curiously, (map-into nil 'alist) is not an error even when
(map-into nil 'list) is.

For now I can't say anything more substantial.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 865 bytes --]

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[akater]

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


It's as if there is old bytecode somewhere, not loaded from emacs -Q but
loaded in most cases.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 865 bytes --]

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

akater <nuclearspace@gmail.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> ANYWAY the real problem seems to have something to do with the recent
>> change to the "eql" specializer for method definitions, done in
>> 6535fd1fa9. That patch added quotes to eg the 'list in:
>>
>> (cl-defmethod map-into (map (_type (eql 'list)))
>>   "Convert MAP into an alist."
>>   (map-pairs map))
>>
>> And removing those quotes removes the error for me. Again, simply
>> reloading either map.el or map.elc (with quotes still in place) also
>> removes the error, so there must be something tricky going on in
>> compilation. I'm cc'ing akater, the author of that patch, in hopes
>> they'll have some light to shed.
>>
>> Eric
>
> Curiously, for me (map-into nil 'list) is an error when run in emacs
> (until redefined) but not in emacs -Q.
>
> Still more curiously, (map-into nil 'alist) is not an error even when
> (map-into nil 'list) is.

Yes, both of those conditions are true for me here, as well.

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Lars Ingebrigtsen]

akater <nuclearspace@gmail.com> writes:

> It's as if there is old bytecode somewhere, not loaded from emacs -Q but
> loaded in most cases.

Just checking -- have you run `M-x list-load-path-shadows' to see if you
have a different map.elc somewhere that you're loading?

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

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[akater]

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


I was not aware of list-load-path-shadows but it doesn't show anything
map-related.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 865 bytes --]

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

On 08/06/21 19:14 PM, akater wrote:
> I was not aware of list-load-path-shadows but it doesn't show anything
> map-related.

"make bootstrap" seems to have solved the problem for me. It's always
"make bootstrap"!!

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Pankaj Jangid]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On 08/06/21 19:14 PM, akater wrote:
>> I was not aware of list-load-path-shadows but it doesn't show anything
>> map-related.
>
> "make bootstrap" seems to have solved the problem for me. It's always
> "make bootstrap"!!

Now-a-days, I rely on complete cleanup. So I do,

git checkout . && git pull && ./autogen.sh && ./configure && make -j8

But this hasn’t solved the issue at my end.

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Lars Ingebrigtsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

>> "make bootstrap" seems to have solved the problem for me. It's always
>> "make bootstrap"!!
>
> Now-a-days, I rely on complete cleanup. So I do,
>
> git checkout . && git pull && ./autogen.sh && ./configure && make -j8
>
> But this hasn’t solved the issue at my end.

That doesn't rebuild the .elc files, though.  Try saying "make
bootstrap".

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

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Pankaj Jangid]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>
>>> "make bootstrap" seems to have solved the problem for me. It's always
>>> "make bootstrap"!!
>>
>> Now-a-days, I rely on complete cleanup. So I do,
>>
>> git checkout . && git pull && ./autogen.sh && ./configure && make -j8
>>
>> But this hasn’t solved the issue at my end.
>
> That doesn't rebuild the .elc files, though.  Try saying "make
> bootstrap".

Sorry. My build command is:

git checkout . && git clean -fdx && git pull && ./autogen.sh && ./configure && make -j8

Forgot ‘git clean -fdx’.

This also gives the same error.

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[akater]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> That doesn't rebuild the .elc files, though.  Try saying "make
> bootstrap".

There are no .elc files in the source tree, if I search correctly.  What
difference would `make bootstrap` make, exactly?  I get these errors
(frame, map-into) with Emacs built from source.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 865 bytes --]

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

On 08/07/21 10:56 AM, Pankaj Jangid wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> On 08/06/21 19:14 PM, akater wrote:
>>> I was not aware of list-load-path-shadows but it doesn't show anything
>>> map-related.
>>
>> "make bootstrap" seems to have solved the problem for me. It's always
>> "make bootstrap"!!
>
> Now-a-days, I rely on complete cleanup. So I do,
>
> git checkout . && git pull && ./autogen.sh && ./configure && make -j8
>
> But this hasn’t solved the issue at my end.

Man, I have provided some really unhelpful suggestions in the course of
this thread. Turns out it wasn't "make bootstrap" (though that did
appear to work, just once), but in fact was some code in EBDB after all.
This method definition:

(cl-defmethod ebdb-records-cite ((_style (eql list))
				 (records list))
  (mapconcat (lambda (pair)
	       (format "%s <%s>"
		       ;; TODO: Wrap non-ASCII record names in double
		       ;; quotes?
		       (ebdb-string (car pair))
		       (ebdb-string (cdr pair))))
	     records "\n"))

uses the unquoted symbol 'list in the specializer, which I'd always
understood to be the normal way of doing it. Now that eql specializers
are evaluated, eval'ling the above definition apparently hoses all
methods specializing on (eql 'list) everywhere in Emacs, until they are
re-evaluated. I've got unquoted eql symbols all over the place in EBDB
and they work fine -- apparently only because in the other cases the
symbols don't clash with those used elsewhere.

This is a sneaky bug. Assuming that the quoted version of the
specializer is backward compatible with earlier code, I will of course
fix EBDB to use that. But NEWS says:

For compatibility, '(eql SYMBOL)' does not evaluate SYMBOL, for now.

Which kind of makes it sound like list should just be treated as 'list?
And the manual doesn't say anything about it at all. And does the same
change need to be to HEAD specializers?

In short, I still have questions :)

Eric

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On 08/07/21 10:56 AM, Pankaj Jangid wrote:
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> On 08/06/21 19:14 PM, akater wrote:
>>>> I was not aware of list-load-path-shadows but it doesn't show anything
>>>> map-related.
>>>
>>> "make bootstrap" seems to have solved the problem for me. It's always
>>> "make bootstrap"!!
>>
>> Now-a-days, I rely on complete cleanup. So I do,
>>
>> git checkout . && git pull && ./autogen.sh && ./configure && make -j8
>>
>> But this hasn’t solved the issue at my end.
>
> Man, I have provided some really unhelpful suggestions in the course of
> this thread. Turns out it wasn't "make bootstrap" (though that did
> appear to work, just once), but in fact was some code in EBDB after all.
> This method definition:
>
> (cl-defmethod ebdb-records-cite ((_style (eql list))
> 				 (records list))
>   (mapconcat (lambda (pair)
> 	       (format "%s <%s>"
> 		       ;; TODO: Wrap non-ASCII record names in double
> 		       ;; quotes?
> 		       (ebdb-string (car pair))
> 		       (ebdb-string (cdr pair))))
> 	     records "\n"))
>
> uses the unquoted symbol 'list in the specializer, which I'd always
> understood to be the normal way of doing it. Now that eql specializers
> are evaluated, eval'ling the above definition apparently hoses all
> methods specializing on (eql 'list) everywhere in Emacs, until they are
> re-evaluated. I've got unquoted eql symbols all over the place in EBDB
> and they work fine -- apparently only because in the other cases the
> symbols don't clash with those used elsewhere.
>
> This is a sneaky bug. Assuming that the quoted version of the
> specializer is backward compatible with earlier code, I will of course
> fix EBDB to use that. But NEWS says:
>
> For compatibility, '(eql SYMBOL)' does not evaluate SYMBOL, for now.
>
> Which kind of makes it sound like list should just be treated as 'list?
> And the manual doesn't say anything about it at all. And does the same
> change need to be to HEAD specializers?
>
> In short, I still have questions :)

Looks like Emacs 27 still requires unquoted symbols:

(cl-defmethod testy ((_bob (eql 'list)))
  (message "bob's a list"))

(testy 'list) -> (cl-no-applicable-method testy list)

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[akater]

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

> eval'ling the above definition apparently hoses all
> methods specializing on (eql 'list) everywhere in Emacs

Something is wrong with the (new) implementation of eql specializers, then.  I CC Stefan Monnier as I didn't study the details.

[-- Attachment #2: Type: text/html, Size: 255 bytes --]

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[akater]

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

Yes, the change is very recent.

[-- Attachment #2: Type: text/html, Size: 31 bytes --]

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Man, I have provided some really unhelpful suggestions in the course of
> this thread. Turns out it wasn't "make bootstrap" (though that did
> appear to work, just once), but in fact was some code in EBDB after all.
> This method definition:
>
> (cl-defmethod ebdb-records-cite ((_style (eql list))
> 				 (records list))
>   (mapconcat (lambda (pair)
> 	       (format "%s <%s>"
> 		       ;; TODO: Wrap non-ASCII record names in double
> 		       ;; quotes?
> 		       (ebdb-string (car pair))
> 		       (ebdb-string (cdr pair))))
> 	     records "\n"))
>
> uses the unquoted symbol 'list in the specializer, which I'd always
> understood to be the normal way of doing it. Now that eql specializers
> are evaluated, eval'ling the above definition apparently hoses all
> methods specializing on (eql 'list) everywhere in Emacs,

Thanks for providing a reproducible test case.


        Stefan "trying to figure out how to fix this mess"

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Thanks for providing a reproducible test case.

I just installed a patch into `master` which should hopefully fix
this problem.  Please confirm that it solves the problem on your side.


        Stefan

bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Pankaj Jangid]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I just installed a patch into `master` which should hopefully fix
> this problem.  Please confirm that it solves the problem on your side.

The issue is fixed now. Thanks for solving this.