delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1998/10/06/19:12:40

Date: Wed, 07 Oct 1998 10:54:19 +1300
From: physmsa AT cantua DOT canterbury DOT ac DOT nz (Mr M S Aitchison)
Subject: Re: Editor suggestions
To: opendos AT delorie DOT com
Message-id: <199810062154.KAA29114@cantua.canterbury.ac.nz>
X-Sun-Charset: US-ASCII
Reply-To: opendos AT delorie DOT com

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