From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Barzilay Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r117340: * lisp/calculator.el: Lots of revisions Date: Sun, 22 Jun 2014 08:23:25 -0400 Message-ID: <21414.51901.656160.869117@home.barzilay.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1403439831 2519 80.91.229.3 (22 Jun 2014 12:23:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Jun 2014 12:23:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 22 14:23:45 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 1WygoD-0000Tx-CF for ged-emacs-devel@m.gmane.org; Sun, 22 Jun 2014 14:23:45 +0200 Original-Received: from localhost ([::1]:48741 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WygoC-0000bM-N7 for ged-emacs-devel@m.gmane.org; Sun, 22 Jun 2014 08:23:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wygo3-0000al-9M for emacs-devel@gnu.org; Sun, 22 Jun 2014 08:23:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wygnx-0005Oh-2V for emacs-devel@gnu.org; Sun, 22 Jun 2014 08:23:35 -0400 Original-Received: from mail-qg0-f46.google.com ([209.85.192.46]:51178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wygnw-0005OW-V6 for emacs-devel@gnu.org; Sun, 22 Jun 2014 08:23:29 -0400 Original-Received: by mail-qg0-f46.google.com with SMTP id q107so4898961qgd.19 for ; Sun, 22 Jun 2014 05:23:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=LvxJDyoYkexLrWpaZWFSiM+938WHscHsuyP1hOZlDUQ=; b=PgrR0gVhR/k+GCGrbJ+GsZmNcHqtNqf/q/28JLNZLe/A/VYoTFRMUpoFYMLqURqsEo QclyoUuohIuk2LChwo0ZGFy2a41iOUlwd39eiNUzNVY9wIysJlFvdUQk1Ai+EAOs42Z1 5twq+IF5Pkb3oK85klHWP+5ZNvNOtizXyIgl5BFe4Wy98Y1VyUqHLWmo5vjDpBbFyuj/ CIx8ak0d9pBlvSwjRfli4w+fHb2Q2F11xCyqtLtMC0DqkDc2Peboa4aH15U2WEweEtMK Y2cwea8sdp/9VPvuV4+5cgASjjkulx03agdvGMEfBJCShw0zm0nRfn5HJ5Ho/+URfcu0 UL0A== X-Gm-Message-State: ALoCoQmMQCeSufbKKWNZZiVL2izFdlPuHYaqFxety7QbM/zVoKJhd3pdZRsAvV3gtjz8ycUyUgHr X-Received: by 10.140.30.195 with SMTP id d61mr21791490qgd.62.1403439807855; Sun, 22 Jun 2014 05:23:27 -0700 (PDT) Original-Received: from home.barzilay.org (c-24-60-254-179.hsd1.ma.comcast.net. [24.60.254.179]) by mx.google.com with ESMTPSA id t103sm9295946qgt.39.2014.06.22.05.23.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jun 2014 05:23:26 -0700 (PDT) In-Reply-To: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-redhat-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.192.46 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:172629 Archived-At: On Wednesday, Stefan Monnier wrote: > > - (cl-letf (((symbol-function 'F) > > - (lambda (&optional x y) (calculator-funcall f x y))) > > - ((symbol-function 'D) > > - (lambda (x) (if calculator-deg (/ (* x 180) float-pi) x)))) > > - (eval f `((X . ,X) > > - (Y . ,Y) > > - (TX . ,TX) > > - (TY . ,TY) > > - (DX . ,DX) > > - (L . ,L)))))) > > - (error 0))) > > + (cl-flet ((F (&optional x y) (calculator-funcall f x y)) > > + (D (x) (if calculator-deg (/ (* x 180) float-pi) x))) > > + (eval `(let ((X ,X) (Y ,Y) (DX ,DX) (TX ,TX) (TY ,TY) (L ',L)) > > + ,f) > > + t))))) > > Hmm... have you tested this? `cl-flet' creates lexically-scoped > function bindings (contrary to the old `flet'), so the F and D above > in your new code aren't accessible to the `f' expression. [I know I did, since one of my commits fixed the `fib' example in the `calculator-user-operators' docstring. But I probably tested it with 24.3.1 which is my regular emacs, though something else must have happened since it's broken there too now.] Is there some way to make it work with 24.3.1 and the trunk version? Using the original seems to complain about unbound functions when letf is trying to save the old `symbol-function' values. > 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... > > (let ((inp (or keys (this-command-keys)))) > [...] > > + ;; translates kp-x to x and [tries to] create a string to lookup > > + ;; operators; assume all symbols are translatable via > > + ;; `function-key-map' or with an 'ascii-character property > > + (concat (mapcar (lambda (k) > > + (if (numberp k) k (or (get k 'ascii-character) > > + (error "??bad key??")))) > > + (or (lookup-key function-key-map inp) inp)))))) > > (this-command-keys) should return "fully decoded events", i.e. after > passing through the keyboard-coding-system, input-decode-map, > function-key-map, and key-translation-map. So neither (lookup-key > function-key-map inp) nor (get k 'ascii-character) should be > necessary. > > IOW if this code really is needed, it deserves a comment explaining > why it's needed despite the fact that function-key-map was already > applied. It's code that has been there before, and I was never sure about it. Here's what leads to it: * 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 "+". The bottom line is, I'm not sure about the whole thing -- one of these should be done: 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. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!