From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Sun, 19 Jul 2009 17:50:27 -0700 Message-ID: <1248051027.6319.92.camel@dell-desktop.example.com> References: <20090712180623.GA1009@muc.de> <1247871746.6287.157.camel@dell-desktop.example.com> <87tz19efhy.fsf@mail.jurta.org> <87vdlo5xzi.fsf@mail.jurta.org> <1248034719.6319.15.camel@dell-desktop.example.com> <7dbe73ed0907191456o5139ebaq346c050a075b72f4@mail.gmail.com> <1248042089.6319.42.camel@dell-desktop.example.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248051050 3429 80.91.229.12 (20 Jul 2009 00:50:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jul 2009 00:50:50 +0000 (UTC) Cc: rms@gnu.org, cyd@stupidchicken.com, joakim@verona.se, emacs-devel@gnu.org, Juri Linkov , rudalics@gmx.at, monnier@iro.umontreal.ca, acm@muc.de, drew.adams@oracle.com, Mathias Dahl To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 20 02:50:42 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MSh5V-000120-Lz for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 02:50:42 +0200 Original-Received: from localhost ([127.0.0.1]:41262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSh5V-0006Zn-5j for ged-emacs-devel@m.gmane.org; Sun, 19 Jul 2009 20:50:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MSh5Q-0006WZ-Fy for emacs-devel@gnu.org; Sun, 19 Jul 2009 20:50:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MSh5K-0006Lw-PW for emacs-devel@gnu.org; Sun, 19 Jul 2009 20:50:35 -0400 Original-Received: from [199.232.76.173] (port=45500 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSh5K-0006Lt-J8 for emacs-devel@gnu.org; Sun, 19 Jul 2009 20:50:30 -0400 Original-Received: from smtp191.dfw.emailsrvr.com ([67.192.241.191]:45073) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MSh5J-0007ry-Ud for emacs-devel@gnu.org; Sun, 19 Jul 2009 20:50:30 -0400 Original-Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id BB53613D31D7; Sun, 19 Jul 2009 20:50:28 -0400 (EDT) Original-Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 59A0213D31D4; Sun, 19 Jul 2009 20:50:27 -0400 (EDT) In-Reply-To: X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:112800 Archived-At: On Mon, 2009-07-20 at 01:58 +0200, Lennart Borgman wrote: > On Mon, Jul 20, 2009 at 12:21 AM, Thomas Lord 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