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: Mon, 23 Jun 2014 09:24:43 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

> 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



reply via email to

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