[Top][All Lists]
[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