unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Barzilay <eli@barzilay.org>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] trunk r117340: * lisp/calculator.el: Lots of revisions
Date: Mon, 23 Jun 2014 09:24:43 -0400	[thread overview]
Message-ID: <jwvwqc7hixl.fsf-monnier+emacsdiffs@gnu.org> (raw)
In-Reply-To: <21414.51901.656160.869117@home.barzilay.org> (Eli Barzilay's message of "Sun, 22 Jun 2014 08:23:25 -0400")

> 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	other threads:[~2014-06-23 13:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1Ww2Qw-0002aL-HF@vcs.savannah.gnu.org>
2014-06-16 21:22 ` [Emacs-diffs] trunk r117340: * lisp/calculator.el: Lots of revisions Stefan Monnier
2014-06-18 10:08   ` Eli Barzilay
2014-06-18 18:49     ` Stefan Monnier
2014-06-23  5:21       ` Eli Barzilay
2014-06-23  5:48         ` Nicolas Semrau
2014-06-23 14:24         ` Stefan Monnier
2014-06-18 15:21 ` Stefan Monnier
2014-06-22 12:23   ` Eli Barzilay
2014-06-23 13:24     ` Stefan Monnier [this message]
2014-06-24  7:47       ` Eli Barzilay
2014-06-25  1:11       ` Stephen J. Turnbull

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvwqc7hixl.fsf-monnier+emacsdiffs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=eli@barzilay.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).