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

[Karl Fogel]

>Richard Copley <address@hidden> 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