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

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

>Richard Copley <rcopley@gmail.com> writes:
>> I agree with Eli, it seems fine to me, but I'm not sure what the
>> alternative is. If it's to move the body of the interactive spec into
>> a function in an elisp file, and replace the spec with a call to that
>> function, it seems overly complicated. (It also feel like a layering
>> violation, but that can only be true if there is a rule or guideline
>> saying so and I don't know of any.)
> 
> One solution would be to rename the C-defined function to
> Ftranspose_regions_internal (with no interactive spec), and move the
> entry point `transpose-regions' out to Lisp with the same interactive
> spec.  The Lisp function would just invoke `transpose-regions-internal'.
> 
> I'd be happy to do this, if there's consensus that it's a good solution.

Some more follow-up on this:

Richard sent an off-list reply (I didn't realize it was off-list until later) saying that the above looked like a good solution.  So I made the change (commit 3a3aa0e05), then reverted (commit 6d2e8fdd) after Eli reiterated that he didn't see a problem with the original code.  I mistakenly thought we had consensus on the change, but clearly I was wrong and further discussion is needed.

So, here is why I would prefer to see that interactive spec moved to Lisp:

Having it in C makes it less hackable.  It's a rather complex interactive spec, and I can imagine someone wanting to play around with it, perhaps with the goal of suggesting a change to the interactive behavior of `transpose-regions'.  If it were in an Elisp file, it would be much easier for people to make those experiments.  (Yes, technically one could find ways to do it anyway, but it would be harder, and in general I think reducing barriers to hackability is a Good Thing.)

Originally I thought my concerns were aesthetic, but when I thought about it more carefully, my concern is really about ease of hacking.  The same argument could apply to the other non-trivial interactive specs defined as `eval'-able strings in C (there are not many of them -- I listed them in my previous mail, quoted below).  To keep things simple, my proposal right now is just about `transpose-regions', though.

If other people have arguments for or against restoring commit 3a3aa0e05, please speak up.  I'll wait at least a week before coming to any conclusions about consensus, to ensure there's time for discussion.

Best regards,
-Karl

> (I wrote the original non-interactive Ftranspose_regions, so am perhaps
> motivated by nostalgia.  Interestingly, while checking my memory to make
> sure, I discovered that although src/ChangeLog.4 has the correct record
> for 1994-04-29, in the git history that change is recorded as being
> authored by RMS -- commit b229b8d187a.  This suggests that there was
> some information lossage in a VC-system conversion somewhere along the
> way.  I don't know if we knew that already or not.)
> 
> I looked for all other C-defined functions that have a Lisp expression
> starting with "(" for their interactive spec in the DEFUN, i.e., are not
> just using the standard code-letter strings for `interactive'.  There
> appear to be a very small number of such functions:
> 
>   - Finsert_char
>   - Ftranspose_regions
>   - Frename_buffer
>   - Fupcase_region
>   - Fdowncase_region
>   - Fdelete_file
>   - Fset_file_modes
> 
> Of these, Ftranspose_regions is certainly the most complex, with
> Fdelete_file and Frename_buffer as runners up.  The others are
> relatively simple.  Maybe it's fine to just rely on our collective
> aesthetic judgement to say that the one in Ftranspose_regions is too
> complex to be tolerated, while the others are okay.
> 
> Best regards,
> -Karl