Re: keymap inheritance for non-sparse keymaps

[Stefan Monnier]

>     You saw the whole patch.  The only place where the `explicit-nil-binding'
>     is introduced is in `store_in_keymap' where we turn a nil binding
>     into an `explicit-nil-binding'.
> 
> Now I understand.  I missed that before.
> 
> So, it looks like the effect is that a nil binding which was not
> explicitly stored will now act like no binding at all.
> I guess that does the job.  I have two issues to raise:
> 
> 1. This unintened symbol is not hidden from the user.
> It can be accessed through aref.  So I have a feeling that
> using an unintened symbol is the wrong thing to do.
> Since the object can't entirely hide, it should not try;
> it should be proud of what it means.

OK.

> What kind of object should it be?

It should be an object that is never used as a binding.
I.e. there should be no code ever that does

   (define-key map key <object>)

Kim's suggestion of simply using t might be good.
But we have to be sure that no code uses (define-key map key t).
A new uninterned symbol is obviously correct, hence my choice.

> 2. Would you like to check the programs in Emacs that call make-keymap
> to make sure they will not be broken by this?  I thought of checking
> them myself but I saw there were 82 of them.

I have used that code for a little while and I have looked through
the few files that seemed relevant, using:

  egrep 'set-keymap-parent|derived-mode' $(grep -l make-keymap lisp/**/*.el)

The only thing changed by my patch, really, is that `make-keymap'
does not hide the "plain-key" bindings of its parent map any more,
and it's really unusual to want to do that.  So I'm quite confident
that it does not break any code (and might even fix some).


        Stefan