From: "Jérôme Laurens" <jerome.laurens@u-bourgogne.fr>
Subject: What about dynamic documentation?
Date: Tue, 6 Dec 2005 14:19:53 +0100 [thread overview]
Message-ID: <1bbbbe0f95e365f76129a09c0e9f2841@u-bourgogne.fr> (raw)
Hi all,
Is is extremely useful for a newbie as I am to have access to the
manuals electronically.
You just open the pdf and search to obtain what you need.
In general, you end up with a command that you have to copy from the
pdf then paste to your source file.
Another solution is to use the text editor completion feature, which is
available only once you know the correct command name, at least the
beginning...
What I am missing is a button in the pdf itself that would
automagically insert the proper code in my source.
To be more concrete, here is what could be done (on Mac OS X at least).
0 - Define a data model.
1 - For a reasonnable set of commands, define dedicated GUIs panels.
2 - Write a dedicated browser
As there is a huge amount of "reasonnable" TeX and ConTeXt commands, it
is -not- reasonnable to fine tune a dedicated GUI for each one.
But with some perl I think it would be possible to turn for example the
Quick References Manuals into a set of xml files, each one dedicated to
its own command. If these files are just HTML forms (modulo the proper
style and automagic filter), we have the GUI for free using a web
browser. The communication between the browser and the text editor
could come from SUBMIT. At least a "copy/paste" phase would be enough.
I already have a custom web browser that can insert some text directly
in a text editor (iTeXMac) It is based on Mac OS X WebKit.
Which means that I will incorporate this browser directly into iTM, but
this not the question so far.
All this makes points 1 and 2 above acceptable IMHO.
The problems come from point 0.
I think a good thing would be to create a subsection of the context
garden, or another wiki, gathering all the sources.
The seed would come from the actual documentation with automagic
scripts and people would update at will.
Then people would be able to work on a local version using a web sucker.
We can imagine searching facilities as well
BTW, Sometimes it is necessary to have some output to understand the
real effect of a command. This should enter into consideration.
How does it sound?
next reply other threads:[~2005-12-06 13:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-06 13:19 Jérôme Laurens [this message]
2005-12-06 13:59 ` Taco Hoekwater
2005-12-06 14:26 ` Adam Lindsay
2005-12-16 7:31 ` Jérôme Laurens
2005-12-16 19:56 ` Taco Hoekwater
2005-12-16 23:12 ` Patrick Gundlach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1bbbbe0f95e365f76129a09c0e9f2841@u-bourgogne.fr \
--to=jerome.laurens@u-bourgogne.fr \
--cc=ntg-context@ntg.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).