emacs-lock-unlockable-modes should default to nil

emacs-lock-unlockable-modes should default to nil

[Tino Calancha]

Dear Emacs,

I see the comment in the source code: the current value is due
to compatibility with older versions.

I was bitten today with this.  I first thought it was a
bug; then, I realized is the result of a default setting.

Many users would assume that their buffers are secured once they
turn on this minor-mode, overlooking that this option does exist.
I think the value nil is a better default to support such expectations.

Tino

Re: emacs-lock-unlockable-modes should default to nil

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Sat, 30 Jun 2018 16:40:45 +0900 (JST)
> Cc: Juanma Barranquero <lekktu@gmail.com>,
> 	Tino Calancha <tino.calancha@gmail.com>
> 
> I see the comment in the source code: the current value is due
> to compatibility with older versions.
> 
> I was bitten today with this.  I first thought it was a
> bug; then, I realized is the result of a default setting.
> 
> Many users would assume that their buffers are secured once they
> turn on this minor-mode, overlooking that this option does exist.
> I think the value nil is a better default to support such expectations.

The current value was set 7 years ago and released in Emacs 24.1 6
years ago.  I'm not sure this is long enough for such a radical
change.

In any case, it is not a good situation that the doc string of
emacs-lock-mode doesn't even mention emacs-lock-unlockable-modes, so
users have no hope of learning about this variable's critical
importance unless they read the code.  So as the first step towards
perhaps changing the default in the future, I added references to this
variable to relevant doc strings.

Thanks.

Re: emacs-lock-unlockable-modes should default to nil

[Tino Calancha]

On Sat, 7 Jul 2018, Eli Zaretskii wrote:

> In any case, it is not a good situation that the doc string of
> emacs-lock-mode doesn't even mention emacs-lock-unlockable-modes, so
> users have no hope of learning about this variable's critical
> importance unless they read the code.  So as the first step towards
> perhaps changing the default in the future, I added references to this
> variable to relevant doc strings.

Good improvement: favor discoverability of such option.
Thank you