Re: Infrastructural complexity.

[Thomas Lord]

On Mon, 2009-07-20 at 01:58 +0200, Lennart Borgman wrote:
> 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?".


There are.  Hmm.   This isn't complicated but I seem
to have caused confusion - my bad and let me try to fix
it.

Emacs windows, menu bars, menu bars, the minibuffer
area - all of these things are "virtual i/o devices".
Each corresponds very directly to a set of pixels on
the screen.  Each implies its own set of rules for translating
associated window system input events into command loop
events.

Buffers, on the other hand, are abstract things (and,
obviously a core abstraction for what Emacs does).  Multiple
windows (virtual i/o devices) can be set so that they are
displaying the same buffer.  The window is the virtual i/o 
device, the buffer is like a "model" to that "view". 

So my suggestion about a hierarchical command menus is
to make a new kind of virtual i/o device.  There are windows
and menu bars and mode lines -- and this suggestion is to 
add, parallel to those, command menu areas.

Windows are virtual i/o devices that happen to display
buffers.  So, one notion is: shouldn't a command menu area
just be a window?  The command menu could then be defined
as the contents of a buffer.

And, I'm suggesting, no, windows aren't quite right
for that.  Windows are far more general than the use
case of a command menu calls for.  User's can kill the 
buffer underlying a window but they shouldn't be able to
kill the data a command menu displays the same way, for 
example.

Menu bars are an example of a virtual i/o device that
displays keymap data, not buffer data, and that treats input
differently from inputs to a buffer window.  I'm suggesting
that command menus should be more like that.

There are four, popular, commonly implemented, and nifty
UI elements:  menus, toolbars, "command menus" like those
old PC programs, and, now that I think about it, tabs.

All of those have in common that the user would use
them to generate command loop events: [MENU foo], [CMD-MENU bar],
[TAB xyzzy], and so forth.   Three of them, menus, tool bars,
and those hierarchical command menus are essentially displaying
keymaps.  Mode lines display various buffer variables, suitably
interpreted.   These can (usefully) all be unified as a single
abstraction with a few parameters that control their differences.





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

"dito"?


> > 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.

Well, that's kind of messy.  For example, in a tmm menu now
you say C-h k f because the menu says "f" is something about
files.  The legacy, and perfectly sufficient command loop logic
and keymap logic leads you to the doc string for tmm-shortcut,
not the the thing you are looking for.

You are really talking about mucking with that that command
loop and keymap logic which is not something to do for such
an ad hoc purpose.  It's too central to the architecture.



> 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...
> 


Ok, why aren't keymaps buffers?

If keymaps were buffers than menu bars would
be windows, rather than something distinct from
windows.

I imagine one could make an Emacs-like program in
which menu bars are windows and keymaps are buffers.
That's a radical architectural change from what 
GNU Emacs is, however.

-t