Re: Key sequence C-c C-f C-e uses invalid prefix characters

[Karl Eichwalder]

"Stefan Monnier" <monnier+gnu/emacs/address@hidden> writes:

>> In any case, this would be easy to fix in psgml.el (is anyone listening ?):
>> just be sure to unbind (define-key ... nil) all of the C-c C-? prefixes in
>> sgml-mode-map before (re)using them as prefix keys later on.  Better do this
>> on too many keys than too few.
>
> First, I simply think that define-key should not fail in the above
> way at all (i.e. rebinding an existing prefix key to a command,
> thus turning a prefix key into a non-prefix key, should work just fine
> because it is a perfectly acceptable operation).

AFAIK (21.2), define-key still isn't able to rebind an existing prefix
key; at least I failed to load psgml when sgml-mode coming with Emacs
was loaded first (the problem was brought to my attention by Martin
Vidner, thanks!).  I don't know whether that's a bug or a feature;
problably a feature since the Elisp manual says:

     Every prefix of KEY must be a prefix key (i.e., bound to a keymap)
     or undefined; otherwise an error is signaled.  If some prefix of
     KEY is undefined, then `define-key' defines it as a prefix key so
     that the rest of KEY can be defined as specified.

My emacs lisp skills are limited, but I'd like to sort out this
problem; Stefan made these proposals to fix the problem in a sane
manner:

> Other ways to fix the problem:
> - Use `psgml-' as prefix rather than `sgml-' so that the two packages can
>   coexist peacefully.
> - Explicitly (unload-feature 'sgml-mode) at the beginning of psgml's code.

The second proposal looks rather heavy, but easy to implement.  I guess
some users won't like it, since they might want to make use of the HTML
support provided by sgml-mode.

The first way would mean you will have to change all the files all over
and in the end user customizations will be broken and all users will get
used to new commands: M-x psgml-... instead of M-x sgml-... 

What do you think?  Especially what's your position on this issue,
Lennart?  By all means we must avoid a fork!

-- 
address@hidden (work) / address@hidden (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)