[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