delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1998/10/07/11:18:28

Message-ID: <361B8443.A4665203@abc-software.com>
Date: Wed, 07 Oct 1998 17:09:55 +0200
From: abcsoft <rchatenier AT abc-software DOT com>
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: opendos AT delorie DOT com
Subject: Re: Editor suggestions
References: <199810062154 DOT KAA29114 AT cantua DOT canterbury DOT ac DOT nz>
Reply-To: opendos AT delorie DOT com

As the opendos development is located in the UK, when some of them are old DRI
people are now working with Caldera they should now about a wordstar compatible
editor, QS.COM which is 32KB or QS.EXE which is 42KB. They were licensed by BSP
Krug of Germany to DRI UK in 1988. It used to work on 256 KB DOS machines, and
is small enough for rescue disks.

Robert du Chatenier




Mr M S Aitchison wrote:

> Good list of suggestions.  I definately want an EDIT that is small enough to
> stick on a rescue diskette though.  You can still have a good sub-100Kb
> editor, if there are optional modules.
>
> How about, if a rewrite is needed, a basic editor that can still do all
> that the present MS and DR edit programs can (the turbo IDE editor has
> a good mixture of Wordstar and MS-style key mappings), but... As it
> starts up it tries to load a special output module for the hardware
> (that can redefine fonts like the present one, or use strange screen
> modes, etc).  If it can't then it continues to work through plain BIOS
> calls in text mode.
>
> It should also look (in a .ini file?) for key remappings as well as
> colour schemes.
>
> To be really fancy, it could try to load a special module for each type
> of document you try to edit - converting word processing formats on the
> fly if needed.  These modules should be in some interpreted language,
> either lisp (as emacs uses) or Java.  The java idea is particularly
> attractive because a library of modules coul dbe built up for not just
> a plain DOS editor but fancy Linux (etc) word processing systems.  Java
> isn't good for the whole editor to be written (too slow) but fine for
> special modules, to provide translation and smart completion,
> language-sensitive syntax checking, etc.
>
> There are some very good features of the present editor I wouldn't
> like to see lost - able to edit very large files, and able to edit
> Unix (LF-delimited) files (but that could be improved).
>
> Mark.



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019