On Wed, 2 Dec 1998, Mark S. Miller wrote:
>
> [+] Looks good. Some further suggestions:
>
> The new collection terminology is EList, ConstList, FlexList, EMap,
> ConstMap, and FlexMap. Wherever you say "List", you should probably say
> either "EList" or "list".
[?] I don't understand why "EList" is necessary. What information value is added by calling it an "EList" instead of just a "List"? We don't prefix other types with "E", like "EPromises" or "EIntegers". It seems like just another issue to potentially confuse people over.
> I like Bill's suggestion that "average" protect itself from a misbehaving
> alleged list (much like asynchAnd protects itself from a misbehaving
> alleged boolean). The one way bad supposed list behavior could screw us up
> is to report a size inconsistent with the number of iterations.
> [-] Do something easy and adequate for now. Do it right in E later.
>
[...]
> I can't imagine how a
> from-scratch converter could take you less than six month just to get to
> the level of bad functionality provided by the other four products.
[#] The key difference for our converter would be that our source format is restricted to a small number of simple constructs. This doesn't mean that we should be forced to stay in Frame if you find another adequate editor that handles figures within HTML. My consideration of the Frame converter was based on your restriction that you had to use Frame because it was the only editor with acceptable inline diagram abilities. I do think that if we went that way, the converter would not be quite so bad.
> Then Javasoft has already done most of the work of creating the wysiwyg
> editor we need. <fingersCrossed>All</fingersCrossed> we would need to do
> is write some E code to tie it all together, and we'll have the html-based
> successor to Elmer. I'm not saying this isn't a lot of work -- I'm sure it
> is -- it's just that the work will invested in the right place: E.
[#] What's unfortunate about this is that i have a hard time choosing E as the right language for any real application at the moment. I can't justify the enormous performance hit. If you ask me to do some conversion or document processing i will probably have to choose Python (or even Perl, if the job is small enough and highly dependent on regular-expression performance). Writing, thinking about things, and communicating in E are all great because E is so elegant. It's just that i'm not yet comfortable with the idea of writing a decent-sized program in E to be used frequently by other people.
> [+] Yes it does, and quite well too.
> I think what we most need (of things we can afford to build) is a set of
> Frame paragraph and character styles built for the purpose of 1)
> representing the semantic (and formatting) distinctions needed by E
> documentation, and 2) being convertable to html in as close to wysiwyg as
> we can get.
>
> Do you have Frame? If not, could you list a set of styles where each has
>
> a) an identifier as a name
> b) semantics / usage recommendations
> c) html tag to translate to.
[#] Certainly. I disagree that the standard HTML tags should be "implicitly included": there are too many pointless ones. If we can stick to a small and clear number of styles for the entire document it will really help. Here are some ideas.
block styles: heading, paragraph, display character styles: prose, emphasized, code, parameter, output (?), keyword (?)
heading:
section headings at various levels
<h1>...</h1>
<h2>...</h2>
<h3>...</h3>
paragraph:
body paragraphs
<p>...
display:
displayed example (usually source code or an interpreter session)
<p><blockquote>...</blockquote>
prose:
explanatory and expository text
...
emphasized:
prose with literary emphasis
<em>...</em>
code:
source code expressions or individual identifiers either in display blocks or mentioned in the text
<code>...</code>
parameter:
identifier standing in the place of an E expression, in an example or a template of some kind
<code><var>...</var></code>
output: (?)
output from a console or an E interpreter
<code><font color="#808080">...</font></code>
keyword: (?)
E keywords within source code
<code><strong>...</strong></code>
The essential styles are really just 'prose', 'emphasized', 'code', and 'parameter'. I like having a separate style for output so you can tell it apart from input (which would all be in the 'code' style). (See http://crit.org/~ping/e-forkv.html.) The style for keywords is kind of optional, but might also be nice -- up to you.
There really is no need for any other HTML tags, aside from links, images and other per-page formatting fluff, and tables if we need them for special figures.
Can you define these HTML expansions in FrameMaker? That would be really cool. I do not have Frame, unfortunately, which makes it very hard for me to see the documents you are actually working on and to have any understanding of your authoring and editing workflow.
!ping