bug#22604: 24.5; (elisp) `Key Binding Conventions': what about other `C-c' keys?

[Drew Adams <drew.adams@oracle.com>]

> > Yes, "punctuation and symbol characters" helps, IMO.  That was
> > one of my points: the chars are not necessarily punctuation, in
> > the usual sense of the word.
> 
> Done.

Thx.

> > Dunno whether it's good to limit it to ASCII.  At a minimum it
> > should cover the "punctuation and symbol character" keys on a
> > typical US keyboard, of course.
> 
> Those are all ASCII, AFAIK.

Yes, I think so.

> > Whether it should also cover other punctuation or other symbol chars
> > is maybe an open question.
> >
> > It's really about character-inserting keys on a keyboard, not
> > punctuation and symbol chars that are not on keys.
> 
> Not sure I agree.  Usurping too many characters would not be a good
> idea, IMO.

Usurping?  From whom/what?  It's about reserving this category
of keys for minor mode keymaps.  The question is which punctuation
and symbol chars?  And the answer, I think, is those that are
associated with keyboard keys (one key inserts one char).
For a US keyboard that means only ASCII punctuation and symbol
chars, but for other keyboards it can mean other chars.

> > But a key on a French keyboard that inserts a left guillemet
> > char should, I think, be handled the same by the convention as
> > is a key on a US keyboard that inserts a double-quote char or
> > a left angle-bracket char.
> 
> How can such a binding be useful, when Emacs runs on a non-French
> keyboard?  Do we really want to encourage modes that can only be fully
> functional in some specific locales?  I don't think so.

Why treat punctuation and symbols on a US keyboard specially?
Why should `$' be treated differently from `€'?

> Any reasons not to close the bug report?

You can close it if you like.  I would prefer that we think about
handling the same category of char-inserting keys (punctuation and
symbols) for other keyboards the same way we handle those for US
keyboards.  But if that is not to be then it is not to be.

Thanks for working on this.