Written in early 1990.

Since the following was written, Para mode has been enchanced to permit references to other files; and an Emacs interface has been written for Zimmermann's browser, which can also now handle multiple files.

These notes are inspired by a discussion on the Para mode mailing list; and are written to be read using Para mode.

This set of notes ask what hypertext is, and how hypertext in general relates to Emacs and to Para mode.  Please try to answer some of the questions I have asked, especially in the section on `Semi-structured Notes'.  See Semi-structured Notes.

The Context
***********

The Para mode mailing list discusses several topics, one of which is Para mode itself, another which is Mark Zimmermann's software for indexing and retrieving information from archives of unstructured text.

In addition, every has interests in hypertext.

Rodney wrote:

I don't know if this part is really the para stuff -- it's more concerned with info storage and retrieval.

and Zimmerman wrote:

as currently set up, it really is neat but seems to be severely oriented toward writing hierarchially-structured printable documents, rather than focused on taking semi-structured notes

I think all are related: Hypertext possesses several parts

Locating information in large stores
====================================

You need to locate information in large stores:

a. from organized data bases using data base technology; these data bases have key words, indices, etc, already created, and their use is widespread

b. from disorganized databases, such the archives of some news group; you have to search through the whole store for what you want, create your own indices etc.

The Interface to the Locating Tool
==================================

Initially at any rate, the locating tool or tools will be separate from the rest of the hyptertext tools; and the tools may always be separate, for reasons of efficency or what ever.  However, the tool should have a good interface to the rest of the hypertext system---if the interface is good enough, no one will notice that the two aspects are not integrated.  For example, Emacs mail uses mailers and carriers that are not part of Emacs itself, but the interface is integrated into Emacs, so that most people who use mail don't think of themselves as running a program separate from Emacs.

As a first step, I encourge Mark to experiment with using his indexer inside a shell running inside of Emacs.  Then he can copy those results he wants to some other buffer using the usual Emacs commands.

Inferior Processes
------------------

Emacs has all sorts of features for running inferior processes (about which I know little).  Running the indexer inside an shell inside of Emacs is the simplest, but lacks special keybindings, local variables, and the other features you expect from a mode.

By the way, to save time, my .emacs file causes Emacs to create three shells for me inside of Emacs when I start Emacs.  This saves me the 20 seconds or so this machine takes to fork a new shell. (I only start Emacs once a week or thereabouts, so a lengthy startup does not matter to me.)

The Notetaking Tool
===================

The notetaking tool is used to hold the information you collect from where ever, including from the large data stores.

This is what Para mode is, a notetaking tool: it has has facilities for adding nodes, cross referencing and indexing.

Moreover, using Texinfo, you can print out a nicely typeset hard copy version of your notes, with cross references to pages, foot notes, a table of contents, and an index at the end.

==> Hard copy printing is an important feature.  We do not yet live in a paperless world.

Enhancements
------------

Multiple views:

One possible enhancement to Para mode is to produce hard copy `projections' of a Para mode file: right now, (although I have not tried it) I think you can produce different master menus for a Para mode file (by hand editing).  Then you can use these different menus to provide you with different `views' of the same Para mode file.  One menu could provide you with access to the full file, and another could provide you with an `Executive summary'.  An as-yet-unwritten command would create a new copy of the Para mode file that reflects the new menu.  You could print this new version.

Put differently:  different master menus can be used to create different `virtual' images of one Para file (with some problems with the detail provided by lower level menus, if you have them). This works with one master file.  A second command could take a menu and copy only those nodes (and subnodes) listed in the menu to another buffer, thus making a `real' file that matches the menu.

Multiple files:

A second, obvious, enhancement is to handle multiple files, but I don't yet know how to do that.  (Menus could go to them, and cross references, but completion and defaults are more difficult, unless we use tags in some way.  Also, there would have to be a way to create master menus of all the files.)

Semi-structured Notes
=====================

As Mark Zimmerman says:

as currently set up, it really is neat but seems to be severely oriented toward writing hierarchially-structured printable documents, rather than focused on taking semi-structured notes

My primary interest is documentation....I view hypertext as a subset of the the documentation problem.

Currently, documents must be publishable in hardcopy as well as online.  Although I hardly ever print out email files, I do find that I refer to or wish to refer to many documents in hard copy.  Hardcopy output is vital in organizational contexts---it is easier in heterogenous contexts to provide all the members of a committee with a hard copy of some document than to persuade them all to learn to use computers.  I have the Emacs manual online and in hard copy; I use the on line version for some things but mostly use the hard copy version. Thus, while I can conceive of an online-only hypertext system, I don't think it is practical.

So the question arises, how structured should a note taking system be?

Traditionally, books are printed with a hiararchical structure, except for the case of encyclopedias, which have a flat node system.

In Texinfo, the encyclopedia structure can be duplicated by using nothing but section headings.  Project GNU will probably use this for the utilities documentation (for ls, cp, mv, rm, pwd, etc.)

Questions:

My first question is for Mark Zimmerman (and who ever else wishes to comment) is this: how should Para mode be changed to handle what Mark calls `semi-structured' note taking?

My assumption is that you can handle this by using a single type of section (`' or maybe `').  But this may not be sufficient.

Maybe hypertext notetaking is fundamentally different from documentation production, and that having the hard copy print capability is impossible.  This leads me to my second question, which is in the next section.

Online Only?
============

Rodney talks of gathering information from large data stores and of having menus point to nodes in special modes, like mail mode.

If a hypertext system includes references to entities that can only be online, such as animated images, or sound, or current weather, then hard copy is impossible.

My question here is: is hard copy sufficiently necessary that the capability should be there so that a subset of a full hypertext node structure could be printed out?  Or do the complications of hard copy outweight the benefits.

My premise is that hardcopy is needed.  But I am open to persuasion. What should a hypertext system include?

Include What?
=============

Related to the question of whether a hypertext system should have a hard copy capability is the question of what a hypertext system should include?

Let us start simply:

Presently, Para mode provides the following items of information for each node:

<node name> <section type> <title> <pointers to Next, Previous, and Up nodes> <optional pointers to incorporated nodes via menus> <optional pointers to other nodes via cross references> <body of the node>

A para node document as a whole can include indices.

Rmail mode provides the following items for each of its nodes (which are individual mail messages):

<from> <date> <subject> <status labels: unread, deleted, filed, forwarded, edited, answered> <labels for projecting a menu (called a summary listing)> <body of the node>

Rmail mode has some of the features of Para mode, except that you cannot include cross references, indices or menus.  An Rmail file is a `flat' collection of nodes, without hierarchical structure.

What of the rmail features should Para mode incorporate?

What other features should Para mode incorporate?

Lost in Hyperspace
==================

To my way of thinking, a fundamental function of a hypertext system is to help you locate yourself in information space.  Most of the features that people have mentioned so far already exist in Emacs, except that a road map is not provided.  Let me list over these:

1. Accessing data stores: run inferior processes, run grep, or searches.

2. Access entities with different modes, like mail mode, or what not: find the appropriate file.

3. Take notes: write short files with other files named.

But people do not think of these separate capabilities as a hypertext system;  there is no overall map.

Perhaps we should think of the problem as how to devise a user interface to a variety of search and reference features, an automated geological survey.  This would be a different way of looking at the problem than we have so far.

I would like comments on this.  Also, I would like comments on what hyertext features I have left out.  Some features may not seem salient to me, so I forget they are desired.  What are these features?