From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master b88e7c8: Make transpose-regions interactive (Bug#30343) Date: Tue, 20 Mar 2018 16:33:52 -0500 Message-ID: <87a7v2zb27.fsf@red-bean.com> References: <20180311105533.30002.78782@vcs0.savannah.gnu.org> <20180311105534.3DAFD23CF3@vcs0.savannah.gnu.org> <83woyiscns.fsf@gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1521581524 25868 195.159.176.226 (20 Mar 2018 21:32:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 20 Mar 2018 21:32:04 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: Emacs Development Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 20 22:32:00 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eyOrP-0006ar-U8 for ged-emacs-devel@m.gmane.org; Tue, 20 Mar 2018 22:32:00 +0100 Original-Received: from localhost ([::1]:51819 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyOtT-000874-0N for ged-emacs-devel@m.gmane.org; Tue, 20 Mar 2018 17:34:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyOtK-00086v-VU for emacs-devel@gnu.org; Tue, 20 Mar 2018 17:34:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eyOtH-0004mx-Qw for emacs-devel@gnu.org; Tue, 20 Mar 2018 17:33:58 -0400 Original-Received: from mail-ot0-x235.google.com ([2607:f8b0:4003:c0f::235]:40088) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eyOtH-0004mc-Kr for emacs-devel@gnu.org; Tue, 20 Mar 2018 17:33:55 -0400 Original-Received: by mail-ot0-x235.google.com with SMTP id l12-v6so3437247otj.7 for ; Tue, 20 Mar 2018 14:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:references:references:in-reply-to:reply-to :date:message-id:user-agent:mime-version; bh=3Sj5rz8qs9k4cna8JJdMQpKnS2IfK3hlJRhCb6U/l0w=; b=owBm6lvk84bon6fTtYCSU4NMoDi2if2MUbyeLWFJq0njlyuhMlgf4+pcftQ9KofjfS OeOcsxr9/HQQjif1PlzE755uBgkXOEm/J26IkefmZm52qmPoW7z6NmM0OqwwK4VteHYg g6agDR43oMoHe/cIWG6bFhE1gf93cMb894X02slUJANl2cnQLBQSZO0cC3IYCZAK9hvR vVPr+j2r1IV6MAdeGPrLXbR+dehUrCsYblC4ON2acy7Wq8r9zvgAYGZqt9vPY7/wHBib JX0h4O+HND/kxIcFxf24+fPRbcj1RFEQo6/9WA2tZ2b2j7fDj8wwnG4IuiPdtMntL5Vw RsVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:references:references :in-reply-to:reply-to:date:message-id:user-agent:mime-version; bh=3Sj5rz8qs9k4cna8JJdMQpKnS2IfK3hlJRhCb6U/l0w=; b=mXiK2o86NYIwgQD9hMzzLC1tym6sjHRPqwcs5UbN7rkHnM75JFUIqrYB71dT/LE+ND uMpGvEQuUwH4IcEfPy5at2Kkyh65Ub8m4DGKOR58Qsgnv1FkNNBgXm4iJHR3FVeFbueu SqF6y5lJfMTpHFX9ER56S44j40Qt7qoZN9hLGBy4Nso4Q9H0PRI1UV8oS11pu4rVAhdx tNT0N3MFLnbXIv0VIgVOFBAmIzyNHKGaNlWsUC0rL1yOBy4xipet7qhA0kJcpp51PU7p NGXv1ggUfIYJsAf3n5xIC3Z8cUGfQSKZ93bnbl0UVC/XbP40mzpkPvJv2o7yjy0vA1C7 RbYw== X-Gm-Message-State: AElRT7HmJZLEWwJJYqn/ZhF7byElmfFUmLhtu1VxhxrK9RWgo27QZ0mD 5T/giLm2QSmx8zT6/XQRKdz8lw== X-Google-Smtp-Source: AG47ELuKq2KadRNd68K5v0SKtVIr/5baek0RrQpPXqEzc/7REuiRq6j97mgBL/DsmaHTnIi4wQ+TyQ== X-Received: by 2002:a9d:17ec:: with SMTP id j99-v6mr12240891otj.77.1521581634291; Tue, 20 Mar 2018 14:33:54 -0700 (PDT) Original-Received: from kwork (74-92-190-114-Illinois.hfc.comcastbusiness.net. [74.92.190.114]) by smtp.gmail.com with ESMTPSA id l133sm1455733oia.2.2018.03.20.14.33.53 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Mar 2018 14:33:53 -0700 (PDT) Original-References: <20180311105533.30002.78782@vcs0.savannah.gnu.org> <20180311105534.3DAFD23CF3@vcs0.savannah.gnu.org> <83woyiscns.fsf@gnu.org> <87po44jb7w.fsf@red-bean.com> In-reply-to: <87po44jb7w.fsf@red-bean.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c0f::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223864 Archived-At: >Richard Copley 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