From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Interactive hat. Date: Thu, 26 Mar 2009 19:06:03 +0000 Message-ID: <20090326190603.GH3358@muc.de> References: <20090324135210.GA4657@muc.de> <20090325101650.GA1487@muc.de> <20090325141935.GC1487@muc.de> <20090326124453.GC3358@muc.de> <20090326152738.GF3358@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1238094567 25046 80.91.229.12 (26 Mar 2009 19:09:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Mar 2009 19:09:27 +0000 (UTC) Cc: Juanma Barranquero , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 26 20:10:45 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LmuwR-0003GY-51 for ged-emacs-devel@m.gmane.org; Thu, 26 Mar 2009 20:08:39 +0100 Original-Received: from localhost ([127.0.0.1]:58506 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lmuv3-0007u3-V6 for ged-emacs-devel@m.gmane.org; Thu, 26 Mar 2009 15:07:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lmuug-0007jS-C3 for emacs-devel@gnu.org; Thu, 26 Mar 2009 15:06:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lmuub-0007hK-Ao for emacs-devel@gnu.org; Thu, 26 Mar 2009 15:06:49 -0400 Original-Received: from [199.232.76.173] (port=34485 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lmuua-0007hB-Tj for emacs-devel@gnu.org; Thu, 26 Mar 2009 15:06:45 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:4781 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LmuuZ-0007AD-LZ for emacs-devel@gnu.org; Thu, 26 Mar 2009 15:06:44 -0400 Original-Received: (qmail 62612 invoked by uid 3782); 26 Mar 2009 19:06:41 -0000 Original-Received: from acm.muc.de (pD9E507B2.dip.t-dialin.net [217.229.7.178]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 26 Mar 2009 20:06:37 +0100 Original-Received: (qmail 9671 invoked by uid 1000); 26 Mar 2009 19:06:03 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:109865 Archived-At: Hi, Stefan! On Thu, Mar 26, 2009 at 01:09:48PM -0400, Stefan Monnier wrote: > > Yes, I hate this feature. But rather than blinding me, this has > > opened my eyes to its problems, and I am thus motivated to root them > > out. By contrast, those who like the feature will be blind to these > > problems. > The feature is a result of a long and painful process. I have no > intention to go through it again. I think the result is pretty clean, > so I'm not open to changing it, except for minor aspects. The process was painful in the extreme, I remember it well. I don't want to go through it again either. I'm confident that my suggestion below doesn't change the status quo; it justs adds a facility for external maintainers. > > Anyhow, I've discovered that this problem is not new, and it's > > already been solved. XEmacs put a "_" into their interactive string > > long ago, and there's a macro `defunx' in antlr-mode.el which, when > > used in place of `defun', strips out the "_" from an interactive > > string; OK, it does a few other things, too. > > How about adapting this macro and putting it into a special source > > file in .../lisp/, and making a discreet mention of it in "Using > > Interactive" in the elisp manual? For example: "Note that using > > \"^\" will prevent your function running in older Emacs versions. If > > you need this compatibility, consider using the macro `defunh' in the > > file lisp/compatibility.el.". > > I would far rather put the work in here and now than have to field > > complaints on bug-cc-mode in a year's time, asking why the CC Mode > > commands don't work with shift-select-mode. > > So, how about it? This solution will leave interactive-hat, as it is > > currently implemented, untouched, and it will stop me moaning about it > > for ever. > What about my other suggestion to make it available to interactive > specs using a Lisp form rather than a string? That would seem a lot > simpler and cleaner. I'm assuming an external package maintainer wanting to use (interactive "^P\nr"), still have the command work in Emacs <23 and XEmacs, yet not have to waste time working out for herself how to achieve this. I think I might have misunderstood your suggestion. > So, I've indeed done that, which incidentally simplifies the code. > Now inserting a "^" in the interactive string is just the same as > calling (handle-shift-selection), so you can write > (interactive > (progn (if (fboundp 'handle-shift-selection) (handle-shift-selection)) > ...blabla...)) No, that's not simpler or clearer. It's just pushing the work onto the package maintainer. And it's a LOT of work. For example, (interactive "^P\nr") becomes (interactive (progn (if (fboundp 'handle-shift-selection) (handle-shift-selection)) `(current-prefix-arg ,(if (< (point) (mark)) ,@((point) (mark)) ,@((mark) (point)))))) , or something equally repulsive, requiring infinitely more debugging than the string it replaces. My proposal is to suggest to the maintainer she copy the macro from .../lisp/compatibility.el into her own sources, rename it `foo-defunh'[*] and write: [*] think of this as a hyperbolic defun. ;-) (foo-defunh foo-forward-blarg (arg beg end) "..." (interactive "^P\nr") ....) Although there's a certain tedium involved in that suggestion, it's a straightforward recipe that doesn't require thinking. > -- Stefan -- Alan Mackenzie (Nuremberg, Germany).