[PATCH] Remove special requirement to disable startup message.

[PATCH] Remove special requirement to disable startup message.

[Mark Oteiza]

* lisp/startup.el (inhibit-startup-echo-area-message): Replace custom
string with t.
(display-startup-echo-area-message): Only check if
inhibit-startup-echo-area-message is truthy.
---

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).

 lisp/startup.el | 41 ++++-------------------------------------
 1 file changed, 4 insertions(+), 37 deletions(-)

diff --git a/lisp/startup.el b/lisp/startup.el
index 1346310..0d3b44a 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -76,21 +76,10 @@ once you are familiar with the contents of the startup screen."
 
 (defvar startup-screen-inhibit-startup-screen nil)
 
-;; FIXME? Why does this get such weirdly extreme treatment, when the
-;; more important inhibit-startup-screen does not.
 (defcustom inhibit-startup-echo-area-message nil
-  "Non-nil inhibits the initial startup echo area message.
-Setting this variable takes effect
-only if you do it with the customization buffer
-or if your init file contains a line of this form:
- (setq inhibit-startup-echo-area-message \"YOUR-USER-NAME\")
-If your init file is byte-compiled, use the following form
-instead:
- (eval \\='(setq inhibit-startup-echo-area-message \"YOUR-USER-NAME\"))
-Thus, someone else using a copy of your init file will see the
-startup message unless he personally acts to inhibit it."
-  :type '(choice (const :tag "Don't inhibit")
-		 (string :tag "Enter your user name, to inhibit"))
+  "Non-nil inhibits the initial startup echo area message."
+  :type '(choice (const :tag "Don't inhibit" nil)
+		 (const :tag "Inhibit" t))
   :group 'initialization)
 
 (defcustom inhibit-default-init nil
@@ -2154,29 +2143,7 @@ Type \\[describe-distribution] for information on "))
   (let ((resize-mini-windows t))
     (or noninteractive                  ;(input-pending-p) init-file-had-error
 	;; t if the init file says to inhibit the echo area startup message.
-	(and inhibit-startup-echo-area-message
-	     user-init-file
-	     (or (and (get 'inhibit-startup-echo-area-message 'saved-value)
-		      (equal inhibit-startup-echo-area-message
-			     (if (equal init-file-user "")
-				 (user-login-name)
-			       init-file-user)))
-		 ;; Wasn't set with custom; see if .emacs has a setq.
-                 (condition-case nil
-                     (with-temp-buffer
-                       (insert-file-contents user-init-file)
-                       (re-search-forward
-                        (concat
-                         "([ \t\n]*setq[ \t\n]+"
-                         "inhibit-startup-echo-area-message[ \t\n]+"
-                         (regexp-quote
-                          (prin1-to-string
-                           (if (equal init-file-user "")
-                               (user-login-name)
-                             init-file-user)))
-                         "[ \t\n]*)")
-                        nil t))
-                   (error nil))))
+	inhibit-startup-echo-area-message
 	(message "%s" (startup-echo-area-message)))))
 
 (defun display-startup-screen (&optional concise)
-- 
2.6.4

Re: [PATCH] Remove special requirement to disable startup message.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > * lisp/startup.el (inhibit-startup-echo-area-message): Replace custom
  > string with t.
  > (display-startup-echo-area-message): Only check if
  > inhibit-startup-echo-area-message is truthy.

Please do not make this change.

  > 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,

OF COURSE this does actually stop people from disabling the message.
It isn't intended to.  In free software, we cannot actually stop
people from making a certain change.

This code blocks the most obvious way for the site to disable the
message for all users.  That's exactly what it is meant to do.  When
this doesn't work, the person will investigate why not, read what we
said about the issue, and may decide not to do it.

Please leave the code alone.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Remove special requirement to disable startup message.

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> 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.

Re: [PATCH] Remove special requirement to disable startup message.

[Mark Oteiza]

On 20/12/15 at 12:13am, Richard Stallman wrote:
> This code blocks the most obvious way for the site to disable the
> message for all users.

Why is this important?

It also makes the init file of a user following the docstring of
inhibit-startup-echo-area-message less portable. Further, it forces
particular syntax upon users not using the customize interface.

> That's exactly what it is meant to do.  When
> this doesn't work, the person will investigate why not, read what we
> said about the issue, and may decide not to do it.

I have yet to see a good explanation for the weird treatment of this
variable. "Preventing site from disabling the message" is silly because
you cannot prevent it. "thoughtless copying of init files" is another
silly reason because the init file can contain elisp that
unconditionally disables the message.

Re: [PATCH] Remove special requirement to disable startup message.

[Mark Oteiza]

On 20/12/15 at 05:46pm, Eli Zaretskii wrote:
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > 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.

What the discussion fails to show is why this is desirable.

I'm also not the only one asking why such weird treatment is present.

  ;; FIXME? Why does this get such weirdly extreme treatment, when the
  ;; more important inhibit-startup-screen does not.

This was added before either bug#12370 or bug#13208 were filed; the
answers in all of these discussions have been incomplete.

> (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.)

The echo-area message simply points out the keybinding to show the
splash screen.

> 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 but no thanks.  I'm not interested in obfuscating the
customization of Emacs, and have not yet been given any reason why such
a thing is important.

Re: [PATCH] Remove special requirement to disable startup message.

[Eli Zaretskii]

> Date: Tue, 22 Dec 2015 14:09:49 -0500
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: emacs-devel@gnu.org
> 
> >   . 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 but no thanks.  I'm not interested in obfuscating the
> customization of Emacs

Overriding internal functions is hardly customization.  But anyway,
that's the 1st item.  What about the second?  Doing that would fix the
use case reported in bug#12370, without obfuscating anything else.

> and have not yet been given any reason why such a thing is
> important.

My take of that is that advertising the GNU project to newcomers is
important to us.  But you already asked Richard about that, and I'm
sure he will be able to explain that much better than I can.

Thanks.

Re: [PATCH] Remove special requirement to disable startup message.

[John Wiegley]

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

>>>>> Mark Oteiza <mvoteiza@udel.edu> writes:

> I have yet to see a good explanation for the weird treatment of this
> variable. "Preventing site from disabling the message" is silly because you
> cannot prevent it. "thoughtless copying of init files" is another silly
> reason because the init file can contain elisp that unconditionally disables
> the message.

I'm not sure how to reach a "good" level in explaining this, but here is the
main idea: Emacs is a flagship of the GNU project, whose primary goal is to
ensure software freedom for users, rather than merely to provide software to
users.

Thus, when Emacs starts up, one of its goals, as a GNU project, is not only to
edit files, but to make people aware of the issues of software freedom. (This
is also why Nicolas is currently having discussions with Richard about text to
be added to the Emacs web page that ostensibly has little to do with Emacs as
a software project.)

If you think in terms of technical merit alone, there are more than a few
things about this project, and participating in its development, that do not
make complete sense, nor have "good" explanations. You have to broaden the
scope to include the issue of promoting software freedom, and how Emacs is
used to help achieve that task, for all the pieces to fall into place.

Note that this is free software after all: You could fork Emacs and remove
this code. But that wouldn't be GNU Emacs; and GNU Emacs strives very hard to
ensure that the question of software freedom is never buried or side-lined.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

Re: [PATCH] Remove special requirement to disable startup message.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > This code blocks the most obvious way for the site to disable the
  > > message for all users.

  > Why is this important?

So that sysadmins will think twice before disabling the message for
their users.

  > It also makes the init file of a user following the docstring of
  > inhibit-startup-echo-area-message less portable. 

In what sense "less portable"?  What does it need to be portable to?
If you answer that, we can judge whether this issue matters.

  > Further, it forces
  > particular syntax upon users not using the customize interface.

That is no great loss.

The feature is important, and these alleged disadvantages seem to be
so minor they hardly exist.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Remove special requirement to disable startup message.

[Mark Oteiza]

On 22/12/15 at 11:39am, John Wiegley wrote:
> >>>>> Mark Oteiza <mvoteiza@udel.edu> writes:
> 
> > I have yet to see a good explanation for the weird treatment of this
> > variable. "Preventing site from disabling the message" is silly because you
> > cannot prevent it. "thoughtless copying of init files" is another silly
> > reason because the init file can contain elisp that unconditionally disables
> > the message.
> 
> I'm not sure how to reach a "good" level in explaining this, but here is the
> main idea: Emacs is a flagship of the GNU project, whose primary goal is to
> ensure software freedom for users, rather than merely to provide software to
> users.
> 
> Thus, when Emacs starts up, one of its goals, as a GNU project, is not only to
> edit files, but to make people aware of the issues of software freedom.

Yes, this is why the splash screen and echo area message are on by default.
There's also a help menu populated by all the items shown in the splash.

The splash is easy to disable, and the elisp manual instructs not to
disable it site wide. But the single redundant line in *Messages* is
somehow exceedingly more important to merit obfuscation shared by
_nothing else_ in Emacs. These two variables, inhibit-startup-screen and
inhibit-startup-echo-area-message, facilitate passing on the same
exact information and are treated wildly differently.

I'm not suggesting changing the defaults, rather removing an outlier in
Emacs customization that is silly in implementation (it's fragile) and
motivation (it's redundant).

To suggest that this defcustom keeps a user, power user, programmer, distro
packager, site admin, etc. from achieving the theoretical desire of hiding
information about Emacs or GNU from themselves or their system's users
is dubious. Anything from an idle search engine query to searching debbugs
or comprehending the source will yield a workaround.

> Note that this is free software after all: You could fork Emacs and remove
> this code. But that wouldn't be GNU Emacs; and GNU Emacs strives very hard to
> ensure that the question of software freedom is never buried or side-lined.

Forking? Wholly unnecessary, as the previous discussions regarding
startup-inhibit-echo-area-message have shown.

Re: [PATCH] Remove special requirement to disable startup message.

[Mark Oteiza]

On 23/12/15 at 12:10am, Richard Stallman wrote:
>   > > This code blocks the most obvious way for the site to disable the
>   > > message for all users.
> 
>   > Why is this important?
> 
> So that sysadmins will think twice before disabling the message for
> their users.

Are there sites that disable the message? Is there something other than
imagining hostile site admins or distro packagers that prompted the
addition (and consequent bizarre treatment) of this variable?

>   > It also makes the init file of a user following the docstring of
>   > inhibit-startup-echo-area-message less portable. 
> 
> In what sense "less portable"?  What does it need to be portable to?
> If you answer that, we can judge whether this issue matters.

An individual using their username to disable the message will not
necessarily be able to use the same config across different sites.
The practice of keeping emacs configs synchronized across sites is
rather prevalent, and this weird treatment of the variable makes it
useless as a defcustom in this respect. Put another way, the message is
not "easily inhibitable" as written in the Elisp manual.

Re: [PATCH] Remove special requirement to disable startup message.

[Mark Oteiza]

On 22/12/15 at 09:27pm, Eli Zaretskii wrote:
> > Date: Tue, 22 Dec 2015 14:09:49 -0500
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Cc: emacs-devel@gnu.org
> > 
> > >   . 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 but no thanks.  I'm not interested in obfuscating the
> > customization of Emacs
> 
> Overriding internal functions is hardly customization.  But anyway,
> that's the 1st item.

What would you call it?

> What about the second?  Doing that would fix the use case reported in
> bug#12370, without obfuscating anything else.

I suppose I'd be amenable letting the value be a regex, but I doubt
anyone here will agree to it! ;)

Joke aside, to do so would be enhancing that which I'm arguing is
a misfeature, so nope. Sorry.

Re: [PATCH] Remove special requirement to disable startup message.

[Eli Zaretskii]

> Date: Wed, 23 Dec 2015 20:41:31 -0500
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: emacs-devel@gnu.org
> 
> >   > It also makes the init file of a user following the docstring of
> >   > inhibit-startup-echo-area-message less portable. 
> > 
> > In what sense "less portable"?  What does it need to be portable to?
> > If you answer that, we can judge whether this issue matters.
> 
> An individual using their username to disable the message will not
> necessarily be able to use the same config across different sites.

I suggested to allow the value be a list of strings instead of just
one string.  Then whenever the user name matches one of those strings,
the message will be suppressed.

Re: [PATCH] Remove special requirement to disable startup message.

[Eli Zaretskii]

> Date: Wed, 23 Dec 2015 20:49:35 -0500
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: emacs-devel@gnu.org
> 
> > What about the second?  Doing that would fix the use case reported in
> > bug#12370, without obfuscating anything else.
> 
> I suppose I'd be amenable letting the value be a regex, but I doubt
> anyone here will agree to it! ;)

No, not a regexp.  It would be easy to come up with a regexp that
disables this for any user.  I meant a list of constant strings.

> Joke aside, to do so would be enhancing that which I'm arguing is
> a misfeature, so nope. Sorry.

Well, I think you understand by now that some of us think it's a
feature.

Re: [PATCH] Remove special requirement to disable startup message.

[Random832]

Mark Oteiza <mvoteiza@udel.edu> writes:
> An individual using their username to disable the message will not
> necessarily be able to use the same config across different sites.

(setq inhibit-startup-echo-area-message "name1")
(setq inhibit-startup-echo-area-message "name2")
(setq inhibit-startup-echo-area-message (user-login-name))

Re: [PATCH] Remove special requirement to disable startup message.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Your argument is based on a goal, uniformity, that is merely
desirable -- not important.

It is good to make things parallel, when there is no reason to do
otherwise.  We think about uniformity so that we don't careelessly
make things non-parallel.

But that's never important enough to change something
which is the way it is for a real reason.

  > > So that sysadmins will think twice before disabling the message for
  > > their users.

  > Are there sites that disable the message?

I found out about one; that's why I added that code.
As to how many there are, I don't know.  It is not worth the trouble
to find out.  That code works, and it causes no trouble to anyone
_except_ a sysadmin who wants to disable that message for other people.

I'm explaining the reasons for this code so people will
understand.  We're not going to change the code.



-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Remove special requirement to disable startup message.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I suggested to allow the value be a list of strings instead of just
  > one string.  Then whenever the user name matches one of those strings,
  > the message will be suppressed.

I see no problem with that.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [PATCH] Remove special requirement to disable startup message.

[Mark Oteiza]

On 25/12/15 at 12:48am, Richard Stallman wrote:
> Your argument is based on a goal, uniformity, that is merely
> desirable -- not important.
> 
> It is good to make things parallel, when there is no reason to do
> otherwise.  We think about uniformity so that we don't careelessly
> make things non-parallel.
> 
> But that's never important enough to change something
> which is the way it is for a real reason.
> 
>   > > So that sysadmins will think twice before disabling the message for
>   > > their users.
> 
>   > Are there sites that disable the message?
> 
> I found out about one; that's why I added that code.
> As to how many there are, I don't know.  It is not worth the trouble
> to find out.  That code works, and it causes no trouble to anyone
> _except_ a sysadmin who wants to disable that message for other people.
> 
> I'm explaining the reasons for this code so people will
> understand.  We're not going to change the code.

Thank you for explaining.

Merry Grav-Mass!

Re: [PATCH] Remove special requirement to disable startup message.

[Phillip Lord]

Mark Oteiza <mvoteiza@udel.edu> writes:
>> 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.
>
> What the discussion fails to show is why this is desirable.
>
> I'm also not the only one asking why such weird treatment is present.
>
>   ;; FIXME? Why does this get such weirdly extreme treatment, when the
>   ;; more important inhibit-startup-screen does not.
>
> This was added before either bug#12370 or bug#13208 were filed; the
> answers in all of these discussions have been incomplete.

Not wishing to restart a discussion I largely missed, but would anyone
object to me fixing the FIXME? comment. I would also like to extend the
docstring with a short explanation.

The code may be sensible from a freedom point-of-view, but it would make
more sense if the documentation explained and reinforced this.

Re: [PATCH] Remove special requirement to disable startup message.

[John Wiegley]

>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:

> Not wishing to restart a discussion I largely missed, but would anyone
> object to me fixing the FIXME? comment. I would also like to extend the
> docstring with a short explanation.

> The code may be sensible from a freedom point-of-view, but it would make
> more sense if the documentation explained and reinforced this.

Sure, an explanatory comment would be good.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [PATCH] Remove special requirement to disable startup message.

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: Eli Zaretskii <eliz@gnu.org>,  <emacs-devel@gnu.org>
> Date: Thu, 07 Jan 2016 00:08:28 +0000
> 
> >   ;; FIXME? Why does this get such weirdly extreme treatment, when the
> >   ;; more important inhibit-startup-screen does not.
> >
> > This was added before either bug#12370 or bug#13208 were filed; the
> > answers in all of these discussions have been incomplete.
> 
> Not wishing to restart a discussion I largely missed, but would anyone
> object to me fixing the FIXME? comment. I would also like to extend the
> docstring with a short explanation.
> 
> The code may be sensible from a freedom point-of-view, but it would make
> more sense if the documentation explained and reinforced this.

If by fixing the FIXME you mean explaining more in the commentary and
doc strings, by all means go ahead.  If you mean something else,
please tell more.

Thanks.