emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs learning curve


From: Teemu Likonen
Subject: Re: Emacs learning curve
Date: Sun, 18 Jul 2010 22:21:18 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2.50 (gnu/linux)

* 2010-07-18 22:00 (+0900), Stephen J. Turnbull wrote:

> Teemu Likonen writes:
>> But do we agree that using substitute-key-definition with reference
>> to global-map is bad and should be replaced with command remapping
>> (see above)?
>
> No. I think you'll find that it's not used as frequently as you think.

I already did "M-x rgrep" on emacs.git/lisp directory before posting
anything about the function.

> Many commands that *should* do slightly different things in different
> modes already *do* do those things in the different modes, by virtue
> of hooks in the commands. If you rebind the command to a different
> key, all the mode-dependent behavior goes with it. I just don't think
> this is the root of the problem. And even if it is, I think the right
> way to handle it is to make the command itself configurable.
>
> The problem is when modes bind completely different functions to the
> keys. If you decide to rearrange the mappings of core commands, users
> of such mode will lose.

But

    (define-key MAP [remap next-line] 'new-next-line)

is great, though.

I dreamed that Emacs had such abstraction that user could redefine
global keyboard bindings and it would be nice and usable throughout the
system. In particular I was interested in only one user: me. But never
mind, it was naïve and I no longer have that dream. I realized that,
even though redefining individual keys is simple, some of the default
bindings still exist conceptually everywhere in different major modes.
I'm not that motivated to redesign modes too because that's what it
takes to maintain consistency. Heavy keyboard customization just isn't
practically possible.

So, I'll just continue to use the default keys with the knowledge that,
although they are not the most ergonomic and fast for text editing, at
least they are quite consistent throughout the Emacs system, even the
GNU system.

Now let's move on. What's the next purely academic discussion we should
have here on emacs-devel? :-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]