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: [Emacs-diffs] trunk r117340: * lisp/calculator.el: Lots of revisions Date: Mon, 23 Jun 2014 09:24:43 -0400 Message-ID: References: <21414.51901.656160.869117@home.barzilay.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1403529914 3627 80.91.229.3 (23 Jun 2014 13:25:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Jun 2014 13:25:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Barzilay Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 23 15:25:07 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wz4F7-0004Uc-So for ged-emacs-devel@m.gmane.org; Mon, 23 Jun 2014 15:25:06 +0200 Original-Received: from localhost ([::1]:53480 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wz4F7-00033n-Ax for ged-emacs-devel@m.gmane.org; Mon, 23 Jun 2014 09:25:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wz4Ew-00032F-OY for emacs-devel@gnu.org; Mon, 23 Jun 2014 09:25:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wz4En-0000VT-8T for emacs-devel@gnu.org; Mon, 23 Jun 2014 09:24:54 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:26638) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wz4En-0000VA-5A for emacs-devel@gnu.org; Mon, 23 Jun 2014 09:24:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSQuh1YI0hkXjnoHhDgEqRmBaoNMIQ X-IPAS-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSQuh1YI0hkXjnoHhDgEqRmBaoNMIQ X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="69220348" Original-Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 Jun 2014 09:24:43 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 525DF603CD; Mon, 23 Jun 2014 09:24:43 -0400 (EDT) In-Reply-To: <21414.51901.656160.869117@home.barzilay.org> (Eli Barzilay's message of "Sun, 22 Jun 2014 08:23:25 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172655 Archived-At: > Is there some way to make it work with 24.3.1 and the trunk version? Ah, so that's what it was about. > Using the original seems to complain about unbound functions when letf > is trying to save the old `symbol-function' values. I guess you could use (eval `(cl-flet ...) t) >> As for changing the `eval' call, the form I used is more efficient >> than the (eval `(let ...)) you're using now: what was the motivation >> for this change? > The change I did makes it work in 24.3.1 (my regular version) which > doesn't have the new eval feature. Efficiency is really not important > in this case, but making me test it more is important... Since calculator.el is not distributed separately, I assumed there was no need to preserve backward compatibility. > * If there is a binding for kp-whatever, rebinding whatever doesn't > affect kp-whatever. > * Since I have (or had) a few of these, I made the code bind *both* > kp-whatever and whatever. (Thinking that for anyone, a good reason > to have kp-whatever bound globally doesn't contradict calculator > re-grabbing it.) > * With both bound, the lookup is needed, otherwise it ends up with > [kp-7] and [kp-add] instead of "7" and "+". Ah, right. That makes a lot of sense. I think you can drop the ascii-character part because the function-key-map should cover a strict superset, but indeed the function-key-map is still needed. > 1. The above is what it is, and needs to be synthesized into the > comment you mention. (Something that says that it's needed because > kp-whatever key bindings are made.) > 2. Maybe the kp-whatever key bindings should go away instead? (I > think that I don't need them anymore, but I hesitate to do such a > big change in an area I don't know much about.) > 3. It would really be best if there's a good way to just eliminate the > need for the whole thing -- currently things like [kp-]7 and [kp-]+ > are bound to `calculator-op' and `calculator-digit', which need to > lookup the actual key. But I suppose that this will take time. To the extent you want to override a global binding to kp-7, I think number 1 is the right solution. Stefan