all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Karl Fogel <kfogel@red-bean.com>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master b88e7c8: Make transpose-regions interactive (Bug#30343)
Date: Wed, 21 Mar 2018 09:22:19 +0200	[thread overview]
Message-ID: <838tallwpg.fsf@gnu.org> (raw)
In-Reply-To: <87a7v2zb27.fsf@red-bean.com> (message from Karl Fogel on Tue, 20 Mar 2018 16:33:52 -0500)

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Tue, 20 Mar 2018 16:33:52 -0500
> 
> 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.

Thanks.

Here are some reasons why not to make the change:

  . there's nothing wrong with that code
  . 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
  . 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
  . moving code between files makes forensics harder ("git log -L" and
    its ilk become almost useless, for example)
  . there's nothing wrong with that code

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



  parent reply	other threads:[~2018-03-21  7:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180311105533.30002.78782@vcs0.savannah.gnu.org>
     [not found] ` <20180311105534.3DAFD23CF3@vcs0.savannah.gnu.org>
2018-03-11 16:05   ` [Emacs-diffs] master b88e7c8: Make transpose-regions interactive (Bug#30343) Stefan Monnier
2018-03-11 17:23     ` Charles A. Roelli
2018-03-12  9:56       ` Leo Liu
2018-03-11 18:13     ` Eli Zaretskii
2018-03-15 20:20       ` Richard Copley
2018-03-16 15:23         ` Karl Fogel
2018-03-20 21:33           ` Karl Fogel
2018-03-20 21:46             ` Richard Copley
2018-03-21  7:22             ` Eli Zaretskii [this message]
2018-03-22  5:30               ` Karl Fogel
2018-03-22  7:12                 ` Eli Zaretskii
2018-03-22  7:15                 ` Unnecessarily moving stiff between files considered harmful (Was: [Emacs-diffs] master b88e7c8: Make transpose-regions interactive) (Bug#30343) Eli Zaretskii
2018-03-23 18:03                   ` Unnecessarily moving stiff between files considered harmful Karl Fogel
2018-03-22 13:39                 ` [Emacs-diffs] master b88e7c8: Make transpose-regions interactive (Bug#30343) Stefan Monnier
2018-03-23 18:05                   ` Karl Fogel
2018-03-25 10:03               ` Charles A. Roelli
2018-03-25 15:41                 ` Eli Zaretskii
2018-03-25 20:29                   ` Charles A. Roelli
2018-03-26 15:59                     ` Eli Zaretskii
2018-03-28 20:19                     ` Juri Linkov
2018-03-29  4:53                       ` Karl Fogel
2018-03-29 11:38                         ` Eli Zaretskii
2018-03-29 12:17                         ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=838tallwpg.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=kfogel@red-bean.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.