Re: Accidental change of behaviour for electric-layout-mode?

[Eli Zaretskii <eliz@gnu.org>]

> From: Morgan Willcock <morgan@ice9.digital>
> Cc: emacs-devel@gnu.org
> Date: Tue, 24 Sep 2024 20:39:42 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Patch is attached.
> >
> > Thanks, but shouldn't the new variable be a defcustom, i.e. a user
> > option?  AFAIU, the preference is on the user level.
> 
> I am following the lead of electric-layout-allow-duplicate-newlines
> which is not a user option.

Which ironically has the following comment:

  ;; TODO: Make this a defcustom?
  (defvar electric-layout-allow-duplicate-newlines nil

So I think this new variable should be a defcustom, and maybe we
should also make electric-layout-allow-duplicate-newlines a defcustom.

> For my use case, electric-layout-rules is being set by a major-mode and
> the functions in those rules would need to be paired with the ability to
> insert a newline within a comment.

If you are saying that it never makes sense to modify the value of
this variable given specific rules, i.e. that any set of rules will
either always support embedded newlines or be unable to support them,
but will never be able to sensibly support both alternatives, then I
agree.  (But in that case, why do we need a variable at all? why not
let the rules specify this directly?)

> If you needed another example of a major-mode configuring it,
> python-mode is also setting rules at the mode level:
> 
> https://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/progmodes/python.el?id=dfecd6037d5ebe5778c40ff7b38bfcbaa3ef779e

The way to let modes control this behavior to introduce an internal
variable which the mode could set and whose initial default value is
taken from the user option.

> 
> If there is any doubt about the usage of the new variable I am happy to
> just put the original behaviour back and omit the new option for the
> moment.

Do you really have such strong feelings about this not being a user
option that you'd rather forget the whole issue?  Why are you so
convinced that no user will ever want to customize this behavior, when
you are the first example of such users?

> > Also, this needs a NEWS entry.
> 
> Does it need a NEWS entry if it is not a user option and the default
> behaviour is the same as Emacs 29?

Let's first agree about the option issue, and then get back to NEWS.

Thanks.