From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "N. Jackson" Newsgroups: gmane.emacs.bugs Subject: bug#33654: 27.0.50; No record of init file errors printed in *Messages* Date: Fri, 07 Dec 2018 12:08:33 -0500 Message-ID: <87o99xe032.fsf@moondust.localdomain> References: <87y392gobm.fsf@moondust.localdomain> <83zhth6c7v.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1544203293 19683 195.159.176.226 (7 Dec 2018 17:21:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Dec 2018 17:21:33 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 33654@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 07 18:21:28 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gVJoe-0004yC-95 for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Dec 2018 18:21:28 +0100 Original-Received: from localhost ([::1]:47435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gVJqk-0006GL-VO for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Dec 2018 12:23:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gVJci-0003Jw-47 for bug-gnu-emacs@gnu.org; Fri, 07 Dec 2018 12:09:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gVJcd-00024J-5p for bug-gnu-emacs@gnu.org; Fri, 07 Dec 2018 12:09:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:32982) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gVJcc-00023e-WB for bug-gnu-emacs@gnu.org; Fri, 07 Dec 2018 12:09:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gVJcc-0008Nz-GU for bug-gnu-emacs@gnu.org; Fri, 07 Dec 2018 12:09:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <87y392gobm.fsf@moondust.localdomain> Resent-From: "N. Jackson" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 07 Dec 2018 17:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33654 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33654-submit@debbugs.gnu.org id=B33654.154420252532212 (code B ref 33654); Fri, 07 Dec 2018 17:09:02 +0000 Original-Received: (at 33654) by debbugs.gnu.org; 7 Dec 2018 17:08:45 +0000 Original-Received: from localhost ([127.0.0.1]:37240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gVJcK-0008NU-Ez for submit@debbugs.gnu.org; Fri, 07 Dec 2018 12:08:44 -0500 Original-Received: from mail-io1-f43.google.com ([209.85.166.43]:37869) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gVJcH-0008NA-OZ for 33654@debbugs.gnu.org; Fri, 07 Dec 2018 12:08:42 -0500 Original-Received: by mail-io1-f43.google.com with SMTP id f14so3824670iol.4 for <33654@debbugs.gnu.org>; Fri, 07 Dec 2018 09:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version; bh=cLImLivcH/KXU9CeSwMMdIaHfRQ9vBDejiszUQNbxbw=; b=Uo5DtbApXhz+L1x/2zmaaG58O6LrkVsiFxWsTQUoHdcKqKowKWDZzso++C6v39bjdX rKq/CGKyzlg/FumoST2l3y0k+yrKslFZmYZ9L0B1/IcnNxq1ALUxAJWL0yIDWJD1zraN NqMknI23JdiWABQsmJC/aBFKcTFzLqrELILiWa9mPnThot2KhbWKyUAfrKjrxGRbHRHa WKrfrB0eEtu32tEVyihdGsYngklQBgYPWs0X+n/FVKGvJXWO30RhROlM3doD8AymEexd N/lNCL3STY9Zi9UkhLPXmmh/S0vYTfge0a3JHbqIUtleVak3ZOkE0sid+iZeKqrGpN4E bfRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:message-id :user-agent:mime-version; bh=cLImLivcH/KXU9CeSwMMdIaHfRQ9vBDejiszUQNbxbw=; b=Nv+kL7Dq7LqOaBSljP52SIH4r3H5rpypep1I4V3Mn63b+boGOL+7TaK0p1bh4CwC2q pLA+A2A6dYGwp6ch8HIYVoOPW+VUIfFxALxfsbKGtPZxKSG5gPhpw3aY73aFpU4QIwoY P3ZFA5FOHOGnahEHwNPMStBbyHvQxTSagH5Cbe0q8aHwz38L59TKvyl6mJcgopQ8RltJ dImFmtR6773VoFP2UEJsrU7PD2Y0rppK6JOyYiF/Sv6mreemViGkSr2pzxlswX6evgVd c/3KE+UvRu95ZMbmrNQkiyCmtBCBpcp3QQLVIHqZ1K7L66W+dvWrhpaEoGTxlcv9HgRS 6SDA== X-Gm-Message-State: AA+aEWY5P/tlWbsjrlfp+YKl6nPYAUngRZqJBHbC8POeXnKBB+9Ta1p/ HOf2YyCXKrztQ6bbQlNS0jXLf2It X-Google-Smtp-Source: AFSGD/Uxp5WQb9nDOSxd1RhSSEvjq7XPX3Rq9xvuwZW+RhNXFMVK7L3EtaF7+FqWP6xaCB5yRlqs7w== X-Received: by 2002:a5e:d910:: with SMTP id n16mr2522342iop.58.1544202515889; Fri, 07 Dec 2018 09:08:35 -0800 (PST) Original-Received: from moondust.localdomain.nodomain.none (toroon474qw-lp130-08-70-26-73-61.dsl.bell.ca. [70.26.73.61]) by smtp.gmail.com with ESMTPSA id v74sm2229793ita.27.2018.12.07.09.08.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 07 Dec 2018 09:08:34 -0800 (PST) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:153182 Archived-At: Hello Eli, At 09:13 +0200 on Friday 2018-12-07, Eli Zaretskii wrote: >> From: "N. Jackson" >> 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