From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Remove special requirement to disable startup message. Date: Sun, 20 Dec 2015 17:46:24 +0200 Message-ID: <83si2xt967.fsf@gnu.org> References: <878u4qdpd4.fsf@udel.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1450626385 19739 80.91.229.3 (20 Dec 2015 15:46:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Dec 2015 15:46:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Mark Oteiza Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 20 16:46:18 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aAgBc-0006T6-F5 for ged-emacs-devel@m.gmane.org; Sun, 20 Dec 2015 16:46:16 +0100 Original-Received: from localhost ([::1]:41086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAgBc-0003V4-1I for ged-emacs-devel@m.gmane.org; Sun, 20 Dec 2015 10:46:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAgBO-0003Ue-Tl for emacs-devel@gnu.org; Sun, 20 Dec 2015 10:46:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aAgBI-0004Ya-9P for emacs-devel@gnu.org; Sun, 20 Dec 2015 10:45:59 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40463) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAgBI-0004YW-67; Sun, 20 Dec 2015 10:45:56 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4398 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aAgBH-0000Iz-Ih; Sun, 20 Dec 2015 10:45:55 -0500 In-reply-to: <878u4qdpd4.fsf@udel.edu> (message from Mark Oteiza on Sat, 19 Dec 2015 17:51:03 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:196552 Archived-At: > From: Mark Oteiza > Date: Sat, 19 Dec 2015 17:51:03 -0500 > > After seeing a commentary on the variable here: > > http://emacshorrors.com/posts/advertising-your-freedom.html > > and reading bug#13208 and bug#12370, I am inclined to change this > behavior. Not only is the checking mechanism in > `display-startup-echo-area-message' naïve and error-prone (see > bug#13208), but it does nothing to stop the site from disabling the > message, which is the only tangible justification (found in bug#12730) > for the special treatment to exist. It is trivial for site-start.el, > default.el, or init.el to contain > > (defun display-startup-echo-area-message () nil) > > or similar to disable the message for all users (example from bug#13208). I'm sorry, but I don't agree with the emacshorrors commentary, and I don't think we should make disabling this startup message site-wide so easy. The discussion in bug#12370 shows I'm not the only one. (Splash screen is different: it shows information useful to first-time Emacs users, whereas the echo-area message is about the GNU system and the software freedom.) I appreciate your efforts in producing a patch for review, but I'd rather encourage development in the other direction: . make sure display-startup-echo-area-message cannot be so easily redefined or advised (up to some practical limit) . allow the value to be a list of strings, each one a user name, and prevent the echo-area message from being displayed if the user name is one of these strings -- this should take care of the use case in bug#12370 Would you like to work on these enhancements? Thanks.