ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
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?

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