From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Mon, 20 Jul 2009 01:58:41 +0200 Message-ID: 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; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1248047945 30602 80.91.229.12 (19 Jul 2009 23:59:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jul 2009 23:59:05 +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: Thomas Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 20 01:58:56 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 1MSgHP-0006gk-6j for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 01:58:55 +0200 Original-Received: from localhost ([127.0.0.1]:42089 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSgHO-0003WP-IE for ged-emacs-devel@m.gmane.org; Sun, 19 Jul 2009 19:58:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MSgHK-0003Vv-5a for emacs-devel@gnu.org; Sun, 19 Jul 2009 19:58:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MSgHF-0003TI-Bt for emacs-devel@gnu.org; Sun, 19 Jul 2009 19:58:49 -0400 Original-Received: from [199.232.76.173] (port=36982 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSgHF-0003T6-79 for emacs-devel@gnu.org; Sun, 19 Jul 2009 19:58:45 -0400 Original-Received: from mail-bw0-f219.google.com ([209.85.218.219]:38211) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MSgHD-0008LJ-6q; Sun, 19 Jul 2009 19:58:43 -0400 Original-Received: by bwz19 with SMTP id 19so2113918bwz.42 for ; Sun, 19 Jul 2009 16:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1srOZWamoRQVQTsrGpMf7dB3HrCSzeUdPR/4FO2Io80=; b=Ru396/zRDirScBvr7HbWYJoJ+EvgSCw41EYcdS+gcSKcxql/7PHq0cixsCubnbSGtN VMulRjp7XQO+0+XI6X7GdHKB/Hu1YLI7NPCiXtrDqCfPE+NzUR3dKpRvy7uwI3EM2IS4 p90SDEN3ikRI6lV0iYiQfZgqWil9zgIC31hUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FCdAyIi5lyR8WihNJfkHud2ZfTLtf/GjvZCIy44+2zYf0wRmHBl4bE+ly8LS7A5UjT gLssk41GXJ5cdHDtxHzi299tizzs/tlm/bYA/vqa+KYqDOKaZXmcFWAoXyhg5NEPQXu6 dJfa6+wippILl8R3VY3qxSMSZriAo/7CTXWpw= Original-Received: by 10.223.120.67 with SMTP id c3mr930779far.15.1248047921771; Sun, 19 Jul 2009 16:58:41 -0700 (PDT) In-Reply-To: <1248042089.6319.42.camel@dell-desktop.example.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:112795 Archived-At: 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. =C2=A0A "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".