bug#67361: 29.1; MH-E: creating a new folder can sometimes fail with a Lisp error

[Eli Zaretskii]

> Cc: cks.emacsbugs-01@cs.toronto.edu
> From: Chris Siebenmann <cks.emacsbugs-01@cs.toronto.edu>
> Date: Tue, 21 Nov 2023 20:45:11 -0500
> 
> Under some conditions, creating a new (N)MH folder in MH-E can fail with
> a Lisp error of 'Wrong type argument: stringp, nil'. This happens if for
> some reason you have loaded/required mh-speed.el but have not created a
> speedbar.
> 
> Reproduction in 'emacs -Q', assuming you have NMH set up:
> 
> * enter MH-E with M-x mh-rmail
> * widen to your entire inbox so you have something to refile, 'F r'.
> * require mh-speed: M-: (require 'mh-soeed)
> * select a message and refile with 'o'. When asked for the target
>   folder, enter one that doesn't exist, say '+anewtestfolder'. Say y to
>   have this folder created.
> * the refile will abort with the minibuffer message showing 'Wrong type
>   argument: stringp, nil'
> 
> The full *Messages* buffer contents are (for my test, with a slightly
> different folder path):
>       Folder +misc/anewtestfolder does not exist.  Create it? (y or n) y
>       Creating +misc/anewtestfolder
>       mh-prompt-for-folder: Wrong type argument: stringp, nil
> 
> I believe the root cause of this problem is that mh-prompt-for-folder
> calls mh-speed-add-folder if 'mh-speed-folder-map is bound:
>       (when (boundp 'mh-speed-folder-map)
>         (mh-speed-add-folder folder-name))
> 
> However, mh-speed-add-folder requires that speedbar-buffer exists, as it
> starts with:
>       (with-current-buffer speedbar-buffer
>         ....)
> 
> In edebug, it is this with-current-buffer call that appears to fail and
> produce the error message when called with no speedbar displayed and
> speedbar-buffer nil.
> 
> Requiring or loading mh-speed without a speedbuffer displayed is
> probably unusual, but I need to do it in order to customize some aspects
> of my MH-E speedbar interface.
> 
> NOTE: I have reproduced this in 'emacs -Q', but this bug report is filed
> from within my regular Emacs and MH-E environment, with multiple third
> party packages and load-file shadowing and so on. You can ignore those
> parts of this report.

Adding Bill.

I'm not sure if it is better to report MH-E-related bugs here or
submit the reports to https://sourceforge.net/p/mh-e/bugs/.