Conference hydra::amiga_v1

I also have been talking to Anker about porting SEDT to the Amiga. He has
agreed to release the sources to me and I am giving it a stab. At first
glance it appears not to be a simple proceedure. It doesn't help that I
am fairly new to the Amiga, but I wanted a challanging project and I guess
I found one. I have no idea how long this might take, but I'm willing to
give it a try!

Frank

I just thought I'd give an update on the SEDT port I am working on. So far
it is going pretty well. It is definitly a major project. The output side
of things is working, ie it opens the window, reads the files, and displays
the screen. I am now working on the input side, which is the more difficult.
I needed to do raw keyboard input so that I could tell the keypad keys from
the main keyboard keys. What I didn't want to do was have a built in table
(like VT100 and SMOKEY) for keyboard character translations. It seemed that
I was going to have to deal with the keymap myself, till deep in the back
of the Devices and Libraries book I found a nice little routine called
RawKeyConvert, which will take a raw key input event, and return the
ASCII translation! This routine is easy to use, and should be put in
SMOKEY to translate the characters. This would fix the problem with
foriegn keyboards. Anyway, once I get the input side working it should
be ready for a limited "field test". Do I have any volunteers? By the
way, does anyone out there know how to tell from a program wether you
are running on a A500/A1000/A2000 ? I need to know this so I can handle
the keymaps correctly.

Frank

if it does EDT I'll test it out on an A500

John

SEDT is a superset of EDT. It is really quite a powerful editor. If anyone
wants to take a look at the user manual, you can copy it from:

TOOTER::DVL:[RIES.SEDT.EDT]SEDTMAN.EDT

Initially, my goal is to just get it to run on the AMIGA from CLI and not
use any AMIGA wizzies, playing it one step at a time.

Frank

re .2

>does anyone out there know how to tell from a program wether you
>are running on a A500/A1000/A2000 ? I need to know this so I can handle
>the keymaps correctly.

I beleive if you use the DeadKeyConvert (re: -1.) you need not know what the
machine is you are using, especially since it is very possible to put a
A2000 keyboard on a A1000, provided you install the proper keymap [which was
posted by CATS to usenet a while back]

Robb

re .5

If you can find some info on DeadKeyConvert please post it. I really want to
make sure I do this right!

Thanks, Frank

Re: .7

>If you can find some info on DeadKeyConvert please post it.

	This is what was posted on Usenet a while ago.  I hope it
helps.

Mark

============================================================================
Newsgroups: comp.sys.amiga
Path: decwrl!decvax!ucbvax!pasteur!cory.Berkeley.EDU!dillon
Subject: AmigaLine 8 - All about keyboard input & RAWKEYS
Posted: 10 Feb 88 19:39:30 GMT
Organization: University of California, Berkeley
 
[This is Bryce Nesbitt, posting via remote-control]
 
----------------------------------------------------------------------------
			Technical Note #8
	  All about keymaps and getting input from the keyboard
 
SUMMARY
 
$ 8/0 All about keymaps and getting input from the keyboard
$ release
$ 29-Jan-88 Bryce Nesbitt / TVD
$ RAWKEY, VANILLAKEY, setmap, keymap, international, DeadKeyConvert()
$ See Also: AmigaMail July/August 1987, AmigaLine #9
 
    There are at least 16 different keyboard configurations for the Amiga.
    If your application expects to work on all of these, it must handle the
    keyboard properly.  Complete, working examples are included.
 
----------------------------------------------------------------------------
 
RAWKEY
 
    If your program processes Intuition RAWKEY messages, it is only half
    baked!  Raw key codes give physical positions; they do not imply
    *anything* about what might be marked on the top of the key.  There are
    a *least* 16 different keyboard configurations available for the Amiga.
 
    RAWKEY messages are ok to use directly for positional control (say, up,
    down, left, and right controls for a game).  They are not acceptable
    for entering *any* sort of text.
 
    RAWKEY messages must be converted with the DeadKeyConvert() function. A
    tutorial is provided.
 
 
VANILLAKEY
 
    If you don't want the hassle of RAWKEYS, just change "RAWKEY" to
    "VANILLAKEY" in your program.  The keys will come through already
    cooked.
 
    The disadvantage is you only get the keys that map to a single
    character.	This eliminates the function, help, and cursor keys.
 
 
CONSOLE DEVICE, CON:, RAW:, CLI, String Gadgets
 
    The console device, CON:, RAW:, CLI, and String Gadgets all provide
    automatic keymap conversion.  Nothing else needed.
 
 
DEAD KEYS
 
    Dead keys are a feature of V.2 Kickstart.  They are used to add accents
    to letters.  To try this out, click into a CLI.  Press and release "ALT
    K".  Now press a letter key such as "a".  It should come out with an
    umlaut.  This is an automatic feature of the keymap conversion process.
 
    Be sure to test to see if accented characters work in your application.
 
 
CUSTOM KEYMAPS
 
    If you wish to build a custom keymap, example source code is provided
    In AmigaLine #9.  This must be put in the "devs:keymaps" drawer, and
    activated with "SetMap".
 
    If your program needs to change a keymap during execution, it must copy
    the current map, modifiy it, then use the modification.
 
 
THE NEW MACHINES
 
    The A500 and A2000 machines add 5 extra keys to the keyboard.  What's
    on top of these keys depends on what country the machine is sold in.
    For the United States the "usa1" keymap knows about the extra keys.
    "usa2" provides the same features with a DVORAK layout.
 
    As of V1.2, Kickstart itself had not been updated to know about the
    keys, or to return the "NUMERICPAD" quailifer when they are pressed.
 
 
DISTRIBUTION DISKS
 
    If you distribute a bootable Workbench disk, it should contain the
    "SetMap" program and the "devs:keymaps" drawer.  This allows a person
    to set up the keymaps to match their keyboard.
 
    Better yet, allow the user to boot up with their normal Workbench, and
    click on your icon to start.
 
    Some of the old international A1000 keyboards do not have the same
    stuff on the tops of the keys as the new international A500/A2000
    keyboards.	Owners of these machines will need to copy their keymap
    over to your disk.
 
 
 
-------Setup needed to use DeadKeyConvert--------
/* Manx users must remove the "ConsoleDevice" line from functions.h */
struct Device	*ConsoleDevice;
struct IOStdReq console_IO;	/* empty, zeroed IOStdReq */
....
    if ( OpenDevice("console.device",-1L,(struct IORequest *)&console_IO,0L) )
	cleanexit(21);
    ConsoleDevice=(struct Device *)console_IO.io_Device;
....
    if (ConsoleDevice)  CloseDevice  ((struct IORequest *)&console_IO);
....
 
----------------DeadKeyConvert.c----------------
#include "exec/types.h"
#include "devices/inputevent.h"
#include "intuition/intuition.h"
 
/*
 * DeadKeyConvert().  Adapted from the Amiga Enhancer Manual
 * by Bryce Nesbitt.
 *
 * Takes an Intuition RAWKEY message and processes it.
 * The result will be "cooked" keys and key conversions in
 * your buffer.
 *
 * The console.device must be open to use this function.
 *
 * The message passed to this must be of Class RAWKEY.
 * Returns -1 if the buffer overflowed, or the
 * number of characters converted if all was ok.
 *
 */
long DeadKeyConvert(msg,kbuffer,kbsize,kmap)
struct IntuiMessage *msg;	/* Message to be converted  */
UBYTE		    *kbuffer;	/* Pointer to your buffer   */
long		    kbsize;	/* Size of your buffer	    */
struct KeyMap	    *kmap;	/* Custom keymap, or Zero   */
{
struct InputEvent ievent;
 
    /* if (msg->Class != RAWKEY) return(-2); */
    if (msg->Code & IECODE_UP_PREFIX)
	return(0);  /* Nothing to do for key up messages */
 
    /* pack message into an input event */
    ievent.ie_NextEvent =0;
    ievent.ie_SubClass	=0;
    ievent.ie_Class	=IECLASS_RAWKEY;
    ievent.ie_Code	=msg->Code;
    ievent.ie_Qualifier =msg->Qualifier;
 
    /* get previous codes from location pointed to by IAddress
     * this "magic" pointer is valid intil the IntuiMessage is
     * replied */
    ievent.ie_position.ie_addr =*((APTR*)msg->IAddress);
 
    return(RawKeyConvert(&ievent,kbuffer,kbsize,kmap));
}
 
 
----------------Complete example-----------------
 
/*
 * 29-Jan-88 Bryce Nesbitt
 *
 * WARNING: In order to compile this program, Manx Aztec C needs to have the
 * line in functions.h that declares "ConsoleDevice();" removed.
 *
 */
#undef LATTICE_4   /* Change to #undef for Manx */
#ifdef LATTICE_4
#include "proto/exec.h"
#include "proto/intuition.h"
#else
#include "functions.h"
extern int Enable_Abort;
#endif
#include "exec/types.h"
#include "intuition/intuition.h"
 
 
struct IntuitionBase *IntuitionBase;
struct GfxBase	     *GfxBase;
struct Device	     *ConsoleDevice;
 
static char buffer[16]; 		/* buffer to convert into */
struct IOStdReq     console_IO; 	/* empty, zeroed IOStdReq */
struct NewWindow    MyNewWindow=
    {
    0,11,200,32,
    1,3,
    RAWKEY|CLOSEWINDOW,
    WINDOWCLOSE|WINDOWDEPTH|WINDOWDRAG|
    SIMPLE_REFRESH|NOCAREREFRESH|ACTIVATE,
    0,0,
    (UBYTE *)"Keymapper",
    0,0,
    64,64,
    -1,-1,  /* No need to limit window growth */
    WBENCHSCREEN,
    };
struct Window	    *MyWindow;
struct IntuiMessage *message;
 
 
 
#ifdef LATTICE_4
CXBREAK()       /* Disable break for Lattice C */
{
    return(0);
}
#endif
 
 
 
void cleanexit(value)
int value;
{
    if (MyWindow)       CloseWindow  (MyWindow);
    if (IntuitionBase)  CloseLibrary ((struct Library *)IntuitionBase);
    if (GfxBase)        CloseLibrary ((struct Library *)GfxBase);
    if (ConsoleDevice)  CloseDevice  ((struct IORequest *)&console_IO);
 
    exit(value);
}
 
 
 
void main()
{
long temp;
 
#ifndef LATTICE_4
    Enable_Abort=0;
#endif
 
    if (!( IntuitionBase=(struct IntuitionBase *)OpenLibrary("intuition.library",33L) ))
	cleanexit(20);
    if (!( GfxBase=(struct GfxBase *)OpenLibrary("graphics.library",33L) ))
	cleanexit(20);
    if (!( MyWindow=OpenWindow(&MyNewWindow) ))
	cleanexit(20);
 
    /*
     *
     * It is not mentioned in the manuals, but the console.device may be
     * opened without attaching it to a window.   To do this, open the device
     * with a unit of -1 and zeroed IOStdReq block.  The console.device
     * pointer will be returned in io_Device.
     *
     * The console.device is also a library... the returned pointer will
     * be used to make calls to it.
     *
     */
    if ( OpenDevice("console.device",-1L,(struct IORequest *)&console_IO,0L) )
	cleanexit(21);
    ConsoleDevice=(struct Device *)console_IO.io_Device;
 
    for(;;)
	{
	WaitPort(MyWindow->UserPort);   /* Wait for one or more messages */
	while( message=(struct IntuiMessage *)GetMsg(MyWindow->UserPort) )
	    {
	    switch (message->Class)
		{
		case RAWKEY:
		    strcpy(&buffer,"               "); /* clear out buffer */
		    temp=DeadKeyConvert(message,&buffer,15L,0L);
		    Move(MyWindow->RPort,66L,22L);
		    Text(MyWindow->RPort,&buffer,15L);
		    break;
 
		case CLOSEWINDOW:
		    cleanexit(0);
		}
	    ReplyMsg((struct Message *)message);
	    }
	}
}

    I would love to test it on my A1000.  I would also love to have a
    mode that allowed use of the serial port, so I could connect a VT220
    to AMY and edit remotely from the main keyboard.

    -jim

re: 8

Thanks much for the DeadKeyConvert information.

re: 9

Depending on how things go, I plan on allowing you to open a buffer on
the serial.device and allowing a VT1XX/VT2XX to be used there for editing.
They are much easier on the eyes, and nicely support 132 column mode. This
way you can have SEDT run as a background task doing all its I/O to the
outboard terminal for editing purposes while you use the AMIGA screen for
compiling, games, etc.

Frank

    Frank,
    
    How is the SEDT port coming?
    
    - steve mcafee

    Steve, the port it going pretty slow. I have been extremely busy on
    a project here at work and have had very little time to do anything
    on the Amiga. It basically runs, but has all sorts of little problems
    here and there. I don't really know why these problems exits, since
    most of the port was hacking the terminal input/output routines. For
    all I know, there could be bugs in the Lattice C compiler which are
    causing the problems. Its a real pain to debug without a source
    language debugger, and SEDT is huge, mostly uncommented, and not
    laid out in the most straightforward way.

    I'll be certain keep everyone updated.

    Frank

    It appears that DEC is marketing the PC version for Anker.  See
    the 10/31/88 Sales Update for details...
    

    As seen in LAPTOP...
    
    It appears that DEC is marketing the PC version for Anker.  See
    the 10/31/88 Sales Update for details...
    

	    		    	I T S ' S  H E R E !

I finally have an initial release of the Sedt port for the Amiga!! Sorry this
took so long, but this was no easy task. Part of my problem was having a buggy
C compiler and no source language debugger. Well, since version 5.01 of
Lattice C and their great source language debugger CodePRobe has arrived the
port progressed nicely. You can get this "field test" release from:

	    CANIS::DUA1:[AMIGA.SEDT]SEDT.ARC

Following the form feed is my "release notes" contained in the README file
in the archive. Please give me feedback on bugs etc which you may find. And
remember, this is field test 1 of Sedt for the Amiga, and I can't gaurantee
that it won't guru or corrupt your file, so use it at your own risk.


Sedt for the Amiga
------------------

This is a preliminary "field test" release of SEDT for the Amiga. It is the
first version which I feel works well enough to release, and its a starting
point for getting some feed back from users. It is by no means complete, in
that there are a few system features such as execute operating system command
etc. that do not work. Also, there is no support for the Amiga 1000 keyboard
layout (sorry 1000 owners).


THIS VERSION OF SEDT IS FOR DEC EMPLOYEE USE ONLY. PLEASE DO NOT DISTRIBUTE
IT TO ANYONE ELSE, AND DO NOT PLACE IT ONTO ANY PUBLIC BBS!


I make no gaurantees about the reliability of this software. Use it at your
own risk! I have been using it to work on itself long enough that I feel it
is stable. So far, no guru's or file corruptions. However, I have not tried
all of the functions in Sedt. This is where you come in. Please send me mail
if you run into any strange behavior, or find that a function does not appear
to work as documented. Also, if you successfully install it on your system,
let me know you are using it so I can get an idea of how much it is being
tested.

The sources that I used as a base for this port are over a year old, and I
would imagine that Anker has added features and/or fixed bugs that are not
in this release. I am going to try and get the latest sources from Anker and
get this version of Sedt up to date.

I have not defined all of the possible combination of keys on the Amiga in
the Sedt database. I would like to get some feedback from users as to what
you would like to see the keys defined as. The help file included shows the
current key mappings. Amiga 1000 owners, please give me some feedback on
how you would like to see the keyboard/keypad mapped. Since the A1000 does
not have the VT style 18 key keypad, how should the keypad be implimented?
What keys should be used as PF1 - PF4 etc?

If you have any suggestions as to Amiga specific features you would like to
see, send me mail. Any changes to Sedt in general should be made directly
to Anker, but if you send them to me, I will forward them to him.

Some features that I plan an adding are:

o	Interlace mode for 48 line support. If I could get some 132 column
	fonts, I'd add 132 col. support.

o	Workbench support

o	Support for AUX: such that Sedt can run on a VTxxx connected to the
	serial port

o	Support for Amiga 1000 keyboard layout


Known bugs
----------

o	None of the commands which invoke a system command or CLI work.
	They do not (I don't believe) crash the system or Sedt, they
	just don't do the right thing.

o	Journal files do not work. A journal file will be created, but
	nothing will be placed into it, and it will be deleted upon exit.
	If you restart an edit session after a crash and Sedt tells you
	it found a journal file and do you want to recover from it, answer
	N, else wierd things will happen :-).


Installation
------------

To install Sedt, create a subdirectory and place the files in this archive
into it. Assign the logical Sedt$Dir to this directory in your startup-sequence.
Sedt will use this logical to locate its various files. You will also want
to add this directory to your "path". Currently, Sedt can only be invoked
from the CLI.

The files in this archive are:

	Sedt		The Sedt executable
	Sedt.cnf	Startup configuration file
	A2key.txt	Amiga 500/2000 key definitions
	A2hlp.txt	Amiga 500/2000 on-line help
	Ruler0.txt	Default ruler definition
	readme		This file

I have placed copies of the various Sedt manuals in a separate archive
called SEDTDOC.ARC. This archive may be found in:

	CANIS::DUA1:[AMIGA.SEDT]SEDTDOC.ARC


Good luck,
Frank Ries		Email: CANIS::RIES

	Just a note of warning.  I sent this to Frank last night, but
couldn't post until now.  This version of SEDT terminates lines with <CR><LF>
pairs, instead of just <LF>.  This plays havoc with many things on the Amiga,
and is, in my opinion, a bug.

Mark

>Amiga 1000 owners, please give me some feedback on
>how you would like to see the keyboard/keypad mapped. Since the A1000 does
>not have the VT style 18 key keypad, how should the keypad be implimented?
>What keys should be used as PF1 - PF4 etc?

    How about the same as in the PD VT100 terminal emulator.  Herewith
    a section of the documentation...

	Keypad mapping (in application keypad mode):
	--------------------------------------------

		AMIGA		VT100		comments
		-------		-------		---------------------------
		0-9	==	0-9
		.	==	.
		ENTER	==	ENTER		(basically, flip the bottom
		-	==	,		 2 keys up to get a VT100)
		HELP	==	-		(only free key around)
		f1-f4	==	PF1-PF4		(or any rebinding you do)
		arrows	==	arrows

As reported in .-2, there was a bug in the FT1 version of SEDT which ended
each line with a carriage return line feed. Unfortunatly when I did my
non-debug build, I used an old version of that module. Gee, I need CMS
for the Amiga! Any way, I have built a new version which fixes this bug.
The new version can be found in:

	CANIS::DUA1:[AMIGA.SEDT]SEDTFT2.ARC

I have also included the Field test version, ie FTn in the sedt version
shown in the title bar to make it easier for you and me to know what
version you have.

Another note of warning, Sedt does not handle fatal errors very well.
When it gets a fatal error, such as not being able to open its key
definition file, or error create/reading/writing its temporary file
used when it runs out of buffer memory, it just reports the error and
exits. It does not go through any shutdown code that I can use to
close the window etc. This is a general problem with Sedt, and users
of Sedt on other environments may have run into this. This should
rarely happen though so shouldn't be much of a problem.

Anyway, give this new version a try, and sorry for the foulup.

Frank

    Works great Frank! Good job!
    
    Two items though:
    
    o  Get rid of that first line with the Quit and Front/Back gadgets.
       It wastes a line.
    
    o  What happened to my Left-Amiga-N/M keys? I can't screen shuffle
       when running SEDT!
    
    Fix those two items and I'll be real happy. Now have SEDT in the
    office on my VT, on my Toshiba lap and on my 2000!
    
    Paul

    Sounds great Frank!  I hope the A1000 support arrives soon!
    
    thanks,
    
    steve

Thanks for the initial feedback. Please remember that I am also learning
about the inards of the Amiga and AmigaDos as I'm working on this, so
some "features" may come slowly (hopefully not as long as this port
took :-) ).

Here's a few questions for you Amiga experts out there:

1.	How can I tell what type of Amiga I am running on. 500/1000/2000?
2.	How can I tell the type of keyboard. 500/2000 or 1000?
3.	How can I tell if I am running on the console as opposed to AUX:?

Also, can anyone tell me where I can find the os routines Execute () and
Output () defined? I have the RKM manuals, but their organization and
indexing have much to be desired.

Frank

Execute is in the AutoDocs.


I believe it's

BOOL	Execute(char *cmd, BPTR input, BPTR output)


John

Re: .21

>Also, can anyone tell me where I can find the os routines Execute () and
>Output () defined? I have the RKM manuals, but their organization and
>indexing have much to be desired.

For full documentation on Execute and Output, you need the AmigaDOS Manual
published by Bantam.

Information about those routines might be in the autodocs section of the
ROM Kernal Manual.  The Autodocs section is an appendix that lists almost
all of library functions in alphabetical order.  The autodocs is a document
from Commodore produced by running a filter on the sources to the Amiga's
system software.  The source of each function includes its documentation (a
Unix-style "man page").  AmigaDOS proper was not written by Amiga Inc
and was not written using Amiga's coding standards (or in one of
Amiga Inc's preferred implementation languages).  Thus, I am not sure
all of the AmigaDOS functions show up in the Autodocs published in the
ROM Kernal Manuals.  The functions do show up in the disk based Autodocs
available from Commodore.

>1.	How can I tell what type of Amiga I am running on. 500/1000/2000?

I don't think you can.  The machines are supposed to be similar enough
that any model running the same version of the system software with
the same configuration will behave the same.

2.	How can I tell the type of keyboard. 500/2000 or 1000?

I don't think you can.  Except that the 1000 keyboard is missing some
keys, that the early 2000 keyboards were at the extreme of one of the
timing ranges published by Commodore, and that the three fingered
reset on 2000 keyboard first tries to send a software shutdown message
to the system before doing the hardware reset, the keyboards are the
same.

Not useful if you want to alter your program's keyboard mapping
based on the physical arrangement of the keys.  The usual method of
handling this problem is to have a command that causes the program
to perform different keyboard mapping, and for 1000 owners to put
the command into their initialization command file for the program.

3.	How can I tell if I am running on the console as opposed to AUX:?

Given a file pointer or the device process for a device, it is possible
to follow a chain of about three or four pointers into system data
structures that tell you all of the mountlist information about the
device along with the name of the handler.  I have that code around
somewhere:  I'll try and find it.

    Help needed with SEDT
    
    I uploaded SEDTDOC.ARC and SEDTFT2.ARC, however I may do
    something wrong when I de-arc them.  I am new Amiga owner
    and not to knoledgable on it's operation.
    
    When I de-arc SEDTDOC, either on the VAX or the AMIGA, I always
    get an error on the last file in the set (SEDTREF.EDT), the
    other files are OK.
    When I de-arc SEDTFT2 it works fine, I installed it, started it
    get to the Sedt Command: prompt then hit, let say Help, I always
    get a visit from my good ol' meditating Guru. (000004, 00C368B8
    or around this address).   Now I may have done something wrong
    to install it, I will try some more later, but I am sure that
    I did NOT do anything wrong for the missing file in the DOC set.
    I tried to upload from canis::dua1... twice with the same result.
    
    Anybody have had the same problem?
    Do I need more than 1 meg memory to run ?
    I am using it from a Hard Disk (A2090A) is this supported,
    or do I have to use it from Floppies?
    Is the fact that I have a bridgeboard affect it?
    
    I desperately want EDT on my Amiga.
    
    Vince.

    Hmmm. I also get the same GURU (000004) while running SEDT.
    Sometimes it works fine for a while but then, usually when in HELP
    (or when entering or leaving HELP) BLAM! same GURU.
    
    I can't reproduce this at will but its almost always the way I 'EXIT'
    SEDT :'(
    
    I'm running on a 1 meg A500 and from a C-Ltd/RD53 hard disk.
    My system runs fine otherwise so I don't beleive this to be a HW prob.
    
    Hope this one can be tracked down and exterminated.
    
    Thanks for the port of my favorite editor.  ;')
    
    	PS.  Mine de-arc'ed error free!
    

    re .24 & .25

    I am also getting the same symptoms.  The Guru strikes whenever
    I try any file access like Gold/G or help.
    
    I have the logical and path set up OK.
    
    Patiently waiting...
    Peter

    Re Guru's and Task held requesters:
    
    I get them too.  Disk activity of any sort seems to bring them on.
    If I type "sedt <filename>" I also see the guru.   Editing a new
    file works very well, but I'm unable to save that file.
    
    My system is a 2000 1M, with a hard disk running FFS.  I have also
    tried running with floppies only, with the same result.


    Gary

I too have had problems with Gurus.

I found my problem was I had removed some fonts from the workbench disk.  When I
replace ALL the fonts, SEDT started working fine.  I have not yet worked out
which fonts are needed I just put them all on.

The reason I removed fonts was to save space so I could get SEDT on my floppy
system in the first.  I now use CRUNCHER to save space, a fine utility.  I use
it to compress a lots of my executable files and it saves masses of space.  SEDT
reduces to 206 blocks on a floppy

Hope this helps.

Andrew

I've still got problems with gurus on file access  - just like earlier
replies. I have all of the fonts on my disk.

If I start with the command SEDT it works fine until I use GOLD G or HELP.

If I start with the command SEDT filename it bombs immediately.

Nick

    I've had SEDT guru when hitting PF2 (Help) or GOLD 4. 
    
    Mike

	FWIW, I've had no problems with FT2.  I can do all the operations
previous notes state cause crashes.  I've tried them repeatedly after reading
the previous notes, and have yet to get it to crash.  Admittedly, I'm not using
it all that much, and since I don't use SEDT on other machines, I'm probably
not stressing it much.

	I'm running on a one meg. Amiga 2000 (Westchester Rev 4.3) with 1.2
Kickstart ROMs, and AmigaDOS 1.3.  I'm running off of an FFS formatted hard disk
(A2090 controller), from the Drew/Dillon Shell (2.07M).  I don't have Workbench
loaded.

Mark

This is really strange folks. I have been using this exact version with none
of these problems. I ill try and download the arc file and try that version,
maybe its a bad upload. The only other thing I can think of is that I compiled
and linked Sedt on my A2620 (68020), and perhaps (though against the doc)
it used some non-68000 instructions. I'll give it a test. This may take a
few days cause I'm not feeling well.

Hang in there,
Frank

    If we read the work/don't work so far, we see that the works:
    
    Work:
    A2000 motherboard V4.3 / Kickstart 1.2 
          A2090 Hard disk controler 	
    	  (Booted from Floppy)
    
    Don't work:
    A2000 Motherboard V 4.4 /Kickstart 1.3
          A2090A Hard Disk controler
    	  (Booted from Hard Disk)
    
    Might be board version?
    
    Might be 68020 instruction set?
    
    Might be missing Fonts (although mine don't work and I have a real 
             Sh*t load of fonts...)?
    
    Can the person that said works, list the fonts he(she) uses?

    
I am sure together, we can find the problem.
    
P.S. anybody else tried the SEDTDOC.ARC last document de-arcing bug?
    
  Vince.
    

Re:.33 (Fonts)

	I have all the Workbench fonts, plus the fonts from the Extras disk,
plus the fonts for Smokey, plus the PD font Pearl (which I use as my default
font).  Maybe others, those are the ones I remember.

	I'm disinclined to believe a 68020 is the issue, since Frank has one
and it works fine, and I don't, and it works fine.

Mark

    I have a feeling there may have been a problem with the arcing of
    the file. Well, if anyone is interested, I reARCed everything that
    works fine on my system, and uploaded it to
    mtwain::user:[macdonald.amiga.file]sedt.arc.
    
    Paul

More details of how FT2 fails on my machine:

	Machine:	A500 (ie 68000), 1Mb, WB1.2
	
	All file access gives a requestor:
	
	"Software Error, task held - finish all disk activity"
	followed by a guru when cancel is selected:
	
	0000003,00C13AE0	(Do these numbers mean anything useful?).
	
	I tried removing DMOUSE etc - but it still did it.
	
Nick

    Well, it works fine on my Amiga 2000 with V1.3 Kickstart and Workbench.
    I also have MachII V2.5 running, and several other subliminal tasks
    (NAG Plus V3.1, GRABbit, SpudClock, etc.).
    
    Paul

GURU error ...03 is an address error.  It's my favorite!  Sometimes it's a 
symptom of running out of memory (AllocMem returns 0, etc.)

    Just another interesting tidbit.... 
    
    I notice that sometimes right before the crash, the contents of
    the window's title bar become garbage.  Sure hope it's not a memory 
    problem.  I've tried it on my 1 meg system with a virgin workbench
    (900000+ bytes free) and it still puked.  I don't think I've tried
    it without loading workbench, however.  I'll have to try that later.
    
    BTW, I've been seeing both ...03 and ...04 gurus.  I'll start making
    more careful notes.
    
    Gary

    AAAARRRGGGHHHH!
    
    	Just tried the latest version  3.2(212).
    
    Still gurus when returning from help. Sme one (00000004).
    
    In fact, I just went back to verify the version number and got the
    dreaded "task held" requestor after invoking sedt and imediately
    quitting via Gold-Q. The requestor came up AFTER sedt cleaned up the
    screen and I was returned to the workbench screen!
    
    BTW, I am running Amigados V1.3
    
    Let me know how I can help.
    
    -bw

    Hmm ... the only time it's GURUed for me is when I invoked it from
    Browser. Otherwise SEDT has been working very well on my 3 Mbyte
    A2000.

	I was able to get it to hang last night.  It wasn't easy, but I did it.
I have two text files that are about .75 megs each.  I have a one meg machine,
with about .70 megs free when I tried this.  I first typed "sedt file1", which
loaded the first file (slow, but no problem).  I moved to the bottom of the
buffer, and did a Get on file2, appending it at the bottom.  I then moved to
the new bottom, and then back to the top.  No problems.  Now I know that it has
to be caching to disk somewhere.  Check T:, nothing there.  SEDT$DIR?  Nope.
Current directory?  Yep, there it is.  That's probably a bug, I think it should
use T:.  Anyway, I exit Sedt, and CD to RAM:.  Repeat the process.  The machine
hung (no Guru, but had to be rebooted) while reading in the first file.

Mark
 

Folks who are having problems with Sedt crashing. The way Sedt works is
that it will keep allocating memory for its buffers as needed until it
can no longer get any. At this point it opens a temporary file on disk
which it uses as a cache. This file is created in the current directory.
If your current directory is RAM:, VD0: etc, then Sedt will definitly hang
or crash, since it won't be able to write to the file since there is no
more RAM! I don't think that its a good idea to create the file in T:
since this is almost always assigned to RAM:. Perhaps there should be
another logical for this file, since its very possible that you might
be editing a file in RAM. Could this possibly be the problem that some
of you are having with Sedt Gurus?

Frank

    Well, running out of ram seemed plausible enough so I re-assigned T: to
    to the top level directory of my hard disk.

    Failed Again!... This time with a (00000003) immediately when the
    initial Sedt screen came up. I fact, the words "loading..." were still
    present at the bottom!

    I'm prepared to try anything at this point.

    Keep those ideas coming.

    thanks
    -bw

I don't know what's going on myself folks. I booted my 2000 from the
68000 (ie, didn't use the 68020 on the A2620) which left me with my
original 1MB, and I was able to get SEDT to guru several times. But
it makes no sense, and it was not consistant. It was not out of
memory, cause it never opened its cache file, and it always crashed
when I went to exit. All I did was run it, get help, then quit. About
1 out of 10 trys at this resulted in a guru #3. However, I only got
it to crash once when my current directory was to a disk. All the
other times was when I was on RAM:. Sedt is always giving back all
the memory it requested, I checked that, and I'm giving back all other
resources as well. Now, I have NEVER had it crash once when I am running
on the 68020 with 3MB of memory. Is there anyone out there having these
crashes with more then 1MB? Also, does anyone have a totaly consistant
method which will always crash SEDT? If so, I would probably have to
try and reproduce your exact enviroment to get it to happen for me.
I am going to try and get ahold of 5.02 of Lattice C to see if that
helps.

In any case, I have a FT3 version of SEDT you can give a try. It has
two differences:

o	There is a new logical Sedt$Tmp which should point to a DISK
	based directory where SEDT can create its temporary caching
	file. This should be something like DF0:T or DH0:T etc. This
	should help those of you who like to run with your current
	directory set to a RAM disk.

o	The SEDT version number in the title bar should no longer
	get messed up.

Neither of these are any big deal, but one never knows. Give it a try.

Frank

Oh, I forgot, you can find FT3 at:

CANIS::DUA1:[AMIGA.SEDT]SEDTFT3.ARC

Frank

    As I said, I'll try anything.  So I tried FT3.
    
    I looked good for about 5 minutes.  All kind of edits, back and forth
    rock and rollin with the help screens and back again.... no problem.
    
    Then I exited and was promply visited by the Guru of type (00000004).
    
    NUTS!  Anyone else have any luck?
    
    

    
    Here's another no-go on FT3.
    
    It works great until you want to exit. Either quiting or exiting
    causes a Guru...
    
    So close, yet so far!
    
    Ray
    
    

Well, lets try this one more time. I have yet another version, FT3A which is
the same as FT3 except that its compiled under Lattice C v5.02 which I just
pulled off their BBS tonight. Its suppose to fix a bunch of bugs, including
some in their startup/exit code. Maybe thats the culprit. Anyway, the code
is a tad smaller. So, give this one a shot and let me know if it still
gurus. The file is:

CANIS::DUA1:[AMIGA.SEDT]SEDTFT3A.ARC

Good luck,
Frank

    I tried it several times. It fails almost immediately when loading
    or just after loading and a few keystrokes into editing (guru #4).

    Your numerous efforts *are* appreciated.

    I haven't lost hope.

    -bw

    Dunno guys, but FT3 works just fine for me, and even on the 68020.
    The only problem I have had is the inability to edit the first and
    last line of the display area after scrolling through one screen.
    I have not seen any Guru.
    
    Paul

    FT3a that is. I never tried FT3.

    And I can still get a "Task Held" requester on demand.  All I need
    do is press the "PF2" equivalent and it craps out before the help
    file is finished loading.  Even with FT3a.
    
    A lot of it works, but I still have problems with file i/o.
    
    Gary

This is indeed a very strange problem. It works perfectly for me. How many
out there have actually given it a try, and how many are having the guru
problems and how many are not. I really need some feedback here. Its seems
that lots of folks have copied the arc file, but only a few have entered
a note here, or sent me mail saying if you have tried it/using it etc.
Please let me know if:

a:	you have tried it

b:	if it works for you, or you get the guru

c:	what is your configuration, especially how much memory do you have

d:	what stack size to you run with?

e:	If it guru's on you, what do you do to get this to happen.

In order for me to track this problem down, I really need to know as much
about your configuration as possible, including any background processes
you may have running etc. If I can't get it to guru for me, I obviously
can't fix it.

Frank

>< Note 1105.54 by CANIS::RIES "Frank W. Ries Jr." >
>                          -< I need help here folks >-

>a:	you have tried it
    
    I have  installed  it and ran it a few times, put it in a seperate
    directory pointed to by the assign sedt$dir. (the ft2 version)
    
>b:	if it works for you, or you get the guru

    It has never  gurued  for  me,  I have done the help, saves, quits
    etc. that other poeple have had trouble with.
    
>c:	what is your configuration, especially how much memory do you have

        Stock B2000 (1 mb),  1.3  in  ROM,  Version  4.4  Motherboard,
    A2090A with autoboot roms, ST225  with  small  autoboot  partition
    (DH0:) and two ffs partitions (FS1:    & FS2:).  Run Qmouse 1.4 in
    the  background  (all features enabled).  Ussually run  SEDT  from
    Drew/Dillon Shell that has been hotkeyed from Qmouse.   That's all
    I can remember for config stuf.
    
>d:	what stack size to you run with?

    Stack size set to 8192 in the startup.
    
>e:	If it guru's on you, what do you do to get this to happen.

    No Gurus.


    Regards....  Clint

    I am using FT3a. It has not Gurued on me. I have it installed in
    DH0:SEDT/    I also have   ASSIGN SEDT$DIR DH0:SEDT  as per the
    instructions. I am using an Amiga 2000 with 2 Mbyte Micron expansion,
    GVP 40Q SCSI Hardcard, A2620 2 Mbyte 68020 board. I have a VD0:
    and RAM: installed too. No probs. Just wish that problem with not
    being able to edit the first and last line of the window could be
    corrected.
    
    Paul

re: .-1

>    and RAM: installed too. No probs. Just wish that problem with not
>    being able to edit the first and last line of the window could be
>    corrected.
    
Paul, if you mean the first and last text lines within the SEDT window,
this is the way SEDT works. It works that way on all the SEDT versions
I have seen.

Frank

a:	you have tried it
	
	Yes, with every version

b:	if it works for you, or you get the guru

	Always a GURU, 3A tends to give it to me almost immediately while
	the others waited for me to get done editing or when I press PF2

c:	what is your configuration, especially how much memory do you have

	A2000 - 2meg Starboard for a total of 3 meg, 2090 with RD32 formatted
	mostly for FFS, 1 internal/1 external floppy, runninin background -
	MACH12, Virusx3.1, Snipit(1.2?), Autodiskchange ( for FFS floppies ).
	and my ASSIGN's are 
		sedt$dir: sys:newsharfiles/sedt/
		Sedt$tmp: T:

d:	what stack size to you run with?

	Stack is 30000 

e:	If it guru's on you, what do you do to get this to happen.

	Press PF2, and it will happen every time

Hope this helps ( also is there anybody close to Frank to demonstrate the
crash on their system? )

	Dick

a:	you have tried it
	
	I have FT3A.

b:	if it works for you, or you get the guru

	Works like a charm!!  Thanks a lot Frank!

c:	what is your configuration, especially how much memory do you have

	B2000 with 1 meg RAM and 2 internal floppies.  I run BlitzFonts and
	the latest version of Mach in the background.  I have the Sedt files
	in the main directory of a floppy labeled Sedt and I assign sedt$dir:
	to sedt:.

d:	what stack size to you run with?

	Stack is 10000 

e:	If it guru's on you, what do you do to get this to happen.

	Never has GURU'ed yet, though I haven't had time to really work it
	over. :-)  Still, I have no problems with PF2 or with loading/saving
	files.


	...richard

    I tried FT3A last night.  I have a 2000 with 1 Meg, 2 floppies.
    DMouse and VirusX running.  I tried two different stack sizes:
    
    	4000 - Help now works.  PF2 would GURU in previous versions.
    	       Looking good so far.  I then exited help, hit the
    	       return key a few times and GURU.  
    
    	12000 - I couldn't get this to GURU at all.  PF2 brought 
    		up help just fine.  I tried editing about a full
    		screen worth of text.  No problem.  I didn't try
    		any larger files.
    
    I'm still a bit leery about trusting SEDT yet, but I do like the
    progress.

    
    Mike

    Whoops .. guess I should have mentioned my stack. I run out of CLI
    (NewShell) via the PopCLI feature of MachII V2.5. The stacksize
    is automatically set to 20000.
    
    -Paul

    This phenomenon of crashing on some systems and not on others as
    well as appearing to be stack size dependant reminds me of some
    problems I was having with Handshake v2.11 a while back. Same type
    of APPARENT problem. It would crash on my system, but not on Ed
    A's. If I made the stack size large enough (100000) it would appear
    to work ok. Well, I called Eric Haberf... and after a litte
    investigation, it turns out that when he compiled the source, he
    left some sort of stack switch set. Is it possible that this may
    be the cause of this problem??
    
    
    Roger
    

a:	you have tried it

>	 All versions of it.

b:	if it works for you, or you get the guru

>	 Guru if exitin' or helpin'.  If exiting, FT3A saves the text
>        OK before guruing.  

c:	what is your configuration, especially how much memory do you have

>	 A2000, PCB 4.4, 2 floppies, A2090A with 20Meg Kyocera (ST225 compat)
>	 A2080 XT-Card.  Only 1 Meg memory.

d:	what stack size to you run with?

>	 20,000	 

e:	If it guru's on you, what do you do to get this to happen.

>	 Exit and help. 
>         I must say, I haven't had time to do much more experiments
>         to find more failure type, nor a possible fix.
>        Re-Assigning T: to hard disk did not help.
>	 Runing from V1.3 workbench "SHELL".
>	 NO other background process running.
>	 In a few days, I will make some more tries/experiments.

BTW: Is there anybody that gor SEDT working on the XT-bridgeboard?
     I will be trying that sometimes, with not much hope.


Vincent.

    I finaly took time to work and exeriment last night,
    (my wife was doing overtime, so I had the amiga to myself)
    I found my bug.
    I was starting a shell from workbench, and my ignorance
    made me beleive that setting a stack of 20000 in startup-sequence
    was setting it for the whole system.  WRONG!
    I am a new Amiga user and have a lot to learn.
    I found myself in a shell and only 4000 for the stack, that will
    guru for sure.
    Raising it to over 8000 is the fix.
    I designed an Icon and put the stack at 8196 in the sedt.info
    I then programed a key that ask me the file name I want to use
    i.e. (:FE^U?"File name to edit: "^U)
    It works like a charm.
    God bless Frank Ries!
    
 An other happy Sedt user.
 Vince.

Glad you got it to work for you Vince. SEDT does require a fair amount of
stack, I find that I need around 8000 or more as well, however, if I have
a smaller stack size, rather than a guru, I get a requester saying STACK
OVERFLOW. Of course at this point your wedged, but at least you know what
happened. From other notes though, it seems that others are having problems
with large stack sizes. Please make SURE that your stack size is at least
8000. I run with a stack size of 10000. I have obtained the latest SEDT
sources from Anker, and have integrated my changes. I will release this
version soon, but it seems that it even wants a slightly larger stack. It
still works for me at 10000.

Frank

Frank,
	Forget my previous statement about my stack size being 40000, when
I go into CLI through the SHELL icon I lose it. I was getting the default
4000 and didn't realize it. After playing with the icon, SEDT works like a
champ. I'm playing with 20000 just to be on the safe side.

Many thanks and now I can get on with learning to use it now that my machine 
will stay alive.
	Dick

    
    That's it! Not having spent too much time in the Shell I was running
    with the default of 4000. I raised it to 20000 and it works great!
    
    How can I make it permanent so that when I select a shell it
    automaticly gives me a larger stack?
    
    Thanks,
    Ray
    

    
>    How can I make it permanent so that when I select a shell it
>    automaticly gives me a larger stack?


edit S:Shell-Startup and add a STACK 20000 line.


John

    Frank,
    
       I notice that the up/down keys are buffered which makes it difficult
    to accurate move to a section of a document without overscrolling.
    The problem is less of a problem on VMS since the LK201 has a nice
    keyclick feature. Can the buffering be turned off somehow on the
    scroll keys?
    
    Paul

    Yea!  I also upped my stack size to 10K.  It all seemed to work great.

    However, there were 2 occasions where I was unable to exit for any
    reason. Gold-Q, Gold- kp7-quit, F10 or F8 resulted in essentially a
    null function.  The editor was still operating I just couldn't exit!
    I even tried to kill if from another cli but to no avail.

    Ideas, anyone?

    I had to reboot to 'end' my sedt session. but it was _great_ not
    visiting the GURU!!!*.

    Thanks for all you help.

    -bw

Why should the user have to worry about stack sizes?  That should be an
attribute of the IMAGE, not the PROCESS.  Even Atari got that one right.
Can't SEDT allocate a reasonable stack size at activation time?

I've also found it finally works with stack size 20000. (A500, 1MB WB1.2).
I really appreciate the effort you're putting into this port -- thanks.

One wishlist item:

Being based in the UK, I have a PAL AMIGA. This is capable of displaying
more text lines on the screen than the US/NTSC version. SEDT, however, only
uses a US size screen. VAX SEDT correctly sizes to the window its activated
in - could that be implemented for AMIGA SEDT? I appeciate that AMIGA SEDT
creates its own window rather than using the one its activated from.
Perhaps we could have a setup feature?

Nick

    .71:
    
    It sort of is, and it sort of isn't, but you're right.
    
    First, if you invoke a program from the workbench, that program's ICON
    definition contains the stack size needed to run that particular image,
    so in a sense, the required stack size is part of the image (abeit in a
    separate file).
    
    Invokation from the CLI is the mystery.  While it is true that programs
    run from the CLI are run within the CLI's process context itself (which
    is to say that the CLI does not create a separate process to run the
    image in), the CLI does not actually allocate the stack for the image
    until just before it runs it.
    
    Thus, there's no reason why they couldn't have made the stack
    requirements somehow a part of the image, and had the CLI use that when
    it loads and runs the programs.
    
    As for non-CLI shells, I imagine most of them invoke things via the
    Execute () service, which in turn invokes RUN, which eventually finds
    its way back to the same image activation code as used by the CLI, so
    it's the same problem.

    re:.73
    
    on a similar tangent... would it be possible to write a program
    that puts a hunk (that would set the stack size before the file
    ran) on an executable file?
    
    -Dave

Re: .74

I have seen code (it may have even been from Commodore) that showed
how a program could create its own stack by just dynamically allocating
a chunk of memory when it starts.

It would be fairly easy for an assembly language programmer to edit
the Lattice startup file c.a and have it allocate a large stack.

You do not need to update the stack related fields in the process control
block (they are wrong for CLI programs anyway).  You do have to do something
if you want the DOS Exit function to work.  (The DOS exit function isn't
used be Lattice C programs unless the programmer puts in a call to Exit.
The C exit function and the c.a startup "exit" the program by returning
to the system.)

Basically, the system treats whatever the stack pointer points at
as the stack.  95% to 100% of the job is making sure that the code in
c.a and exit have the proper context for returning to the system when
the program exits.  (The C functions exit and _exit eventually branch
to _XCEXIT (I think is the label) in c.a to exit the program.)

        I got SEDT FT3A running on my A500 with 1MByte using
        Kickstart 1.2 and Workbench 1.3 without producing any Guru.
        
        But I have another problem with Sedt.
        
        When I have started SEDT and press any key I get a "<255>" on 
        my screen.
        
        What is wrong ?
        
        Does anybody got the same ?
        
        Help please !
        

        Dieter 

    
    Frank,
    	How are the definitions for the Amiga 1000 keyboard coming?
    I have a copy of SEDT FT3A and it seems to work great!!!  Only
    problem is that I have a 1000.  I have fiddled with the key
    definition file to get the commands that I use most, but I
    can't redefine all the keys that reference the Gold key.  
    Is there any way that I can define a Gold key?   If so, can
    I make it one of the "Amiga" keys (next to the space bar).
    If not, what can I do?????   
    
    As an aside:
    	Is there anyway that a VT220 keyboard could be hooked up
    to my Amiga, or is it just a dream??? (would be nice for SEDT)
    
    		Any help would be appreciated,
    
    				thanks,
    
    				Phil
    
    

	Well most of you probably figured I'd died or something. Sorry its
	been so long since an update. I was out sick for a while and then
	got very busy at work. However, I have been busy on Sedt as well.

	I Obtained the latest Sedt sources from Anker, and have upgraded
	to them. I have also put in Amiga 1000 support, and added support
	for custom screens. You can now have sedt open its window in a
	custom 24 line non-interlaced screen (the default), a custom 48
	line interlaced screen, or the workbench screen which yields
	23 lines. You can change the screen default by using the SCREEN
	command in sedt.cnf. You can also change it during operation
	using menu options. You select the system type by using the
	SYSTEM command in sedt.cnf. For more information on all this,
	see the readme file included in the archive.

	It seems from previous notes that the guru problems were due
	to running Sedt with too small a stack. I have done some
	playing around, and found that you should run it with at
	least 8000 bytes of stack. I usually run at 10000 and never
	have any problems.

	With the exception of the notes in this conference, I haven't
	heard much from anyone who is actually using Sedt. Would those
	that are using it please reply to this note and let me know, and
	also how much you have been using it? I really need to get
	a feel for how much it is really being exercised. It's also
	nice to know if all this work has been worth while.

	Since I didn't really receive any feedback from 1000 owners
	on how they'd like to see the keyboard mapped, I ended up
	mapping it the same as SMOKEY. If you 1000 users would
	like this changed, let me know!

	Also, in general, would you like to see some of the non-keypad
	keys mapped differently? If you look at the on-line help, you
	will see that I left alot of the keys blank. Would you like
	to see any of these keys mapped to any function?

	I have also updated the documentation, so you might want to
	get a new copy of it. The files can be found at:

	CANIS::DUA1:[AMIGA.SEDT]SEDTDOC.ARC
	CANIS::DUA1:[AMIGA.SEDT]SEDTFT4.ARC

	Have fun,
	Frank

       Franks, thanks for the posting and your efforts.  I was waiting
       for A1000 support before trying it out.  From my personal
       perspective, mapping to the SMOKEY standard is fine.
       
       I loaded it up last night and as I only had time to play with it
       for a couple of hours you may want to hold off addressing anything
       I report below until I've had another crack at it this evening.
       
       I am happy to say that I wasn't visited by the Guru (running with
       a stack of 10000 as suggested).  I have an A1000, 2.5 meg of
       memory, RD through a WEDGE, with CONMAN, SPUDCLOCK, MACHII,
       VIRUSX, FASTFONTS, AREXX, GOMF (and probably a few others I've
       forgotten) running in the background.
       
       I did some initial testing with your A1Key.EDT key definition file,
       and then loaded the key bindings that I use on the VAX and my
       VAXmate here at work.  O.K. I admit it, I prefer the WPS standard
       over the EDT standard!  For the most part, everything worked.
       When I discovered something that didn't feel or work right, I
       tried both key definition files to confirm or deny the problem.
       
       
       BUGS FOUND:
       
       Gold <Right Arrow> and Gold <Left Arrow>, which are supposed to
       scroll down and up until another key is struck, don't work.  The
       display scrolls until the top or bottom of the buffer are reached,
       no matter how much key bashing you do.  I tried the WPS
       equivalents (Gold <Keypad 1> and Gold <Keypad 2>) with the same
       results.
       
       Not sure how close the AMIGA version is supposed to be relative to
       valid commands in the SEDT.CNF file, but when I added REMEMBER=ON,
       the first line (File line) got screwed up, and if I remember
       correctly (it was late!) although it created a 'SEDT.REM' file in
       SEDT$DIR it didn't want to load the last file edited. 
       
       Both the 'Keypad -' key and the 'DEL' key on the A1000 keyboard
       are assigned to key code F041.  Could you assign one or the other
       to another key code, so they could be programmed separately.
       
       I tried "run SEDT" at the CL in order to detach it from the
       current window, and I got a message something like "error in
       SIZE".  I'll try again tonight and keep better track of the error
       messages.  I also invoked a couple of simple system commands (list
       dh0: and dir dh0:) and they seemed to work, other then the fact
       that I had to select the screen to back gadget in order to see the
       results.  Didn't have time to try anything more complicated, but I
       suspect that the fact that SEDT wasn't detached from the window
       would have a major impact on the results.
       
       WISH LIST:
       
       Mouse support.
       AREXX support.

       QUESTION (not complaining, just asking):
       
       Are there known limitations of the AMIGA version vs the native VAX
       version (as an example) that you haven't mentioned in the README.
       In other words, will all the commands, .CNF file options, etc.,
       that are in the SEDT Manual, work on the AMIGA?  And if not today,
       is it your intent to get them to work?  
       
       The VMS and MsDos implementations of SEDT are now at 3.3-248.  Is
       it your intent to try and keep pace with Anker?  That would be a
       challenge for a team let alone an individual!
       
       BOTTOM LINE:
       
       Again - thanks for your efforts.  I also thank Anker for releasing
       the source code to you.  Guess this marks the end of my
       relationship with Rick Stiles and his excellent Uedit product.
       Although there are some features of Uedit I will miss, there is
       nothing - as far as I'm concerned - that can compete with SEDT.
       
       
       Art
       

Art, thank you very much for your comments. Its feedback like this that I am
really looking for. I personally am not a big SEDT user. I use TPU on the VAX
and SEDT on my VAXmate. When I first got the Amiga, I knew that I had to have
some sort of decent editor before I got serious about other development work.
I wanted an EDT style editor because thats what I was used to at work, and
didn't really want to learn various editors for different machines. This is
really what got me to think about SEDT for the Amiga. I talked with Anker, and
he agreed to give me the sources, although I don't think he gave me much of a
chance to pull it off. SEDT is HUGE, and the port was not easy. It really
makes me feel it was worth while when I get a response such as yours.

Since I don't really use alot of the non-EDTish features of SEDT, its from
people like you that I need to rely on to tell me what things don't work
the way they should.

And now for some answers to your questions:

>       I did some initial testing with your A1Key.EDT key definition file,
>       and then loaded the key bindings that I use on the VAX and my
>       VAXmate here at work.  O.K. I admit it, I prefer the WPS standard
>       over the EDT standard!

I hope to put together .wps files. If you'd like to volunteer :-) it would
be great since I have never used a wps editor.       
       
>       BUGS FOUND:
>       
>       Gold <Right Arrow> and Gold <Left Arrow>, which are supposed to
>       scroll down and up until another key is struck, don't work.  The
>       display scrolls until the top or bottom of the buffer are reached,
>       no matter how much key bashing you do.  I tried the WPS
>       equivalents (Gold <Keypad 1> and Gold <Keypad 2>) with the same
>       results.

Yeah, I forgot to put that one in the README file. I haven't got round to
finding the problem yet. Its on my list!
       
>       Not sure how close the AMIGA version is supposed to be relative to
>       valid commands in the SEDT.CNF file, but when I added REMEMBER=ON,
>       the first line (File line) got screwed up, and if I remember
>       correctly (it was late!) although it created a 'SEDT.REM' file in
>       SEDT$DIR it didn't want to load the last file edited. 

Hmmm, I must admit I haven't tried the remember file stuff yet. There was
nearly a year between my initial sources from Anker and these. He added
LOTS of new features, and rather than wait till I could test them all out
before making a release, I figured I'd get the release out now and rely
on you folks to help me find problems such as this. I'll check it out.
       
>       Both the 'Keypad -' key and the 'DEL' key on the A1000 keyboard
>       are assigned to key code F041.  Could you assign one or the other
>       to another key code, so they could be programmed separately.

I can do this, but I must map it to one of the functions defined by Anker.
I will look into it.       

>       I tried "run SEDT" at the CL in order to detach it from the
>       current window, and I got a message something like "error in
>       SIZE".  I'll try again tonight and keep better track of the error
>       messages.

Another odd one, I'll check it out.

>       I also invoked a couple of simple system commands (list
>       dh0: and dir dh0:) and they seemed to work, other then the fact
>       that I had to select the screen to back gadget in order to see the
>       results.  Didn't have time to try anything more complicated, but I
>       suspect that the fact that SEDT wasn't detached from the window
>       would have a major impact on the results.

I mentioned in the readme that the operating system command stuff doesn't
work right, but I should have put that under the known bugs section. Problem
is that I'm not quite sure how to do some of that stuff on the AMiga.
       
>       WISH LIST:
>       
>       Mouse support.
>       AREXX support.

Mouse support might be a tough one. Anker does not really do it in an elegant
way, I suppose since he didn't plan for it in the initial design. As far
as AREXX support goes, I don't have it or know much about it or what it might
take to support it. Part of the problem here is that unlike Anker, who I think
has made SEDT his life work :-), I have other projects I'd like to work on
and once I get the basic editor all working don't know how much more time I'll
want to put into it.

>       QUESTION (not complaining, just asking):
>       
>       Are there known limitations of the AMIGA version vs the native VAX
>       version (as an example) that you haven't mentioned in the README.
>       In other words, will all the commands, .CNF file options, etc.,
>       that are in the SEDT Manual, work on the AMIGA?  And if not today,
>       is it your intent to get them to work?  

I plan on making all the editing functions work. As far as the command like
and .CNF options go, there are alot of them which don't really apply to the
Amiga, but are mainly for the PC implimentations. Do you have any particular
ones in mind?
       
>       The VMS and MsDos implementations of SEDT are now at 3.3-248.  Is
>       it your intent to try and keep pace with Anker?  That would be a
>       challenge for a team let alone an individual!

I hope to keep up with Anker, but that not easy. I sware that he must work
on it every day! What I hope to do is get the AMIGAtized sources back to him
at some point so that they are kept up to date in the general sense by Anker,
and all I should have to do is make changes when there is something machine
specific.
       
Thanks again for the feedback, and keep it comming...
Frank       

    Thanks, Frank!  I've spent a good amount of time with SEDT, and I've
    found precious few bugs.  One that sticks in my mind is now working
    properly with FT4, so I won't bother telling you about it.  I have
    noticed that on certain occasions pieces of the cursor are left
    behind.  Sorry, but that's the best way to describe it.  It's fairly
    rare and inobtrusive.
    
    My wishes include some nasty things like getting the journaling
    to work, and being able to do DOS things in a buffer, and getting the
    cursor to track the mouse pointer.   But there is also a simple
    thing that you could do that would make me a happy guy.  The support
    for custom 24 and 48 line screens is a good thing.  Could I
    convince you to cut the number of bit planes to to 1?  Or at least
    make it an option.  This would both speed up the scrolling and eat
    up a little less memory.

    Sorry I didn't give much feedback sooner.  It's hard to talk when
    you've got your mouth full.  SEDT tastes good!
    
    Gary

    Frank,
    
       I use SEDT on VMS, on my laptop (Toshiba), and now - thanks to you
    - on my Amiga 2000. Keep up the good work!

    Paul

       Frank, thanks for the speedy response - just like Anker!
       
       I would be more than happy to work up a WPS key definition file.
       I basically use the key file and associated help file that Dick
       Danek put together and maintains (along with all his handy dandy
       .SEX files) with some very minor - and I do mean minor -
       modifications.  As I said yesterday, I downloaded my VMS based WPS
       key file to the AMIGA, renamed it to A1KET.EDT, and ran SEDT with
       no problems (other than a few commands calling the operating
       system didn't work).  I will load my VMS based WPS key and help
       files (SEDTKEYS.WPS and SEDTHELP.WPS) into POLAR::AMIGA_PUBLIC, if
       anyone wants to use them, understanding that a couple of things
       don't work.  WPS key and help files are also available in the
       Anker's normal SEDT directories and Dick Danek's public directory
       (see SEDT notes conference for pointers).  Once I AMIGA'ize them,
       I will gladly upload and maintain them.  I'm sure that hard core
       SEDT users are already using their own key definition files.
       
       I did some further testing of the REMEMBER=ON command.  Try this
       and you I think you will get a flavour for the bug - which is not
       as major as I reported yesterday.  As I said "it was late".
       
       1) Edit SEDT.CNF to include REMEMBER=ON
       
       2) Create a file using SEDT called testfile.one (do a gold-f to
          file and save) 
       
       3) Now type 'SEDT' which will automatically load up testfile.one
          (the Remembered file) with no problem.
       
       4) End the testfile.one editing session and then type 'SEDT
          testfile.two'.  When the SEDT window opens, you will notice that
          the color combination (blue letters - white background) in the
          File Line get screwed up after the file name.  Note that the
          column, row and buffer numbers will appear as you move through
          the document, or change buffers, but you never get to see 'C=',
          'R=', or 'B='.
       
       Relative to the error message I got when I tried to "run SEDT", I
       don't know what I did on Wednesday (perhaps tried to run an
       alias), but I have not problem running SEDT as a separate task
       last night.
       
       Relative to the wish list, it was just that.  I'd also like to be
       independently wealthy and live on a tropical island with a bunch
       of scantly clad young ladies!  But.....
              
       Relative to the .CNF commands, etc., what I was driving at was to
       find out if there was anything that you absolutely know won't work
       on the AMIGA in order to avoid having to go through a trial and
       error process - although trial and error at this point in time is
       not a bad idea as it may help ferret out some unexpected bugs that
       otherwise would have gone unnoticed.
       
       I have some other thoughts, comments, and questions, but I will
       hold them until I have had further time to formulate them properly
       and to do some additional testing.  I'll measure twice and cut
       once this time!
       
       Again, thanks.
       
       Art
       

    Thanks for the feedback folks! I will try and impliment as much of the
    asked for features as I can, but as I said before, I really don't want
    to make SEDT my life long project. Trying to keep up with Anker is a
    major task in itself. One of the more difficult things to add will be
    mouse support. Anker has it in the DOS and ATARI versions, but the
    implimentation is not real clean. There are calls all over the place
    to support it, and it would be quite a bit of work to put it in. The
    question is, is it really worth all the effort? I'm not ruling it out,
    just saying that it's not at the top of my list.

    Frank

Personally, I'm not sure that it _is_ worth the major effort to keep
up with Anker.  I think you have the base of a GREAT editor here!  I
would concentrate on isolating and fixing existing bugs and adding 
mouse support [well, it would be nice :-)].  DOS calls would be fine,
but hey, with a multitasking machine we don't really need them do we?

The 24/48 line option is great!  One of my excuses for not getting
into developing software on the Amiga is lack of an editor I feel
comfortable with.  Oh no, I've lost that excuse!!!!  Hey, nobody can
do serious development without a hard disk!  Yea, that's the ticket.
I gotta buy a hard disk first...

...richard

	I believe the Amiga can handle mouse buttons just like keys.  You 
probably could do it fairly cleanly.  Only poll the mouse position when a
button is pressed (or released).

Mark

> 	I believe the Amiga can handle mouse buttons just like keys.  You 
> probably could do it fairly cleanly.  Only poll the mouse position when a
> button is pressed (or released).

The problem isn't reading the mouse events from the Amiga, its what you do
with them once you get them. There is no clean interface in Sedt for handling
them.

Frank

       Frank - had a few more hours to work with SEDT on the weekend.
       I'm working on the WPS key definition and help files, but it will
       take a few days more before they are done (in test form anyway).
       
       The following is what I deduced to be the key mapping that you
       have used in mapping key codes for the AMIGA 1000 Keyboard against
       those referred to in the SEDT manual.  I have marked (*) the keys
       I questioned or have comments regarding.
       
                      
        KEY     SEDT                    AMIGA 1000
        CODE    KEY STANDARD            KEY
        ----    -----------------       -------------------------
       *F001    <F1>
       *F002    <F2>          
       *F003    <F3>
       *F004    <F4>                    
        F005    <F5>                    <F5> 
        F006    <F6>                    <F6> 
        F007    <F7>                    <F7> 
        F008    <F8>                    <F8> 
        F009    <F9>                    <F9> 
        F010    <F10>                   <F10>
        F011    <F11>                   <Shift F1> 
        F012    <F12>                   <Shift F2> 
        F013    <F13>                   <Shift F3> 
        F014    <F14>                   <Shift F4> 
       *F015    <HELP>                  <Shift F5> + <Shift HELP>
        F016    <DO>                    <Shift F6> 
        F017    <F17>                   <Shift F7> 
        F018    <F18>                   <Shift F8> 
        F019    <F19>                   <Shift F9> 
        F020    <F20>                   <Shift F10>   
       *F021    <FIND>
       *F022    <INSERT HERE>           
       *F023    <REMOVE>                <Shift DEL> 
       *F024    <SELECT>                            
        F025    <PREV SCREEN>           <Shift Up Arrow>
        F026    <NEXT SCREEN>           <Shift Dn Arrow>
        F027    <up arrow>              <up arrow>      
        F028    <left arrow>            <left arrow>    
        F029    <down arrow>            <down arrow>    
        F030    <right arrow>           <right arrow>   
        F031    keypad <0>              keypad <0>      
        F032    keypad <1>              keypad <1>            
        F033    keypad <2>              keypad <2>      
        F034    keypad <3>              keypad <3>      
        F035    keypad <4>              keypad <4>      
        F036    keypad <5>              keypad <5>      
        F037    keypad <6>              keypad <6>      
        F038    keypad <7>              keypad <7>      
        F039    keypad <8>              keypad <8>      
        F040    keypad <9>              keypad <9>      
       *F041    keypad <,>              keypad <-> + <DEL>
        F042    keypad <->              <HELP>
        F043    keypad <.>              keypad <.>
        F044    <PF1>                   <F1>
        F045    <PF2>                   <F2>
        F046    <PF3>                   <F2>
        F047    <PF4>                   <F4>
        F048    Keypad <ENTER>          keypad <ENTER>

       
       As you know there are a number of keys for which there are no
       equivalents on the A1000 keyboard - either because of physical
       numbers of keys or the fact that you haven't mapped them to other
       key combinations.  With the goal of portability of the key
       definition files in mind (which for me means I can us the same key
       definitions and help files on the VAX, VAXmate, and now AMIGA) I
       would like to see as many one-to-one mappings as possible.  
       
       A review of Anker's EDT and Danek's WPS key definition files
       indicate that <F1> thru <F5> (the exception being <F4>) are not
       used as they make calls directly to the firmware (Hold, Print
       Screen, Set-Up, Break) on any DEC product.  Therefore, as these
       keys are not used on the VAX/VAXmate implementation, I don't see a
       need to have A1000 key combinations (and it would have to be
       combinations given that all the single keys are used up) that map
       to F001, F002, F003, and F004.  For the A500/2000 owners I guess
       that means some bonus keys given that you have <PF1> thru <PF4>
       eqivalents!  I can always reassign any F004 command that I use at
       work to F005 on the AMIGA with little problem.
       
       This leaves the <REMOVE>, <FIND>, <INSERT HERE> and <SELECT> keys
       with no natural A1000 equivalents.
      
       With respect to the <REMOVE> key, I question (as stated last week)
       the mapping of the A1000 <SHIFT DEL> to F023.  I would like to see
       the A1000 <DEL> key mapped to F023.  Using <SHIFT DEL> to delete
       the character under the cursor is not intuitive, on top of which,
       having the <DEL> key and the <Keypad -> key mapped to the same
       code, causes me no end of problems.  It also means you have
       reduced the number of 'programmable' keys by one!  This fix would
       be on the TOP of my wish list.
       
       To accomodate the <FIND>, <INSERT HERE> and <SELECT> keys an
       option may be to map <SHIFT DEL>, <SHIFT BACKSPACE>, and <SHIFT
       HELP> to F021, F022, and F024.  Given that you have already
       accomodated HELP by using <Shift F5> I don't see a problem with
       unassigning <SHIFT HELP> from F015.
       
       In terms of layout, this would give you something that looked like
       this, which may not be perfect, but is managable:
       
                LK2XX                                A1000   
       +-----------------------+                   +--------+    
       |       | INSERT|  RE-  |                   |  DEL   |    
       | FIND  |  HERE |  MOVE |                   |        |    
       |       |       |       |                  +---------|    
       +-----------------------+                  | BACK-   |    
       |       |       |       |                  | SPACE   |    
       | SELECT|  PREV |  NEXT |                  +---------|    
       |       |       |       |                    | HELP  |    
       +-----------------------+                    |       |    
                                                    |-------|    
       CODE    LK2XX           AMIGA 1000           |  UP   |    
       ----  -----------     ---------------        | ARROW |    
       F021  FIND        =   SHIFT DEL          +---------------+
       F022  INSERT HERE =   SHIFT BACKSPACE    | LEFT  | RIGHT |
       F023  REMOVE      =   DEL                | ARROW | Char  |
       F024  SELECT      =   SHIFT HELP         +---------------+
       F025  PREV        =   SHIFT UP ARROW         | DOWN  |    
       F026  NEXT        =   SHIFT DN ARROW         | ARROW |    
                                                    +-------+    


       
       **** Note, that the above are my own observations and
            thoughts.  If there is anyone else out there that
            cares to dispute or agree, please pitch in. ****

       I discovered another problem/bug.  If I create an SEDTCOM.TXT
       initialization file and place it in the directory I have assigned
       to SEDT$DIR (which happens to be dh0:sedt_dir), it does not get
       read nor are the commands contained in it executed upon startup of
       SEDT.  However, if I include the '-i' option in the command line,
       i.e. 'SEDT -idh0:sedt_dir/sedtcom.txt', it is read and the
       commands are executed.  I thought maybe you had changed the
       accepted file name of this initialization file so it would be
       AMIGA specific (like you did with the key and help files), but
       when I did a search of SEDT using NEWZAP I found the reference to
       'Sedt$Dir:SedtCom.txt'.  I have set up an alias in my
       s/shell-startup file to force the reading of SedtCom.txt, but
       unless I am mistaken that shouldn't be necessary as it is supposed
       to be read and executed automatically when you invoke SEDT.  At
       least it works like that on the VAXmate, and reads whatever file
       you have defined as SEDT$COMMANDS on the VAX.
       
       With the exception of the above, I'm pleased (and I can live with
       the above - although whatever you could do with the key mapping
       would be nice).  I was also happy that after a number of hours of
       banging away at it, it ran great - no Guru visits!  Looks like the
       basic platform is solid which is the main thing.  I also agree
       with whoever commented a reply or 2 back.  Keeping up with Anker
       may be impossible and unwarranted.  Some of his latest releases
       (when not bug fixes) have been to incorporate features which I
       suspect 99 out of 100 SEDT users could live without - although
       there is no doubt they enhance the functionality of the product.
       
       Thanks again.
       
       Art
       
       P.S. if you want to discuss any specifics over the phone I can be
            reached at dtn 621-2519.

Thanks again Art for your comments and suggestions. I'll look into the
keymappings you suggested, as well as the SedtCom.txt problem. I found
the bug with REMEMBER=ON, but it's not an easy one to fix. Suffice it
to say that Sedt lives in a world where lines in a file are terminated
with a carriage return and a line feed, and on the Amiga, lines are
terminated only with a line feed. I have to jump through rings in
Anker's file routines to make all this work right :-(. This is also
why file reading/writing may seem slow. On other machines, Anker just
reads/writes whole chunks of a file, while on the Amiga, I have to
read/write a line at a time and add/remove the return/line feed to the end.
Sigh.

Frank

    I finally had a chance to play with it this weekend.  Thanks for
    adding the A1000 keyboard mapping that is the same as the Smoggy
    keypad (whatever the final keyboard mapping turns out to be, I'd love
    to have it the same for the editor and terminal emulator).
    
    Great job, no GURUs with a stack size of 10000.
    
    One question: I've heard SEDT was famous for being able to edit
    files larger than existing memory, true?  Since I'm living on a 512K A1000
    I noticed it didn't work, it just dumped me out of SEDT (I haven't
    found ANY editor so far that implements that feature so far).
    
    I'd be willing to trade-off speed for the ability to edit any size
    file.
    
    -dave

The FT5 release of Sedt for the Amiga is now available. As usual you can find
the files in CANIS::DUA0:[AMIGA.SEDT]. The following is an excerpt from the
release notes describing the changes in this version.

Enjoy,
Frank Ries


3.3(247)-FT5	This version fixes a few bugs, greatly speeds up file
		reading and writing, and remaps a few of the keyboard keys.

		Bug fixes:	Keymaps are now handled properly. Ie, entering
				ALT-K "key" does the right thing.
				The REMEMBER=ON configuration option now works
				correctly.
				Journaling is now implemented.
				Subprocess functions are now implemented.

		I have rewritten the file input/output routines, and have
		more than doubled their speed. Ie, reading/writing a file
		that took 7 seconds before, now loads/saves in 3 seconds.
		The executable is even a bit smaller :-) !

		From some suggestions by Art Gosling, I have changed a few
		of the key mappings. This was done so that in some form or
		another, all of the keys defined by SEDT (based upon the
		LK201/LK250 keyboard) are mapped to some unique key combo
		on the Amiga. The following key equivalences have been
		added:

		LK2xx key	Amiga key
		-----------	----------------
		Find		Shift Back Space
		Insert Here	Shift DEL
		Remove		DEL
		Select		Shift HELP
		Prev Screen	Shift Up Arrow
		Next Screen	Shift Down Arrow

		Note that the DEL key no longer deletes the character under
		the cursor, it now performs a cut! The on-line help has been
		changed to reflect these changes.

		The Amiga version of SEDT differs from other versions of
		SEDT in the naming convention of the initialization file
		SEDTCOM. The Amiga version will look for the file
		Sedt$Dir:SedtCom.edt if edt keymapping is selected, or
		Sedt$Dir:SedtCom.wps if wps keymapping is selected.
		This way you can have different initialization files
		for the different keymappings. Other versions of SEDT
		always look for SedtCom.txt regardless of the keymapping.

		The Amiga version of SEDT also differs in that it will store
		the journal files in Sedt$Tmp:, rather than in the current
		directory. This was done so that the journal files would be
		written to a disk device (Sedt$Tmp: should be defined as a
		directory on a disk, not in RAM), rather than RAM if you
		are editing a file in a ram disk. After all, if the system
		croaks and your journal file was in a non-recoverable ram
		disk, you lose your edits anyway. The journal file is
		updated every 128 keystrokes, so if your disk drive cronks
		once in a while, its because SEDT is updating the journal
		file. If you find you don't care for this, and can live
		without journaling, put the line:

		JOURNALING=OFF

		in your Sedt.cnf file.

		The :SYS, :SYQ and :SYR commands now work, so you may open
		up a CLI, or perform various operating system commands from
		SEDT. I have bound a new function to the F5 key. Pressing
		F5 will ask you to enter an operating system command. The
		output of this command will be entered into the current
		buffer at the current cursor position.

Please note the following error in the previous note.

>>the files in CANIS::DUA0:[AMIGA.SEDT]. The following is an excerpt from the
	       ^^^^^^^^^^^^^^^^^^^^^^^^
	       CANIS::DUA1:[AMIGA.SEDT]. 

Thought I'd give SEDT a try.
Thanks
-Tom-

Oops, your right....the files are in:

	       CANIS::DUA1:[AMIGA.SEDT]. 

Frank

    Frank,
    
       Journaling does not appear to function. I have SEDT$TMP: assigned
    to DH0:t but I keep receiving an error message "Could not open journal
    file."
    
       Any clues?
    
    Paul
    

>    Frank,
>    
>       Journaling does not appear to function. I have SEDT$TMP: assigned
>    to DH0:t but I keep receiving an error message "Could not open journal
>    file."
>    
>       Any clues?
>    
>    Paul

Paul, I have fixed the journaling problem and the fixed version is available
as SEDTFT5A.ARC. This is the only change to this version. You can find it in
the standard place:

CANIS::DUA1:[AMIGA.SEDT]SEDTFT5A.ARC

Thanks for reporting the problem and in helping me track it down.

Frank    

    Thanks Frank. I haven't found any other problems with this version.
    Looking good!
    
    Paul

    BTW Frank. Is there any way to change the default value of 128
    keystrokes?
    Paul

>    BTW Frank. Is there any way to change the default value of 128
>    keystrokes?
>    Paul

Fraid not Paul. That value is hardcoded into the sources.

Frank

    Hmm ... no way to change a bit with NEWZAP?

>    Hmm ... no way to change a bit with NEWZAP?

Nope, sorry bout that. There is a hardcoded buffer which holds the last 128
keys typed. Elsewhere the code checks if the buffer is full then writes it
out. In fact it used to used a constant of 128 in a number of places, but
I changed this to a symbol cause the Amiga buffer is actually 256 bytes,
since a save two bytes per key. This could be a suggestion to Anker to
allows something in your .CNF file to set the buffer size. What would
you like to see as the default? I admit its kinda annoying the hear your
disk drive gronk every couple of lines or so. But of course you can always
disable journaling. Sedt also supports automatic file saves, which I haven't
tried yet but image would be quit startling.

Frank

    Variable would be nice. 128 may actually be too large in some
    instances. For example, if I go into a file merely to seek out an
    destroy a word, I might like to have that buffer set at 32. Most
    of the key strokes would be cursor movement. 

    Frank, I thought you might be interested in this.  I was dying to tell
    this person about SEDT, but since it's in field test, and I don't know
    what its final status will be, I held myself back.  But there are
    people out there who want it, if it's any comfort to you.
    
    I love it and wouldn't trade it for anything, BTW.  Thanks to both
    you and Anker.
    
Path: hubcap!gatech!ncar!boulder!sunybcs!ugkamins
From: ugkamins@sunybcs.uucp (John Kaminski)
Newsgroups: comp.sys.amiga
Subject: Re: Unvalidated hard disk
Message-ID: <5214@cs.Buffalo.EDU>
Date: 12 Apr 89 05:03:30 GMT
References: <7350009@hpscdc.HP.COM>
Sender: nobody@cs.Buffalo.EDU
Reply-To: ugkamins@sunybcs.UUCP (John Kaminski)
Organization: SUNY/Buffalo Computer Science
Lines: 34

In article <7350009@hpscdc.HP.COM> hal@hpscdc.HP.COM (Hal Work) writes:
>After rebooting and trying to save a file, I got the message 'Error
>validating disk.  Key 33330 already set.'  This is my hard disk.  What
>happened?  What can I do short of reformatting and reloading?  How can
>I prevent this from happening again?

Firstly, only the guru knows what happened :^)  That could have happened
because of a power surge, a temporary power drop, or any of a zillion things
could have happened to cause a glitch that put the whammy on your disk.

Secondly, I thought disk problems are why C-A gave us DiskDoctor.

Thirdly, if you don't already have one, try a spike protector.  Or, if you
really want to be safe, get UPS (no, not United Parcel Service, an Uninter-
ruptible Power Supply).  That not only takes care of the spikes (too much
voltage) but also power brownouts and drops (too little voltage) as well
as honest-to-goodness blackouts.

In fact, because all computers ocasionally freeze for one reason to
another, when:

1.) am I going to remember to save to disk (and not RAM disk) often?
2.) is an editor going to be written that realizes that fact and save
      automatically?
3.) is DEC EDT going to be ported to the Amiga (ha!) or something like it
      that creates a history file (called a journal or .JOU file by DEC)?

as a sort of "P.S." -- have any of you done about an hour or two of change
mode (in EDT) editing, have the machine go down, and edt/recover your file?
It's something like watching a videotape of your editing, but locked in
fast forward visual search.

P.P.S. -- while I'm on the subject of editors, I couldn't BELIEVE the diff
between microemacs distributed for extras 1.2 and 1.3!  What a speedup!
    

    re: 1105.103---``have any of you done about an hour or two of change
mode (in EDT) editing, have the machine go down, and edt/recover your file?
It's something like watching a videotape of your editing, but locked in
fast forward visual search.''
    
    I always laugh when I see that observation.  The "videotape of your
    editing" was deliberately put into EDT so that you would have something
    to watch while journal recovery was in progress.  It causes a
    significant slowdown in recovery, but we felt that the user would like
    some reassurance that his work is recovering correctly.
        John Sauter, former EDT project leader

re -1
	You can achieve the same thing by going into DTM in the morning so 
that if you have a good day, you can play it back on a day where nothing seems
to be going right

	Dick

	I've found two more bugs.  One is minor (if it hurt's when you do
that...), the other is a bit more of a problem.

	The more important one:  SEDT doesn't preserve the script protection
bit.  If I have a script file that has the script protection bit set, and I
edit it, the new file doesn't have the script bit set, but the .BAK file does.
I think the new one should as well.

	The minor:  Hit F5 followed immediatly with F5.  I expected it to spawn
a CLI (like DO DO in SEDT VMS), but it prints garbage accross the bottom of the
screen.

Mark

    What ever happened to SEDT V4 for the Amiga?