Re: HTML-Info design

[Nic Ferrier]

Eli Zaretskii <address@hidden> writes:

>> > 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:

Thanks for your comments. I've tried to respond. I'm conscious it could
sound a bit rude. It's not meant to be, it's just a statement or
explanation of where I am with it.


>   . 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.

Yes, it's pulled down from the GNU HTML manuals online. So a proxy call
basically. I've been slowly working on a better way (a direct way) of
delivering the content. That's a relatively difficult logistics job. A
matter of building everyone's documentation and putting it in a place.


>   . 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.

Probably not. I did enough to show it could be done. I didn't implement
*everything* from help.


>   . 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.

I never test with IE 11. So I'm sure there are a lot of problems.


>   . 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).

No. Or maybe not. The point for me was not to slavishly implement Info
but to show that the same interactive experience could be achieved. I
tried it the way Info does it and it didn't feel or look right to
me. But then I have very little feedback right now. Some of it was in
direct contravention to what you just said. So I'm not saying it's right
the way it is now. This is an advantage of webapps, you can get that
feedback.


>   . 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.

That's right. Fuzzy matching wasn't implemented yet.


>   . 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?

That's right. It's clear that it could be implemented. But I didn't do
it yet. It certainly offers more completion than the existing GNU HTML
manuals.


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

Again, that's a decision I'm not prepared to listen to much definitive
thought on right now.


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

It could do. The index nodes are understood as 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).

The former aren't implemented and maybe I never will... the point is not
to implement info in HTML/JS but to implement everything that info can do
in HTML/JS.

The latter could be implemented. It's quite a bit more work and requires
the logistics to be done. I can't do it with a proxy connection as now.


>   . 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.

Didn't even test it.


>   . 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.

You're wrong. This POC is proof that an info reader is feasible. Nothing
you have pointed as it substantive except search and we absolutely know
that could be done.

This has not moved only because:

1. the next obvious massively beneficial step is a difficult and time
consuming one - to generate the info for all the manuals because a proxy
is not scalable

2. no one else is helping, despite many people being excited about
it. Hey what's new?



> Once again, thanks for working on this.

I work on what I work on.


Nic