From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joseph Brenner Newsgroups: gmane.emacs.help Subject: proposed keyboard-macro to record to elisp (was Re: line-move-visual) Date: Wed, 09 Jun 2010 12:42:48 -0700 Message-ID: <87ljaoat6v.fsf_-_@kzsu.stanford.edu> References: <87pr07qjio.fsf@thinkpad.tsdh.de> <878w6vq7ew.fsf@thinkpad.tsdh.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291829999 2430 80.91.229.12 (8 Dec 2010 17:39:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 17:39:59 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 08 18:39:55 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQNzd-0008S3-Pv for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 18:39:53 +0100 Original-Received: from localhost ([127.0.0.1]:55268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQNzd-0000Bi-7c for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 12:39:53 -0500 Original-Path: usenet.stanford.edu!postnews.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.posted.rawbandwidth!news.posted.rawbandwidth.POSTED!not-for-mail Original-NNTP-Posting-Date: Wed, 09 Jun 2010 14:42:31 -0500 Original-Newsgroups: gnu.emacs.help,comp.emacs User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:frkSzT6TJJ+tBVROpWzjxnkxsyA= Original-Lines: 56 X-Usenet-Provider: http://www.giganews.com Original-NNTP-Posting-Host: 198.144.208.84 Original-X-Trace: sv3-ys6T5dn2czsKQ6UY25jws98GmyzTAPlW0VzGVDSxQn4uDyuA18EoyiUeXGw8VXzS+BDxzwnkDST68WR!F9FA/YNvCnVX1PUep+U+Bbw41Vx7kbQDVCPcv6hokArzvtafzxki/P6SHeeBeLgZzOToAN8sGQTX!6ww= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Original-Xref: usenet.stanford.edu gnu.emacs.help:178770 comp.emacs:99954 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:75713 Archived-At: Stefan Monnier writes: >> IMO, that should be done automatically. But others argue, that a >> keyboard macro should act exactly as doing the same stuff manually. Then > > There's a tension here, indeed: OT1H keyboard macros only record > a sequence of keys, so they should really be equivalent to having the > user hit the same keys in the same order, but OTOH they correspond to > mechanical execution, i.e. to code, so they need simple&reliable > semantics in order to work well. > > As Emacs commands tend to get more complex over time (more DWIMish, > usually), we have more cases of commands that should really only ever be > used interactively because they require the user to see the result > before making the next step. > > This tension for keyboard macros is made evident if you ever try to turn > a keyboard macro into a piece of Elisp code. A job which would seem > simple enough that a little Elisp package could do it for you, right? > > I would encourage people to try and write up a new keyboard-macro > package which would be closer to writing Elisp code: instead of > recording keys, it would record commands, and would do so in a submode > where DWIMish things (line-move-visual, abbrev-mode, auto-fill-mode, > ... you name it) are disabled. The existing keyboard-macro recorder is funky in a number of respects. (1) saving your work is not the default, and in fact takes several additional steps that are not very obvious. I might suggest: (a) automatic naming of macros ("keyboard-macro-1", "keyboard-macro-2"...) (b) a standard init file where keyboard-macros accumulate: ~/.emacs.d/user-generated-macros.el alternately: a standard directory: ~/emacs.d/key-macros/, where macros are saved one-per-file, and old and unloved ones can be expired (c) a follow-on command to fixup macros you expect to use in the future, which encourages/simplifies the process of: o renaming o assign key binding o documenting (2) There's no easy way to recover from errors during macro recording. The user can type very carefully for hundreds of commands, and then a single mistake can trash all of their work and require starting from scratch. (3) There is indeed too high a barrier between creating a keyboard-macro and converting it to emacs lisp code. There's an easy way to do customizations (keyboard-macros) and a more powerful, but harder way (write elisp) and the user sees the switch between the two as a big leap.