RE: address@hidden: RE: cannot find :enable inElispmanualindex]

[Drew Adams]

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 <A href="an-entry#index.html" accesskey="i"> or <A
> href="an-xref#foo.html" accesskey="f"> or <A href="an-uplink#foo.html
> accesskey="u"> 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.