From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gavin Smith Subject: Re: Any interest in using HTML for locally-installed Texinfo documentation? Date: Tue, 2 Apr 2019 16:02:45 +0100 Message-ID: <20190402150245.GA30067@darkstar> References: <87a7h8u4r4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <87a7h8u4r4.fsf@gnu.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-texinfo-bounces+gnu-bug-texinfo2=m.gmane.org@gnu.org Sender: "bug-texinfo" To: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: guix-devel@gnu.org, Texinfo List-Id: guix-devel.gnu.org On Tue, Apr 02, 2019 at 11:37:51AM +0200, Ludovic Courtès wrote: > (For some reason ‘i’ does open the index search box for me, but then > hitting enter doesn’t produce any effect. The other navigation commands > work fine, though.) It works on Firefox 53, at least. > Yet I’m not completely sold to the everything in the browser approach, > and everything in JavaScript. In an ideal world (for me), we’d rather > provide a local documentation viewer that renders Texinfo directly. > TTN’s IXIN experiment was a step in the right direction IMO, but I > understand this approach is not something that’s happening now. To my knowledge, no program has ever been produced that does anything useful with IXIN. Using JavaScript within a web browser has big drawbacks due to its "sandboxed" nature. (You can't access environment variables, for example.) However, we'd want to avoid having to re-implement too much of the web browser; for example, input file parsing, text layout and font rendering. One thought is that there may be other "layout engines" that could be used, such as those in various GUI toolkits. > When talking about ease of access, we can’t ignore keyword searches. > How would you do ‘info -k’? I don't know. You would have to have some way of finding all the installed manuals. This may be difficult with a standard web browser due to security restrictions. > How would you even simply point your > browser to a specific manual? Maybe there could be a command for this within the browser. There could also be a command-line program that would launch the documentation browser. > What about inter-manual cross-references? > Would we need a mechanism similar to ‘htmlxref.cnf’ but that would > browse local manuals? Good question. The inter-manual links in locally-installed HTML files would have to be recognizable. They could look like Texinfo instead of Texinfo as there were would no way of resolving the second link to a locally-installed file (it is not clear from the URL what the name of the manual even is). It would be quite simple to get texi2any to output this instead. (It can currently be done by passing '-c HTMLXREF=empty' where 'empty' is an empty file, but a better interface could be devised.) Then inter-manual links would all work, assuming the installed manuals are all subdirectories of the same directory (e.g. /usr/share/info/html). This doesn't address the issue of multiple installed versions of the same manual or manuals in different "prefix hierarchies". I imagine the Info browser would interpret the "../" string specially in a link and go looking through a search path for the referenced manual. Again, this may be difficult to implement in standard web browsers due to security restrictions. > What would be the recommended solution for Emacs > and console users? Info files would carry on as an option. I'm getting the feeling that we need a web browser, or something like it, which can integrate with the operating system a lot more, without sandboxing or security restrictions.