[Toybox] Editors and such.

[David Seikel]

On Tue, 17 Jul 2012 23:58:40 -0400 Dennis McCunney
<dennis.mccunney at gmail.com> wrote:

> On 06/28/2012 05:31 PM, David Seikel wrote:
> 
> Coming late to this party, but..
> 
> > More importantly, the infrastructure is taking shape well.  So right
> > now making a really cut down microemacs, wordstar, nano, or
> > whatever is as simple as providing a different key to command
> > mapping array, then calling the editLine() function.  New commands
> > for a more feature full editor should be easy to add.
> 
> I wonder if it's really that simple?  Most of the discussion I've
> seen here seems to focus on how you display the text on screen, but
> that's only part of the issue.  Pagers like less simply read files
> from disk and put the results on screen, letting you scroll forward
> and backward. Less was popular when it first came out because it
> simply started to read from disk and put up what it had, which could
> be a lot faster than using an editor like vi in read-only mode and
> needing to wait for the whole file to load.
> 
> But when you want to *edit* files, you start running into questions
> of how you will store the text to be edited in memory.  Storing it as
> one big blob may not be feasible when you are dealing with large
> files, and you have issues of how you handle things like copying,
> moving or deleting blocks.
> 
> Some editors have used linked lists or doubly linked lists, where the 
> list is an array of lines.  What happens if the file you want to edit
> is one *very* long line?   Current practice seems to be using the
> "buffer gap" technique.  An outfit called Blue Mug software did a
> research paper on writing a word processor for handheld devices that
> might be a useful reference.  See http://goo.gl/bJtPt
> 
> 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.

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.

> 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.


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

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.

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.

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.

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.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120718/90d013e4/attachment-0002.sig>