[Toybox] Editors and such.

[David Seikel]

Wasn't getting to sleep, and this discussion should be here rather than
the Aboriginal Linux list like earlier today.

On Thu, 25 Oct 2012 20:16:15 -0500 Rob Landley <rob at landley.net> wrote:

> On 09/05/2012 11:11:09 PM, David Seikel wrote:
> 
> > But as I mentioned, not interested in a bug hunt right now.  That 
> > will be more appropriate when it's less of a "sandbox for testing
> > the ideas" and more of a "good enough to bother using".  Always
> > good to have other terminals for testing though.
> 
> Ok, back up.
> 
> I've learned lots of snippets of open source general practices over
> the years, and some day I need to track down Al Viro's "trail of 
> breakcrumbs" post so I can attribute it properly.

See below, but first some other comments.

> Don't give me a big finished solution. Give me a small set of easily 
> understood chunks that take the code from where it is now to where 
> you want it to be.
> 
> Yes, I'm explicitly saying it: I'd rather the code you give me be
> easy to understand than that it actually _work_. I can fix "doesn't
> work", once I understand what it's doing.

Ah, but if the only chunks that are bite sized are not big enough to do
anything useful, then you might waste time "fixing" it, when the proper
fix is to feed you the next chunk.

> The result of each addition must compile and run, so I can bsect 
> regressions introduced by changes (that's not an "if", that's a
> "when", including for my own changes). But beyond that, the important
> thing is that I be able to read each chunk of code and see what it's
> doing.
> 
> And one of the big truths of computer programming is that READING
> code is harder than WRITING code. When you write code, you construct
> a mental model first, and the code on the screen trails the mental
> model in your head. But when you _read_ code your mental model trails
> the code on the screen, and you understand _why_ it's doing stuff
> before you type up the _what_.
> 
> Programs do not have a single simple linear ordering, they jump
> around all over the place in normal operation, so whenever you're
> reading code it will rely on stuff you haven't read yet which isn't
> in front of you either, and you're either constantly going off on
> tangents or reading past gaps you don't understand yet. You have to
> assemble an understanding of the code by reading it out of order, and
> you have to reverse engineer the _why_ from the _what_.

I attempted to lay out the code so that reading it from bottom to top
might be a reasonable way to go.  That also fits my usual "keep forward
function declarations to a minimum" style.  Less lines of code that
way.  But you are correct, sometimes you need too know how the deeper
levels work.  That's one reason why I don't like "hide the details" OOP
style coding.  When working with other peoples code, it's those hidden
details that you often actually need to know.  It really does not help
if they went to some effort to hide them from you.

Also, there's copious comments, including a really long one at the top
that tries to explain the big picture.

> And that's if it's good code, reasonably cleanly laid out, with no 
> mistakes.

As was discovered by the first person to actually try it out, there's
bugs in my line navigation dead reckoning code.  lol

> So when you give me code, assume I'm dumber than you. Because in this 
> context, I am. I need bite sized pieces, each of which I can
> understand in its entirety before moving on to the next.

As I mentioned in my last email to the Aboriginal linux list, I wrote
the large blob so I could see how the ideas all work to do the generic
editor stuff and other things.  It kinda needs to be that big to do
anything that is actually useful.  So, onto musings about cutting it up
into bite sized bits...

You mentioned on the Aboriginal Linux list that you wanted a
"readline", and you listed some features.  My reply was that you had
basically listed the features of my "basic editor".  The main
difference between "readline" and a full screen editor, is that the
editor is fullscreen, while the "readline" is one line.  They both have
to deal with a list of lines, going up and down through those lines,
editing the contents of those lines, one line at a time.  For persistent
line history, they both have to save and load those lines to a file.
Other than that "readline" adds other behaviour, like moving the
current line to the end when you hit return and presenting that line to
the caller (here's the command).  So just making "readline" wont cut
out much of the code.  In fact, my "readline" is really just a thin
wrapper around the rest of the code.

Starting from the other end of the size spectrum, I guess "find out
terminal size" is a small enough bite sized chunk.  To actually do
anything useful with that you would probably start to write stuff I've
already written though.  Would be better off just using the stuff I've
already written.  On the other hand, maybe that would be useful for
"ls" listings and the like, then we can start with just that bit?

I guess the smallest useful command I have in my huge blob of code
would be "more".  I could even cut it down more.  Show a page of text,
show the next page of text when you hit the space bar, quit when you
hit "q".  Even then, I would estimate it would only cut out a third of
the code.

On the other hand, there's a bunch of crap in that blob that is for
future plans, and is not doing anything now.

In the end though, breaking it up into suitable bite sized bits might
be almost as hard as writing it in the first place.  I'll see what I
can do, when I find some time.  I did want to break it up into three
bits anyway, and there's a TODO to untangle a couple of bits that are
currently too tightly coupled.

-- 
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/20121228/a7315978/attachment-0001.sig>