Re: Have you all gone crazy? Was: On being web-friendly and why info must die

[Yuri Khan]

On Mon, Dec 22, 2014 at 9:43 PM, Eli Zaretskii <address@hidden> wrote:

>> I use Google to search for information about Emacs, unless I know
>> exactly what I’m looking for.
>
> That's a mistake.  The Info's 'i' command is precisely the means to
> use when you do NOT know exactly what you are looking for.  I urge you
> to try that next time: at 'i's prompt type some word or phrase that
> you think relates to the subject you are after, and see what happens.

This is limited to the features that are currently installed. The
question “how do I do X” does not always mean “how do I do X using
features I already have installed” — rather frequently it means “what
can I install in order to do X”.

> The Info manuals are indexed up front with this usage pattern in mind,
> and you'd be surprised how efficient this search can be.  Well, with
> good manuals, anyway.  (Emacs manuals are good.)  We add index entries
> all the time to continuously improve the indexing.

What good is an efficient search facility if it is limited to good manuals?

I program in several languages, not only and not primarily Elisp. I
want to have a single search habit which works for all languages,
libraries and tools that I use. Typing “gg <tool name> <feature>” into
my Firefox’s address bar gives me that. Info, only if the relevant
Info manuals exist, are installed and contain the information I want.

I come from Windows background and I used to be used to well-indexed
MSDN Library manuals. (This was before they replaced their hand-made
indexes with machine-generated crap.) I know the value of a good index
and I miss them. But unless all tools I need to use come with Info
manuals, I will still have to search the Web.

> I encourage you (or anyone else) to enhance info.el, which will remove
> or hide the newlines from the explanatory text, and then use word-wrap
> and wrap-prefix to get the same effect as you see in HTML browsers.
> (Not that I understand why it would be more readable to have the
> description in 200-column lines, but if someone wants such a feature,
> why not?)  The only not-entirely-trivial part here is to identify the
> lines where the newlines should be kept, like examples, list items,
> etc.  But there are enough clues in the text to identify those, in the
> same manner as we identify the section headings.

You are suggesting that I solve a backward problem — inferring
structure given a hard-wrapped text rendition. And, as much as I can
infer without reading the Info source, it’s all like that — first
render to an unparseable format, then heuristically infer structure.
Why do that when it’s possible to just not lose structural information
at all?

And, where do you get that mythical 200-column width? A 24" display
accommodates two side-by-side frames, 100 columns each.

>> * The HTML version uses my preferred proportional font for prose and
>> my preferred monospace font for code. The Info version is monospace
>> throughout, except for headings.
>
> Likewise: should be easy to do this for Info.  Patches are welcome.

I might do that *if* Info were sufficiently better for me than
Google-indexed HTML. As it stands, it is not.

>> * The HTML version uses text styles to highlight different kinds of
>> text (keys, commands, paths, arguments, etc.). The Info version uses
>> the spacing grave accent and the straight single quote and all-caps
>> formatting.
>> * The HTML version uses typographic quotes “”. The Info version uses
>> straight quotes "".
>
> Some of this is simply untrue nowadays, I guess you haven't looked at
> an Info manual for a few years.

Emacs manual, emacs24-common-non-dfsg 24.3+1-1 as packaged in Ubuntu
Trusty on 2013-04-13. Ok, maybe it’s ancient; I don’t know.

>> To summarize the above, the HTML version “feels like” an electronic
>> version of a well-typeset printed book. The Info version feels like an
>> electronic version of a samizdat book typed on a typewriter.
>> *Readability counts.*
>
> If this is an itch to scratch, I invite you and others to scratch it.
> Should be a fine project, and not a hard one, either.  Volunteers are
> welcome.

I see no reason to. Improving the HTML output to support indexes is a
much more productive goal.

>> no autoscrolling
>
> Not sure what that means.  Emacs certainly auto-scrolls when point
> enters the scroll-margin.

In browser parlance, “autoscrolling” means that you can press the
middle mouse button and the content starts to scroll.

It comes in two minor variations.

* You can press and release, then a circle appears around the point
where you middle-clicked, and as soon as you move the mouse outside
this circle, the content starts to scroll at a constant speed in the
direction where you moved the mouse. Move it farther, and it scrolls
faster. Move it closer, and it scrolls slower. Move it back inside the
circle, and it stops but is ready to start scrolling again if you move
outside. Middle-click again to stop.

* Or, you can press and hold. Then it works the same way as described
above, except that releasing the middle button exits the scroll mode.

It’s somewhat similar to wheel scrolling but different.

> As was written many times here, HTML-Info browser you are talking
> about doesn't exist.  It needs to be coded first.  Existing HTML
> browsers lack a few important features, they were identified in these
> discussions.

Works for me, except for the wonderful hand-crafted indexes.


> Btw, if you, or someone else, are ambitious, I can suggest a larger
> and more challenging project: add a front end to Info's search
> capabilities that can accept queries in more-or-less natural language,
> not unlike Google.  Examples of such queries:
>
>   . "how do I do SOMETHING?"
>   . "what is THAT-THING?"
>   . "look for SUBJECT but excluding THIS-CRAP"
>
> etc.  Bonus points for maintaining a database of user-specific
> preferences and personal style of queries, and applying that to future
> queries.
>
> Interested?

Might be a good research project for a candidate dissertation in
linguistics/programming. Requires much more time than I’m prepared to
invest; sorry.