Package: emacs;
Reported by: "N. Jackson" <nljlistbox2 <at> gmail.com>
Date: Fri, 7 Dec 2018 00:43:01 UTC
Severity: minor
Tags: patch
Found in version 27.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Message #11 received at 33654 <at> debbugs.gnu.org (full text, mbox):
From: "N. Jackson" <nljlistbox2 <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 33654 <at> debbugs.gnu.org Subject: Re: bug#33654: 27.0.50; No record of init file errors printed in *Messages* Date: Fri, 07 Dec 2018 12:08:33 -0500
Hello Eli, At 09:13 +0200 on Friday 2018-12-07, Eli Zaretskii wrote: >> From: "N. Jackson" <nljlistbox2 <at> gmail.com> >> Date: Thu, 06 Dec 2018 19:42:05 -0500 >> >> When there is an error in the init file, so that Emacs fails to >> start normally, the user is not notified of the problem in the >> *Messages* buffer. > > Generally, that happens when we cannot safely display anything, > nor even insert text into *Messages*, if problems occur early > enough into the startup process, because the necessary > infrastructure is not yet available. But we do try our best, see > below. So your report, which sounds as if there's a general > non-display of any error or warning messages in this case, is > inaccurate. Yes, you are quite right. Sorry for the rather sweeping statement, I was trying to characterise the problem I saw. I've typically been happy with the information I've had from Emacs when I've had errors in my init files, and I think that was why I was surprised when I was (in my opinion) inadequately informed in this case. I though something might have changed, but perhaps the specific circumstances were different from the errors I've had in the past. > Please be more specific regarding the particular problems you saw > that didn't get logged. Please see below. > Such errors are generally displayed right away, after interrupting > the initialization process. So I wonder what specific example do > you have in mind. Please see below. > Are you talking about errors or warnings? And did you include the > *Warnings* buffer in your review? That's where we put delayed > warnings from the initialization process. More generally, did you > read up on the "delayed warnings" machinery? No, I've not read that documentation recently -- I'll add it to my reading list. Yes there was a *Warnings* buffer, but it was in a window on a frame I didn't visit. I did not know that I needed to check both *Messages* and *Warnings*. I think, perhaps, that if something were written to *Messages* to inform the user that there was a warning/error, and to direct them to the *Warnings* buffer for details, it would make it less likely that the user would miss the information altogether. Something like An initialization error occurred -- see *Warnings* buffer for details. Also, the frame that was split to display the *Warnings* buffer was not the one that had the focus when Emacs finished starting up. (Indeed, I think it might have been on the most deeply buried frame.) There is a very high probability I would never see a warning/error displayed so obscurely. It would seem that it would be better, if it were feasible, if the *Warnings* buffer could be displayed in a window on the frame that has the focus after Emacs finishes starting up. DETAILS Here is a detailed example of the problem. I think this might have really happened to me in real life (resulting in Bug##33536 [1]). Scenario: I have a notion that it would be a good idea to remove and then re-install an Emacs package. I decide that to be sure that none of it still hanging around in memory, I should exit an restart Emacs between removing the package and reinstalling it. The package in this case happens to be bbdb from Gnu Elpa. I have (bbdb-initialize 'gnus 'message) in my init file. When Emacs starts after bbdb has been uninstalled, the above line results in an error. A *Warnings* buffer is displayed as follows: Warning (initialization): An error occurred while loading `/home/nlj/.emacs': Symbol's function definition is void: bbdb-initialize To ensure normal operation, you should investigate and remove the cause of the error in your initialization file. Start Emacs with the `--debug-init' option to view a complete error backtrace. But I don't see this error/warning message because I don't visit the frame on which it is displayed. After all, it's just going to be a short Emacs session during which all I'm going to do is install bbdb. In my *Messages* buffer is displayed: Loading cua-base...done Loading delsel...done Loading desktop...done Loading battery...done Loading time...done Loading elec-pair...done Loading saveplace...done Loading savehist...done Loading paren...done Loading /home/nlj/.recentf...done Cleaning up the recentf list...done (0 removed) Starting new Ispell process /usr/bin/aspell with default dictionary... Loading dired-x...done Setting up indent for shell type sh Indentation variables are now local. Indentation setup for shell type sh Ispell process killed Starting new Ispell process /usr/bin/aspell with default dictionary... Setting up indent for shell type sh Indentation variables are now local. Indentation setup for shell type sh Omitting... Omitted 384 lines. uncompressing de.map.gz...done Wrote /data/projects/vc/emacs/git/emacs/.emacs.desktop.lock Desktop: 7 frames, 54 buffers restored. For information about GNU Emacs and the GNU system, type C-h C-a. This shows no indication of the initialization error. Now it might be a user error to look for an indication of start up problems only in *Messages*, and it might a user error to miss the *Warnings* buffer, but I think it would improve Emacs, were it feasible, if it helped the user to avoid these mistakes by mentioning the error/warning in *Messages*, and by displaying the *Warnings* buffer in a frame that isn't buried. [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33536
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.