From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: [drew.adams@oracle.com: RE: cannot find :enable inElispmanualindex] Date: Wed, 6 Jun 2007 08:06:01 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1181142462 16960 80.91.229.12 (6 Jun 2007 15:07:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Jun 2007 15:07:42 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 06 17:07:40 2007 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 1Hvx6o-0004VY-2x for ged-emacs-devel@m.gmane.org; Wed, 06 Jun 2007 17:07:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hvx6n-000427-Gl for ged-emacs-devel@m.gmane.org; Wed, 06 Jun 2007 11:07:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hvx6j-0003yE-8P for emacs-devel@gnu.org; Wed, 06 Jun 2007 11:07:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hvx6h-0003un-K0 for emacs-devel@gnu.org; Wed, 06 Jun 2007 11:07:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hvx6h-0003uk-C3 for emacs-devel@gnu.org; Wed, 06 Jun 2007 11:07:31 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Hvx6g-0000fL-SC for emacs-devel@gnu.org; Wed, 06 Jun 2007 11:07:31 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l56F7RuZ024744 for ; Wed, 6 Jun 2007 10:07:28 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l56D2uwR014287 for ; Wed, 6 Jun 2007 09:07:26 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by acsmt351.oracle.com with ESMTP id 2830458481181142361; Wed, 06 Jun 2007 08:06:01 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 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:72344 Archived-At: I wrote: > HTML without some indication of key bindings provides no > particular support > for keybindings. If the standard Emacs bindings (`i', for instance) were > specified in the HTML code as `accesskey' attributes, then browsers would > still be able to ignore them or do whatever else they like, but at least a > browser that supports `accesskey' would, without doing anything special, > provide user support for the standard Emacs Info bindings. > > I don't know anything about `accesskey' besides what I read during a few > minutes of googling. In particular, I don't know which browsers might > support it. But it seems to be a standard HTML way to indicate key-binding > suggestions to a browser - in particular for links. > > In our case, putting or href="an-xref#foo.html" accesskey="f"> or would presumably be a simple way to indicate to an > accesskey-enabled browser to support `i', `f', and `u' for those three > links, respectively. > > If the new Info browser itself was accesskey-enabled, then we would be > killing two birds with one stone. Anyway, it's just an idea that might be > worth exploring. I realized, walking to work after writing that, that some of what I wrote above is nonsense. Presumably, `accesskey' can only work when the key is unique for the HTML page (in our case, Info node). So (IIUC), `accesskey' could work for `u', `n', `p', `1', `2', etc. (menu items), but not for `i' or `f' (`i' is not even a link!). I wasn't thinking of `accesskey' for `i' originally anyway, but I got carried away above. In my original mention of `accesskey', I separated it from treatment of `i' and `s'. This is what I suggested: > there are at least two possibilities: > > 1. design and implement a replacement for Info that is based > on (X)HTML > > 2. add ways for standard Web browsers to take advantage of > features that Info has, beyond clicking links: index > search and other cross-page searches, keyboard access > to follow links (e.g. HTML `accesskey' attribute) > > If some thought is given to #2 when thinking about #1, then #1 can perhaps > benefit from some of the same implementation. Sorry for muddying the waters.