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

[Mark Oteiza]

On 22/12/15 at 11:39am, John Wiegley wrote:
> >>>>> Mark Oteiza <address@hidden> 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.