20-Jun-83    teitelman.pa    Position Bug in Tioga
Date: 20-Jun-83 16:22:07 PDT
From: teitelman.pa
Subject: Position Bug in Tioga
To: tiogaimplementors^
cc: Guibas, teitelman
Reply-To: teitelman.pa

If you select a number and click position in a viewer, under certain circumstances, there is no secondary selection. To see this, 
retrieve /ivy/teitelman/bug/bug.profile, select the number 585 somewhere, and click position. 584 and 586 work fine.

warren




    22-Jun-83    Maxwell.pa    bug report on Find
Date: 22-Jun-83 10:31:34 PDT
From: Maxwell.pa
Subject: bug report on Find
To: TiogaImplementors^.pa
cc: CedarSupport^.pa 
Reply-To: Maxwell.pa

The following procedure should make Karen's bug happen:

1) move an &n line to be the first invisible line below the window of the Executive.

2) select a visible &.

3) click Find repeatedly.  The Finds will cycle through the visible & plus the one invisible one.

-------------------------------------
Date: 20-Jun-83 15:48:33 PDT
From: kolling.pa
Subject: bug report on Find
To: cedarSupport^.pa
cc: kolling
Reply-To: kolling.pa

There's something wrong with Find in my (non-editable) userexec viewer.  I think this is new in this release, but I'm not sure.  
(I'm on the boot file from just before the release).  The problem is as follows:  I frequently select "&" and Find backwards or 
forwards.  Find backwards works, but Find forwards when there is only one & displayed (several &s exists ahead in the typescript) 
does not.  What happens is I select the visible &, click Find forward, and the select bar disappears but the viewer does not 
scroll;  if I click Find forward again it reselects the visible &.  Perhaps there are two different bugs here.

Karen
 

------------------------------------------------------------

    23-Jun-83    Maxwell.pa    minor bug in ContainersImpl.ContainerPaint
Date: 23-Jun-83  8:21:03 PDT
From: Maxwell.pa
Subject: minor bug in ContainersImpl.ContainerPaint
To: Pausch.pa
cc: McGregor, Beach, Maxwell

Rick pointed out a bug in my code to determine the correct width and height for bounded viewers.  The effect of the bug was to 
leave a scrollbar wide gap to the right of the bounded viewer.  The fixes are easy.  

The code:

    IF (temp _ MAX[v.parent.cw-v.cx, 5]) # v.ww THEN {

should be replaced by:

    IF (temp _ MAX[v.parent.cw-v.wx, 5]) # v.ww THEN {
    
    
    

Similarly with:

    IF  (temp _ MAX[v.parent.ch-v.cy, 5]) # v.wh THEN {

and:

    IF  (temp _ MAX[v.parent.ch-v.wy, 5]) # v.wh THEN {
    

John.
    23-Jun-83    atkinson.pa    PostCedar4.2.tioga
Date: 23-Jun-83 10:56:56 PDT
Sender: atkinson.pa
Subject: PostCedar4.2.tioga
To: CedarUsers^
From: PostCedar Coordinator <Atkinson.PA>
Reply-To: PostCedar Coordinator <Atkinson.PA>

Reasonably up-to-date documentation on changed components living on PostCedar is now kept in the file:

    [Indigo]<PostCedar>Documentation>PostCedar4.2.tioga

I will update this file when there are new entries.
    23-Jun-83    To: Maxwell    Re: minor bug in ContainersImpl.ContainerPaint
Date: 23-Jun-83 13:23:35 PDT
From: pausch.pa
Subject: Re: minor bug in ContainersImpl.ContainerPaint
In-reply-to: "Maxwell's message of 23-Jun-83  8:21:03 PDT"
To: Maxwell
cc: Pausch, McGregor, Beach


I've made the change and re-compiled my version.  This will show up later
releases.
    22-Jun-83    Beach.pa    Re: Some curious Viewers difficulties
Date: 22-Jun-83 11:30:12 PDT
From: Beach.pa
Subject: Re: Some curious Viewers difficulties
To: Pausch
Reply-To: Beach
cc: Beach

Maureen suggested that you might be able to help here, since you had just rolled a new Viewers for the ISL prerelease.

-------------------------------------
Date: 22-Jun-83 11:15:36 PDT
From: Beach.pa
Subject: Some curious Viewers difficulties
To: Maxwell
Reply-To: Beach
cc:  Beach

I am implementing a scroll-by-page scroll bar for ShowPress. This relies on Darlene Plebon's new Sliders interface that works just 
fine. However to establish the slider, its necessary to nest both the slider and press viewer inside a container -- thats when the 
fun begins.

1. binding the X and Y bounds of the nested press viewer fails to position the press viewer properly. I believe this is due to an 
interaction with scrollable: TRUE.

2. All the containers, buttons, sliders, and press viewers have paint: TRUE, but the press viewer does not paint itself unless the 
whole column is repainted. I am not sure of the interactions here -- some assistance would be appreciated.

3. Positioning buttons and text viewers on the same line is awful! Off-by-one errors abound. Grrr. . . Seems that its the defaults 
that differ in Buttons and MakeNewTextViewer.

4. It would be nice to use the ViewerBLT cache on the press viewer. Can I get some assistance on doing that properly?

Cheers,
Rick
    24-Jun-83    teitelman.pa    viewer suggestion
Date: 24-Jun-83  9:43:01 PDT
From: teitelman.pa
Subject: viewer suggestion
To: tiogaimplementors^
cc: teitelman
Reply-To: teitelman.pa

It would be nice if there were a way to open an icon or a viewer and specify where in the column the new one was to go. For 
example, when opening an error log, it would be nice if I could open it just below the corresponding viewer. Split seems to know 
how to do this.

warren
 
    24-Jun-83    McGregor.pa    Re: viewer suggestion
Date: 24-Jun-83  9:59:25 PDT
From: McGregor.pa
Subject: Re: viewer suggestion
In-reply-to: "Your message of 24-Jun-83  9:43:01 PDT"
To: Teitelman
cc: Pausch

Warren;

ViewerOps has interfaces for moving viewers above and below other viewers.  In combination with Open, you can do what you want 
(just like split).

Scott.
    24-Jun-83    teitelman.pa    Re: viewer suggestion
Date: 24-Jun-83 11:45:39 PDT
From: teitelman.pa
Subject: Re: viewer suggestion
In-reply-to: "McGregor's message of 24-Jun-83  9:59:25 PDT"
To: McGregor
cc: Pausch

The last time I tried, there were problems relating to doing this in a single operation, i.e. you had to specify paint false on the 
call to Open, then remember to recompute column etc., I think that it would be a good idea if this were an option in OpenViewer and 
CreateViewer.

warren
    27-Jun-83    McGregor.pa    Trying out the Tioga keyset commands
Date: 27-Jun-83 10:16:15 PDT
From: McGregor.pa
Subject: Trying out the Tioga keyset commands
To: Teitelman, Mitchell, Daniels, ISLImplementors^
Reply-To: McGregor
cc: TiogaImplementors^

If you'd like to try out the Tioga keyset functions, you'll need to do the following:

1)  Acquire a keyset (the alto lab used to have a stockpile)

2)  Retrieve the following files from [Ivy]<McGregor>Cedar>
        Keyset.label
        KeysetReadonlyTioga.TIP
        KeysetTioga.TIP
    You may want to modify your personal df file to point to these files.

3)  Hardcopy the Keyset.label file and tape it to your keyset.

4)  Modify your <user>.profile to contain the following entries:
        ReadonlyTiogaTIP: KeysetReadonlyTioga.TIP
        TiogaTIP: KeysetTioga.TIP

5)  Boot Othello; Open Indigo, and fetch <PreISLCedar>Top>CedarDorado.boot onto the client volume.  The new boot file is required 
because of a bug in TIP that prevents specifying more than two control or shift keys; it should be included in the next normal 
Cedar release.  The PreISLCedar boot file also fixes the known Viewers repaint bugs.  (Note to non-ISL folks:  PreISLCedar is our 
staging area for ISL Cedar releases.  At some point it will become incompatible with Cedar 4.2).

6)  Boot the client volume with the "D" switch and let it do its thing with the automatic bringover.  If you have any files from 
<PostCedar> you may need to re-retrive them.

7)  You should now be in business.  Make a checkpoint if you like and try out the new functions.  I'll fix the Viewers TIPTables to 
be consistent at some point, but for now, I'm especially interested in comments about the following:

Are the set of functions reasonable?  What would you add or delete?
If you give up on the keyset or never use it, I'd be interested in hearing (even if you can't articulate what drove you off).
If you find yourself becoming a "hard-core" addict, I'd be interested in hearing about that as well.

Enjoy,

Scott.

    27-Jun-83    teitelman.pa    autoscrolling
Date: 27-Jun-83 20:51:48 PDT
From: teitelman.pa
Subject: autoscrolling
To: tiogaimplementors^
Reply-To: teitelman.pa

It is still the case that when you are composing a walnut message and typing goes below the bottom of the viewer, the viewer does 
not always scroll up so that the typeinpoint is visible.

warren
    28-Jun-83    Swinehart.pa    Re: Some hints for private Tioga styles
Date: 28-Jun-83  8:45:07 PDT
From: Swinehart.pa
Subject: Re: Some hints for private Tioga styles
In-reply-to: "Your message of 14-Jun-83 17:24:46 PDT"
To: Beach
cc: TiogaImplementors^, Swinehart
Reply-To: Swinehart.pa

The edit tool was a stroke of genius from the standpoint of manifesting the largest number of available actions in the smallest 
amount of space, and the most quickly.  But for any given action it is of course not the most convenient way one could imagine 
providing that action.

When it comes to looks, formats, and styles, I find myself wishing I had something like the Star property sheets.  A property sheet 
could be a new viewer that would contain an excerpt from the edit tool, whose fields would be filled in already with the current 
values.  The viewer could also have buttons that would yield higher and lower-level property sheets (looks leads to formats and 
styles, and so on), as in Star.  The viewer would automatically refer to the text sequence or node from which it was derived, so 
the result would be a lot less clicking.  It would be compatible in some sense with the edit tool, too, so I think it would fit in 
OK.

Aside on edit tool:  How about putting into a second menu line some buttons which, when clicked, would scroll the tool data to a 
selected section (search, sort, format, style, edit ops, and so on?)  At the cost of one or maybe two lines of additional height at 
the default size, this would substantially reduce the number of times I have to grow the edit tool window or laboriously scroll it.

Thanks for listening,
Dan
    28-Jun-83    kolling.pa    sigh
Date: 28-Jun-83 12:00:34 PDT
From: kolling.pa
Subject: sigh
To: tiogaimplementors^.pa
cc: kolling 
Reply-To: kolling.pa

-------------------------------------
Date: 28-Jun-83 11:24:41 PDT
From: kolling.pa
Subject: Adjust
To: tiogaaimplementors^.pa, cedarsupport^.pa
cc: kolling
Reply-To: kolling.pa

Someday God will justly reward an Adjust algorithm that, in response to a request to move a border up, moves it even further down 
than it started out, or that takes three adjustments to get to the correct set up of one border.  How about believing the border is 
where the cursor is moved to?

Karen


------------------------------------------------------------
    28-Jun-83    teitelman.pa    TiogaOps.RegisterFileNameProc
Date: 28-Jun-83 16:07:31 PDT
From: teitelman.pa
Subject: TiogaOps.RegisterFileNameProc
To: tiogaimplementors^
cc: teitelman
Reply-To: teitelman.pa

Should allow more than one such procedure to be registered at a time. Spreitzer wants to try fooling around with somethiing that 
does a bringover from a df file, and he ought to be able to do this without turning off the one in the userexec that does spelling 
correction.

warren
    28-Jun-83    Taft.PA    Circumventing the unbound style problem
Date: Tue, 28 Jun 83 16:58 PDT
From: Taft.PA
Subject: Circumventing the unbound style problem
To: TiogaImplementors^.pa
cc: Taft

Tioga documents that use things from the default style assuming that it is Cedar.style are becoming increasingly widespread; and I 
am finding this to be a considerable nuisance.  I assume there is no likelihood of this being fixed before Cedar 5 or Tioga 2 or 
whatever.

I wonder whether there is a way of circumventing the problem.  For example, is it possible to make my default style effectively 
say, "If the document in question contains Tioga formatting then use Cedar.style, else use PlainText.style"?  Or is there any other 
way to get a similar effect?

Reading through the Cedar 4.2 documentation, I noticed the ExtensionStyles feature which has recently been added.  This might help 
somewhat, but it doesn't completely solve the problem for me.  For example, I regularly deal with both Tioga formatted and plain 
text files whose extensions are ".mesa".

    Ed
    28-Jun-83    teitelman.pa    TiogaOps2Impl.Normalize
Date: 28-Jun-83 17:18:04 PDT
From: teitelman.pa
Subject: TiogaOps2Impl.Normalize
To: tiogaimplementors^
Reply-To: teitelman.pa

see anything wrong with this:

Normalize: PUBLIC PROC [viewer: Viewer] = { [] _ TEditInput.Normalize[] };

Hint: TEditInput.Normalize[NIL] causes an address fault.

warren
    29-Jun-83    Beach.pa    Use of <Cedar>Styles and <Cedar>Icons
Date: 29-Jun-83 17:30:01 PDT
From: Beach.pa
Subject: Use of <Cedar>Styles and <Cedar>Icons
To: CedarDiscussion^
Reply-To: Beach

Recently I have been curious to see how people use Tioga styles in packages and eager to change or augment icons provided by a 
couple of packages. The current location for such files (mumble.style and mumble.icons) is determined by the package implementor 
and must be identified by examining the package DF file. However, there exist two directories: <Cedar>Styles and <Cedar>Icons. 
Disappointingly, they contain only a small number of samples.

Following the convention for <Cedar>Documentation, I wonder about the merits of package implementors placing styles and icon files 
on <Cedar>Styles and <Cedar>Icons. There seem to be stronger reasons for placing documentation in one place than for placing 
supporting files in one place. However one argument for a centralized location is to enumerate the use of styles or icons (or tip 
tables?) in Cedar clients. This would benefit the curious and the style or icon implementor in a similar manner to the 
documentation directory.

A related issue to the location of styles and icons is the difficulty of registering commands which rely on package styles and 
icons. The command registry accepts only a filename for the BCD. Some packages supply styles, icons, or tip tables (TSetter, 
Walnut, Remember) and thus the package must be brought over before it can be effectively used. I wonder how the advent of better 
remote file accessing conventions in Cedar FS would help the use of package support files.
    29-Jun-83    Taft.PA    Re: Use of <Cedar>Styles and <Cedar>Icons
Date: Wed, 29 Jun 83 17:44 PDT
From: Taft.PA
Subject: Re: Use of <Cedar>Styles and <Cedar>Icons
In-reply-to: "Your message of 29-Jun-83 17:30:01 PDT"
To: Beach
cc: CedarDiscussion^

Seems to me that your last issue could be addressed by either of two means:

  1) Invoking a registered command should (when necessary) BringOver a DF file, not just retrieve a BCD.

  2) Programs should be responsible for bringing over their own auxiliary files.

Approach (1) seems more desirable since it retrieves a consistent set of files.  But approach (2) has the appeal of locality and 
transparency.  With the new Cedar FS, it may be possible to get the best of both approaches.

    Ed 
     1-Jul-83    lamming.pa    TIP Testing
Date:  1-Jul-83  8:44:14 PDT
From: lamming.pa
Subject: TIP Testing
To: ISL^
Reply-To: lamming

I have this Micky Mouse program for testing new TIP tables.  It creates two viewers: an input and an output viewer.  You point at a 
TIP file name and hit LOAD and it parses the TIP file and tells you where the problems are if any.  It then prints in the output 
viewer all tokens generated in the input viewer.

I have found it helpful for some while and it suddenly occurred to me that I hadn't heard of a better tool.  Is there is a better 
tool for testing TIP tables or is this a non-problem. If the tool already exists what is it called.  If there isn't is anybody 
interested in mine?

                                            Mik
      6-Jul-83    bier.pa    Cycling Through Options
Date:  6 Jul 83 14:30:42 PDT
From: bier.pa
Subject: Cycling Through Options
To: McGregor, Pausch
cc: Bier

In the solidviews edittool, there are many buttons which cycle through possibilites when pushed (for instance: "Shadows" cycles 
through TRUE and FALSE, "Material" cycles through plastic, metal, and moondust).

I use a separate button to mean "use the value now displayed" much as the Tioga edit tool uses its "Set" buttons.  The problem is 
that, if the value is being displayed by a Label, I cannot read the value displayed so I must remember what it is in another 
variable (presumable updated in parallel).  Another choice is to use edittable viewers as Tioga does since these can be read.  
However, I don't want my Labels to be edittable.

I am getting good at updating associated variables in parallel with setting new values to my labels, but there is a potential 
variable/label consisitency problem here.

Perhaps there should be a Labels.Get command.

Eric
     6-Jul-83    McGregor.pa    Re: Cycling Through Options
Date:  6-Jul-83 14:45:49 PDT
From: McGregor.pa
Subject: Re: Cycling Through Options
In-reply-to: "bier's message of 6 Jul 83 14:30:42 PDT"
To: Bier
cc: Pausch

Eric;

There is a "Labels.Get" command (but alas not documented in the interface).  You can call rope _ NARROW[ViewerOps.GetViewer[label]] 
or just cheat and note that labels store their contents in the viewer name field: rope _ label.name.

Randy:  Let's put a "Get" routine in the Labels interface next recompile...

Scott.
     7-Jul-83    kolling.pa    openh or viewers bug
Date:  7 Jul 83 12:29:34 PDT
From: kolling.pa
Subject: openh or viewers bug
To: atkinson, tiogaimplementors^.pa
cc: kolling
Reply-To: kolling.pa


When I do a long Find in a viewer that's been OpenHed, and meanwhile change the input selection to another viewer, when the Find 
completes the OpenHed viewer is not displaying the newly Found section of the file, rather it is still where it was at the start of 
the Find.  If the intervening change selection is not done, the viewer is set up correctly.  I don't know if this is a problem for 
normally opened viewers as well.

Karen
     7-Jul-83    teitelman.pa    menus
Date:  7 Jul 83 14:03:42 PDT
From: teitelman.pa
Subject: menus
To: pausch


Date: Sun, 27 Mar 83 10:08 PST
From: Taft.PA
Subject: Overloaded buttons
To: CedarDiscussion^

A number of Cedar tools have chosen to conserve screen real-estate by multiplexing several functions onto each button in the menu.  
Left, middle, and right clicks of a button have different meanings, and for a few buttons the meaning is further modified by the 
shift and/or control keys.

As the number of tools has increased, there has been an explosion of independent meanings assigned to the different mouse buttons 
and control/shift mouse button combinations.  There is no consistent user model for these assignments.  I am finding it 
increasingly difficult to remember all of them, and I think the situation has gotten rather badly out-of-hand.

I have an alternative proposal.  The "primary" function of a button (i.e., the one corresponding most directly to the button's 
label) should be invoked by the left mouse button, as it is now.

All the other, "secondary" functions should be collected together in a subsidiary menu, which is brought up when you click the 
button with the middle mouse button.  I have in mind something along the lines of the Smalltalk/Tajo-style pop-up menu, though I 
imagine there are other possible arrangements that would also be satisfactory.

I don't have any systematic use for the right mouse button.  Perhaps the most frequently-used secondary function can be invoked by 
it.  Users can learn about this if they want to, but they don't have to since the secondary function is also available in the 
subsidiary menu.  For completeness, the subsidiary menu should also include the primary function.

Examples:

Compile:    left click: compiles file
        middle click: brings up menu {Compile, Bind, CompileAndBind}

Set:        left click: sets breakpoint at selected place
        middle click: brings up menu {Set, BreakEntry, BreakExit}

In order for this scheme to have any benefit, all tools must be converted to use it.  This suggests that the Menus interface should 
be changed along the following lines.

Current:

ClickProc, MenuProc: TYPE = PROC [parent: REF ANY, clientData: REF ANY _ NIL, mouseButton: MouseButton _ red, shift, control: BOOL 
_ FALSE] ;

CreateEntry: PROC [name: Rope.ROPE, proc: ClickProc, clientData: REF ANY _ NIL, documentation: REF ANY _ NIL, fork: BOOL _ TRUE, 
guarded: BOOL _ FALSE] RETURNS [entry: MenuEntry] ;

Proposed:

ClickProc, MenuProc: TYPE = PROC [parent: REF ANY, clientData: REF ANY _ NIL, function: ATOM] ;

CreateEntry: PROC [functions: LIST OF ATOM, proc: ClickProc, clientData: REF ANY _ NIL, fork: BOOL _ TRUE, guarded: BOOL _ FALSE] 
RETURNS [entry: MenuEntry] ;

The primary name of the button is the print name of the first atom in the functions list, and clicking it with the left mouse 
button calls proc[..., function: a] where a is that atom.  The second atom in the list is similarly associated with the right mouse 
button.  The middle mouse button brings up a subsidiary menu consisting of the entire functions list, and releasing the middle 
mouse button over one of the buttons in that menu calls proc[..., function: a] where a is the corresponding atom.

I think this scheme also subsumes the purpose presently served by the "documentation" argument, so I have omitted it.

Comments?

    Ed


Date: 28-Mar-83  9:00:15 PST
From: paxton.pa
Subject: Re: Overloaded buttons
In-reply-to: Taft's message of Sun, 27 Mar 83 10:08 PST
To: Taft.pa
Reply-To: Paxton
cc: CedarDiscussion^

Ed,

YES!  We should have a standard convention for menu buttons.  And as Warren points out, we should still be able to include 
accelerators for "non-primary" operations.  How about the following proposal:

Holding CTRL down when click a menu button brings up a pop up menu (no matter which mouse button is used, so you just have to 
remember CTRL).  The pop up menu stays up as long as CTRL is held down, and while it is up you cannot click anything else (perhaps 
this restriction can be relaxed, but do we really want several pop-up menus up at once?).  You can do multiple operations in the 
pop-up menu, but as soon as you release CTRL, the menu goes away.  Perhaps the menu should include a HELP entry that defines the 
different menu commands.  This would take care of the desire for documentation without dedicating a mouse button.

There will be a standard mapping from entries in the pop up menu to buttons as an accelerator for use by "expert" users.  For 
example, 
    
    1st menu entry available by LEFT button
    2nd available by MIDDLE button
    3rd available by RIGHT button
    4th by LEFT-SHIFT
    5th by MIDDLE-SHIFT
    6th by RIGHT-SHIFT

This proposal satisfies the need for a standard convention.  It is upward compatible with the current user-interface.  It is easy 
to explain to new users.  The mapping from pop-up entries to mouse buttons is simple so users will quickly learn to use the 
accelerators.  It supports new users without penalizing experts.

Let's do it.

--Bill  

Date: 28 March 1983 12:33 pm EST (Monday)
From: Lampson.PA
Subject: Re: Overloaded buttons
In-reply-to: Your message of 28-Mar-83  9:00:15 PST
To: Paxton
cc: CedarDiscussion^

I like this proposal, and have one small extension to propose. Different users may
well have different ideas about what is common, so it would be nice if the
choice of operations invoked by buttons could be set in the profile, as Warren
suggested. How about a list of atoms which determines the order of menu items
(and hence, by your proposal, the meaning of button clicks)? The only problem
I can see with this is that it will be hard to use a Cedar with an unfamiliar
profile, but this probably happens seldom, and it's always possible to use the
menu for everything in case of confusion.

If there is going to be a standard HELP entry, I think it should be in a standard
place in each pop-up menu, namely first, and your table of menu-button
correspondences should be shifted by one:
    
    2nd menu entry available by LEFT button
    3rd available by MIDDLE button
    4th available by RIGHT button
    5th by LEFT-SHIFT
    6th by MIDDLE-SHIFT
    7th by RIGHT-SHIFT

About two-button mouse compatibility: could we standardize on
Left+Right=Middle? A user with a two-button mouse could use a profile which
minimizes the use of this combination.

Date: Mon, 28 Mar 83 09:52 PST
From: Taft.PA
Subject: Re: Overloaded buttons
In-reply-to: "Your message of 28-Mar-83  9:00:15 PST"
To: Paxton
cc: CedarDiscussion^

Bill, I would be very happy with your version of the proposal.

I have one comment to make about a point that was brought up by both Warren and Scott, with regard to "buttoning ahead".  It is 
currently the case (and rightly so) that feedback from clicking menu buttons is immediate, even if the action invoked by the button 
is deferred.  I see no reason in principle why this should not extend to the operation of a pop-up menu.  That is, CTRL-click on a 
menu button should bring up the pop-up menu immediately, and the button selected from it should have its action queued for later 
execution, just the same as is now done for top-level buttons.

    Ed


Date: 15-Apr-83 14:49:13 PST
From: teitelman.pa
Subject: A proposal for eliminating the need for a Levels menu 
To: cedardiscussion^
cc: TiogaImplementors^
Reply-To: teitelman.pa

How about having a single Levels button work as follows:

Date: 15-Apr-83 15:09:47 PST
From: kolling.pa
Subject: Re: A proposal for eliminating the need for a Levels menu
In-reply-to: teitelman's message of 15-Apr-83 14:49:13 PST
To: teitelman.pa, TiogaImplementors^, cedardiscussion^
cc: kolling
Reply-To: kolling.pa

How about:

left click = more levels (by 1),


     7-Jul-83    teitelman.pa    menus
Date:  7 Jul 83 14:15:38 PDT
From: teitelman.pa
Subject: menus
To: pausch

Date: 12-Oct-82 14:27:01 PDT
From: teitelman.pa
Subject: button suggestion
To: tiogaimplementors^
cc: teitelman.pa
Reply-To: teitelman.pa

allow user to specify process.priority to use when invoking a clickproc.

warren


Date: 22-Sep-82 11:58:12 PDT
From: teitelman.pa
Subject: menus
To: tiogaimplementors^
cc: teitelman.pa

Scott,

it would be nice if in 3.5 viewers made it easy for clients to put up new menu lines and take them down. It would also be nice if 
the repainting for same were instantaneous, i.e. the repaint of the main viewer area used blt. Maybe a different hint would be 
required for PaintViewer, or maybe a new procedure like AddMenuLine or RemoveMenuLine. I think that the repainting issue is going 
to be more important now that the new action area scheme puts up menus and takes them down every time you proceed or abort from an 
action.

warren
 



     8-Jul-83    Maxwell.pa    new boolean in viewer class record
Date:  8 Jul 83 10:03:21 PDT
From: Maxwell.pa
Subject: new boolean in viewer class record
To: McGregor
cc: Pausch, Maxwell

Scott,

Next time you change the ViewerClasses interface please add a boolean to the class record which indicates whether or not new 
instances of this class can be constructed just with ViewerOps.CreateViewer[$ClassFlavor, info: [name: instanceName]].  This will 
allow Clean and Desktops to know when it is ok to reconstruct a dead viewer.  The data base may also be able to make use of it.  
Eventually we will want all of the classes to conform to this convention, but it will be nice until then to have some way of 
determining whether or not a particular class does.

John.
    12-Jul-83    gnelson.pa    TiogaOps
Date: 12-Jul-83 23:35:00 PDT
From: gnelson.pa
Subject: TiogaOps
To: TiogaImplementors^
cc: gnelson, CedarDiscussion^
Reply-To: gnelson.pa

Three questions.

I would like to insert at the end of a given Tioga text viewer v two nodes h and t whose contents are respectively the given ropes 
rheader and rtext, with h a first-level node and t it's child.  My code for this is:

nd:  TiogaNode _ TiogaOps.LastWithin[TiogaOps.ViewerDoc[v]];
TiogaOps.SelectNodes[viewer: v, start: nd, end: nd, caretBefore: FALSE];
TiogaOps.Break[];
TiogaOps.UnNest[];
TiogaOps.InsertRope[rheader];
TiogaOps.Break[];
TiogaOps.Nest[];
TiogaOps.InsertRope[rtext];

Question 1.  I expected this to work provided that the last node in v is at level 2.   If the level of the last node in v is not 
known, then the first call to TiogaOps.UnNest[] should be replaced by

WHILE "level of insertion caret is not 1" DO TiogaOps.UnNest[] ENDLOOP.

But I can't figure out how to determine the level of the insertion caret.  I could just call UnNest[] a hundred times, but Tioga 
seems to flash "can't do it" in the message window when UnNest[] is called and the caret is at level 1.  How can I solve this 
problem?

Question 2.  In fact even when the last node of v is at level 2, the above code works sometimes and doesn't work other times, 
unreplicatably, and I can't figure out what's going on.  When I set breakpoints in the code, the action area grabs the insertion 
carat as soon as the breakpoint is hit. It seems to restore the selection before proceeding, and, in fact, the code always works 
when I step through it with breakpoints.  When I remove the breakpoints, it sometimes flashes "can't do it", and fails to insert 
the new nodes.  Sometimes it inserts only rheader and not rtext.  Does anybody have any idea what's going on, or suggestions for 
how to debug this?

Question 3.  I question the practice of operating on Tioga node structures by maniputing the global variables of the user 
interface.  I would like to replace the code above with something like:

t: TiogaNode = X.NewNode[contents: rtext, firstChild: NIL, nextSibling: NIL];
h: TiogaNode = X.NewNode[contents: rheader, firstChild: t, nextSibling: NIL];
nd: TiogaNode _ TiogaOps.ViewerDoc[v].firstChild; -- assume v non-empty
WHILE nd.nextSibling # NIL DO nd _ nd.nextSibling ENDLOOP;
nd.nextSibling _ h;
X.Repaint[v]

Does an interface like X exist?  It must somewhere.  Are there plans to make it public?  
    13-Jul-83    Paxton.pa    Menus
Date: 13-Jul-83 15:48:18 PDT
From: Paxton.pa
Subject: Menus
To: Pausch, McGregor
cc: Paxton

The basic idea I want to propose is to break the direct link from menu button to procedure and insert an "interpretive" step.  This 
makes it easy to drive menu actions from programs.

1) Each button has associated with it a list of atoms.  Clicking a button causes its list of atoms to be passed to the button 
interpreter.

2) The button interpreter keeps a registry of command atoms.  It looks up the atoms to find the procedures and calls them.  The 
details of the user interface are hidden from the command interpreter -- it simply gets a list of command atoms and a viewer.  This 
is analogous to the situation with TIP in which the user interface details are dealt with by TIP and the viewer notify procedure 
takes care of interpreting the lists of command atoms, etc. that come from the TIP table.

    Interpret: PROC [viewer: Viewer, list: LIST OF ATOM];
    
3) To make it easy for people to experiment with adding to the functionality of buttons, the interpreter saves a list of procedures 
for each atom.  It goes down the list calling each procedure in turn until it finishes the list or one of the procedures raises the 
signal QuitList.  When registering a command proc, you can specify whether it goes at the front of the list or the end.  If you are 
adding a special interpretation for some standard button, you register your proc after the standard one and put your's at the front 
of the list.  If your operation preempts the normal one, it can raise the signal to prevent the normal one from being executed.  
However, it your operation decides to do nothing, the normal operation will be executed as usual.

4) The command procedures are passed the viewer and a client data which can optionally be provided at registration.

    ButtonCommandProc: TYPE = PROC [viewer: Viewer, clientData: REF];
    
    Register: PROC [
        name: ATOM, proc: ButtonCommandProc, clientData: REF _ NIL, front: BOOL _ TRUE]; 
        -- if front is true, put this proc at the front of the list of proc's for this atom
    
    UnRegister: PROC [name: ATOM, proc: ButtonCommandProc];
        -- removes the proc from the list for this atom
    
    QuitList: SIGNAL; -- raised by command proc to tell interpreter to stop with this atom



-- blah, blah, blah -- This is where I stopped before coming to talk to you.

--Bill
    13-Jul-83    PolleZ.pa    Levels in Tioga
Date: 13-Jul-83 17:05:09 PDT
From: PolleZ.pa
Subject: Levels in Tioga
To: TiogaImplementors^
cc: PolleZ
Reply-To: PolleZ.pa

As you probably know, I am writing my thesis using Tioga.  Here's an item from my wishlist for your consideration for future 
releases of Tioga.

When I have anything other than AllLevels selected, what I usually want to see is just the head nodes.  In other words, I want to 
see just the outline, so that I can see how the structure of the document is progressing.  With the current Tioga, I can get the 
first level of such an outline for free, but the rest tends to be obscured by the text in the upper levels.  Having the outline 
come for free when you write a document is extremely helpful.

To implement this, a HeadersOnly toggle button could be added to the Levels menu line.  A user could then browse the outline of a 
document to whatever level she wishes without giving up the ability to browse the text at multiple levels also.


                Polle

    14-Jul-83    Paxton.pa    Re: TiogaOps
Date: 14-Jul-83  9:34:13 PDT
From: Paxton.pa
Subject: Re: TiogaOps
In-reply-to: "Your message of 12-Jul-83 23:35:00 PDT"
To: gnelson
cc: TiogaImplementors^, CedarDiscussion^

Greg,

The problems may come from the fact that Break behaves differently depending on whether the node is empty or not (try it -- notice 
where the caret ends up).  Try rewriting it so that you 1) make a caret selection at the end of the last node, 2) save the 
selection, 3) insert the rope, 4) restore the selection, and 5) break the node.  Do this for rheader and then do it again for 
rtext.  Then select the last node and Nest.

Regarding "the practice of operating on Tioga node structures by maniputing the global variables of the user interface"  --  I 
agree completely.  Tioga2 is being designed to support client code more in the style you suggest.  Tioga1 cannot quite manage it 
for a variety of reasons.

--Bill
    14-Jul-83    Maxwell.pa    scrolling very large files
Date: 14 Jul 83 12:48:50 PDT
From: Maxwell.pa
Subject: scrolling very large files
To: McGregor, Pausch

Could this be an off-by-one error somewhere in the thumbing logic?  Russ says that OpenHuge has nothing to do with scrolling.  It 
is just a convenient interface to using a virtual rope on the file.

-------------------------------------
Date: 14 Jul 83 10:26:28 PDT
From: hagmann.pa
Subject: openhuge scrolling
To: CedarSupport^
cc:  hagmann
Reply-To: hagmann.pa

I opened a 2250913 byte file using openhuge.  I cannot use the middle mouse button to scroll to the end.  Selecting with the middle 
button very close to the bottom of the bar moves the window down somewhere into the file (not the end).  The scroll bar indicates 
that you are at the end, but thumbing down using the left mouse button reveals much more text.
-- Bob


------------------------------------------------------------



    14-Jul-83    McGregor.pa    Re: scrolling very large files
Date: 14-Jul-83 12:59:36 PDT
From: McGregor.pa
Subject: Re: scrolling very large files
In-reply-to: "Maxwell's message of 14 Jul 83 12:48:50 PDT"
To: Maxwell
cc: Pausch

I don't believe that this is a Viewers problem.  Tioga should probably treat anything between 95% and 100% of the viewer as 100% 
for thumbing purposes (ditto for 0% to 5% or some other suitable metric).

I'm actually passing 100% to the client; what they choose to do with it is another problem...

"It will all be wonderful in Tioga2".

Thanks,

Scott.
    14-Jul-83    PolleZ.pa    Spaces at ends of lines
Date: 14-Jul-83 14:04:20 PDT
From: PolleZ.pa
Subject: Spaces at ends of lines
To: TiogaImplementors^
cc: PolleZ
Reply-To: PolleZ.pa

Spaces at the ends of lines seem to be second-class citizens: no matter how hard I try, I can't select one so that the insertion 
caret is at the right edge of it, whereas I can with other characters.  How come?  I really would like to be able to do this - for 
example, sometimes the next character (on the following line) is in a different font, so that selecting the left edge of it and 
inserting is less convenient.

                    Polle
    14-Jul-83    McGregor.pa    ChoiceButtons
Date: 14-Jul-83 14:13:33 PDT
From: McGregor.pa
Subject: ChoiceButtons
To: CedarUsers^
Reply-To: McGregor

Do you use the ChoiceButtons interface?  Please check, and if so, speak up or it may go away...

Thanks,

Scott.
    14-Jul-83    Paxton.pa    Viewers automatic column height adjust
Date: 14-Jul-83  9:53:51 PDT
From: Paxton.pa
Subject: Viewers automatic column height adjust
To: Pausch, McGregor

I have lots of icons around.  I start with the usual one row of icons at the bottom, but as I work that gets full and icons start 
going in the second row.  Trouble is, I have to adjust the height manually -- what I'd really like is a way to tell Viewers to show 
as many rows of icons as necessary.  I.e., if I have icons in the second row, shorten the columns automatically so I can see them.  
Sounds like a simple hack to add.

--Bill
    18-Jul-83    teitelman.pa    Re: TiogaOps
Date: 18 Jul 83  9:52:49 PDT
From: teitelman.pa
Subject: Re: TiogaOps
In-reply-to: "Your message of 12-Jul-83 23:35:00 PDT"
To: gnelson
cc: cedardiscussion^
Reply-To: teitelman.pa

"When I set breakpoints in the code, the action area grabs the insertion carat as soon as the breakpoint is hit. It seems to 
restore the selection before proceeding, and, in fact, the code always works when I step through it with breakpoints.  When I 
remove the breakpoints, it sometimes flashes "can't do it", and fails to insert the new nodes.  Sometimes it inserts only rheader 
and not rtext.  Does anybody have any idea what's going on, or suggestions for how to debug this?"


I don't want to go into why the action area grabs the carat (for almost all break points, you are going to want to type smoething 
to the action area anyway), but you are right that it does grab it and therfore, it does save and restore it. In addition, if you 
want to see what the current selection was before the action occurred, there is a command called showselection. If you want to 
interpret expressions in the action area which require that the selection be where it was, e.g. calls to TiogaOps. there is another 
command called restoreselection which restores the current selection before each event. (Both of these are documented in 
userexec.tioga.) I hope this helps. Otherwise, let's discuss what I could provide that would.

warren
    
    18-Jul-83    teitelman.pa    Proceed be guarded button
Date: 18 Jul 83  9:55:20 PDT
From: teitelman.pa
Subject: Proceed be guarded button
To: cedarusers^
Reply-To: teitelman.pa

It has been suggested that the proceed button in actionareas be guarded, the reason being that it is awfully easy to hit Proceed 
when aiming for Find. This would of course mean that you would have to quick proceed twice to proceed. Is there a strong 
groundswell for this change?

warren
    18-Jul-83    teitelman.pa    buttons, menus etc.
Date: 18 Jul 83  9:40:16 PDT
From: teitelman.pa
Subject: buttons, menus etc.
To: tiogaimplementors^
cc: teitelman
Reply-To: teitelman.pa

appropos of earlier conversation on things I would like to see done with buttons, we (Randy and I) discussed ways of making the 
menu information into a data structure that the user could edit. For example, some users might want to make certain buttons be 
guarded, and others might not. It is hard to make this sort of change when the information is stored in a program, but a lot easier 
if it is represented as data in a file, e.g. a profile.

warren
    19-Jul-83    McGregor.pa    Interface changes for PreISLCedar vs Cedar 4.4 ...
Date: 19-Jul-83 10:30:33 PDT
From: McGregor.pa
Subject: Interface changes for PreISLCedar vs Cedar 4.4 release
To: Atkinson
cc: Pausch, Wyatt

Russ;

Could you let Randy and me know when you've snapshotted the TIP and Viewers stuff from <PreISLCedar> and stored them on <PreCedar> 
or <Cedar>?  We'd like to use that directory as a staging area for the new Viewers changes...

Thanks,

Scott.
    19-Jul-83    PolleZ.pa    Interaction between Look.s and Look.d
Date: 19-Jul-83 15:44:37 PDT
From: PolleZ.pa
Subject: Interaction between Look.s and Look.d
To: TiogaImplementors^
cc: PolleZ

When you select a section of text containing subscripts and make it use a smaller font, why don't the subscripts get smaller too?

Polle
    20-Jul-83    teitelman.pa    rolling back at inopportune times
Date: 20 Jul 83 11:36:11 PDT
From: teitelman.pa
Subject: rolling back at inopportune times
To: mcgregor
cc: pausch, levin, teitelman 

Scott,

this is a recapitulation of our discussion.

There are various times in the running of a program when clicking the rollback button to cause a rollback will result in 
information being lost. The case that is currently covered (built in to the implementaiton of the rollback button) is where tioga 
documents have been edited but not saved. Rollback asks the user whether to go ahead with the rollback, thereby losing edits, or to 
abort.

I have another situation where I would like to inform the rollback button to inform the user that it might not be a good idea to 
rollback at that exact point, namely when the user has done something requiring that rememberevents.txt be rewritten, and this has 
not yet been done (completed).

What we discussed as a way for a client program to register/inform rollback that this was not a good time, and to allow the user 
the option of saying go ahead anyway, abort, or possibly spin and wait for the operation (the exact nature of which the user might 
not be aware) to complete.

 
 
 warren
 
    26-Jul-83    Stewart.pa    Scrolling message sets
Date: 26 Jul 83 13:46:25 PDT
From: Stewart.pa
Subject: Scrolling message sets
To: TiogaImplementors^, WalnutSupport^
cc: Stewart
Reply-To: Stewart.pa

It is impossible to keep scrolling a typescript or text viewer after one is at the bottom.  It is possible to keep scrolling a 
message set.  Probably the scrolling should stop working when the last message is displayed in the first line of the viewer.  This 
seems to be a general problem with containers.

    -Larry
    18-Jul-83    McGregor.pa    Viewers Bug
Date: 18-Jul-83 13:38:17 PDT
From: McGregor.pa
Subject: Viewers Bug
To: Pausch

Looks easy to fix...

Scott.

-------------------------------------
Date: 18-Jul-83 13:21:41 PDT
From: donahue.pa
Subject: Bug in ViewerEventsImpl
To: McGregor, Maxwell
cc:  donahue

If ViewerEventsImpl.ProcessEvent is called with viewer = NIL (which will happen if you register something for killinputfocus and 
the input focus is not in any viewer yet), then the code 

FOR l: EventProcs _ eventProcs[event], l.rest UNTIL l=NIL DO
IF l.first.before # before THEN LOOP;
IF l.first.filter # NIL AND l.first.filter # viewer 
AND l.first.filter # viewer.class.flavor THEN LOOP;
abort _ l.first.proc[viewer, event, before    ! ABORTED => CONTINUE].abort;
IF abort THEN RETURN;
ENDLOOP;
will fail in the evaluation of viewer.class.flavor.

Jim D.
    28-Jul-83    vanleunen.pa    omigod, now she's fooling around with .tip tables
Date: 28 Jul 83 12:39:17 PDT
From: vanleunen.pa
Subject: omigod, now she's fooling around with .tip tables
To: TiogaImplementors^
cc:  vanleunen
Reply-To: vanleunen.pa

It would be nice if saving a new version of one's own .tip table did an automatic CTRL-! ReadTiogaTipTables, the way that saving a 
new version of one's .profile automatically processes for changed entries. 
    28-Jul-83    vanleunen.pa    CTRL-! and ReadTiogaTipTables
Date: 28 Jul 83 13:09:50 PDT
From: vanleunen.pa
Subject: CTRL-! and ReadTiogaTipTables
To: TiogaImplementors^
cc:  vanleunen
Reply-To: vanleunen.pa

Hmmm ... sometimes I do not seem to be able to get CTRL-! to pay attention to me, and so I have to go do ReadTiogaTipTables 
instead.  Twice now (I think) CTRL-! ignored my deleting an entry from my .tip table.  Is there some magic I don't know about? 
    28-Jul-83    vanleunen.pa    more on CTRL-!
Date: 28 Jul 83 13:20:25 PDT
From: vanleunen.pa
Subject: more on CTRL-!
To: TiogaImplementors^
cc:  vanleunen
Reply-To: vanleunen.pa

Nor can I get CTRL-! to attend to changes within an entry.  (It's a shame, too, I think "control-bang" is one of the more 
attractive expressions I've acquired since coming here.) 
    28-Jul-83    vanleunen.pa    fickle CTRL-!
Date: 28 Jul 83 13:30:28 PDT
From: vanleunen.pa
Subject: fickle CTRL-!
To: TiogaImplementors^
cc:  vanleunen
Reply-To: vanleunen.pa

Then again, sometimes CTRL-! does attend to changes within an entry.  Obviously there's something crucial missing in my grasp of 
what's going on.  Words of one syllable, please? 
    29-Jul-83    Willie-Sue.pa    viewers/tioga funniness
Date: 29 Jul 83 13:00:28 PDT
From: Willie-Sue.pa
Subject: viewers/tioga funniness
To: TiogaImplementors^
cc:  Willie-Sue
Reply-To: Willie-Sue.pa

Here's what I think I did;  I don't know if this is reproducible.  I was doing a save on a (non-split) viewer;  while it was saving 
I selected something for deletion, moved the input focus to the exec typescript & did a login.  I then noticed that the file had 
been saved, the deletion done, but [New Version] did NOT appear in the caption.  A Reset did restore the version I had just saved.

  Cheers.
    30-Jul-83    Spreitzer.pa    LogicalWord select
Date: 30 Jul 83 15:17:06 PDT
From: Spreitzer.pa
Subject: LogicalWord select
To: TiogaImplementors^.PA
cc: Spreitzer.PA, winslett.pa 
Reply-To: Spreitzer.pa

I have wanted this too.

-------------------------------------
Date: 30 Jul 83 10:25:37 PDT
From: winslett.pa
Subject: mice
To: spreitzer
cc: 

To the remover of small annoyances:

What I want is a mouse click that selects a logical word, eg given SprintFileAndDatabase it would allow me to select "Sprint" or 
"And" or whatever, rather than just one letter or the whole thing.

--Marianne

------------------------------------------------------------

1) Is it so easy that I can run right out and do it? (If so, how?)

2) If not, is it so easy that you can run right out and do it? (If so, will you? please?)

3) If not, consider this lobbying to have it in Tioga 2.

Mike
    29-Jul-83    Maxwell.pa    PaintViewer[hint: client, clearClient: FALSE]
Date: 29 Jul 83 12:04:56 PDT
From: Maxwell.pa
Subject: PaintViewer[hint: client, clearClient: FALSE]
To: Pausch
cc: McGregor, Maxwell

Mike Sprietzer points out that although the documentation in ViewerOps.mesa implies that the children of a viewer won't be 
repainted if hint = client and clearClient = FALSE, they in fact get repainted no matter what.  He would like the implementation 
changed so that the children don't get repainted in this case. 

John.
    29-Jul-83    McGregor.pa    Re: PaintViewer[hint: client, clearClient: FALSE]
Date: 29-Jul-83 14:51:09 PDT
From: McGregor.pa
Subject: Re: PaintViewer[hint: client, clearClient: FALSE]
In-reply-to: "Maxwell's message of 29 Jul 83 12:04:56 PDT"
To: Maxwell
cc: Pausch

Fixed in the new Viewers...

Scott.
     3-Aug-83    Maxwell.pa    ViewerLocksImpl.CallUnderXXXLock and UNWIND
Date:  3 Aug 83 10:07:28 PDT
From: Maxwell.pa
Subject: ViewerLocksImpl.CallUnderXXXLock and UNWIND
To: Pausch
cc: Plass, McGregor

Each of the CallUnderXXXLock procedures should release its locks when an UNWIND is raised.  The best place for the catch phrase is 
in the call on the client's procedure, e.g.:

CallUnderWriteLock: PUBLIC SAFE PROC [proc: PROC, viewer: Viewer] = TRUSTED BEGIN
    ENABLE { 
        AMEvents.Debugging => MarkColumnWedged[ViewerColumn[viewer]];
        AMEvents.Debugged => MarkColumnUnWedged[ViewerColumn[viewer]]};
    AcquireWriteLock[viewer];
    proc[ ! UNWIND => ReleaseWriteLock[viewer]];
    ReleaseWriteLock[viewer];
    END;

    John.
     6-Aug-83    crow.pa    Color Cursor and Overlays
Date:  6 Aug 83 11:01:30 PDT
From: crow.pa
Subject: Color Cursor and Overlays
To: ISL^
Reply-To: crow.pa

The standard mode for the color display allows a 2-bit overlay plane which can be useful for the cursor, pop-up menus, etc.  The 
two extra bits, in effect, allow switching between 4 different color maps on a pixel-by-pixel basis.  I propose that the default 
use of the four maps be as follows:
0 - Standard or user-supplied color map
1 - Cursor color (may be chosen to complement or otherwise modify map 0, or be constant)
2 - Constant overlay color
3 - 2nd constant overlay color

This gives a cursor color which is guaranteed to show up and two colors (eg. black and white) to use for opaque pop-up menus, etc.  


The color display allows the overlay bits (also the regular display) to be panned around with very low overhead (no BitBlts 
necessary) by updating "Channel Control Blocks".  As I understand it, it is possible, by manipulating control blocks to 
independently control a number of cursors and overlays as long as no more than one occupies a given scan line (shades of Atari game 
computers!!).

What level of function would people like for the above purposes?  I am about to start mucking around with the B-channel and I'm 
willing to build as much generality into the resulting imager functions as it appears people will use.  Full generality is possible 
(overlapping overlays, cursors, etc.) with only minor hiccups as bitmaps get combined and separated when occupying overlapping sets 
of scan lines.

One major purpose here is to try to better understand what sorts of features belong in the Dragon display.  Very little use has 
been made of the Dorado color board's capabilities so far, and I need evidence that all the goodies therein really are useful.

Note that none of this will work on 24-bit color.  Also note that up to 4 bits can be used for the overlays if less than 8 are used 
for the primary display (primary + overlay <= 10 bits).  

Frank
     8-Aug-83    vanleunen.pa    embarrassing question for the evening
Date:  8 Aug 83 18:51:59 PDT
From: vanleunen.pa
Subject: embarrassing question for the evening
To: TiogaImplementors^
cc:  vanleunen
Reply-To: vanleunen.pa

(Oh well, I figure silly mail from me is probably much more entertaining than anything else you have to think about at the moment.)

How can I see on line where I've put PageBreak nodes in a document?
     8-Aug-83    Pier.PA    Tioga/Viewers bug
Date: Mon, 8 Aug 83 17:06 PDT
From: Pier.PA
Subject: Tioga/Viewers bug
To: McGregor, Pausch
cc: Pier

1. Open a new viewer. Load a text file into it, say FOO.TIOGA.
2. RIGHT (Blue) Bug CLEAR in that viewer. Viewer closes and new one appears.
3. Load a different text file, say FEE.TIOGA into the new viewer.
4. Open the iconic viewer, FOO.TIOGA
5. Observe: viewer opens with FEE in it instead of FOO. FOO may appear as the name of the viewer, but FEE is in it. Resetting the 
viewer will bring up FOO correctly.
    10-Aug-83    teitelman.pa    minor flame
Date: 10 Aug 83 15:39:23 PDT
From: teitelman.pa
Subject: minor flame
To: tiogaimplementors^
Reply-To: teitelman.pa

the fact that tabs line up differently on your screen than when printed is to my mind the single biggest annoyance in tioga. I 
usually have to make about five trips down the hall to the printer to get something right, and then it looks terrible on my 
display. I hope you fix this sometime.

warren
    11-Aug-83    Cattell.pa    I'm told you should have this
Date: 11 Aug 83  9:44:17 PDT
From: Cattell.pa
Subject: I'm told you should have this
To: Pausch

-------------------------------------
Date: 11 Aug 83  9:12:43 PDT
From: Cattell.pa
Subject: reminder
To: McGregor
cc: Cattell

For you, or whoever takes over Buttons when you're off in the rainforest:

I need a way in the Buttons interface to change the clientData associated with a button.  Something like ReLabel, but maybe called 
ReData instead?
------------------------------------------------------------
    11-Aug-83    McGregor.pa    Bug File
Date: 11-Aug-83  9:49:09 PDT
From: McGregor.pa
Subject: Bug File
To: Plass
Reply-To: McGregor
cc: Pausch, Paxton

Michael;

I've stored the collected set of user requests regarding the Viewers package on /Indigo/CedarViewers/Temp/Bugs.mail.

Many of the requests will be fixed as a result of Randy's menu rework.

Scott.
    11-Aug-83    Horning.pa    Caret Looks
Date: 11 Aug 83 17:47:45 PDT
From: Horning.pa
Subject: Caret Looks
To: TiogaImplementors^
cc: WalnutSupport^, Horning
Reply-To: Horning.pa

For your file of "things that ought to be fixed in the next go-round."

-------------------------------------
Date: 11 Aug 83 17:16:10 PDT
From: Willie-Sue.pa
Subject: Re: Two Walnut glitches
In-reply-to: "Your message of 11 Aug 83 11:33:55 PDT"
To: Horning
cc: Willie-Sue

Yes, the caret has looks attached to it.  The problem is that there is no easy (and almost NO) way to find out what the current 
caret looks are, so they could be saved & restored.  Since the odd looks in sent messages are pretty much harmless, this won't get 
fixed.

I didn't think about perhaps having to make the typescript smaller when changing databases.  SMOP.

  WS
------------------------------------------------------------
    12-Aug-83    Plass.pa    Tioga Q&A
Date: 12-Aug-83 10:19:00 PDT
From: Plass.pa
Subject: Tioga Q&A
In-reply-to: "vanleunen's message of 8 Aug 83 18:51:59 PDT"
To: vanleunen
cc: CedarUsers^
Reply-To: Plass



Q: How can I see on line where I've put PageBreak nodes in a document?

A: To find PageBreak nodes in a document:
1. Type "PageBreak" into the Target field of the EditTool
2. Type CNTRL-_ to set the format on the (now empty) node in the target field (yuk -- invisible state)
3. Clear "Text" and set "Format" in the "Pick one or more:" section.
4. Now the Search menu item will find pagebreak nodes for you.


    12-Aug-83    Horning.pa    Re: Tioga Q&A - PageBreak nodes
Date: 12 Aug 83 11:51:24 PDT
From: Horning.pa
Subject: Re: Tioga Q&A - PageBreak nodes
In-reply-to: "PolleZ's message of Fri, 12 Aug 83 11:33 PDT"
To: PolleZ
cc: Plass, CedarDiscussion^
Reply-To: Horning.pa

Polle,

You CAN put text in pageBreak nodes. It appears in a paragraph at the bottom of the page (sometimes useful for footnotes and that 
sort of thing). It's only empty pageBreak nodes that are invisible. Unfortunately, that's usually the kind that I need to use.

Your other points make a lot of sense to me, except that Tioga 1 is not  WYSIWYG editor (ever try to build a table where the 
columns line up?). Hopefully, this is one of the things that will be fixed in the wonderful world of Tioga 2.

Jim H.

    12-Aug-83    Willie-Sue.pa    the next time interfaces can change
Date: 12 Aug 83 12:03:33 PDT
From: Willie-Sue.pa
Subject: the next time interfaces can change
To: TiogaImplementors^
cc:  Willie-Sue
Reply-To: Willie-Sue.pa

Please provide a way to do GetLooks on the caret.
    12-Aug-83    mitchell.pa    Re: Tioga Q&A - PageBreak nodes
Date: 12 Aug 83 12:38:44 PDT
From: mitchell.pa
Subject: Re: Tioga Q&A - PageBreak nodes
In-reply-to: "PolleZ's message of Fri, 12 Aug 83 11:33 PDT"
To: PolleZ
cc: Plass, CedarDiscussion^
Reply-To: mitchell.pa

What I would like to see in Tioga II is a way of displaying some or all of the properties and their values associated with every 
node (this includes Format, Comment, etc.) so that I don't have to use the EditTool to probe for them one at a time.  In fact, I 
think of the contents as just one of the interesting properties that I want to see, and I would like to specify what properties are 
displayed at a give time - this is a property of a viewer and not of the document itself.

--Jim M.
    12-Aug-83    PolleZ.PA    Re: Tioga Q&A - PageBreak nodes
Date: Fri, 12 Aug 83 11:33 PDT
From: PolleZ.PA
Subject: Re: Tioga Q&A - PageBreak nodes
In-reply-to: "Your message of 12-Aug-83 10:19:00 PDT"
To: Plass
cc: CedarDiscussion^

Mary-Claire's question has reminded me that PageBreak node invisibility is something that I've groused about to myself in the past.

I don't doubt that PageBreak nodes can be found in the way you've described.  However, my experience with them has been that I 
would MUCH prefer that they were visible in some way--as a blob, a sequence of dashes, anything!  Having to explicitly hunt for 
them (via a nontrivial set of actions, yet) is too much work.  Even after you've found them, you scroll the document a few times 
and you've forgotten where they were.  Furthermore, if you're editing someone else's document, you don't even know to hunt for them 
until you get some strange and undesirable results from the printer.  WYSIWYG editors are supposed to reduce the number of trips to 
the printer, not increase it.

This is an area where WYSIWYGness traditionally has trouble, but resolving it in favor of "what you can't see is what you get" 
seems like a lose.  I think it's better for things to appear in the document that don't appear in the printed version than vice 
versa.  Editing is easier when you can see--directly, without excess incantations--the things that affect the printed result (in 
those cases that you can't see a facsimile of the result).

Is there some overriding reason why PageBreak nodes are invisible on the screen?  If you don't want to make the node appear on the 
screen as something, you could make the contents of a PageBreak node not print, so that users could insert their own text to alert 
themselves.  This solution is not as good for editing someone else's document, though.

                Polle 
    12-Aug-83    Maxwell.pa    Target with node breaks
Date: 12 Aug 83 15:00:35 PDT
From: Maxwell.pa
Subject: Target with node breaks
To: TiogaImplementors^.pa
Reply-To: Maxwell.pa

Mike Sprietzer observed that 'Find' and 'Search' both fail to work if the target contains a node break.  For example consider the 
two following lines:

Foo Bar
Bar Foo

Foo Bar
Bar Foo

If you select "Foo Bar Bar Foo" and click 'Find', it will not find the second example.  If you copy "Foo Bar Bar Foo" into the Edit 
Tool and then click 'Search', it will search for just "Foo Bar".  (Clicking 'Count' will count 5 examples of in this message, even 
though there are only two.)

John.

    12-Aug-83    Maxwell.pa    a change for MBQueue
Date: 12 Aug 83 12:47:45 PDT
From: Maxwell.pa
Subject: a change for MBQueue
To: TiogaImplementors^.pa
Reply-To: Maxwell.pa, Willie-Sue.pa 

-------------------------------------
Date: 12 Aug 83 12:07:44 PDT
From: Willie-Sue.pa
Subject: a change for MBQueue
To: Maxwell
cc:  Willie-Sue

Walnut is currently using a private version of MBQueue (called WQueue to save sanity) with the following change:


Flush: PROC [q: Queue, proc: PROC[Action]_ NIL];
  -- Flushes all pending button presses and menu selections in the context of q.  This procedure
  -- can be called, e.g., when some illegal actions suggests the user is confused an further
  -- mouse-ahead should be ignored.
  --  proc will get called for each Action in the queue, to allow cleanup, NOTIFY's, etc

The reason is that Walnut sticks things on its queue which contain condition variables;  the programs hanging on any variables that 
get flushed from the queue would then be hung forever (a good way to lose your exec, etc.)
The implementation:

Flush: PUBLIC ENTRY PROC [q: Queue, proc: PROC[Action]_ NIL] = {
  event: Event;
  IF proc = NIL THEN q.firstEvent_ NIL
   ELSE
   UNTIL q.firstEvent = NIL DO
     event_ q.firstEvent;
     q.firstEvent_ q.firstEvent.rest;
     proc[event.first];
   ENDLOOP;
  };


Thanks, ws

------------------------------------------------------------

    15-Aug-83    Plass.pa    Re: Tioga Q&A - PageBreak nodes
Date: 15-Aug-83  9:36:40 PDT
From: Plass.pa
Subject: Re: Tioga Q&A - PageBreak nodes
In-reply-to: "mitchell's message of 12 Aug 83 12:38:44 PDT"
To: mitchell
cc: Plass, CedarDiscussion^
Reply-To: Plass.pa


There is a program called AnnotateProperties (written by Rick Beach last summer) that will insert comment nodes in your Tioga-I 
document that describe the format, properties, etc.  Run it, and it registers two commands with the exec, AnnotateProperties and 
PruneAnnotations; the latter undoes the effect of the first.  These programs save the document after they make their changes, so it 
might be prudent to back your file up first, although I haven't had any files clobbered by them.

Michael




    16-Aug-83    Horning.pa    MIDDLE-select
Date: 16 Aug 83 13:48:31 PDT
From: Horning.pa
Subject: MIDDLE-select
To: TiogaImplementors^
cc: CedarSupport^, Horning
Reply-To: Horning.pa

I notice the following anomalous property of MIDDLE-select: If I am over a word when I go down on MIDDLE, I get word-select. 
However, if I roam around with MIDDLE down, I can get into a mode where single characters are selected (and underlined). One way to 
get into this mode appears to be to pass a point that causes the selection to be the end of a typescript, but there may be others. 
Once in the mode, it seems to persist, even into other viewers, and sometimes even after MIDDLE released and depressed again. 
Strange. Like a confusion about what TIP table to use?

Jim H.
    16-Aug-83    Plass.pa    Vewers bug fixes
Date: 16-Aug-83  9:55:24 PDT
From: Plass.pa
Subject: Vewers bug fixes
To: Pausch
Reply-To: Plass
cc: McGregor, Plass


Randy,

I found and fixed several bugs in the new Viewers, and put the fixed versions on CedarViewers.  The changes were in

CaretsImpl.InvertCaret
VFontsImpl.EstablishFont
ViewerBLTImpl.BLTViewer
WindowManagerImpl.PostScrollFeedback

Let me know if you need any help merging these changes in.

Michael

    17-Aug-83    vanleunen.pa    Desktops
Date: 17 Aug 83 22:58:16 PDT
From: vanleunen.pa
Subject: Desktops
To: CedarUsers^, CedarFolklore^
cc:  vanLeunen
Reply-To: vanleunen.pa

Jim Horning just recently mentioned John Maxwell's Desktops to me, and I love them and thought I might draw them to other people's 
attention as well.  A desktop is a way of capturing a configuration of viewers, and it's possible to move from one desktop to 
another.  Here is how I use them:

After a Rollback my screen contains an open UserExec and icons for one text file (called, perspicuously, ThingsToDo.tioga), a 
TSetter, the FileTool, and the Clock.  I putt-putt along merrily in that world, reading my mail, writing about commas, trying to 
write with the Alpine documentation, fooling around with some demonstration button-helps for Maintain -- all the while opening 
viewers and creating icons.  Finally things start getting messy enough to offend me and slow me down.  At that point, I do:

&n Desktop Messy

to create a desktop of my current messy state.  (I might destroy some viewers first, but usually I don't bother.)  Down at the 
lower right-hand corner of the screen, Desktop makes a nice little squared-off icon named Messy.  I then do Desktop again, 
immediately, for the task I plan to continue or begin next; say for instance:

&n Desktop Buttons

Down at the lower right-hand corner of the screen, Desktop makes a nice little squared-off icon named Buttons.  The Messy desktop 
shows that it is the current one by showing its name in white on black; the Buttons desktop has its name in black on white.  I then 
"fly to" the Buttons desktop (that's Maxwell's metaphor, not mine) by control-middle-clicking it.  (I could equally well have 
opened the Buttons desktop icon and left-clicked FlyTo.)

Shazam, my screen is clear again and I have icons for only my A: UserExec and the two desktops.  (Every desktop automatically 
includes the A: exec and all desktops.)  Buttons is now the current desktop and has its name in white on black.)  I open the icon 
for the old Messy desktop and left-click only the things I want for my current task, several files and the FileTool and the Clock 
and Maintain.  I don't actually want the exec on this desktop but I don't destroy it -- that's the only inconvenient thing about 
desktops, that destroying such a viewer would have awkward results.

Again I putt-putt along till the desire to read my mail overwhelms me.  So I do:

&n Desktop Mail

That creates my third desktop.  Again I fly to it and again I fetch the things I want from my old Messy desktop.  Meanwhile the 
Buttons desktop is preserving exactly the state I had reached in doing my button-helps.  When I have temporarily sated my mail 
addiction, I fly back to Buttons and resume fooling around.

The documentation for Desktops is in [Indigo]<Cedar>Documentation>ViewerDoc.tioga.  I believe Jim uses them rather differently from 
the way I do -- maybe he and John would be willing to describe what they do?

(To destroy a viewer other than a plain Tioga viewer on one desktop while keeping it on another desktop, select the viewer you want 
to destroy and left-click AddSelected on the desktop where you want to keep it.  Even if it's already there.)

(One small sorry note:  Building up Desktops I had my first experience of running out of virtual memory.)  (At least now I know 
what virtual memory is.) 
    18-Aug-83    Horning.pa    Re: Desktops
Date: 18 Aug 83 10:42:43 PDT
From: Horning.pa
Subject: Re: Desktops
In-reply-to: "Your message of 17 Aug 83 22:58:16 PDT"
To: vanleunen
cc: CedarUsers^, CedarFolklore^
Reply-To: Horning.pa

Mary-Claire,

Yes, my style of using Desktops is considerably different. Perhaps it is because my activities are more predictable, or because I 
am compulsively tidy (about some things--certainly not about my real desktop!).

I include three Desktops in my Checkpoint, so that when I start the day or Rollback I'm conveniently set up for any of three modes 
of activity:

- On my Mail Desktop (which is Current in the Checkpoint) I have opened Watch, Executive A, Walnut, Active Messages, and Whiteboard 
Scratch (which I use like your ThingsToDo.tioga, but with 5 text boxes--for Priority Activities, This Week's Calendar, Pending 
Activities, Long-term Calendar, In Progress Activities, Past Calendar (accumulated for Activity Report time)). I also have icons 
for Maintain, Debug Local, File Tool, Clover, Encryption Tool, Clock, and Edit Tool.

- On my Editing Desktop, I have opened Watch, Executive A, Edit Tool, Clover, and Larch-Handbook.tioga (my current editing task). I 
also have icons for Edit History Tool, Encryption Tool, Clock, Debug Local, File Tool, Walnut, and TiogaDoc.tioga.

- On my Phone Desktop, I have opened Watch, Executive A, Horning.TDir, Finch, and Telephone Directory: Personal. I also have icons 
for Clock, File Tool, Walnut, and Debug Local.

I rarely create further Desktops during a session. When one of my existing Desktops gets too cluttered, I just start deleting 
icons. Switching Desktops corresponds to a fairly major switch of attention.

Jim H. 
    18-Aug-83    Horning.pa    Levels: Bugs or Features?
Date: 18 Aug 83 12:18:44 PDT
From: Horning.pa
Subject: Levels: Bugs or Features?
To: TiogaImplementors^
cc: Donahue, Maxwell, Horning
Reply-To: Horning.pa

Since Whiteboard text boxes don't have Level menus, I find myself relying on the "scroll with level adjustment" more there than in 
other documents. Two aspects of this have surprised me:

- I can't seem to get minimum levels with SHIFT-CTRL when the cursor happens to be alongside a bottom-level node (in a small text 
box, it can frequently be the case that only bottom-level nodes are visible). Is Tioga trying to protect me against myself or 
something?

- SHIFT and CTRL only seem to be effective in combination with LEFT. I find myself wanting to do things like "thumb to middle and 
show all levels" or "return to top and show minimum levels." Is there any reason not to make SHIFT and CTRL effective with all 
three mouse buttons?

Jim H.
    22-Aug-83    McGregor.pa    Re: BNF (best read on a wide viewer
Date: 22-Aug-83 13:18:41 PDT
From: McGregor.pa
Subject: Re: BNF (best read on a wide viewer
In-reply-to: "Your message of 22-Aug-83 12:57:50 PDT"
To: Pausch

Randy;

In general, it looks fine.  Before you make your slides though...

A few comments/questions:

1)  What's an ID?  It only appears in LHS's.  I assume you'll tell people that the new menu files contain a list of ITEMs.
2)  What are the defaults for breakBefore, breakAfter, beginsActive, and notifyProc?
3)  I don't understand notrigger.
4)  shiftLeftUp was left out.
5)  I suggest defining PROC as "'#' IMPL '.'  ITEM" or some such where IMPL and ITEM are STRINGs.  That way, you convey a bit more 
semantics.
6)  How about renaming "COMPLEX" to be "TRIGGERLIST" and rename "TRIGGERLIST" to be "TRIGGER" since it really isn't a list.
7)  Nit:  in one place you use "STRINGORPROC" in another you use "(STRING | PROC)"
8)  Something to ponder:  Could you always use STRINGORPROC in place of STRING?

Scott.
    22-Aug-83    Maxwell.pa    viewer blt bug
Date: 22 Aug 83 11:24:45 PDT
From: Maxwell.pa
Subject: viewer blt bug
To: Pausch
cc: Plass, McGregor

I found the source of the viewer blt bug that we saw Friday.  I had an unmonitored call to CloseViewer with paint: FALSE.  To fix 
it, replace ViewerOpsImplA.GrowViewer with the following code:



GrowViewer: PUBLIC PROC [viewer: Viewer, paint: BOOL _ TRUE] = BEGIN
LockedGrowViewer: PROC = {
FOR v: Viewer _ rootViewerTree[viewer.column], v.sibling WHILE v # NIL DO
IF v = viewer THEN LOOP;
ViewerOps.CloseViewer[v, FALSE]; -- must be under a lock!
IF paint THEN ViewerOps.PaintViewer[v, all]; -- just paint the icon
ENDLOOP; 
InternalComputeColumn[viewer.column, paint]};

IF viewer.iconic THEN {ViewerOps.OpenIcon[viewer, TRUE, paint]; RETURN};
IF ViewerEvents.ProcessEvent[grow, viewer, TRUE].abort THEN RETURN;
IF viewer.offDeskTop THEN ChangeColumn[viewer, left];

FOR v: Viewer _ rootViewerTree[viewer.column], v.sibling WHILE v # NIL DO
IF v # viewer THEN KillInputFocus[v]; -- done here to prevent deadlock
ENDLOOP; 
ViewerLocks.CallUnderColumnLocks[LockedGrowViewer, viewer.column, static];
<<-- you MUST acquire the static column here, since CloseViewer needs it.>>

[] _ ViewerEvents.ProcessEvent[grow, viewer, FALSE];
END;



Please test the code when you get a chance.

John.
    22-Aug-83    Maxwell.pa    Re: GrowViewer
Date: 22 Aug 83 15:52:05 PDT
From: Maxwell.pa
Subject: Re: GrowViewer
In-reply-to: "Your message of 22-Aug-83 15:39:22 PDT"
To: pausch
cc: Maxwell


Try this:


GrowViewer: PUBLIC PROC [viewer: Viewer, paint: BOOL _ TRUE] = BEGIN
LockedGrowViewer: PROC = {
v, next: Viewer _ NIL;
v _ rootViewerTree[viewer.column];
WHILE v # NIL DO
next _ v.sibling;
IF v # viewer THEN {
ViewerOps.CloseViewer[v, FALSE]; -- must be under a lock!
IF paint THEN ViewerOps.PaintViewer[v, all]}; -- just paint the icon
v _ next;
ENDLOOP; 
InternalComputeColumn[viewer.column, paint]};

IF viewer.iconic THEN {ViewerOps.OpenIcon[viewer, TRUE, paint]; RETURN};
IF ViewerEvents.ProcessEvent[grow, viewer, TRUE].abort THEN RETURN;
IF viewer.offDeskTop THEN ChangeColumn[viewer, left];

FOR v: Viewer _ rootViewerTree[viewer.column], v.sibling WHILE v # NIL DO
IF v # viewer THEN KillInputFocus[v]; -- done here to prevent deadlock
ENDLOOP; 
ViewerLocks.CallUnderColumnLocks[LockedGrowViewer, viewer.column, static];
<<-- you MUST acquire the static column here, since CloseViewer needs it.>>

[] _ ViewerEvents.ProcessEvent[grow, viewer, FALSE];
END;



    23-Aug-83    gomez.pa    drawing routines
Date: 23 Aug 83 10:52:36 PDT
From: gomez.pa
Subject: drawing routines
To: Pausch

DoDrawCircle: PROC [dc: Graphics.Context] = 
{   x, y, theta: REAL _ 0.;
IF color = white THEN Graphics.SetColor[dc, Graphics.white]        -- set color to white
                    ELSE  Graphics.SetColor[dc, Graphics.black];        -- set color to black
Graphics.SetCP[dc, controlPoint.x + radius, controlPoint.y];
UNTIL theta > 2*3.1416 DO
x _ radius * RealFns.Cos[theta] + controlPoint.x;
y _ radius * RealFns.Sin[theta] + controlPoint.y;
Graphics.DrawTo[dc, x, y];
theta _ theta + 3.1416 / 12.;
ENDLOOP; 
};

DoDrawOct: PROC [dc: Graphics.Context] = 
{   x, y, theta: REAL _ 0.;
IF color = white THEN Graphics.SetColor[dc, Graphics.white]        -- set color to white
                    ELSE  Graphics.SetColor[dc, Graphics.black];        -- set color to black
Graphics.SetCP   [dc, controlPoint.x + radius  , controlPoint.y - radius/3.];
Graphics.DrawTo[dc, controlPoint.x + radius  , controlPoint.y + radius/3.];
Graphics.DrawTo[dc, controlPoint.x + radius/3., controlPoint.y + radius];
Graphics.DrawTo[dc, controlPoint.x - radius/3., controlPoint.y + radius];
Graphics.DrawTo[dc, controlPoint.x - radius,    controlPoint.y + radius/3.];
Graphics.DrawTo[dc, controlPoint.x - radius,    controlPoint.y - radius/3.];
Graphics.DrawTo[dc, controlPoint.x - radius/3., controlPoint.y - radius];
Graphics.DrawTo[dc, controlPoint.x + radius/3., controlPoint.y - radius];
Graphics.DrawTo[dc, controlPoint.x + radius,    controlPoint.y - radius/3.];
};

    18-Aug-83    Maxwell.pa    locking the message window
Date: 18 Aug 83 11:48:37 PDT
From: Maxwell.pa
Subject: locking the message window
To: Pausch
cc: Plass, McGregor

There is a simple deadlock involving the message window:

Process A:    PaintViewer => read lock a column.
Process B:    OpenIcon or CloseViewer =>
                CallUnderColumnLocks[static, column] => 
                write lock the static column then 
                wait for Process A's column.
Process A:    MessageWindow.Append (print error message) => PaintViewer =>
                attempt to read lock the static column. (dead lock)
                
I can think of two ways around it:
    1) Make up a new column just for the message window, or
    2) have CallUnderColumnLocks lock the static column last.

1) is conceptually cleaner, but 2) is easier to implement.  Can you think of any reason a process would acquire the static column 
and then later decide it also wanted another column?

John.
                                                    
    25-Aug-83    vanleunen.pa    Re: interlineation
Date: 25 Aug 83 12:03:40 PDT
From: vanleunen.pa
Subject: Re: interlineation
In-reply-to: "Your message of 25-Aug-83  9:59:04 PDT"
To: Beach
cc: vanleunen, TiogaImplementors^
Reply-To: vanleunen.pa

... see edittool "Patterns for Search and Substitute" which describes how to use patterns to match things. Perhaps you can use the 
multiple instances of named subpatterns to generate the duplicates you desire. Possibly ...  etc.

Hmmm.  This is not exactly my idea of a straightforward solution.  Let me pose the problem in the degenerate case:

I have a list like this (but forty items long rather than three):

    Apple baker charlie.
    Dog easy foxtrot?
    Golf helical isotherm.
    
And I want to make a list like this:

    Apple baker charlie.
    Apple baker charlie.
    Dog easy foxtrot?
    Dog easy foxtrot?
    Golf helical isotherm.
    Golf helical isotherm.
    
How do I do it?