emacs-devel
[Top][All Lists]
Advanced

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

Re: Shall menu_bar_items and tool_bar_items look at text property keymap


From: Kim F. Storm
Subject: Re: Shall menu_bar_items and tool_bar_items look at text property keymaps?
Date: 15 Feb 2002 12:39:45 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50

Richard Stallman <address@hidden> writes:

>     Since it doesn't really work, I doubt anyone is actually using it.
> 
>     So my proposal is to remove the "look for keymaps at PT" from those
>     functions.
> 
> Why change this at all?  Is there a bug that needs fixing here?
> If so, what is it?

It is a bug: If a programmer puts a menu-bar or tool-bar binding into
a keymap or local-map text property, that will not work realiable.

Instead of trying to make it work (which will involve a severe performance
penalty), I suggest to remove the code and document in the Elisp manual
that those text property maps don't support menu-bar and tool-bar bindings.

In the specific situation, I was investigating how to add a new type
of keymap (details may follow later :-) when I stumbled across the
(seemingly) bogus code in keyboard.c.  So I decided to ask my fellow
developers whether that code was really needed -- or it could be
removed -- to simplify the task of adding the new type of keymap - in
which case I could just remove the bogus code instead of adding more
(bogus) code.


> 
> I'm concerned because Emacs developers are putting a large fraction of
> their time into areas that are attractive for programmers to work on,
> but not a large fraction into areas that really help users.  We need
> to shift the effort to places where it will make Emacs more
> powerful or more convenient or easier to learn and use.

I know you regularly express this concern, and I fully agree with you!
There is no need to spend time on features which are not visible to
the user.  

However, I feel that this concern sometimes is used to reject changes
to the "core" emacs that would subsequently make it *significantly*
easier (for the programmer) to write packages which *does* make emacs
better (for the user) in the ways you express above.

And with emacs, a lisp package programmer (like me) is also a user!

-- 
Kim F. Storm <address@hidden> http://www.cua.dk




reply via email to

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