emacs-devel
[Top][All Lists]
Advanced

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

Re: Infrastructural complexity.


From: Lennart Borgman
Subject: Re: Infrastructural complexity.
Date: Mon, 20 Jul 2009 01:58:41 +0200

On Mon, Jul 20, 2009 at 12:21 AM, Thomas Lord<address@hidden> wrote:

>> That sounds very similar to M-x tmm-menubar. It seems to lack a
>> feature to back up though.

Sounds like a bug.


> A big difference is that a tmm-menubar menu is a
> buffer.  A "virtual input device" of the same idea
> is not a buffer

Why not? Couldn't there be several "virtual input devices?".

Of course, a virtual input device corresponding to the default dito on
the platform is very important.


> Choosing an item off of a virtual input device
> hierarchical menu should produce a synthetic
> input event, such as [CMD-MENU FIND-FILE].
>
> That would not directly call "find-file" it would
> go through the usual keymap process to find the
> binding for [CMD-MENU FIND-FILE].

Can't that kind of abstraction be reach on different routes? For
example could tmm look for a flag from C-h k (and other things, of
course) telling it what to do at the end.

I do not think the abstraction is impossible in the current Emacs
structure. But there could surely be a general mechanism for this.
This could just consist of:

- Setting a flag at "virtual input device" start tellinng it how to
treat input in the end.
- And of course the "virtual input device" should check that at the end...
- ... and more... the help function must understand this structure...


> For example, suppose I type C-h k
>
> Next, I pick a menu item off of the command menu.
>
> I should see the doc string for the command
> that would be invoked had I not typed C-h k first.
>
> In tmm-mode, instead, I get the documentation
> string for "tmm-shortcut".




reply via email to

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