sxemacs-devel
[Top] [All Lists]

Re: Issue Trackers - What do we want [And sexy docs]

From: Johann Gunnar Oskarsson <johann@xxxxxxxxxxxxxx>
Subject: Re: Issue Trackers - What do we want [And sexy docs]
Date: Mon, 16 Aug 2004 19:53:48 +0000
Cc: SXEmacs Devel List <sxemacs-devel@xxxxxxxxxxx>
Hi,

heat sink writes:
 > I think this could easily be a web-service.  We'd have a dedicated
 > server that takes care of all of the login information for bugzilla. 
 > And then we'd have a standalone front-end and a built-in (in SXemacs)
 > front-end to the service.  We basically facade or abstract all of that
 > nasty bugzilla information from the user when he/she submits a bug
 > report.  This also allows us to pipe that bug submition not only to
 > bugzilla via the server backend, but also allows us to pipe it out to
 > everyone, respond to the user, and even if we make it smart enough
 > parse the bug report and send it to certain members of the team for
 > resolution.

 > Now the question remains.....how does lisp become web-service savvy. 
 > I highly doubt anyone has written a web-service library for it.  So my
 > next question would be can lisp access shared object libraries?  I'm
 > sure it can i'm just wondering how much of a boogle that would be on
 > performance.

Well, there *is* the DSO (dynamic shared object) support in XE and
using it to implement something like a web browser has just ... not
been done yet.

The *could* be done with the following recipy:

Paste the w3m C code into the DSO file.

Rewrite parts of emacs-w3m in C to make the binding in the C part.

Ok, this is not really a realistic approach, but for interfacing web,
something similar is probably best.  To actually have a web browser
built-in (err, linked in).

We could also make this use anything else we can think of for
protocol.

Well, this brings me to another issue, documentation.

A Sexy Macs, needs Sexy Docs.  And the current way of generating docs
is ... horrible.

What I want:

 * Translatable doc strings!

I'm not sure gettext is the best/only solution, so I'll be looking
into stuff.

 * Cross references between the doc strings and the manuals.

Whatever happens, I *insist* on this.

 * The manuals in something else than info for online reading

If we implement html parser for Sexy, then we can use that.  Please
note that we can use the META tags to provide the UP, NEXT, PREV
links.  I even think the html standard provides such META tags
... (trying to recall stuff I read in '96 ... can't be sure, or if it
was just examples of possible use of META ...).

In this world of text rendered html, there are no real arguments
against that.  And I think we should be using a subset of it anyway.

* No duplicated info in the doc strings and the manuals.

This is just horrible to maintain.  For printed manuals, we can
provide way(s) to include doc strings into the rest.  (And that info
should mostly be in appendixes anyway).

Have fun,

Johann


<Prev in Thread] Current Thread [Next in Thread>