emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On being web-friendly and why info must die


From: chad
Subject: Re: On being web-friendly and why info must die
Date: Sat, 13 Dec 2014 13:14:44 -0800

> On 12 Dec 2014, at 17:47, Richard Stallman <address@hidden> wrote:
> 
>> http://www.w3.org/Talks/Tools/Slidy2/#%281%29
> 
>> This implements next and previous buttons like info.
> 
> Do you have to click on the buttons to use them?  If so, that is not as
> convenient as the Info reader, with its n and p commands.

No, the mouse is not required in any way. 

The package is designed to work like presentation programs, rather
than info, so its key-bindings are different, but theyre no less
functional. The second page of that presentation includes this text:

* Advance to next slide with mouse click, space bar or swipe left
* Move forward/backward between slides with Cursor Left, Cursor 
  Right, Pg Up and Pg Dn keys, or swipe left or right
* Home key for first slide, End key for last slide
* The "C" key for an automatically generated table of contents, or 
  click on "contents" on the toolbar or swipe up or down
* Function F11 to go full screen and back
* The "F" key toggles the display of the footer
* The "A" key toggles display of current vs all slides
* Switching off JavaScript reveals all slides

> I don't think any general web browser could give the convenience of
> Info.  The Info-style n and p commands (and others) don't belong in a
> general web browser.

Web browsers *that can run javascript* are far more capable (in
terms of available functionality) than info browsers other than
emacs, and have been for a while now. By way of example, someone
recently posted a link to a page that runs a PC emulator and boots
a unix kernel, using only the web browser's functionality. Making
a general web browser of the sort that is considered baseline
functionality these days do everything that the info browser needs
to do is not at all hard from a technical standpoint; the harder
part is getting the information that the program needs in a way
that is convenient (particularly in time and mental effort) the
documentation-writers want is a harder concern.

This sort of functionality uses client-side javascript, which is
something of a concern. That's a separate problem worth addressing,
but seems likely to be a distraction from the current topic. If
client-side javascript is a deal-breaker for this topic, I suggest
that you just declare it so and move on.

I hope that helps,
~Chad






reply via email to

[Prev in Thread] Current Thread [Next in Thread]