Re: Emacs User Friendliness Question/Hope

[Óscar Fuentes]

Miles Bader <address@hidden> writes:

> Christoph <address@hidden> writes:
>> In order to help increasing the "user-friendliness" couldn't we do
>> something similar to what viper-mode does? I.e. provide different levels
>> of "Emacs-ness".
>>
>> The lowest level (default?) could enable features that are common among
>> other editors/IDEs, e.g. CUA. Increasing levels could "unlock" more and
>> more "Emacs-ness" up to the point of where you get what everybody would
>> consider the "true" Emacs in all its glory.
>
> You'd have to be much more specific.
>
> This seems like the sort of idea that's attractive when stated vaguely
> with lots of hand-waving, but would be very hard to actually make work
> in practice.
>
> What "levels" would there be, exactly?  What bindings would be different
> in each level?  How would you avoid conflicts between "traditional"
> Emacs bindings and CUA bindings?  How would your scheme work in the
> presence of 3rd-party packages?  Would your scheme discourage people
> from learning Emacs bindings?
>
> As I mentioned in a previous message on this thread, cua-mode, which has
> fairly limited goals, has to use extremely kludgey methods to achieve
> them.  Something considerably more elaborate would probably have an even
> harder time.

I possible solution for this problem is to use `actions'. An action is a
generic concept like `fordward-line', or `undo', or `save', or `yank'
(`paste', if you prefer.)  `universal-argument',
`execute-extended-command' and `C-x' (whatever is officially called on
Emacs jargon) would be actions as well.

Currently a mode defines its keymap relating keys to functions. An
action-aware mode relates actions to functions. At a higher level, there
is a mapping of keys into actions. When a mode is activated for a
buffer, the keymap is constructed looking up the corresponding keys
assigned to the actions the mode implements. A mode inherits the
key->action mapping from its parent mode, but can define its own actions
that overrides its parent's.

The legacy code that defines keymaps keeps working. local-set-key keeps
working as well. There could be a "classic-emacs" key->action mapping, a
"cua" one, etc. Of course those mappings could collide with some keymaps
defined on legacy code, but nothing is perfect, and Emacs could inform
the user about that circumstance when the legacy keymap is activated.

This can be extended to menus and buttons on the toolbar, so a button
that implements an action is useful for all modes that support that
action.