emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] trunk r117340: * lisp/calculator.el: Lots of revisions


From: Stefan Monnier
Subject: Re: [Emacs-diffs] trunk r117340: * lisp/calculator.el: Lots of revisions
Date: Wed, 18 Jun 2014 11:21:59 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

> -          (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.

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?

>    (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.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]