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

[Karl Fogel]

Eli Zaretskii <address@hidden> 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