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

[Morgan Willcock]

Eli Zaretskii <eliz@gnu.org> writes:

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

With the current setup, functions which are used within rules cannot
decide for themselves on the context - the function call happens before
the guards that have traditionally been in place are checked.

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

It is more that I don't have strong enough feelings to be making
modifications which significantly change the user experience or design.

Just to make sure everything works in Emacs 30, I'd rather just revert
the accidental change than get further involved in the development of
this feature (at least in the short term).

I've attached a patch which just reverts the change that was
accidentally applied.  This should be all that is needed unless you
specifically want to accommodate features which accidentally worked in
an unreleased version of Emacs.

-- 
Morgan Willcock

0001-Restore-comment-string-check-for-electric-layout-mod.patch
Description: Text Data