[Toybox] Editors and such.

[Dennis McCunney]

On 07/18/2012 03:57 AM, David Seikel wrote:
> On Tue, 17 Jul 2012 23:58:40 -0400 Dennis McCunney

>> Additional documentation that might be useful is here:
>> http://texteditors.org/cgi-bin/wiki.pl?DesigningTextEditors
>
> I'll read those documents, thanks for pointing them out.  The first one
> starts by mentioning that text editors are easy, except for all the
> hard bits.  Indeed there are lots of niggling little corner cases to
> deal with, but the basics are easy.

Yes, I was amused by the Blue Mug piece, too.  But I've been bitten in 
the past by what editors do with text in memory, so "How will it be 
stored?" is an immediate question.  (I used an editor under DOS that 
packed a large number of features in a 5K COM file, but lines longer 
than 80 columns were silently truncated in memory because of the way 
text was stored.  I had to remember not to try to edit program code with 
it...)

> Buffer gaps actually complicate the code, and my first pass at this is
> to stick with simple code, as per the toybox development guidelines.
> Once it's all working to my satisfaction, then I can start to look at
> what bits should be optimised with more complicated code like buffer
> gaps and other things.  Right now though, it wastes memory, CPU cycles,
> and bandwidth to the terminal, but it's very simple code.

Okay.

>> Something else to look at might be Albrecht Kliene's e3 editor.
>
> I'm familiar with e3, I had looked at it years ago, it did indeed
> provide some of the inspiration for this project.

What Albrecht did seems to be what you are trying to do.  I'm pleased 
you were aware of it.

> I've been side tracked with a contract, so not spent much time on it
> this month.

Work that pays the bills comes first.

> I do have working now what I refer to as "simple" versions of joe
> (wordstar), mcedit, vi (with ex mode), and a readline type thing with
> history.  Emacs and nano are next on my radar, and I expect them to be
> just simple variations on the key mappings I already have for the other
> editors.  Less and more will need a little bit more than just key
> mappings, I'd have to add the rest of the "read only" mode.  After
> these are done, I'll drop the code for people to laugh at.

If what you want is simply an editor whose keybindings emulate those of 
other popular editors, preferably in a configurable manner, that should 
be fine.  There are enough editors following the emacs model that just 
use the emacs key bindings.  When you start adding things like macros 
the equation changes.  I'd hardly expect something included in Toybox, 
for instance, to include a Lisp interpreter.

> By "simple" editing I mean you can move the cursor around, insert
> a character, delete a character, load and save files, as well as
> quitting.  The absolute minimum you need to be called a text editor.
> Though it still does not pass my "is this an editor I'd use" basic
> test, which is mostly about instant discoverability.

It wouldn't pass the "editor I would use" test either.  I'd require 
search/replace and block move/copy/delete, as in your "basic editor" below..

> There's also a few extra features that happened as part of the design.
>
> Next up after that is what I call "basic" editing.  That will add
> cut/copy/paste, as well as search and replace.  The next stage I have
> in my design is "advanced" which is really just a hodge podge
> collection of features culled from the target editors, most of which
> are just automated invocations of the "simple" and "basic" functions.
> Note that this is not all features of the target editors, just
> a collection that is common, or that I think would not be too hard.

Thinking about it, another editor you can look at is Jeremy Hall's G 
editor, released back in 1995.  He used a novel approach to managing 
text in memory, and some of the basic functionality is actually 
implemented as macros calling editor primitives.  (The macro language 
was based on that used by ICL mainframes.)  It uses WS key bindings, and 
is not configurable in that respect.

See http://texteditors.org/cgi-bin/wiki.pl?G for details and pointers to 
source and docs.

> Lastly I have in my design document "code" editing.  I'm assuming that
> the actual users of this editor will mostly be sys admins and embedded
> programmers.  "Code" editing features are just a small handful of
> things that would be useful to programmers.  Considering that I often
> use midnight commander as an IDE, I do intend to do a separate "turn it
> into an IDE" project, but that is beyond the scope of this project.
> "Code" editing is borderline and might not make it into this project.
> Parts of "advanced" might also not make the cut.

"Code" editing tends to imply things like syntax highlighting, and that 
gets messy fast.  For an editor intended as a utility included in 
Toybox, I suspect I wouldn't worry about it.  For something built on 
that designed to be a separate product, I might.

As for turning MC into an IDE, have you looked at rhide? 
(http://www.rhide.com/)  It's a console mode IDE written for DJGPP (and 
I have it under FreeDOS), but it's been released for Linux, too.  The UI 
is based on the old Borland Turbo IDE.


 1342759364.0