From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: position on changing defaults? Date: Sat, 08 Mar 2008 15:09:19 -0500 Message-ID: References: <200803050637.m256bXL3008361@sallyv1.ics.uci.edu> <87hcfkdhqk.fsf@stupidchicken.com> <87d4q8sq9c.fsf@jurta.org> <8763w0n393.fsf@catnip.gol.com> <87bq5p3x8y.fsf@kfs-lx.rd.rdm> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205006979 16274 80.91.229.12 (8 Mar 2008 20:09:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Mar 2008 20:09:39 +0000 (UTC) Cc: Juri Linkov , Chong Yidong , emacs-devel@gnu.org, Miles Bader To: storm@cua.dk (Kim F. Storm) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 08 21:10:06 2008 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 1JY5Mr-0002sG-Iy for ged-emacs-devel@m.gmane.org; Sat, 08 Mar 2008 21:10:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JY5MJ-0007AA-B3 for ged-emacs-devel@m.gmane.org; Sat, 08 Mar 2008 15:09:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JY5ME-00079R-GF for emacs-devel@gnu.org; Sat, 08 Mar 2008 15:09:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JY5MD-00078x-46 for emacs-devel@gnu.org; Sat, 08 Mar 2008 15:09:26 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JY5MC-00078u-UL for emacs-devel@gnu.org; Sat, 08 Mar 2008 15:09:24 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JY5M8-00017e-T0; Sat, 08 Mar 2008 15:09:21 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcCAKKB0kfO+J2CdGdsb2JhbACQfQEwmS+BBw X-IronPort-AV: E=Sophos;i="4.25,467,1199682000"; d="scan'208";a="15745963" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 08 Mar 2008 15:09:20 -0500 Original-Received: from pastel.home ([206.248.157.130]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id OXR38120; Sat, 08 Mar 2008 15:09:20 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id F17547F60; Sat, 8 Mar 2008 15:09:19 -0500 (EST) In-Reply-To: <87bq5p3x8y.fsf@kfs-lx.rd.rdm> (Kim F. Storm's message of "Sat, 08 Mar 2008 19:07:41 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:91763 Archived-At: >> Obviously, this can't work as is. Maybe an even better generalization >> would be >> >> (define-key function-key-map [is-shifted-p] >> (lambda (prompt key) (vector (remove-shift key)))) >> (define-key function-key-map [is-mouse-4-p] >> (lambda (prompt key) >> (vector (combine-modifiers (modifiers key) 'mwheel-up))) >> >> where `is-shifted-p' and `is-mouse-4-p' are Lisp functions. > The argument against using pre-command-hook and post-command-hook is > efficiency Actually, for me it is not. The issue is reliability, maintainability and debuggability. This said, the use of a function-key-map binding which sets a variable is just as bad as a pre-command-hook, if not worse. OTOH I find the above two examples of "generic function-key-map bindings" desirable. Note that they have nothing to do with pre-command-hook: they just move a hardcoded C-level feature to elisp (well, the first is in C, the other doesn't exist because I don't want to add it to the C code but I don't have any clean way to do it in elisp right now). More specifically, I feel like anything that will help reduce the complexity of read_key_sequence is desirable. Stefan PS: And yes, I plead guilty to adding input-decode-map recently which made it more complex.