Re: HTML-Info design

[Eli Zaretskii]

> From: Nic Ferrier <address@hidden>
> Date: Mon, 22 Dec 2014 10:36:11 +0000
> Cc: address@hidden, address@hidden
> 
> > Yes.  There are several browser+Javascript-based presentation packages
> > (for example, S5) that do exactly that.  It's easy to do with simple
> > HTML and a tiny bit of CSS,  and only a few lines of Javascript per
> > "primitive" navigation function (eg, "next" and "last").  Whether you
> > could get acceptable appearance and performance, and how much effort
> > that would take, I don't know.  I would guess it's not that hard.
> 
> This is what my app does:
> 
>   http://gnudoc.ferrier.me.uk
> 
> it implements indexing (press i) and toc and all of that.

Thanks.  Please allow me some comments:

  . The initial display of the top-level menu is annoyingly slow.  For
    a few seconds there I thought it didn't work, then suddenly the
    menu appeared in its entirety.

  . There's no help, at least AFAICS.  Neither h nor ?  display
    anything.  The only instructions I found are in the README on the
    Github page.

  . With IE 11, typing i opens the "minibuffer" area, but doesn't show
    the "Index topic" prompt.  (Same behavior with the menu prompt.)
    Firefox does show the prompt, but there's no colon ":" and no
    space between the prompt and the cursor -- not sure if this is a
    display problem or a JS problem.

  . Typing i or m in my locale puts the cursor at the right edge of
    the window (both in Firefox v34.0 and IE 11.0.9600 on Windows 7).
    Please force the browser to use the left-to-right base paragraph
    direction, independent of the locale (that's what Emacs does with
    minibuffer prompts and input).

  . Looks like index entries are matched exactly (except for the
    letter-case), as opposed to substring matches in Info.  E.g.,
    "i display RET" takes me to http://gnudoc.ferrier.me.uk/undefined.
    Consequently, the "," key in Info has no equivalent.  This makes
    index searches much less efficient than they are in Info.

  . Typing m followed by something exhibits unexpected completion
    behavior: TAB has no effect, whereas typing enough of the menu
    item to make it unambiguous automatically completes.  Is this the
    intended behavior?  If so, why the difference from completion
    implemented for the i command?

  . Repeated i and m keypresses start with the last value I typed,
    which is not useful, and requires to always delete that.

  . A question: does i work in a manual with more than 1 index node,
    like the Emacs User manual (which has 5 index nodes)?

  . Navigation keys (n, p, u, l) are not implemented, or don't work.
    Likewise with s (regular expression search through the entire
    manual).

  . Links to footnotes don't work.  E.g., clicking on "1" on the 15th
    line in "Using 'interactive'"
    (http://gnudoc.ferrier.me.uk/info/Using-Interactive.html#Using-Interactive)
    takes me to the top-level menu instead, although the footnote is
    shown at the bottom of the "Using 'interactive'" section.

  . Info mode currently has a lot of useful features besides basic
    navigation, index-search, and cross-reference following, like
    "virtual index", info-apropos, etc.  These will have to be
    implemented or migrated to this kind of solution.

  . Summary: OK as a POC, but IMO more work is needed to make sure a
    functional equivalent of the Info reader is indeed feasible and
    practical with this technology.

Once again, thanks for working on this.