From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: recording-elisp.el - try recording commands as elisp code Date: Sun, 4 Nov 2007 08:48:44 -0800 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1194195079 28708 80.91.229.12 (4 Nov 2007 16:51:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Nov 2007 16:51:19 +0000 (UTC) To: "yzhh" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 04 17:51:23 2007 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 1Ioih0-0007Aq-4M for ged-emacs-devel@m.gmane.org; Sun, 04 Nov 2007 17:51:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ioigp-000208-Iy for ged-emacs-devel@m.gmane.org; Sun, 04 Nov 2007 11:51:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ioigl-0001xd-Bh for emacs-devel@gnu.org; Sun, 04 Nov 2007 11:51:07 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ioigi-0001wq-1V for emacs-devel@gnu.org; Sun, 04 Nov 2007 11:51:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ioigh-0001wh-NJ for emacs-devel@gnu.org; Sun, 04 Nov 2007 11:51:03 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ioigh-000211-Ai for emacs-devel@gnu.org; Sun, 04 Nov 2007 11:51:03 -0500 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id lA4Go6JW029029; Sun, 4 Nov 2007 10:50:06 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id lA4GPnIq027718; Sun, 4 Nov 2007 09:50:05 -0700 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-189.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3342523121194194898; Sun, 04 Nov 2007 08:48:18 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:82501 Archived-At: I have not followed all the details in this thread. I have the impression that the discussion now is mostly about how to do the best thing when dealing with various interactive dialogs (isearch, completion, recursive minibuffers,...). I suspect there is no one simple answer here. There seem to be several viable interpretations of TRT, depending on the context and user goals and preferences. If so, then, once the discussion has settled down a bit and there is some agreement on TRT in general, please consider also letting the user have a say interactively, perhaps by toggling an option or two on the fly (during macro recording). The user's choice could affect both the macro itself (replay) and the recorded Lisp code. That is, assuming that there is no simple one-size-fits-all solution, let's avoid hard-coding a smart, reasonable algorithm that fits many situations, if we could (easily) also provide that default behavior plus alternative behaviors that a user might prefer, depending on the situation. IOW, instead of hard-coding TRT, let the user decide TRT on the spot (if possible). IOW, consider promoting some of the design discussion you are having now to interactive user choices. Just a suggestion to keep in mind. I have no idea how feasible this is.