Re: [Emacs-diffs] master b88e7c8: Make transpose-regions interactive (Bug#30343)

[Karl Fogel <kfogel@red-bean.com>]

Eli Zaretskii <eliz@gnu.org> writes:
>Here are some reasons why not to make the change:

I'll respond point-by-point below, but for the record, I don't feel strongly enough about this to continue arguing for the change if consensus is not imminent.  So if I don't convince you here, Eli, the code will just stay as it is, which is fine.  This was never a very important change to begin with.

>  . there's nothing wrong with that code

A circular argument? :-)  (Well, this point may have been tongue-in-cheek humor on your part.)

>  . having it in C doesn't make hacking harder because one can always
>    override functions in Emacs, and moving the interactive spec to
>    Lisp will still leave the code preloaded anyway

"Is hackable" != "is as easily hackable as some other way".  There are plenty of Elisp programmers who will just stop at the C boundary -- they'll just choose not to hack on that particular interactive spec, if they see it's more complicated than opening up an Elisp file, editing, and hitting M-C-x.  Yes, of course it's "hackable" where it is now; so is everything in Emacs.  I'm just saying that it's more work to hack on than it would be if it were in Elisp.  This seems objectively true, just in the sense of measuring sheer number of keystrokes, never mind even the difference in mental burden.  If you think that "having it in C doesn't make hacking harder" [for some people, anyway], I probably can't persuade you.

>  . it's good to have a small number of examples of using this feature
>    of DEFUN in our sources, so that people knew it's possible, and
>    could learn from these examples

We already have several other examples in that file (I listed them in one of my posts).

>  . moving code between files makes forensics harder ("git log -L" and
>    its ilk become almost useless, for example)

True.  (I already interfered with git log -L for Ftranspose_regions -- sorry about that.)

>  . there's nothing wrong with that code

Naturally I resist the temptation to copy my earlier statement!

>Yes, they are all weak reasons, but so are the proposed reasons in
>favor of the change.

Yes, agreed on both counts.

Best regards,
-Karl