Discussion:
Editors and such.
(too old to reply)
David Seikel
2011-11-22 09:09:35 UTC
Permalink
Just read your triage blog, and noticed that the only editor in the
group is vi. Unless I missed something. Personally, I'd want to add
any simple editor that is not vi. Vi fails my editor test, a complete
lack of discoverability. I'd also want to eventually add a very simple
version of midnight commander (mc).

I'm thinking it would be useful to have some common support for full
screen terminal driving. The more command could probably use it to.
So that would be four commands that could use it right off the bat,
which is handy to help keep the design sane. More, vi, something like
nano, and something like a basic cut down mc.

I like your idea that you can pretty much deal with ANSI codes these
days. I have seen a really tiny editor, that used a profiles concept,
you could invoke it to act like simple versions of a number of popular
editors. It was written in pure assembler though.

If I have time, I'd like to tackle writing a common library of full
screen terminal app code, and basic generic file editing. The basic
generic file editing stuff could also be used by the non screen
editors.

BTW, I do have one command memorised for those times I accidentally
find myself stuck in vi -

killall -TERM vi

Substituting -KILL if I'm feeling particularly annoyed at it.
--
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/20111122/b7b8c27a/attachment.pgp>
Rob Landley
2011-11-22 14:02:19 UTC
Permalink
Post by David Seikel
Just read your triage blog, and noticed that the only editor in the
group is vi.
That's because the only editors in POSIX-2008 are "vi" and "ed". (I was
triaging the utilities list in the current POSIX standard.)
Post by David Seikel
Unless I missed something.
Yes: the Austin Group POSIX standard update committee meetings back in
2006 or so.
Post by David Seikel
Personally, I'd want to add
any simple editor that is not vi. Vi fails my editor test, a complete
lack of discoverability.
The only editors Linux has that are worth anything are notepad clones
(which was itself a clone of the original 1980's macintosh text editor).

That said, there are two de-facto standard editors available when you
ssh into a box and get a text mode session: vi and emacs. And the main
advantage of vi has always been "it's not emacs".

Emacs is an utterly horrible waste of time that needs to die. I'm aware
it provides a lithp programming framework for manipulating text buffers
the same way web browsers provide a Javascript programming framework for
manipulating web page contents, and that people have implemented a Lots
of Irritating Superfluous Parentheses script to feed zippy the pinhead
quotes to the Eliza program, AND ARE PROUD OF THIS. I do not consider
this an argument _against_ my position.

When I do an editor I want to make the keybindings flexible enough that
it can do vi, nano, microemacs, and ye olde wordstar keybindings (ala
joe, turbo C, and so on) from the same engine. (I want a _C_
programming framework for manipulating a text buffer.)

But I haven't written that yet, and it's not low-hanging-fruit.
Post by David Seikel
I'd also want to eventually add a very simple
version of midnight commander (mc).
I'm up for adding an mc clone if somebody wants to do that. I don't
personally use it, but I do miss xtree gold from DOS and OS/2. :)
Post by David Seikel
I'm thinking it would be useful to have some common support for full
screen terminal driving. The more command could probably use it to.
So that would be four commands that could use it right off the bat,
which is handy to help keep the design sane. More, vi, something like
nano, and something like a basic cut down mc.
Priorities are wrong there.

More can totally half-ass what it does because the standard requires a
"-num" option to specify the number of vertical lines, and it can always
fall back to 80x25 if it gets confused. Me getting hung up on
infrastructure issues says more about me than about more.

Less has to get it _right_, as does line editing for a command shell.
Even before you get to cursor up: unix tty handling is epically crappy.
My commodore 64 could backspace past the left edge of the screen and
continue from the right edge one line up. A TRS-80 could do this. Unix
derivatives _can't_, you have to know when you're at the left edge of
the screen and do the ansi sequences for "cursor up one, jump right
999". Which means you have to know when backspace puts you at the left
edge of the screen, which means you need to know when outputting normal
characters put you off the _right_ edge of the screen...

That's right: if you don't know what your current screen size is, your
command shell can't backspace past a line wrap. Welcome to unix
terminal handling.
Post by David Seikel
I like your idea that you can pretty much deal with ANSI codes these
days.
I inflicted said idea upon busybox in 2006, and Erik Andersen was
de-facto doing it before my time.

"These days" means DOS 3.x circa 1984. All the unix terminal handling
magic was for different brands of printer in the 1970's (and then the
"glass tty" stuff where you essentially plugged in a printer that didn't
use up reams of paper), back before the computer had a video card in it.

In 1987 Unix got xterms, which are software. So your output is being
parsed by a program, and having 237 different output formats a piece of
software can use to talk to another piece of software, even for
historical reasons, is insane. Just PICK ONE. And the one DOS picked
was a subset of ANSI, and they shipped over 100 million units, and Linux
inherited their hardware.

The only reason this is NOT obvious to Unix greybeards is they haven't
questioned any of their established assumptions in over 30 years. (You
can spot these guys because they still think the word "hacker" means
something other than "variety of criminal that breaks into computers
through the internet".)
Post by David Seikel
I have seen a really tiny editor, that used a profiles concept,
you could invoke it to act like simple versions of a number of popular
editors. It was written in pure assembler though.
When I was around 17 I wrote my first DOS bulletin board system (after
writing 3 of them on the commodore 64, and extensively mangling two
different versions of WWIV). It compiled a rather sad scripting
language into bytecode, and used it to emulate the user interface of
WWIV and deadlock and a couple others.

Not a new idea, really.
Post by David Seikel
If I have time, I'd like to tackle writing a common library of full
screen terminal app code, and basic generic file editing.
Infrastructure in search of a user isn't my idea of fun. And you can
output raw ansi escape sequences with "echo", that's not the hard part.

Back in 2006 I wrote a function for busybox that fell back to something
like three different methods to determine screen size (COLUMNS and LINES
environment variables, tty querying of both stdin and stdout, and
finally the escape sequence to query xterm across a serial connection).

I blogged about it last week (on the 15th). The problem is receiving
asynchronous escape sequence input after an arbitrary delay, potentially
intermixed (queued up behind) other random user input: doable, but has
to be part of a line editing thing that can make use of the rest of the
data rather than just discarding it.

Here's a fun one:

cat /proc/mounts | less

When less outputs the escape sequence to query terminal parameters, it
has to peek not stdin but /dev/tty. Except the cursor keys scrolling up
and down also come from /dev/tty, as do "user hit forward slash and
wants to type in a search regex"... Innit fun?

Plus you have to figure out the width of what you're outputting, which
means isprint() and probably UTF8 awareness... (Flashbacks to
fontmetrics in java 1.1, but we can assume monospace text grid...)
Post by David Seikel
The basic
generic file editing stuff could also be used by the non screen
editors.
I'm told it's called "ncurses". I once spent four hours beating a
"hello world" out of it, which is kind of sad if you think about it.
Post by David Seikel
BTW, I do have one command memorised for those times I accidentally
find myself stuck in vi -
killall -TERM vi
escape-colon-q-exclamation point should get you out of anything.
Post by David Seikel
Substituting -KILL if I'm feeling particularly annoyed at it.
Apparently, you are not the target audience of this command. It's still
in posix. (And busybox.)

Rob
David Seikel
2011-11-22 17:31:02 UTC
Permalink
3AM this side of the planet, one last email before bed.
Post by Rob Landley
Post by David Seikel
Just read your triage blog, and noticed that the only editor in the
group is vi.
That's because the only editors in POSIX-2008 are "vi" and "ed". (I
was triaging the utilities list in the current POSIX standard.)
Post by David Seikel
Unless I missed something.
Yes: the Austin Group POSIX standard update committee meetings back in
2006 or so.
It was too far to swim.
Post by Rob Landley
Post by David Seikel
Personally, I'd want to add
any simple editor that is not vi. Vi fails my editor test, a
complete lack of discoverability.
The only editors Linux has that are worth anything are notepad clones
(which was itself a clone of the original 1980's macintosh text editor).
That said, there are two de-facto standard editors available when you
ssh into a box and get a text mode session: vi and emacs. And the
main advantage of vi has always been "it's not emacs".
Emacs is an utterly horrible waste of time that needs to die. I'm
aware it provides a lithp programming framework for manipulating text
buffers the same way web browsers provide a Javascript programming
framework for manipulating web page contents, and that people have
implemented a Lots of Irritating Superfluous Parentheses script to
feed zippy the pinhead quotes to the Eliza program, AND ARE PROUD OF
THIS. I do not consider this an argument _against_ my position.
Why is it when I say I hate vi, people assume I love emacs? I won't
use either of them if I can help it.
Post by Rob Landley
When I do an editor I want to make the keybindings flexible enough
that it can do vi, nano, microemacs, and ye olde wordstar keybindings
(ala joe, turbo C, and so on) from the same engine. (I want a _C_
programming framework for manipulating a text buffer.)
That's exactly what I'm talking about. B-)
Post by Rob Landley
Post by David Seikel
I'd also want to eventually add a very simple
version of midnight commander (mc).
I'm up for adding an mc clone if somebody wants to do that. I don't
personally use it, but I do miss xtree gold from DOS and OS/2. :)
B-)
Post by Rob Landley
Post by David Seikel
I'm thinking it would be useful to have some common support for full
screen terminal driving. The more command could probably use it to.
So that would be four commands that could use it right off the bat,
which is handy to help keep the design sane. More, vi, something
like nano, and something like a basic cut down mc.
Priorities are wrong there.
Don't think I mentioned priorities, just that more COULD use it to, or
just be as brain dead as simple can make it. After all, toybox's main
design goal is simple.
Post by Rob Landley
Less has to get it _right_, as does line editing for a command shell.
Even before you get to cursor up: unix tty handling is epically
crappy. My commodore 64 could backspace past the left edge of the
screen and continue from the right edge one line up. A TRS-80 could
do this. Unix derivatives _can't_, you have to know when you're at
the left edge of the screen and do the ansi sequences for "cursor up
one, jump right 999". Which means you have to know when backspace
puts you at the left edge of the screen, which means you need to know
when outputting normal characters put you off the _right_ edge of the
screen...
That's right: if you don't know what your current screen size is, your
command shell can't backspace past a line wrap. Welcome to unix
terminal handling.
Yes, I read your blog about that.
Post by Rob Landley
Post by David Seikel
I like your idea that you can pretty much deal with ANSI codes these
days.
I inflicted said idea upon busybox in 2006, and Erik Andersen was
de-facto doing it before my time.
"These days" means DOS 3.x circa 1984. All the unix terminal handling
magic was for different brands of printer in the 1970's (and then the
"glass tty" stuff where you essentially plugged in a printer that
didn't use up reams of paper), back before the computer had a video
card in it.
I'm old enough that "real time" for me used to mean you did not have to
wait a week after submitting your OMR cards to peruse the printout and
spot your "typo", but got the rare privilege of sitting on top of the
noisy bastard printer and actually typing in your typo in "real time".

Now I'm happy working with embedded "real time", where half a
microsecond too long to respond is a critical failure.
Post by Rob Landley
The only reason this is NOT obvious to Unix greybeards is they haven't
questioned any of their established assumptions in over 30 years.
(You can spot these guys because they still think the word "hacker"
means something other than "variety of criminal that breaks into
computers through the internet".)
I resemble that remark. Well, except I question assumptions all the
time. Gets me into lots of trouble, but usually means I write good
code. My beard IS starting to grey, but I look young for my age.
Post by Rob Landley
Post by David Seikel
The basic
generic file editing stuff could also be used by the non screen
editors.
I'm told it's called "ncurses". I once spent four hours beating a
"hello world" out of it, which is kind of sad if you think about it.
Yes, one of the first things I was glad to do, when I got the job of
rewriting this embedded project from the ground up, was ditch ncurses.

Not the first time this company has hired me to rip their software a
new one, but probably the last, I think they've run out of crappy
software for me to rewrite. B-)
Post by Rob Landley
Post by David Seikel
BTW, I do have one command memorised for those times I accidentally
find myself stuck in vi -
killall -TERM vi
escape-colon-q-exclamation point should get you out of anything.
killall gets you out of way more things than that. :-P
Post by Rob Landley
Post by David Seikel
Substituting -KILL if I'm feeling particularly annoyed at it.
Apparently, you are not the target audience of this command. It's
still in posix. (And busybox.)
--
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/20111123/aa9a9d47/attachment-0001.pgp>
Rob Landley
2011-11-25 19:17:05 UTC
Permalink
Post by David Seikel
Post by Rob Landley
When I do an editor I want to make the keybindings flexible enough
that it can do vi, nano, microemacs, and ye olde wordstar keybindings
(ala joe, turbo C, and so on) from the same engine. (I want a _C_
programming framework for manipulating a text buffer.)
That's exactly what I'm talking about. B-)
Woot!

But I'm focusing on vi first because SUSv4 is the only publicly
available standard I've found (so far) that's worth following for this
sort of thing.
Post by David Seikel
Post by Rob Landley
Post by David Seikel
I'd also want to eventually add a very simple
version of midnight commander (mc).
I'm up for adding an mc clone if somebody wants to do that. I don't
personally use it, but I do miss xtree gold from DOS and OS/2. :)
B-)
Post by Rob Landley
Post by David Seikel
I'm thinking it would be useful to have some common support for full
screen terminal driving. The more command could probably use it to.
So that would be four commands that could use it right off the bat,
which is handy to help keep the design sane. More, vi, something
like nano, and something like a basic cut down mc.
Priorities are wrong there.
Don't think I mentioned priorities, just that more COULD use it to, or
just be as brain dead as simple can make it. After all, toybox's main
design goal is simple.
I like simple. :)

Alas, POSIX does not seem to like simple. To start with, the spec
requires "more" to be terminal aware, which isn't entirely surprising
given what it does. But it's not just _height_ aware, it's width aware too.

It's actually kinda fiddly: more needs to be able to wrap lines at the
screen size to figure out when to prompt, but the first 32 ascii
characters (all the stuff below space) don't consistently print one
character. Some print nothing, some move the cursor around (tab,
newline, linefeed, backspace, form feed, whatever the heck "vertical
tab" does...)

In theory I can hijack catv and just escape most of the low-ascii
weirdness (so it's two characters, but it's _consistently_ two
characters whatever $TERM thinks). In practice, when not hooked up to a
tty more is supposed to act like cat and pass data through unmodified...

I plan to do the simplest standards conformant implementation I can, and
every once in a while I go "you know, the standard's nuts, let's just
document the divergence"...
Post by David Seikel
Post by Rob Landley
"These days" means DOS 3.x circa 1984. All the unix terminal handling
magic was for different brands of printer in the 1970's (and then the
"glass tty" stuff where you essentially plugged in a printer that
didn't use up reams of paper), back before the computer had a video
card in it.
I'm old enough that "real time" for me used to mean you did not have to
wait a week after submitting your OMR cards to peruse the printout and
spot your "typo", but got the rare privilege of sitting on top of the
noisy bastard printer and actually typing in your typo in "real time".
38911 basic bytes free is as far as I go back. (poke 53280,0:poke
53281,1:poke 686,0... actually I'd have to look up that last one to be
sure I had it right, it's been a while.)

Most of my computer history before then is theoretical. I've used my
Uncle Alan's HP minicomputer to play hangman on a line printer TTY, and
dialed into a couple creepy mainframes (assembly programming on some HP
thing with BCD, the zero and add packed instruction). But they weren't
my normal programming environment.
Post by David Seikel
Now I'm happy working with embedded "real time", where half a
microsecond too long to respond is a critical failure.
If you've got your own dedicated processor that can busy wait for input,
that's doable. If you've got a multitasking OS on that processor,
latencies that tight are just not gonna happen.
Post by David Seikel
Post by Rob Landley
The only reason this is NOT obvious to Unix greybeards is they haven't
questioned any of their established assumptions in over 30 years.
(You can spot these guys because they still think the word "hacker"
means something other than "variety of criminal that breaks into
computers through the internet".)
I resemble that remark. Well, except I question assumptions all the
time. Gets me into lots of trouble, but usually means I write good
code. My beard IS starting to grey, but I look young for my age.
My father went grey at 19, so I'm less concerned about starting to do so
myself than I might otherwise be.
Post by David Seikel
Post by Rob Landley
Post by David Seikel
The basic
generic file editing stuff could also be used by the non screen
editors.
I'm told it's called "ncurses". I once spent four hours beating a
"hello world" out of it, which is kind of sad if you think about it.
Yes, one of the first things I was glad to do, when I got the job of
rewriting this embedded project from the ground up, was ditch ncurses.
Not the first time this company has hired me to rip their software a
new one, but probably the last, I think they've run out of crappy
software for me to rewrite. B-)
Post by Rob Landley
Post by David Seikel
BTW, I do have one command memorised for those times I accidentally
find myself stuck in vi -
killall -TERM vi
escape-colon-q-exclamation point should get you out of anything.
killall gets you out of way more things than that. :-P
You don't have to say -TERM, it's the default.

Rob
David Seikel
2012-06-15 11:20:11 UTC
Permalink
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
When I do an editor I want to make the keybindings flexible enough
that it can do vi, nano, microemacs, and ye olde wordstar
keybindings (ala joe, turbo C, and so on) from the same engine.
(I want a _C_ programming framework for manipulating a text
buffer.)
That's exactly what I'm talking about. B-)
Woot!
But I'm focusing on vi first because SUSv4 is the only publicly
available standard I've found (so far) that's worth following for this
sort of thing.
Post by David Seikel
Post by Rob Landley
Post by David Seikel
I'd also want to eventually add a very simple
version of midnight commander (mc).
I'm up for adding an mc clone if somebody wants to do that. I
don't personally use it, but I do miss xtree gold from DOS and
OS/2. :)
B-)
Post by Rob Landley
Post by David Seikel
I'm thinking it would be useful to have some common support for
full screen terminal driving. The more command could probably
use it to. So that would be four commands that could use it right
off the bat, which is handy to help keep the design sane. More,
vi, something like nano, and something like a basic cut down mc.
Priorities are wrong there.
Don't think I mentioned priorities, just that more COULD use it to,
or just be as brain dead as simple can make it. After all,
toybox's main design goal is simple.
I like simple. :)
I woke up this morning with the remnants of a dream about how to get
started on my MC clone. Sometimes I program in my sleep. Spent much
of the rest of today writing it down and blowing life into it as a
proper design for a useful toybox full screen handling library and
generic editor (with flexible keybindings as stated above), with
pretensions of supporting MC style stuff to. I even started writing out
suitable data structures.

I'm guessing that we don't want a full vi clone, just a minimal one.
As mentioned in this thread long ago, I don't use vi. So I would want
those that do use vi to agree on an absolute bare minimal subset that we
should implement. And perhaps a second almost minimal "nice to have"
subset. I can do the same for MC's editor, and nano is likely
minimalist enough. Wordstar I used long ago, and can probably find the
relevant details. Microemacs I think I used once, emacs fans can sort
that out for us. Then see what that adds up to as a common set of bare
minimum editor features to write generically.

One of the more interesting ideas I came up with was to implement lots
of MC, and fancy editing features as some sort of special purpose
scripting language with shell abilities. So there would be the full
screen handling library, with bindable functions for editing and other
basic generic functions, with callbacks.

Then there would be a toy I'm calling toyboxes. You pass it a script,
the script binds keystrokes to functions, perhaps binds some functions
to a menu, then calls the generic editor.

An MC script could bind keys and menus as before, create two boxes on
the screen, send the output of "ls" to each box, and bind some
callbacks to other keys. The library handles moving the file selector
up and down one of the two boxes, as well as scrolling the box
contents, switching between the boxes, etc. The library passes stuff
back to the script when the user hits return on one of the lines. The
script notices it was a directory, changes to that directory, then
sends another "ls" commands output to the box again. Or notices it's a
file and opens the proper viewer. Similar for the other standard MC
keystrokes, they get bound to a callback in the script, the script
does the MC stuff, the library handles the generic box and content
stuff.

Add a shell alias for "mc" to be "toyboxes mc" and you get an MC
replacement. Or "toyboxes vi", "toyboxes nano", etc.

I once wrote a program to run any program as a separate process, read
commands from it's stdin, execute those commands, then send the result
back through stdout. The results where implemented as a callback
system, though it was all just plain text. It was up to the
external program to figure out what to do with the results. I think
something similar might work here. Then people can use the language of
their choice to implement stuff using the toyboxes library. This keeps
the toybox binary small and simple, while allowing people to create full
blown MC / editor / whatever replacements. People can still write toys
for toybox that use it internally. I can reuse some of that code.

Almost finished my virtual worlds web site redo, and just got paid to
get back to the embedded contract (I make him pay in advance, coz he
has a hard time coming up with money). So I might not have much time
to bang on it. See what I can get done.
--
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/20120615/a1bf9f25/attachment.pgp>
David Seikel
2012-06-16 15:47:05 UTC
Permalink
On Fri, 15 Jun 2012 21:20:11 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
--
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/20120617/4372f63f/attachment.pgp>
Rob Landley
2012-06-17 06:28:40 UTC
Permalink
Post by David Seikel
On Fri, 15 Jun 2012 21:20:11 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
The multiplexer name is a special case, so you can have more than one of
it via a postfix.

So if you want to isolate suid support you can have two binaries, one
without the suid bit and the other with, and have both in the $PATH as
"toybox" and "toybox-suid", for example.

I did that in busybox years ago. That's why my static busybox binaries
were "busybox-i686" instead of "i686-busybox": you didn't have to rename
it to use it, just set the executable bit.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-17 06:44:22 UTC
Permalink
Post by Rob Landley
Post by David Seikel
On Fri, 15 Jun 2012 21:20:11 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
The multiplexer name is a special case, so you can have more than one
of it via a postfix.
So if you want to isolate suid support you can have two binaries, one
without the suid bit and the other with, and have both in the $PATH as
"toybox" and "toybox-suid", for example.
I did that in busybox years ago. That's why my static busybox binaries
were "busybox-i686" instead of "i686-busybox": you didn't have to
rename it to use it, just set the executable bit.
Ah, fair enough. I'll stick with "boxes" for my toys name.
--
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/20120617/de7ff913/attachment.pgp>
David Seikel
2012-06-17 06:44:22 UTC
Permalink
Post by Rob Landley
Post by David Seikel
On Fri, 15 Jun 2012 21:20:11 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
The multiplexer name is a special case, so you can have more than one
of it via a postfix.
So if you want to isolate suid support you can have two binaries, one
without the suid bit and the other with, and have both in the $PATH as
"toybox" and "toybox-suid", for example.
I did that in busybox years ago. That's why my static busybox binaries
were "busybox-i686" instead of "i686-busybox": you didn't have to
rename it to use it, just set the executable bit.
Ah, fair enough. I'll stick with "boxes" for my toys name.
--
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/20120617/de7ff913/attachment-0002.pgp>
Rob Landley
2012-06-17 06:28:40 UTC
Permalink
Post by David Seikel
On Fri, 15 Jun 2012 21:20:11 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
The multiplexer name is a special case, so you can have more than one of
it via a postfix.

So if you want to isolate suid support you can have two binaries, one
without the suid bit and the other with, and have both in the $PATH as
"toybox" and "toybox-suid", for example.

I did that in busybox years ago. That's why my static busybox binaries
were "busybox-i686" instead of "i686-busybox": you didn't have to rename
it to use it, just set the executable bit.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-16 15:47:05 UTC
Permalink
On Fri, 15 Jun 2012 21:20:11 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
--
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/20120617/4372f63f/attachment-0002.pgp>
David Seikel
2012-06-15 11:20:11 UTC
Permalink
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
When I do an editor I want to make the keybindings flexible enough
that it can do vi, nano, microemacs, and ye olde wordstar
keybindings (ala joe, turbo C, and so on) from the same engine.
(I want a _C_ programming framework for manipulating a text
buffer.)
That's exactly what I'm talking about. B-)
Woot!
But I'm focusing on vi first because SUSv4 is the only publicly
available standard I've found (so far) that's worth following for this
sort of thing.
Post by David Seikel
Post by Rob Landley
Post by David Seikel
I'd also want to eventually add a very simple
version of midnight commander (mc).
I'm up for adding an mc clone if somebody wants to do that. I
don't personally use it, but I do miss xtree gold from DOS and
OS/2. :)
B-)
Post by Rob Landley
Post by David Seikel
I'm thinking it would be useful to have some common support for
full screen terminal driving. The more command could probably
use it to. So that would be four commands that could use it right
off the bat, which is handy to help keep the design sane. More,
vi, something like nano, and something like a basic cut down mc.
Priorities are wrong there.
Don't think I mentioned priorities, just that more COULD use it to,
or just be as brain dead as simple can make it. After all,
toybox's main design goal is simple.
I like simple. :)
I woke up this morning with the remnants of a dream about how to get
started on my MC clone. Sometimes I program in my sleep. Spent much
of the rest of today writing it down and blowing life into it as a
proper design for a useful toybox full screen handling library and
generic editor (with flexible keybindings as stated above), with
pretensions of supporting MC style stuff to. I even started writing out
suitable data structures.

I'm guessing that we don't want a full vi clone, just a minimal one.
As mentioned in this thread long ago, I don't use vi. So I would want
those that do use vi to agree on an absolute bare minimal subset that we
should implement. And perhaps a second almost minimal "nice to have"
subset. I can do the same for MC's editor, and nano is likely
minimalist enough. Wordstar I used long ago, and can probably find the
relevant details. Microemacs I think I used once, emacs fans can sort
that out for us. Then see what that adds up to as a common set of bare
minimum editor features to write generically.

One of the more interesting ideas I came up with was to implement lots
of MC, and fancy editing features as some sort of special purpose
scripting language with shell abilities. So there would be the full
screen handling library, with bindable functions for editing and other
basic generic functions, with callbacks.

Then there would be a toy I'm calling toyboxes. You pass it a script,
the script binds keystrokes to functions, perhaps binds some functions
to a menu, then calls the generic editor.

An MC script could bind keys and menus as before, create two boxes on
the screen, send the output of "ls" to each box, and bind some
callbacks to other keys. The library handles moving the file selector
up and down one of the two boxes, as well as scrolling the box
contents, switching between the boxes, etc. The library passes stuff
back to the script when the user hits return on one of the lines. The
script notices it was a directory, changes to that directory, then
sends another "ls" commands output to the box again. Or notices it's a
file and opens the proper viewer. Similar for the other standard MC
keystrokes, they get bound to a callback in the script, the script
does the MC stuff, the library handles the generic box and content
stuff.

Add a shell alias for "mc" to be "toyboxes mc" and you get an MC
replacement. Or "toyboxes vi", "toyboxes nano", etc.

I once wrote a program to run any program as a separate process, read
commands from it's stdin, execute those commands, then send the result
back through stdout. The results where implemented as a callback
system, though it was all just plain text. It was up to the
external program to figure out what to do with the results. I think
something similar might work here. Then people can use the language of
their choice to implement stuff using the toyboxes library. This keeps
the toybox binary small and simple, while allowing people to create full
blown MC / editor / whatever replacements. People can still write toys
for toybox that use it internally. I can reuse some of that code.

Almost finished my virtual worlds web site redo, and just got paid to
get back to the embedded contract (I make him pay in advance, coz he
has a hard time coming up with money). So I might not have much time
to bang on it. See what I can get done.
--
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/20120615/a1bf9f25/attachment-0002.pgp>
Rob Landley
2011-11-25 19:17:05 UTC
Permalink
Post by David Seikel
Post by Rob Landley
When I do an editor I want to make the keybindings flexible enough
that it can do vi, nano, microemacs, and ye olde wordstar keybindings
(ala joe, turbo C, and so on) from the same engine. (I want a _C_
programming framework for manipulating a text buffer.)
That's exactly what I'm talking about. B-)
Woot!

But I'm focusing on vi first because SUSv4 is the only publicly
available standard I've found (so far) that's worth following for this
sort of thing.
Post by David Seikel
Post by Rob Landley
Post by David Seikel
I'd also want to eventually add a very simple
version of midnight commander (mc).
I'm up for adding an mc clone if somebody wants to do that. I don't
personally use it, but I do miss xtree gold from DOS and OS/2. :)
B-)
Post by Rob Landley
Post by David Seikel
I'm thinking it would be useful to have some common support for full
screen terminal driving. The more command could probably use it to.
So that would be four commands that could use it right off the bat,
which is handy to help keep the design sane. More, vi, something
like nano, and something like a basic cut down mc.
Priorities are wrong there.
Don't think I mentioned priorities, just that more COULD use it to, or
just be as brain dead as simple can make it. After all, toybox's main
design goal is simple.
I like simple. :)

Alas, POSIX does not seem to like simple. To start with, the spec
requires "more" to be terminal aware, which isn't entirely surprising
given what it does. But it's not just _height_ aware, it's width aware too.

It's actually kinda fiddly: more needs to be able to wrap lines at the
screen size to figure out when to prompt, but the first 32 ascii
characters (all the stuff below space) don't consistently print one
character. Some print nothing, some move the cursor around (tab,
newline, linefeed, backspace, form feed, whatever the heck "vertical
tab" does...)

In theory I can hijack catv and just escape most of the low-ascii
weirdness (so it's two characters, but it's _consistently_ two
characters whatever $TERM thinks). In practice, when not hooked up to a
tty more is supposed to act like cat and pass data through unmodified...

I plan to do the simplest standards conformant implementation I can, and
every once in a while I go "you know, the standard's nuts, let's just
document the divergence"...
Post by David Seikel
Post by Rob Landley
"These days" means DOS 3.x circa 1984. All the unix terminal handling
magic was for different brands of printer in the 1970's (and then the
"glass tty" stuff where you essentially plugged in a printer that
didn't use up reams of paper), back before the computer had a video
card in it.
I'm old enough that "real time" for me used to mean you did not have to
wait a week after submitting your OMR cards to peruse the printout and
spot your "typo", but got the rare privilege of sitting on top of the
noisy bastard printer and actually typing in your typo in "real time".
38911 basic bytes free is as far as I go back. (poke 53280,0:poke
53281,1:poke 686,0... actually I'd have to look up that last one to be
sure I had it right, it's been a while.)

Most of my computer history before then is theoretical. I've used my
Uncle Alan's HP minicomputer to play hangman on a line printer TTY, and
dialed into a couple creepy mainframes (assembly programming on some HP
thing with BCD, the zero and add packed instruction). But they weren't
my normal programming environment.
Post by David Seikel
Now I'm happy working with embedded "real time", where half a
microsecond too long to respond is a critical failure.
If you've got your own dedicated processor that can busy wait for input,
that's doable. If you've got a multitasking OS on that processor,
latencies that tight are just not gonna happen.
Post by David Seikel
Post by Rob Landley
The only reason this is NOT obvious to Unix greybeards is they haven't
questioned any of their established assumptions in over 30 years.
(You can spot these guys because they still think the word "hacker"
means something other than "variety of criminal that breaks into
computers through the internet".)
I resemble that remark. Well, except I question assumptions all the
time. Gets me into lots of trouble, but usually means I write good
code. My beard IS starting to grey, but I look young for my age.
My father went grey at 19, so I'm less concerned about starting to do so
myself than I might otherwise be.
Post by David Seikel
Post by Rob Landley
Post by David Seikel
The basic
generic file editing stuff could also be used by the non screen
editors.
I'm told it's called "ncurses". I once spent four hours beating a
"hello world" out of it, which is kind of sad if you think about it.
Yes, one of the first things I was glad to do, when I got the job of
rewriting this embedded project from the ground up, was ditch ncurses.
Not the first time this company has hired me to rip their software a
new one, but probably the last, I think they've run out of crappy
software for me to rewrite. B-)
Post by Rob Landley
Post by David Seikel
BTW, I do have one command memorised for those times I accidentally
find myself stuck in vi -
killall -TERM vi
escape-colon-q-exclamation point should get you out of anything.
killall gets you out of way more things than that. :-P
You don't have to say -TERM, it's the default.

Rob
David Seikel
2011-11-22 17:31:02 UTC
Permalink
3AM this side of the planet, one last email before bed.
Post by Rob Landley
Post by David Seikel
Just read your triage blog, and noticed that the only editor in the
group is vi.
That's because the only editors in POSIX-2008 are "vi" and "ed". (I
was triaging the utilities list in the current POSIX standard.)
Post by David Seikel
Unless I missed something.
Yes: the Austin Group POSIX standard update committee meetings back in
2006 or so.
It was too far to swim.
Post by Rob Landley
Post by David Seikel
Personally, I'd want to add
any simple editor that is not vi. Vi fails my editor test, a
complete lack of discoverability.
The only editors Linux has that are worth anything are notepad clones
(which was itself a clone of the original 1980's macintosh text editor).
That said, there are two de-facto standard editors available when you
ssh into a box and get a text mode session: vi and emacs. And the
main advantage of vi has always been "it's not emacs".
Emacs is an utterly horrible waste of time that needs to die. I'm
aware it provides a lithp programming framework for manipulating text
buffers the same way web browsers provide a Javascript programming
framework for manipulating web page contents, and that people have
implemented a Lots of Irritating Superfluous Parentheses script to
feed zippy the pinhead quotes to the Eliza program, AND ARE PROUD OF
THIS. I do not consider this an argument _against_ my position.
Why is it when I say I hate vi, people assume I love emacs? I won't
use either of them if I can help it.
Post by Rob Landley
When I do an editor I want to make the keybindings flexible enough
that it can do vi, nano, microemacs, and ye olde wordstar keybindings
(ala joe, turbo C, and so on) from the same engine. (I want a _C_
programming framework for manipulating a text buffer.)
That's exactly what I'm talking about. B-)
Post by Rob Landley
Post by David Seikel
I'd also want to eventually add a very simple
version of midnight commander (mc).
I'm up for adding an mc clone if somebody wants to do that. I don't
personally use it, but I do miss xtree gold from DOS and OS/2. :)
B-)
Post by Rob Landley
Post by David Seikel
I'm thinking it would be useful to have some common support for full
screen terminal driving. The more command could probably use it to.
So that would be four commands that could use it right off the bat,
which is handy to help keep the design sane. More, vi, something
like nano, and something like a basic cut down mc.
Priorities are wrong there.
Don't think I mentioned priorities, just that more COULD use it to, or
just be as brain dead as simple can make it. After all, toybox's main
design goal is simple.
Post by Rob Landley
Less has to get it _right_, as does line editing for a command shell.
Even before you get to cursor up: unix tty handling is epically
crappy. My commodore 64 could backspace past the left edge of the
screen and continue from the right edge one line up. A TRS-80 could
do this. Unix derivatives _can't_, you have to know when you're at
the left edge of the screen and do the ansi sequences for "cursor up
one, jump right 999". Which means you have to know when backspace
puts you at the left edge of the screen, which means you need to know
when outputting normal characters put you off the _right_ edge of the
screen...
That's right: if you don't know what your current screen size is, your
command shell can't backspace past a line wrap. Welcome to unix
terminal handling.
Yes, I read your blog about that.
Post by Rob Landley
Post by David Seikel
I like your idea that you can pretty much deal with ANSI codes these
days.
I inflicted said idea upon busybox in 2006, and Erik Andersen was
de-facto doing it before my time.
"These days" means DOS 3.x circa 1984. All the unix terminal handling
magic was for different brands of printer in the 1970's (and then the
"glass tty" stuff where you essentially plugged in a printer that
didn't use up reams of paper), back before the computer had a video
card in it.
I'm old enough that "real time" for me used to mean you did not have to
wait a week after submitting your OMR cards to peruse the printout and
spot your "typo", but got the rare privilege of sitting on top of the
noisy bastard printer and actually typing in your typo in "real time".

Now I'm happy working with embedded "real time", where half a
microsecond too long to respond is a critical failure.
Post by Rob Landley
The only reason this is NOT obvious to Unix greybeards is they haven't
questioned any of their established assumptions in over 30 years.
(You can spot these guys because they still think the word "hacker"
means something other than "variety of criminal that breaks into
computers through the internet".)
I resemble that remark. Well, except I question assumptions all the
time. Gets me into lots of trouble, but usually means I write good
code. My beard IS starting to grey, but I look young for my age.
Post by Rob Landley
Post by David Seikel
The basic
generic file editing stuff could also be used by the non screen
editors.
I'm told it's called "ncurses". I once spent four hours beating a
"hello world" out of it, which is kind of sad if you think about it.
Yes, one of the first things I was glad to do, when I got the job of
rewriting this embedded project from the ground up, was ditch ncurses.

Not the first time this company has hired me to rip their software a
new one, but probably the last, I think they've run out of crappy
software for me to rewrite. B-)
Post by Rob Landley
Post by David Seikel
BTW, I do have one command memorised for those times I accidentally
find myself stuck in vi -
killall -TERM vi
escape-colon-q-exclamation point should get you out of anything.
killall gets you out of way more things than that. :-P
Post by Rob Landley
Post by David Seikel
Substituting -KILL if I'm feeling particularly annoyed at it.
Apparently, you are not the target audience of this command. It's
still in posix. (And busybox.)
--
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/20111123/aa9a9d47/attachment-0002.pgp>
David Seikel
2011-11-22 09:09:35 UTC
Permalink
Just read your triage blog, and noticed that the only editor in the
group is vi. Unless I missed something. Personally, I'd want to add
any simple editor that is not vi. Vi fails my editor test, a complete
lack of discoverability. I'd also want to eventually add a very simple
version of midnight commander (mc).

I'm thinking it would be useful to have some common support for full
screen terminal driving. The more command could probably use it to.
So that would be four commands that could use it right off the bat,
which is handy to help keep the design sane. More, vi, something like
nano, and something like a basic cut down mc.

I like your idea that you can pretty much deal with ANSI codes these
days. I have seen a really tiny editor, that used a profiles concept,
you could invoke it to act like simple versions of a number of popular
editors. It was written in pure assembler though.

If I have time, I'd like to tackle writing a common library of full
screen terminal app code, and basic generic file editing. The basic
generic file editing stuff could also be used by the non screen
editors.

BTW, I do have one command memorised for those times I accidentally
find myself stuck in vi -

killall -TERM vi

Substituting -KILL if I'm feeling particularly annoyed at it.
--
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/20111122/b7b8c27a/attachment-0002.pgp>
Rob Landley
2011-11-22 14:02:19 UTC
Permalink
Post by David Seikel
Just read your triage blog, and noticed that the only editor in the
group is vi.
That's because the only editors in POSIX-2008 are "vi" and "ed". (I was
triaging the utilities list in the current POSIX standard.)
Post by David Seikel
Unless I missed something.
Yes: the Austin Group POSIX standard update committee meetings back in
2006 or so.
Post by David Seikel
Personally, I'd want to add
any simple editor that is not vi. Vi fails my editor test, a complete
lack of discoverability.
The only editors Linux has that are worth anything are notepad clones
(which was itself a clone of the original 1980's macintosh text editor).

That said, there are two de-facto standard editors available when you
ssh into a box and get a text mode session: vi and emacs. And the main
advantage of vi has always been "it's not emacs".

Emacs is an utterly horrible waste of time that needs to die. I'm aware
it provides a lithp programming framework for manipulating text buffers
the same way web browsers provide a Javascript programming framework for
manipulating web page contents, and that people have implemented a Lots
of Irritating Superfluous Parentheses script to feed zippy the pinhead
quotes to the Eliza program, AND ARE PROUD OF THIS. I do not consider
this an argument _against_ my position.

When I do an editor I want to make the keybindings flexible enough that
it can do vi, nano, microemacs, and ye olde wordstar keybindings (ala
joe, turbo C, and so on) from the same engine. (I want a _C_
programming framework for manipulating a text buffer.)

But I haven't written that yet, and it's not low-hanging-fruit.
Post by David Seikel
I'd also want to eventually add a very simple
version of midnight commander (mc).
I'm up for adding an mc clone if somebody wants to do that. I don't
personally use it, but I do miss xtree gold from DOS and OS/2. :)
Post by David Seikel
I'm thinking it would be useful to have some common support for full
screen terminal driving. The more command could probably use it to.
So that would be four commands that could use it right off the bat,
which is handy to help keep the design sane. More, vi, something like
nano, and something like a basic cut down mc.
Priorities are wrong there.

More can totally half-ass what it does because the standard requires a
"-num" option to specify the number of vertical lines, and it can always
fall back to 80x25 if it gets confused. Me getting hung up on
infrastructure issues says more about me than about more.

Less has to get it _right_, as does line editing for a command shell.
Even before you get to cursor up: unix tty handling is epically crappy.
My commodore 64 could backspace past the left edge of the screen and
continue from the right edge one line up. A TRS-80 could do this. Unix
derivatives _can't_, you have to know when you're at the left edge of
the screen and do the ansi sequences for "cursor up one, jump right
999". Which means you have to know when backspace puts you at the left
edge of the screen, which means you need to know when outputting normal
characters put you off the _right_ edge of the screen...

That's right: if you don't know what your current screen size is, your
command shell can't backspace past a line wrap. Welcome to unix
terminal handling.
Post by David Seikel
I like your idea that you can pretty much deal with ANSI codes these
days.
I inflicted said idea upon busybox in 2006, and Erik Andersen was
de-facto doing it before my time.

"These days" means DOS 3.x circa 1984. All the unix terminal handling
magic was for different brands of printer in the 1970's (and then the
"glass tty" stuff where you essentially plugged in a printer that didn't
use up reams of paper), back before the computer had a video card in it.

In 1987 Unix got xterms, which are software. So your output is being
parsed by a program, and having 237 different output formats a piece of
software can use to talk to another piece of software, even for
historical reasons, is insane. Just PICK ONE. And the one DOS picked
was a subset of ANSI, and they shipped over 100 million units, and Linux
inherited their hardware.

The only reason this is NOT obvious to Unix greybeards is they haven't
questioned any of their established assumptions in over 30 years. (You
can spot these guys because they still think the word "hacker" means
something other than "variety of criminal that breaks into computers
through the internet".)
Post by David Seikel
I have seen a really tiny editor, that used a profiles concept,
you could invoke it to act like simple versions of a number of popular
editors. It was written in pure assembler though.
When I was around 17 I wrote my first DOS bulletin board system (after
writing 3 of them on the commodore 64, and extensively mangling two
different versions of WWIV). It compiled a rather sad scripting
language into bytecode, and used it to emulate the user interface of
WWIV and deadlock and a couple others.

Not a new idea, really.
Post by David Seikel
If I have time, I'd like to tackle writing a common library of full
screen terminal app code, and basic generic file editing.
Infrastructure in search of a user isn't my idea of fun. And you can
output raw ansi escape sequences with "echo", that's not the hard part.

Back in 2006 I wrote a function for busybox that fell back to something
like three different methods to determine screen size (COLUMNS and LINES
environment variables, tty querying of both stdin and stdout, and
finally the escape sequence to query xterm across a serial connection).

I blogged about it last week (on the 15th). The problem is receiving
asynchronous escape sequence input after an arbitrary delay, potentially
intermixed (queued up behind) other random user input: doable, but has
to be part of a line editing thing that can make use of the rest of the
data rather than just discarding it.

Here's a fun one:

cat /proc/mounts | less

When less outputs the escape sequence to query terminal parameters, it
has to peek not stdin but /dev/tty. Except the cursor keys scrolling up
and down also come from /dev/tty, as do "user hit forward slash and
wants to type in a search regex"... Innit fun?

Plus you have to figure out the width of what you're outputting, which
means isprint() and probably UTF8 awareness... (Flashbacks to
fontmetrics in java 1.1, but we can assume monospace text grid...)
Post by David Seikel
The basic
generic file editing stuff could also be used by the non screen
editors.
I'm told it's called "ncurses". I once spent four hours beating a
"hello world" out of it, which is kind of sad if you think about it.
Post by David Seikel
BTW, I do have one command memorised for those times I accidentally
find myself stuck in vi -
killall -TERM vi
escape-colon-q-exclamation point should get you out of anything.
Post by David Seikel
Substituting -KILL if I'm feeling particularly annoyed at it.
Apparently, you are not the target audience of this command. It's still
in posix. (And busybox.)

Rob
Roy Tam
2012-06-17 05:14:34 UTC
Permalink
Post by David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
maybe we can have a simplified GNU SCREEN with it? ;-)

Best regards,
Roy
David Seikel
2012-06-17 06:13:15 UTC
Permalink
Post by Roy Tam
Post by David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
That's exactly what I did, and that worked fine. Still, shows there's
a problem in toybox. The name "toyboxes" failed, coz it got confused
with "toybox", the name "boxes" worked. I can't think off the top of my
head of any other cases where a command we might want to support has
it's name being a subset of the name of some other command we might
want to support, but it could happen.
Post by Roy Tam
maybe we can have a simplified GNU SCREEN with it? ;-)
Does GNU own screen? Careful with such assumptions around here.

I do have a note on my design docs that it might be possible to
implement something like screen or tmux, and a warning not to turn into
curses or twin. lol

The design goal is to support things like full screen text viewers,
editors, and midnight commander. Being a generalised full screen text
UI library is out of scope. Side by side boxes, status lines, menus,
scrolling text, text editing, these things are in scope. A centred
popup widget for selecting options and entering command parameters is
borderline in scope, I'm gonna see if I can leave it out at first.
Arbitrary text "windows" that you can drag around with the mouse,
cacalib support, these things are out of scope.

Screen and tmux do happen to fall within the scope of what is supported
by the library design though. There's a nohup toy, so it might be
possible. That's about the limit of my thoughts in how to support
screen or tmux. I'm not going out of my way to support them, but it
may be possible anyway.

So far the code has ended up being a lot simpler than I expected. B-)
--
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/20120617/f7b33df7/attachment.pgp>
Roy Tam
2012-06-17 11:20:12 UTC
Permalink
Post by Roy Tam
Post by David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. ?Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
That's exactly what I did, and that worked fine. ?Still, shows there's
a problem in toybox. ?The name "toyboxes" failed, coz it got confused
with "toybox", the name "boxes" worked. ?I can't think off the top of my
head of any other cases where a command we might want to support has
it's name being a subset of the name of some other command we might
want to support, but it could happen.
Post by Roy Tam
maybe we can have a simplified GNU SCREEN with it? ;-)
Does GNU own screen? ?Careful with such assumptions around here.
Yes they did.
http://www.gnu.org/software/screen/
I do have a note on my design docs that it might be possible to
implement something like screen or tmux, and a warning not to turn into
curses or twin. lol
The design goal is to support things like full screen text viewers,
editors, and midnight commander. ?Being a generalised full screen text
UI library is out of scope. ?Side by side boxes, status lines, menus,
scrolling text, text editing, these things are in scope. ?A centred
popup widget for selecting options and entering command parameters is
borderline in scope, I'm gonna see if I can leave it out at first.
Arbitrary text "windows" that you can drag around with the mouse,
cacalib support, these things are out of scope.
Screen and tmux do happen to fall within the scope of what is supported
by the library design though. ?There's a nohup toy, so it might be
possible. ?That's about the limit of my thoughts in how to support
screen or tmux. ?I'm not going out of my way to support them, but it
may be possible anyway.
So far the code has ended up being a lot simpler than I expected. ?B-)
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
_______________________________________________
Toybox mailing list
Toybox at lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
David Seikel
2012-06-17 11:32:09 UTC
Permalink
Post by Roy Tam
On Fri, Sat Jun 16 08:47:05 PDT 2012 David Seikel
Post by David Seikel
On Fri, 15 Jun 2012 21:20:11 +1000 David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. ?Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
That's exactly what I did, and that worked fine. ?Still, shows
there's a problem in toybox. ?The name "toyboxes" failed, coz it
got confused with "toybox", the name "boxes" worked. ?I can't think
off the top of my head of any other cases where a command we might
want to support has it's name being a subset of the name of some
other command we might want to support, but it could happen.
maybe we can have a simplified GNU SCREEN with it? ;-)
Does GNU own screen? ?Careful with such assumptions around here.
Yes they did.
http://www.gnu.org/software/screen/
It's hosted there, but I don't think they own it.
--
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/20120617/259245ef/attachment.pgp>
Roy Tam
2012-06-18 01:00:09 UTC
Permalink
Post by David Seikel
Post by Roy Tam
On Fri, Sat Jun 16 08:47:05 PDT 2012 David Seikel
Post by David Seikel
On Fri, 15 Jun 2012 21:20:11 +1000 David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. ?Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
That's exactly what I did, and that worked fine. ?Still, shows
there's a problem in toybox. ?The name "toyboxes" failed, coz it
got confused with "toybox", the name "boxes" worked. ?I can't think
off the top of my head of any other cases where a command we might
want to support has it's name being a subset of the name of some
other command we might want to support, but it could happen.
maybe we can have a simplified GNU SCREEN with it? ;-)
Does GNU own screen? ?Careful with such assumptions around here.
Yes they did.
http://www.gnu.org/software/screen/
It's hosted there, but I don't think they own it.
even wikipedia says so, although the developer names can also be found
in the article.
http://en.wikipedia.org/wiki/GNU_Screen
Post by David Seikel
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
_______________________________________________
Toybox mailing list
Toybox at lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Roy Tam
2012-06-18 01:00:09 UTC
Permalink
Post by David Seikel
Post by Roy Tam
On Fri, Sat Jun 16 08:47:05 PDT 2012 David Seikel
Post by David Seikel
On Fri, 15 Jun 2012 21:20:11 +1000 David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. ?Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
That's exactly what I did, and that worked fine. ?Still, shows
there's a problem in toybox. ?The name "toyboxes" failed, coz it
got confused with "toybox", the name "boxes" worked. ?I can't think
off the top of my head of any other cases where a command we might
want to support has it's name being a subset of the name of some
other command we might want to support, but it could happen.
maybe we can have a simplified GNU SCREEN with it? ;-)
Does GNU own screen? ?Careful with such assumptions around here.
Yes they did.
http://www.gnu.org/software/screen/
It's hosted there, but I don't think they own it.
even wikipedia says so, although the developer names can also be found
in the article.
http://en.wikipedia.org/wiki/GNU_Screen
Post by David Seikel
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
_______________________________________________
Toybox mailing list
Toybox at lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Rob Landley
2012-06-18 14:38:17 UTC
Permalink
Post by Roy Tam
Post by David Seikel
Post by Roy Tam
Post by David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
That's exactly what I did, and that worked fine. Still, shows there's
a problem in toybox. The name "toyboxes" failed, coz it got confused
with "toybox", the name "boxes" worked. I can't think off the top of my
head of any other cases where a command we might want to support has
it's name being a subset of the name of some other command we might
want to support, but it could happen.
Post by Roy Tam
maybe we can have a simplified GNU SCREEN with it? ;-)
Does GNU own screen? Careful with such assumptions around here.
Yes they did.
http://www.gnu.org/software/screen/
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.

The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Andre Renaud
2012-06-19 03:10:59 UTC
Permalink
Post by Rob Landley
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.

Regards,
Andre
David Seikel
2012-06-19 06:14:54 UTC
Permalink
On Tue, 19 Jun 2012 15:10:59 +1200 Andre Renaud
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it
over to a second pair of maintainers who handed it over to the gnu
somebody wrote a thing that worked and the Gnu project managed to
take it over and plaster their name all over it as the versions
they ship bloat and lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I did mention tmux when I talked about screen the first time. I was
saying that using my new infrastructure and perhaps something like the
nohup toy, it might be possible to implement something like screen or
tmux. It's not actually on my TODO, not part of the design to
specifically support such things, just mentioning that it might be
possible.

I actually use tmux in preference to screen, but that's not a subject
for this list. I don't think either screen or tmux are on the toybox
roadmap.

Tmux is a completely different design to screen. It serves the same
purpose, but is enough different that I doubt if it was even useful for
them to share code. I got the impression they did not WANT any of
screen's code.
--
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/20120619/a15b4d78/attachment.pgp>
David Seikel
2012-08-04 18:15:08 UTC
Permalink
On Tue, 19 Jun 2012 16:14:54 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
On Tue, 19 Jun 2012 15:10:59 +1200 Andre Renaud
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed
it over to a second pair of maintainers who handed it over to the
gnu project. So it's a bit like Gold and Patch and Grub and EGCS
so on: somebody wrote a thing that worked and the Gnu project
managed to take it over and plaster their name all over it as the
versions they ship bloat and lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I did mention tmux when I talked about screen the first time. I was
saying that using my new infrastructure and perhaps something like the
nohup toy, it might be possible to implement something like screen or
tmux. It's not actually on my TODO, not part of the design to
specifically support such things, just mentioning that it might be
possible.
I actually use tmux in preference to screen, but that's not a subject
for this list. I don't think either screen or tmux are on the toybox
roadmap.
Just spotted waaay down the bottom of
http://www.landley.net/code/toybox/todo.txt -

"Maybe:
screen,"

So I'll look at it I guess. Very low priority, but some of the other
things I want to do should also support most of screen.
--
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/20120805/f3e1b6ae/attachment.pgp>
David Seikel
2012-08-04 18:15:08 UTC
Permalink
On Tue, 19 Jun 2012 16:14:54 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
On Tue, 19 Jun 2012 15:10:59 +1200 Andre Renaud
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed
it over to a second pair of maintainers who handed it over to the
gnu project. So it's a bit like Gold and Patch and Grub and EGCS
so on: somebody wrote a thing that worked and the Gnu project
managed to take it over and plaster their name all over it as the
versions they ship bloat and lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I did mention tmux when I talked about screen the first time. I was
saying that using my new infrastructure and perhaps something like the
nohup toy, it might be possible to implement something like screen or
tmux. It's not actually on my TODO, not part of the design to
specifically support such things, just mentioning that it might be
possible.
I actually use tmux in preference to screen, but that's not a subject
for this list. I don't think either screen or tmux are on the toybox
roadmap.
Just spotted waaay down the bottom of
http://www.landley.net/code/toybox/todo.txt -

"Maybe:
screen,"

So I'll look at it I guess. Very low priority, but some of the other
things I want to do should also support most of screen.
--
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/20120805/f3e1b6ae/attachment-0002.pgp>
Rob Landley
2012-06-20 23:57:03 UTC
Permalink
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I wrote a terminal multiplexer for my old "chamelyn" bulletin board
system as a teenager. (DOS with Desqview. Those were the days. Well,
some of 'em anyway.)

All the tabbed browsing terminals are also terminal multiplexers. In
Linux, ptys make it easy.

The fiddly part is curses output, but the line handling stuff for
editing a shell command line and doing command line history is 90% of
the work, and then stacking those vertically gets you something like vi.
(That was my general plan of attack, anyway.)

Keep in mind that Unix doesn't implement backspace sanely (like the
commodore 64 did), thus you have to figure out when you're at the left
edge of the screen (keeping track of your cursor position)

That's why if you do "echo -n this will screw bash up" and then cursor
up a few times bash's command history gets all wonky because it _thinks_
it knows where the cursor is but actually started farther to the right.
(I contributed ansi escape screen position querying code to busybox to
improve the situation for ash.)

I'm pretty sure I blogged about this... Recentish:

http://landley.net/notes-2011.html#15-11-2011

During toybox's first regeneration:

http://landley.net/notes-2007.html#19-10-2007

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-21 05:00:07 UTC
Permalink
Post by Rob Landley
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed
it over to a second pair of maintainers who handed it over to the
gnu project. So it's a bit like Gold and Patch and Grub and EGCS
so on: somebody wrote a thing that worked and the Gnu project
managed to take it over and plaster their name all over it as the
versions they ship bloat and lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I wrote a terminal multiplexer for my old "chamelyn" bulletin board
system as a teenager. (DOS with Desqview. Those were the days. Well,
some of 'em anyway.)
All the tabbed browsing terminals are also terminal multiplexers. In
Linux, ptys make it easy.
The fiddly part is curses output, but the line handling stuff for
editing a shell command line and doing command line history is 90% of
the work, and then stacking those vertically gets you something like
vi. (That was my general plan of attack, anyway.)
Keep in mind that Unix doesn't implement backspace sanely (like the
commodore 64 did), thus you have to figure out when you're at the left
edge of the screen (keeping track of your cursor position)
That's why if you do "echo -n this will screw bash up" and then cursor
up a few times bash's command history gets all wonky because it
_thinks_ it knows where the cursor is but actually started farther to
the right. (I contributed ansi escape screen position querying code
to busybox to improve the situation for ash.)
http://landley.net/notes-2011.html#15-11-2011
http://landley.net/notes-2007.html#19-10-2007
I was pretty much coming to the conclusion that I would have to write
something that smells like readline. Sounds like you agree.

I'm half tempted to implement tabbed boxes as well, but that would be
low priority
--
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/20120621/3c9f9570/attachment.pgp>
Jens Staal
2012-06-21 06:48:36 UTC
Permalink
Post by David Seikel
I was pretty much coming to the conclusion that I would have to write
something that smells like readline. Sounds like you agree.
I'm half tempted to implement tabbed boxes as well, but that would be
low priority
To save you the trouble, linenoise (https://github.com/antirez/linenoise)
is an alternative to GNU and BSD readline/libedit and significantly lighter.
It is not a drop-in replacement and not a traditional stand alone library but
rather a .c and a .h file that can be integrated in projects that want line
editing. Apparently Android uses it...

For the curses stuff discussed earlier, termbox looks interesting although also
not a drop-in replacement.
David Seikel
2012-06-21 07:21:48 UTC
Permalink
On Thu, 21 Jun 2012 08:48:36 +0200 Jens Staal <staal1978 at gmail.com>
Post by Jens Staal
Post by David Seikel
I was pretty much coming to the conclusion that I would have to
write something that smells like readline. Sounds like you agree.
I'm half tempted to implement tabbed boxes as well, but that would
be low priority
To save you the trouble, linenoise
(https://github.com/antirez/linenoise) is an alternative to GNU and
BSD readline/libedit and significantly lighter. It is not a drop-in
replacement and not a traditional stand alone library but rather a .c
and a .h file that can be integrated in projects that want line
editing. Apparently Android uses it...
For the curses stuff discussed earlier, termbox looks interesting
although also not a drop-in replacement.
I'll look at them both. Not being drop in replacements is fine, since
we are not currently using either readline or curses.
--
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/20120621/343738fe/attachment.pgp>
David Seikel
2012-06-21 10:18:58 UTC
Permalink
On Thu, 21 Jun 2012 17:21:48 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
On Thu, 21 Jun 2012 08:48:36 +0200 Jens Staal <staal1978 at gmail.com>
Post by Jens Staal
Post by David Seikel
I was pretty much coming to the conclusion that I would have to
write something that smells like readline. Sounds like you agree.
I'm half tempted to implement tabbed boxes as well, but that would
be low priority
To save you the trouble, linenoise
(https://github.com/antirez/linenoise) is an alternative to GNU and
BSD readline/libedit and significantly lighter. It is not a drop-in
replacement and not a traditional stand alone library but rather
a .c and a .h file that can be integrated in projects that want line
editing. Apparently Android uses it...
For the curses stuff discussed earlier, termbox looks interesting
although also not a drop-in replacement.
I'll look at them both. Not being drop in replacements is fine, since
we are not currently using either readline or curses.
Actually, I had looked at termbox before, and put it aside until I got
around to working in this project. Now I have dusted it off and
looking at both of those.

I can see some scope in combining source code from both and mixing them
into what I did already, and what I plan. There's a bit of duplication
I would like to tidy up, and some generalizations that can be made to
further reduce code. We don't really need two input loops and two
different ways of interpreting keystrokes for instance.
--
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/20120621/f49129fc/attachment.pgp>
David Seikel
2012-06-21 10:18:58 UTC
Permalink
On Thu, 21 Jun 2012 17:21:48 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
On Thu, 21 Jun 2012 08:48:36 +0200 Jens Staal <staal1978 at gmail.com>
Post by Jens Staal
Post by David Seikel
I was pretty much coming to the conclusion that I would have to
write something that smells like readline. Sounds like you agree.
I'm half tempted to implement tabbed boxes as well, but that would
be low priority
To save you the trouble, linenoise
(https://github.com/antirez/linenoise) is an alternative to GNU and
BSD readline/libedit and significantly lighter. It is not a drop-in
replacement and not a traditional stand alone library but rather
a .c and a .h file that can be integrated in projects that want line
editing. Apparently Android uses it...
For the curses stuff discussed earlier, termbox looks interesting
although also not a drop-in replacement.
I'll look at them both. Not being drop in replacements is fine, since
we are not currently using either readline or curses.
Actually, I had looked at termbox before, and put it aside until I got
around to working in this project. Now I have dusted it off and
looking at both of those.

I can see some scope in combining source code from both and mixing them
into what I did already, and what I plan. There's a bit of duplication
I would like to tidy up, and some generalizations that can be made to
further reduce code. We don't really need two input loops and two
different ways of interpreting keystrokes for instance.
--
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/20120621/f49129fc/attachment-0002.pgp>
David Seikel
2012-06-21 07:21:48 UTC
Permalink
On Thu, 21 Jun 2012 08:48:36 +0200 Jens Staal <staal1978 at gmail.com>
Post by Jens Staal
Post by David Seikel
I was pretty much coming to the conclusion that I would have to
write something that smells like readline. Sounds like you agree.
I'm half tempted to implement tabbed boxes as well, but that would
be low priority
To save you the trouble, linenoise
(https://github.com/antirez/linenoise) is an alternative to GNU and
BSD readline/libedit and significantly lighter. It is not a drop-in
replacement and not a traditional stand alone library but rather a .c
and a .h file that can be integrated in projects that want line
editing. Apparently Android uses it...
For the curses stuff discussed earlier, termbox looks interesting
although also not a drop-in replacement.
I'll look at them both. Not being drop in replacements is fine, since
we are not currently using either readline or curses.
--
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/20120621/343738fe/attachment-0002.pgp>
Rob Landley
2012-06-22 13:52:33 UTC
Permalink
Post by David Seikel
Post by Rob Landley
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed
it over to a second pair of maintainers who handed it over to the
gnu project. So it's a bit like Gold and Patch and Grub and EGCS
so on: somebody wrote a thing that worked and the Gnu project
managed to take it over and plaster their name all over it as the
versions they ship bloat and lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I wrote a terminal multiplexer for my old "chamelyn" bulletin board
system as a teenager. (DOS with Desqview. Those were the days. Well,
some of 'em anyway.)
All the tabbed browsing terminals are also terminal multiplexers. In
Linux, ptys make it easy.
The fiddly part is curses output, but the line handling stuff for
editing a shell command line and doing command line history is 90% of
the work, and then stacking those vertically gets you something like
vi. (That was my general plan of attack, anyway.)
Keep in mind that Unix doesn't implement backspace sanely (like the
commodore 64 did), thus you have to figure out when you're at the left
edge of the screen (keeping track of your cursor position)
That's why if you do "echo -n this will screw bash up" and then cursor
up a few times bash's command history gets all wonky because it
_thinks_ it knows where the cursor is but actually started farther to
the right. (I contributed ansi escape screen position querying code
to busybox to improve the situation for ash.)
http://landley.net/notes-2011.html#15-11-2011
http://landley.net/notes-2007.html#19-10-2007
I was pretty much coming to the conclusion that I would have to write
something that smells like readline. Sounds like you agree.
toysh needs readline. less needs readline (forward slash searches). vi
not only needs it for colon mode, but implemented correctly the rest of
it could be _built_ on top of it. And once you have "manage a text
buffer, respond to escapes" pretty much any text editor becomes a config
file for this (although vi is the only one required by posix). And then
there's screen...
Post by David Seikel
I'm half tempted to implement tabbed boxes as well, but that would be
low priority
Managing an area of the screen other than the current screen size
shouldn't be too big a deal.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Jens Staal
2012-06-21 06:48:36 UTC
Permalink
Post by David Seikel
I was pretty much coming to the conclusion that I would have to write
something that smells like readline. Sounds like you agree.
I'm half tempted to implement tabbed boxes as well, but that would be
low priority
To save you the trouble, linenoise (https://github.com/antirez/linenoise)
is an alternative to GNU and BSD readline/libedit and significantly lighter.
It is not a drop-in replacement and not a traditional stand alone library but
rather a .c and a .h file that can be integrated in projects that want line
editing. Apparently Android uses it...

For the curses stuff discussed earlier, termbox looks interesting although also
not a drop-in replacement.
Rob Landley
2012-06-22 13:52:33 UTC
Permalink
Post by David Seikel
Post by Rob Landley
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed
it over to a second pair of maintainers who handed it over to the
gnu project. So it's a bit like Gold and Patch and Grub and EGCS
so on: somebody wrote a thing that worked and the Gnu project
managed to take it over and plaster their name all over it as the
versions they ship bloat and lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I wrote a terminal multiplexer for my old "chamelyn" bulletin board
system as a teenager. (DOS with Desqview. Those were the days. Well,
some of 'em anyway.)
All the tabbed browsing terminals are also terminal multiplexers. In
Linux, ptys make it easy.
The fiddly part is curses output, but the line handling stuff for
editing a shell command line and doing command line history is 90% of
the work, and then stacking those vertically gets you something like
vi. (That was my general plan of attack, anyway.)
Keep in mind that Unix doesn't implement backspace sanely (like the
commodore 64 did), thus you have to figure out when you're at the left
edge of the screen (keeping track of your cursor position)
That's why if you do "echo -n this will screw bash up" and then cursor
up a few times bash's command history gets all wonky because it
_thinks_ it knows where the cursor is but actually started farther to
the right. (I contributed ansi escape screen position querying code
to busybox to improve the situation for ash.)
http://landley.net/notes-2011.html#15-11-2011
http://landley.net/notes-2007.html#19-10-2007
I was pretty much coming to the conclusion that I would have to write
something that smells like readline. Sounds like you agree.
toysh needs readline. less needs readline (forward slash searches). vi
not only needs it for colon mode, but implemented correctly the rest of
it could be _built_ on top of it. And once you have "manage a text
buffer, respond to escapes" pretty much any text editor becomes a config
file for this (although vi is the only one required by posix). And then
there's screen...
Post by David Seikel
I'm half tempted to implement tabbed boxes as well, but that would be
low priority
Managing an area of the screen other than the current screen size
shouldn't be too big a deal.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-21 05:00:07 UTC
Permalink
Post by Rob Landley
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed
it over to a second pair of maintainers who handed it over to the
gnu project. So it's a bit like Gold and Patch and Grub and EGCS
so on: somebody wrote a thing that worked and the Gnu project
managed to take it over and plaster their name all over it as the
versions they ship bloat and lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I wrote a terminal multiplexer for my old "chamelyn" bulletin board
system as a teenager. (DOS with Desqview. Those were the days. Well,
some of 'em anyway.)
All the tabbed browsing terminals are also terminal multiplexers. In
Linux, ptys make it easy.
The fiddly part is curses output, but the line handling stuff for
editing a shell command line and doing command line history is 90% of
the work, and then stacking those vertically gets you something like
vi. (That was my general plan of attack, anyway.)
Keep in mind that Unix doesn't implement backspace sanely (like the
commodore 64 did), thus you have to figure out when you're at the left
edge of the screen (keeping track of your cursor position)
That's why if you do "echo -n this will screw bash up" and then cursor
up a few times bash's command history gets all wonky because it
_thinks_ it knows where the cursor is but actually started farther to
the right. (I contributed ansi escape screen position querying code
to busybox to improve the situation for ash.)
http://landley.net/notes-2011.html#15-11-2011
http://landley.net/notes-2007.html#19-10-2007
I was pretty much coming to the conclusion that I would have to write
something that smells like readline. Sounds like you agree.

I'm half tempted to implement tabbed boxes as well, but that would be
low priority
--
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/20120621/3c9f9570/attachment-0002.pgp>
Marc Andre Tanner
2012-06-21 09:03:48 UTC
Permalink
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I might be a little biased but

http://www.brain-dump.org/projects/dvtm/

works reasonably well for my purposes and the code isn't the worst either.
Also in my opinion session handling / detach support is a separate issue
and should be handled with dtach or a similar standalone program.

Marc
--
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
David Seikel
2012-06-21 10:06:03 UTC
Permalink
On Thu, 21 Jun 2012 11:03:48 +0200 Marc Andre Tanner
Post by Marc Andre Tanner
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed
it over to a second pair of maintainers who handed it over to the
gnu project. So it's a bit like Gold and Patch and Grub and EGCS
so on: somebody wrote a thing that worked and the Gnu project
managed to take it over and plaster their name all over it as the
versions they ship bloat and lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I might be a little biased but
http://www.brain-dump.org/projects/dvtm/
works reasonably well for my purposes and the code isn't the worst either.
I think that shares some functionality with what we want to do, but it
uses curses, which is a concept we are definitely trying to get away
from. The basic concept is "terminal handling can be done generically
with just a few standard ANSI escape sequences that pretty much all
modern terminals can handle".
Post by Marc Andre Tanner
Also in my opinion session handling / detach support is a separate
issue and should be handled with dtach or a similar standalone
program.
A agree that this is a separate issue, best dealt with by some other
program. Though no reason why that other program could not be some
other toy.
--
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/20120621/8ff90e9e/attachment.pgp>
Rob Landley
2012-06-22 13:45:49 UTC
Permalink
Post by Marc Andre Tanner
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I might be a little biased but
http://www.brain-dump.org/projects/dvtm/
works reasonably well for my purposes and the code isn't the worst either.
Also in my opinion session handling / detach support is a separate issue
and should be handled with dtach or a similar standalone program.
I'm ok saying we _shouldn't_ have something in toybox if it's
sufficiently complicated and there's an existing standalone solution for
it that's clean.

Dropbear and tinycc are like that: not part of toybox. Even though ssh
is enormously useful and having a 'c99' command is required by posix 2008.

The question here is how much of this we already need to do for shell
history, which is what I was going to implement first. (Actually the one
I've already sat down and wrestled with is "more", which turns out to
have rather a lot of these issues as well. Knowing what printable
characters actually _print_ so you know where your darn cursor is and
where the screen wraps. You'd think less would have more issues here,
but more actually hits just about all of 'em...)

Moving the cursor isn't the issue. Querying the screen size is a
reasonably contained issue. Knowing how the cursor will move when you
print out an arbitrary string: that's the hard part. (utf8 awareness is
kinda required here. And I'm assuming a monospaced font even in klingon.
And replacing the !isprint() characters below space with escape
sequences...)

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-21 10:06:03 UTC
Permalink
On Thu, 21 Jun 2012 11:03:48 +0200 Marc Andre Tanner
Post by Marc Andre Tanner
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed
it over to a second pair of maintainers who handed it over to the
gnu project. So it's a bit like Gold and Patch and Grub and EGCS
so on: somebody wrote a thing that worked and the Gnu project
managed to take it over and plaster their name all over it as the
versions they ship bloat and lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I might be a little biased but
http://www.brain-dump.org/projects/dvtm/
works reasonably well for my purposes and the code isn't the worst either.
I think that shares some functionality with what we want to do, but it
uses curses, which is a concept we are definitely trying to get away
from. The basic concept is "terminal handling can be done generically
with just a few standard ANSI escape sequences that pretty much all
modern terminals can handle".
Post by Marc Andre Tanner
Also in my opinion session handling / detach support is a separate
issue and should be handled with dtach or a similar standalone
program.
A agree that this is a separate issue, best dealt with by some other
program. Though no reason why that other program could not be some
other toy.
--
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/20120621/8ff90e9e/attachment-0002.pgp>
Rob Landley
2012-06-22 13:45:49 UTC
Permalink
Post by Marc Andre Tanner
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I might be a little biased but
http://www.brain-dump.org/projects/dvtm/
works reasonably well for my purposes and the code isn't the worst either.
Also in my opinion session handling / detach support is a separate issue
and should be handled with dtach or a similar standalone program.
I'm ok saying we _shouldn't_ have something in toybox if it's
sufficiently complicated and there's an existing standalone solution for
it that's clean.

Dropbear and tinycc are like that: not part of toybox. Even though ssh
is enormously useful and having a 'c99' command is required by posix 2008.

The question here is how much of this we already need to do for shell
history, which is what I was going to implement first. (Actually the one
I've already sat down and wrestled with is "more", which turns out to
have rather a lot of these issues as well. Knowing what printable
characters actually _print_ so you know where your darn cursor is and
where the screen wraps. You'd think less would have more issues here,
but more actually hits just about all of 'em...)

Moving the cursor isn't the issue. Querying the screen size is a
reasonably contained issue. Knowing how the cursor will move when you
print out an arbitrary string: that's the hard part. (utf8 awareness is
kinda required here. And I'm assuming a monospaced font even in klingon.
And replacing the !isprint() characters below space with escape
sequences...)

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-19 06:14:54 UTC
Permalink
On Tue, 19 Jun 2012 15:10:59 +1200 Andre Renaud
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it
over to a second pair of maintainers who handed it over to the gnu
somebody wrote a thing that worked and the Gnu project managed to
take it over and plaster their name all over it as the versions
they ship bloat and lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I did mention tmux when I talked about screen the first time. I was
saying that using my new infrastructure and perhaps something like the
nohup toy, it might be possible to implement something like screen or
tmux. It's not actually on my TODO, not part of the design to
specifically support such things, just mentioning that it might be
possible.

I actually use tmux in preference to screen, but that's not a subject
for this list. I don't think either screen or tmux are on the toybox
roadmap.

Tmux is a completely different design to screen. It serves the same
purpose, but is enough different that I doubt if it was even useful for
them to share code. I got the impression they did not WANT any of
screen's code.
--
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/20120619/a15b4d78/attachment-0002.pgp>
Rob Landley
2012-06-20 23:57:03 UTC
Permalink
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I wrote a terminal multiplexer for my old "chamelyn" bulletin board
system as a teenager. (DOS with Desqview. Those were the days. Well,
some of 'em anyway.)

All the tabbed browsing terminals are also terminal multiplexers. In
Linux, ptys make it easy.

The fiddly part is curses output, but the line handling stuff for
editing a shell command line and doing command line history is 90% of
the work, and then stacking those vertically gets you something like vi.
(That was my general plan of attack, anyway.)

Keep in mind that Unix doesn't implement backspace sanely (like the
commodore 64 did), thus you have to figure out when you're at the left
edge of the screen (keeping track of your cursor position)

That's why if you do "echo -n this will screw bash up" and then cursor
up a few times bash's command history gets all wonky because it _thinks_
it knows where the cursor is but actually started farther to the right.
(I contributed ansi escape screen position querying code to busybox to
improve the situation for ash.)

I'm pretty sure I blogged about this... Recentish:

http://landley.net/notes-2011.html#15-11-2011

During toybox's first regeneration:

http://landley.net/notes-2007.html#19-10-2007

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Marc Andre Tanner
2012-06-21 09:03:48 UTC
Permalink
Post by Andre Renaud
Post by Rob Landley
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.
I might be a little biased but

http://www.brain-dump.org/projects/dvtm/

works reasonably well for my purposes and the code isn't the worst either.
Also in my opinion session handling / detach support is a separate issue
and should be handled with dtach or a similar standalone program.

Marc
--
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Rob Landley
2012-06-21 05:14:51 UTC
Permalink
Post by David Seikel
Post by Rob Landley
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.
perhaps
http://tmux.sourceforge.net/
could be an interesting alternative
Doing a "less" or "vi" implementation is 90% of doing screen. You have a
text buffer that displays on the screen. You write at the current cursor
position to update that text buffer.

That's pretty much what screen and less both do. I'd like to get them to
share infrastructure to do it, which means writing some kind of
lib/buffer.c.

Rob

P.S. Sorry for the delay. Thunderbird is just _eating_ itself since the
last ubuntu package update. It sits there at 100% cpu for six hours and
then downloads _some_ of the outstanding messages. Today, it gave me 3
days worth of email at once, after telling me i didn't have any.

My new netbook, I'll be setting up a different mail client, I just have
to figure out which one...
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-21 05:40:16 UTC
Permalink
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed
it over to a second pair of maintainers who handed it over to the
gnu project. So it's a bit like Gold and Patch and Grub and EGCS
so on: somebody wrote a thing that worked and the Gnu project
managed to take it over and plaster their name all over it as the
versions they ship bloat and lose reliability.
perhaps
http://tmux.sourceforge.net/
could be an interesting alternative
Doing a "less" or "vi" implementation is 90% of doing screen. You
have a text buffer that displays on the screen. You write at the
current cursor position to update that text buffer.
That's pretty much what screen and less both do. I'd like to get them
to share infrastructure to do it, which means writing some kind of
lib/buffer.c.
That's what I'm working on, common infrastructure for such purposes.
--
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/20120621/a6e63ef0/attachment-0001.pgp>
David Seikel
2012-06-25 21:04:54 UTC
Permalink
I've gone through the features of those editors we have mentioned in
this thread, and compiled a list of most of those features. Separated
them into "basic infrastructure" "basic editing", "advanced editing",
and "code editing". It's a long list, even if you leave out advanced
and code editing. On the other hand, a lot would just be options to
common functions, or is already covered by the full screen handling
library.

So now to come up with a design for the generic editing library that
can cater for most of that. And leaves scope for more advanced stuff
to be bolted on.

One thing I'm wondering about. A lot of these editors where written
for the days of really slow serial connections. I see three use cases
for this - direct console / xterm access (including on your smart
phone), ssh over the Internet or local network, and high speed serial
connection to an embedded computer on your desk (or emulator). I don't
know if serial over modem access would be common. So there's a fair
amount of "cater to really slow connections" stuff which I don't
think we need. Also a fair bit of "cater for dumb terminal" which the
basic "anything modern can understand ANSI escapes" design principle
leaves out.

Not worrying about these things means we don't complicate the code with
lots of optimizations for how much we output, or using fancy ANSI
escapes for scrolling existing text and such. I think we can get away
with that.
--
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/20120626/49c785a8/attachment.pgp>
David Seikel
2012-06-28 21:31:17 UTC
Permalink
I got a very simple editor working now. It can load a file, navigate
within it, move the cursor, insert characters, delete them, and save the
file. The keys are currently bound to commands via an array, but I plan
on making a "bind key" command to.

For microemacs, wordstar help window, and later for midnight commander,
there's "split the screen into boxes" stuff.

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.

There's a few bugs and missing features to iron out, but I think I'll
show it to you when I got those sorted.
--
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/20120629/9b385476/attachment.pgp>
Dennis McCunney
2012-07-18 03:58:40 UTC
Permalink
On 06/28/2012 05:31 PM, David Seikel wrote:

Coming late to this party, but..
Post by David Seikel
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

Something else to look at might be Albrecht Kliene's e3 editor. e3 is
open source and cross platform, with X86 versions available for Linux,
FreeBSD, NetBSD, OpenBSD, Win9x, QNX, Atheos, BeOS(TM), DOS and ELKS,
and a version for ARM as well. Significantly, they're written in NASM
Assembler. There is also a generic C version for other platforms.

e3 emulates a subset of the emacs, nedit, pico, vi, and WordStar command
sets. Which emulation it uses is determined by the name it is called
by, and the usual installation practice is to hard link or symlink it to
the desired names. The 64 bit Linux executable is a whopping 17K in
size here.

(Under DOS/Windows, there is a 4K stub and a 20K overlay. On a 16 bit
system it's possible to use just the 4K stub, which has WS keybindings
and a 64K file size limit.)

e3 is at https://sites.google.com/site/e3editor/

Key bindings in vi mode:

<ESC> enter cmd mode
h,j,k,l,+,-,<Ret>,<SPC> move by chars&lines
^B,^F,^D,^U move by [half]page
$,0,^,w,b,e,H,L,M,z. move in line/screen
/,?,G srch fwd/bwd, go EOF
ma,'a set/go marker a
x,X,<Del>,dw,D dele chr,word,EOL
S,C,dd,d'a,yy,y'a subst,change,dele,yank
p,P paste
A,a,I,i,<Ins>,O,o enter ins.mode
R,r enter ovw.mode,ovw.chr
J join lines
ZZ,^Z, u save&quit,suspend, undo!
;,# E3 SPECIAL: set edit mode,calculate
:w,:wq,:x,:q,:q!,:e ex mode:save,quit,save_as,edit other
:0,:$,:<line#> ex mode:go BOF,EOF,line
:h ex mode:help
:<other cmd> pipe buffer thru 'sed'


Key bindings in WS mode:

Files: ^KR Insert ^KS Save ^KX Save&Exit ^KQ Abort&Exit
^KD Save&Load ^KP Pipe buffer thru 'sed'

Blocks: ^KB Start ^KK End ^KC Copy ^KY Del
^KV Move ^KW Write

Search: ^QF Find ^L Repeat ^QA Srch&Repl

Move: ^E Up ^X Down ^S Left ^D Right
^R Page Up ^C Page Dn ^W Scroll Up ^Z Scroll Dn

Quick- ^QE Wnd Top ^QX Wnd Bott ^QS Home ^QD End
-Move: ^QR BOF ^QC EOF ^QB Blk Begin ^QK Blk End
^F Next Word ^A Prev Word ^QI Line# ^QV Last Find

Delete: ^T Word ^Y Line ^H Left ^G Chr
^QY Line End ^QDel,^QH Line Beg

Other: ^KM Set mode ^KN Numerics ^KZ Suspend ^U Undo



Key bindings in EMACS mode:

Files: ^X^C Exit ^XI Insert ^X^S Save ^X^F Load New
^X^W Write new ^X^H Help ^X^P Pipe buffer thru 'sed'

Move: ^P Up ^N Down ^B Left ^F Right
altV Pg up ^V Pg down altB Left word altF Right word
^A Home ^E End alt< BOF alt> EOF
altG Go line# ^L Center Pos

Search: ^S Find fwd ^R Find bwd alt% Search&Replace like WS

Buffer: altW Copy ^Y Yank ^<SPC> Mark ^X^X Xchg Mark/Pt

Delete: ^K Line ^W Region ^H Left Chr ^D This Chr

Other: ^O Open line ^I Ins Tab ^Q Quoted Ins
^M NL ^J NL+indent altX Set edit mode
^X^N Calculate ^Z Suspend ^_ Undo


Key bindings in PICO mode:

Files: ^XN ExitNoSave ^XY Exit+Save ^XL Save+Load New File
^O Save ^S Save as ^R Read

Move: ^P Up ^N Down ^B Left ^F Right
^Y Page up ^V Page down ^QN Next word ^QP Previous word
^A Home ^E End ^QS Start ^QE EOF
^QT Top screen ^QB Bottom scr ^QL Line # ^QF last Find

Search: ^W Where is ^T Search&Repl ^JT Repeat Search & Replace

Delete: ^H Left char ^D This char ^K Kill line/region
^JW Word ^JL Line end ^JH Line begin

Other: ^U Unkill ^G Help ^^,^L,^<SPC> Mark region
^QM Set Edit Mode ^JP Pipe buffer thru 'sed'
^QC Calculate ^Z Suspend ^QU Undo


Key bindings in NEDIT mode:

Files: ^QN Exit_NoSave ^QY Exit&Save ^QL Save&Load new
^S Save ^W WriteTo=SaveAs
Move: ^L Line#
^F Find ^R Search&Replace (like WS)
^G Go repeat last ^F,^R

Select: ^<SPACE> begin&extend by cursor keys (like Emacs)
^A All buffer
^X Cut ^C Copy ^V Paste

Other: ^E Set edit mode
^K Calculate
altH Help ^Z Suspend ^U Undo
David Seikel
2012-07-18 07:57:08 UTC
Permalink
On Tue, 17 Jul 2012 23:58:40 -0400 Dennis McCunney
Post by Dennis McCunney
Coming late to this party, but..
Post by David Seikel
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
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.
Post by Dennis McCunney
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.pgp>
Dennis McCunney
2012-07-20 04:42:44 UTC
Permalink
Post by David Seikel
On Tue, 17 Jul 2012 23:58:40 -0400 Dennis McCunney
Post by Dennis McCunney
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...)
Post by David Seikel
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.
Post by David Seikel
Post by Dennis McCunney
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.
Post by David Seikel
I've been side tracked with a contract, so not spent much time on it
this month.
Work that pays the bills comes first.
Post by David Seikel
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.
Post by David Seikel
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..
Post by David Seikel
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.
Post by David Seikel
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.
Dennis McCunney
2012-07-20 04:42:44 UTC
Permalink
Post by David Seikel
On Tue, 17 Jul 2012 23:58:40 -0400 Dennis McCunney
Post by Dennis McCunney
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...)
Post by David Seikel
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.
Post by David Seikel
Post by Dennis McCunney
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.
Post by David Seikel
I've been side tracked with a contract, so not spent much time on it
this month.
Work that pays the bills comes first.
Post by David Seikel
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.
Post by David Seikel
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..
Post by David Seikel
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.
Post by David Seikel
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.
David Seikel
2012-07-18 07:57:08 UTC
Permalink
On Tue, 17 Jul 2012 23:58:40 -0400 Dennis McCunney
Post by Dennis McCunney
Coming late to this party, but..
Post by David Seikel
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
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.
Post by Dennis McCunney
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.pgp>
Dennis McCunney
2012-07-18 03:58:40 UTC
Permalink
On 06/28/2012 05:31 PM, David Seikel wrote:

Coming late to this party, but..
Post by David Seikel
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

Something else to look at might be Albrecht Kliene's e3 editor. e3 is
open source and cross platform, with X86 versions available for Linux,
FreeBSD, NetBSD, OpenBSD, Win9x, QNX, Atheos, BeOS(TM), DOS and ELKS,
and a version for ARM as well. Significantly, they're written in NASM
Assembler. There is also a generic C version for other platforms.

e3 emulates a subset of the emacs, nedit, pico, vi, and WordStar command
sets. Which emulation it uses is determined by the name it is called
by, and the usual installation practice is to hard link or symlink it to
the desired names. The 64 bit Linux executable is a whopping 17K in
size here.

(Under DOS/Windows, there is a 4K stub and a 20K overlay. On a 16 bit
system it's possible to use just the 4K stub, which has WS keybindings
and a 64K file size limit.)

e3 is at https://sites.google.com/site/e3editor/

Key bindings in vi mode:

<ESC> enter cmd mode
h,j,k,l,+,-,<Ret>,<SPC> move by chars&lines
^B,^F,^D,^U move by [half]page
$,0,^,w,b,e,H,L,M,z. move in line/screen
/,?,G srch fwd/bwd, go EOF
ma,'a set/go marker a
x,X,<Del>,dw,D dele chr,word,EOL
S,C,dd,d'a,yy,y'a subst,change,dele,yank
p,P paste
A,a,I,i,<Ins>,O,o enter ins.mode
R,r enter ovw.mode,ovw.chr
J join lines
ZZ,^Z, u save&quit,suspend, undo!
;,# E3 SPECIAL: set edit mode,calculate
:w,:wq,:x,:q,:q!,:e ex mode:save,quit,save_as,edit other
:0,:$,:<line#> ex mode:go BOF,EOF,line
:h ex mode:help
:<other cmd> pipe buffer thru 'sed'


Key bindings in WS mode:

Files: ^KR Insert ^KS Save ^KX Save&Exit ^KQ Abort&Exit
^KD Save&Load ^KP Pipe buffer thru 'sed'

Blocks: ^KB Start ^KK End ^KC Copy ^KY Del
^KV Move ^KW Write

Search: ^QF Find ^L Repeat ^QA Srch&Repl

Move: ^E Up ^X Down ^S Left ^D Right
^R Page Up ^C Page Dn ^W Scroll Up ^Z Scroll Dn

Quick- ^QE Wnd Top ^QX Wnd Bott ^QS Home ^QD End
-Move: ^QR BOF ^QC EOF ^QB Blk Begin ^QK Blk End
^F Next Word ^A Prev Word ^QI Line# ^QV Last Find

Delete: ^T Word ^Y Line ^H Left ^G Chr
^QY Line End ^QDel,^QH Line Beg

Other: ^KM Set mode ^KN Numerics ^KZ Suspend ^U Undo



Key bindings in EMACS mode:

Files: ^X^C Exit ^XI Insert ^X^S Save ^X^F Load New
^X^W Write new ^X^H Help ^X^P Pipe buffer thru 'sed'

Move: ^P Up ^N Down ^B Left ^F Right
altV Pg up ^V Pg down altB Left word altF Right word
^A Home ^E End alt< BOF alt> EOF
altG Go line# ^L Center Pos

Search: ^S Find fwd ^R Find bwd alt% Search&Replace like WS

Buffer: altW Copy ^Y Yank ^<SPC> Mark ^X^X Xchg Mark/Pt

Delete: ^K Line ^W Region ^H Left Chr ^D This Chr

Other: ^O Open line ^I Ins Tab ^Q Quoted Ins
^M NL ^J NL+indent altX Set edit mode
^X^N Calculate ^Z Suspend ^_ Undo


Key bindings in PICO mode:

Files: ^XN ExitNoSave ^XY Exit+Save ^XL Save+Load New File
^O Save ^S Save as ^R Read

Move: ^P Up ^N Down ^B Left ^F Right
^Y Page up ^V Page down ^QN Next word ^QP Previous word
^A Home ^E End ^QS Start ^QE EOF
^QT Top screen ^QB Bottom scr ^QL Line # ^QF last Find

Search: ^W Where is ^T Search&Repl ^JT Repeat Search & Replace

Delete: ^H Left char ^D This char ^K Kill line/region
^JW Word ^JL Line end ^JH Line begin

Other: ^U Unkill ^G Help ^^,^L,^<SPC> Mark region
^QM Set Edit Mode ^JP Pipe buffer thru 'sed'
^QC Calculate ^Z Suspend ^QU Undo


Key bindings in NEDIT mode:

Files: ^QN Exit_NoSave ^QY Exit&Save ^QL Save&Load new
^S Save ^W WriteTo=SaveAs
Move: ^L Line#
^F Find ^R Search&Replace (like WS)
^G Go repeat last ^F,^R

Select: ^<SPACE> begin&extend by cursor keys (like Emacs)
^A All buffer
^X Cut ^C Copy ^V Paste

Other: ^E Set edit mode
^K Calculate
altH Help ^Z Suspend ^U Undo
Rob Landley
2012-06-30 19:52:56 UTC
Permalink
Post by David Seikel
One thing I'm wondering about. A lot of these editors where written
for the days of really slow serial connections.
I think we can assume that a serial connection will be 115k or so.
Post by David Seikel
Not worrying about these things means we don't complicate the code with
lots of optimizations for how much we output, or using fancy ANSI
escapes for scrolling existing text and such. I think we can get away
with that.
There are times scrolling existing text would be nice. Keep in mind
that's half of what "less" does".

Basically, "vi" and "less" are my two initial use cases for this. Emacs
ain't in posix. If it's a really trivial additional binding (basically a
.config file), fine. But I personally will never use it, and no standard
requires it.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-30 20:42:13 UTC
Permalink
Post by Rob Landley
Post by David Seikel
One thing I'm wondering about. A lot of these editors where written
for the days of really slow serial connections.
I think we can assume that a serial connection will be 115k or so.
Works for me. B-)
Post by Rob Landley
Post by David Seikel
Not worrying about these things means we don't complicate the code
with lots of optimizations for how much we output, or using fancy
ANSI escapes for scrolling existing text and such. I think we can
get away with that.
There are times scrolling existing text would be nice. Keep in mind
that's half of what "less" does".
I did not mean the functionality of scrolling text, I meant using escape
sequences for scrolling text. It already scrolls text, it just does a
screen redraw instead of trying to figure out which bit of the screen
it can scroll with escape sequences first before drawing the rest.

This is one of the reasons I was checking if we ever have to deal with
slow connections. Fast ones can handle complete redraws for paging
and scrolling, and that keeps the code simple. Optimized redraws can
come later if we feel it's needed.
Post by Rob Landley
Basically, "vi" and "less" are my two initial use cases for this.
Emacs ain't in posix. If it's a really trivial additional binding
(basically a .config file), fine. But I personally will never use it,
and no standard requires it.
I would not use vi or emacs, so it's gonna do what ever I like as an
editor as well as those two. Once it can deal with the horrid vi
command and insert modes, which are no longer needed, just ancient
historic artefacts, then a simple emacs editor is just a matter of
different key bindings.

It's gotta scratch my itches as well, or it's not worth my time. And
people will scream if I leave out emacs. shrugs
--
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/20120701/4f20285e/attachment.pgp>
Rob Landley
2012-06-30 23:00:08 UTC
Permalink
Post by David Seikel
Post by Rob Landley
There are times scrolling existing text would be nice. Keep in mind
that's half of what "less" does".
I did not mean the functionality of scrolling text, I meant using escape
sequences for scrolling text. It already scrolls text, it just does a
screen redraw instead of trying to figure out which bit of the screen
it can scroll with escape sequences first before drawing the rest.
I'm currently debugging a horrible fedora-only build issue where running
a shell script snippet via /bin/bash inserts stuff at the start of the
$PATH for some reason. (Maybe /etc/profile? Fedora is horribly
overcomplicated.) This, like everything else, breaks cross compiling.

I'm running it under kvm, where screen writes are extremely expensive
due to the 2D sdl graphics card emulation.

Scrolling the screen is a bitblt, but redrawing the screen is slow
enough that I can see the characters redraw in the xterm.

This means cursoring down in another less implementation will be
essentially instantaneous in otherimplementations, and will take a
couple seconds per cursor-down key in the one you're proposing.

Saving redrawing half a line is useless, but redrawing the entire screen
unnecessarily rather than moving the lines of text up/down is still
pretty noticeable.
Post by David Seikel
This is one of the reasons I was checking if we ever have to deal with
slow connections. Fast ones can handle complete redraws for paging
and scrolling, and that keeps the code simple. Optimized redraws can
come later if we feel it's needed.
Optimizing redraws is more complicated than it's worth, but _avoiding_
redraws is a pretty common case that can be expensive in certain
contexts. (Scrolling up or down, happens a lot.)
Post by David Seikel
Post by Rob Landley
Basically, "vi" and "less" are my two initial use cases for this.
Emacs ain't in posix. If it's a really trivial additional binding
(basically a .config file), fine. But I personally will never use it,
and no standard requires it.
I would not use vi or emacs, so it's gonna do what ever I like as an
editor as well as those two. Once it can deal with the horrid vi
command and insert modes, which are no longer needed, just ancient
historic artefacts, then a simple emacs editor is just a matter of
different key bindings.
If you say so...
Post by David Seikel
It's gotta scratch my itches as well, or it's not worth my time.
Oh sure.
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-30 23:10:27 UTC
Permalink
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
There are times scrolling existing text would be nice. Keep in mind
that's half of what "less" does".
I did not mean the functionality of scrolling text, I meant using
escape sequences for scrolling text. It already scrolls text, it
just does a screen redraw instead of trying to figure out which bit
of the screen it can scroll with escape sequences first before
drawing the rest.
I'm currently debugging a horrible fedora-only build issue where
running a shell script snippet via /bin/bash inserts stuff at the
start of the $PATH for some reason. (Maybe /etc/profile? Fedora is
horribly overcomplicated.) This, like everything else, breaks cross
compiling.
I'm running it under kvm, where screen writes are extremely expensive
due to the 2D sdl graphics card emulation.
Scrolling the screen is a bitblt, but redrawing the screen is slow
enough that I can see the characters redraw in the xterm.
This means cursoring down in another less implementation will be
essentially instantaneous in otherimplementations, and will take a
couple seconds per cursor-down key in the one you're proposing.
Saving redrawing half a line is useless, but redrawing the entire
screen unnecessarily rather than moving the lines of text up/down is
still pretty noticeable.
Post by David Seikel
This is one of the reasons I was checking if we ever have to deal
with slow connections. Fast ones can handle complete redraws for
paging and scrolling, and that keeps the code simple. Optimized
redraws can come later if we feel it's needed.
Optimizing redraws is more complicated than it's worth, but _avoiding_
redraws is a pretty common case that can be expensive in certain
contexts. (Scrolling up or down, happens a lot.)
It is on my TODO to see what optimizations I can do simply. I want to
get it correct first though.
Post by Rob Landley
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...
I don't care about emacs or vi, but vi is apparently mandatory, though
hideous, and basic emacs should be trivial, with a full emacs being
more hideous. Simple emacs, yep easy to do, could almost do it now.
Microemacs subset, most likely I'll do it. Full emacs, not gonna
happen.
--
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/20120701/53ce6ac5/attachment.pgp>
David Seikel
2012-06-30 23:14:13 UTC
Permalink
On Sun, 1 Jul 2012 09:10:27 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
There are times scrolling existing text would be nice. Keep in
mind that's half of what "less" does".
I did not mean the functionality of scrolling text, I meant using
escape sequences for scrolling text. It already scrolls text, it
just does a screen redraw instead of trying to figure out which
bit of the screen it can scroll with escape sequences first before
drawing the rest.
I'm currently debugging a horrible fedora-only build issue where
running a shell script snippet via /bin/bash inserts stuff at the
start of the $PATH for some reason. (Maybe /etc/profile? Fedora is
horribly overcomplicated.) This, like everything else, breaks cross
compiling.
I'm running it under kvm, where screen writes are extremely
expensive due to the 2D sdl graphics card emulation.
Scrolling the screen is a bitblt, but redrawing the screen is slow
enough that I can see the characters redraw in the xterm.
This means cursoring down in another less implementation will be
essentially instantaneous in otherimplementations, and will take a
couple seconds per cursor-down key in the one you're proposing.
Saving redrawing half a line is useless, but redrawing the entire
screen unnecessarily rather than moving the lines of text up/down is
still pretty noticeable.
Post by David Seikel
This is one of the reasons I was checking if we ever have to deal
with slow connections. Fast ones can handle complete redraws for
paging and scrolling, and that keeps the code simple. Optimized
redraws can come later if we feel it's needed.
Optimizing redraws is more complicated than it's worth, but
_avoiding_ redraws is a pretty common case that can be expensive in
certain contexts. (Scrolling up or down, happens a lot.)
It is on my TODO to see what optimizations I can do simply. I want to
get it correct first though.
Post by Rob Landley
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...
I don't care about emacs or vi, but vi is apparently mandatory, though
hideous, and basic emacs should be trivial, with a full emacs being
more hideous. Simple emacs, yep easy to do, could almost do it now.
Microemacs subset, most likely I'll do it. Full emacs, not gonna
happen.
BTW, emacs dired I'll do, coz it just looks like a bit of midnight
commander which I want to do as well. So do one, done them both.
--
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/20120701/2c7240f2/attachment.pgp>
Rob Landley
2012-06-30 23:36:55 UTC
Permalink
Post by David Seikel
Post by Rob Landley
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...
I don't care about emacs or vi, but vi is apparently mandatory, though
hideous,
It's in posix, and is the only text editor that is unless you count
"ed". That means I'd need a reason _not_ to do it. (I might eventually
wind up doing ed, since sed is halfway there...)
Post by David Seikel
and basic emacs should be trivial, with a full emacs being
more hideous. Simple emacs, yep easy to do, could almost do it now.
Microemacs subset, most likely I'll do it. Full emacs, not gonna
happen.
Microemacs is what Linus uses, apparently. That probably makes it a
reasonable target:

http://kernel.org/pub/linux/kernel/uemacs/

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-07-01 00:01:02 UTC
Permalink
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...
I don't care about emacs or vi, but vi is apparently mandatory,
though hideous,
It's in posix, and is the only text editor that is unless you count
"ed". That means I'd need a reason _not_ to do it. (I might eventually
wind up doing ed, since sed is halfway there...)
Actually, vi includes an ex mode, and ex includes an ed mode. Think ed
might just come for free with vi. Oh yeah, my infrastructure is aiming
at sed to. All fairly similar at the basic level anyway.
Post by Rob Landley
Post by David Seikel
and basic emacs should be trivial, with a full emacs being
more hideous. Simple emacs, yep easy to do, could almost do it now.
Microemacs subset, most likely I'll do it. Full emacs, not gonna
happen.
Microemacs is what Linus uses, apparently. That probably makes it a
http://kernel.org/pub/linux/kernel/uemacs/
There's also "MicroGnuEmacs", which changed it's name to mg coz Richard
"GNU/Linux dammit" Stallman apparently objected.

/me snickers.
--
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/20120701/6f35e37c/attachment.pgp>
Rob Landley
2012-07-01 01:02:55 UTC
Permalink
Post by David Seikel
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...
I don't care about emacs or vi, but vi is apparently mandatory,
though hideous,
It's in posix, and is the only text editor that is unless you count
"ed". That means I'd need a reason _not_ to do it. (I might eventually
wind up doing ed, since sed is halfway there...)
Actually, vi includes an ex mode, and ex includes an ed mode. Think ed
might just come for free with vi.
Busybox has gone more than a decade without having that, and nobody's
ever complained that I noticed. But they do have a separate ed
implementation because explicitly it's in posix.

Me, I use the "v/y/p" commands that are missing from busybox vi because
it's the cut and paste functionality. (I only know a dozen or so vim
commands. before that it was Joe, but joe and ctrl-s do not combine
portably, and wordstar bindings wanted ctrl-s...)
Post by David Seikel
Oh yeah, my infrastructure is aiming
at sed to. All fairly similar at the basic level anyway.
What does interactive line editing have to do with sed, a line-by-line
regex stream processor I previously wrote the busybox implementation of?

Just wondering.
Post by David Seikel
Post by Rob Landley
Post by David Seikel
and basic emacs should be trivial, with a full emacs being
more hideous. Simple emacs, yep easy to do, could almost do it now.
Microemacs subset, most likely I'll do it. Full emacs, not gonna
happen.
Microemacs is what Linus uses, apparently. That probably makes it a
http://kernel.org/pub/linux/kernel/uemacs/
There's also "MicroGnuEmacs", which changed it's name to mg coz Richard
"GNU/Linux dammit" Stallman apparently objected.
"A bad thing exists".

Don't care?

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-07-01 06:13:43 UTC
Permalink
Post by Rob Landley
Post by David Seikel
Oh yeah, my infrastructure is aiming
at sed to. All fairly similar at the basic level anyway.
What does interactive line editing have to do with sed, a line-by-line
regex stream processor I previously wrote the busybox implementation of?
Just wondering.
I'm writing generic text editing functions. They don't care if it's a
full screen editor, line editor, or stream editor driving them, they do
text editing. Ed, ex, vi, and sed all have "select lines with a regex,
do some editing function on them". Lots of other things they have in
common to. Including the ability to run "scripts" of their own
commands over text.

I read through the relevant standards and compiled lists of what they
do that is common, and what they do that is not so common. Did the
same with the documentation for joe, microemacs, nano, and midnight
commanders editor. Also included more, less, and readline.

Not gonna be all things for all people, but there's enough common stuff
for generalization to work out for us.

The toybox sed (as of 0.3.0) is a stub with "hello world" in it. None
of the others have been written yet. I think my stuff could be useful
to them all, and toysh as well (readline type stuff).
--
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/20120701/7ee44168/attachment.pgp>
Rob Landley
2012-07-01 16:58:05 UTC
Permalink
Post by David Seikel
Post by Rob Landley
Post by David Seikel
Oh yeah, my infrastructure is aiming
at sed to. All fairly similar at the basic level anyway.
What does interactive line editing have to do with sed, a line-by-line
regex stream processor I previously wrote the busybox implementation of?
Just wondering.
I'm writing generic text editing functions. They don't care if it's a
full screen editor, line editor, or stream editor driving them, they do
text editing. Ed, ex, vi, and sed all have "select lines with a regex,
do some editing function on them". Lots of other things they have in
common to. Including the ability to run "scripts" of their own
commands over text.
So you're writing command line history infrastructure for shells.

And you're writing the pluming behind "more" and "less".

And you're writing the plumbing behind sed.

And you're writing vi, but it's also going to do emacs and joe and ex
and ed.

And you're writing scripting infrastructure.

And you're writing midnight commander.

And it's all one big thing which you're going to deliver all at once in
a giant patchbomb.

Good luck?
Post by David Seikel
I read through the relevant standards and compiled lists of what they
do that is common, and what they do that is not so common. Did the
same with the documentation for joe, microemacs, nano, and midnight
commanders editor. Also included more, less, and readline.
Not gonna be all things for all people, but there's enough common stuff
for generalization to work out for us.
I'm adding a chunk at a time and checking it in. I have somewhat
elaborate plans, but they change as I go along.

Your design of course takes into account none of _my_ elaborate plans,
but since I haven't checked them in yet they're fair game.

But I'm a bit nervous about impedence matching a giant code drop.
Post by David Seikel
The toybox sed (as of 0.3.0) is a stub with "hello world" in it.
What I've checked in is, yes.
Post by David Seikel
None
of the others have been written yet. I think my stuff could be useful
to them all, and toysh as well (readline type stuff).
I have yet to see, let alone review, a line of code from this.

I still have pending todo items from Elie and Georgi, which I'd be
working on if I hadn't gotten distracted into working on od.

Speaking of od, more notes on that:

-j has to support non-seekable input, such as pipes (cat | od -j 123).

What does -j do when you have multiple files? Ah, _concatenated_ input
files. So xlseek() is wrong on multiple counts: because if seek fails
you need to fall back to read(), and because you may skip more than one
entire input file. And this can't be "skip input blocks" because the
skip isn't required to be block aligned.

If the output of od gets dropped (-EPIPE), what happens? Should it retry
short writes, which implies xprintf() should do an xmprintf() into a
malloc buffer and then do a writeall() on it, although I really am
trying to get automatic retry in there with sigaction(SA_RESTART) but
that doesn't protect you against _short_ writes, just spurious zero
length writes, and yes you can get that with "cat | cat" when you kill
-STOP and then kill -CONT them...

Really? -A defaults to _octal_? The spec doesn't say (explicitly says
the default is undefined) but the gnu/dammit one does and busybox picked
it up from that, so...

Currently trying to figure out when I should I increment the error exit
return code. (I.E. what corner cases count as an error...)


Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-07-01 17:14:15 UTC
Permalink
Post by Rob Landley
I'm adding a chunk at a time and checking it in. I have somewhat
elaborate plans, but they change as I go along.
Your design of course takes into account none of _my_ elaborate plans,
but since I haven't checked them in yet they're fair game.
But I'm a bit nervous about impedence matching a giant code drop.
My design is changing as I go along as well. I'm trying to shake out a
proper design for all of this with some real world sanity checking.

The first code drop will just be a single toy, which is just a
prototype. A work in progress for commenting on. Later it should
probably be split up into a few library bits that can be left out of
the build if not needed.
--
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/20120702/4e4fef02/attachment.pgp>
Rob Landley
2012-07-02 03:20:24 UTC
Permalink
Post by David Seikel
Post by Rob Landley
I'm adding a chunk at a time and checking it in. I have somewhat
elaborate plans, but they change as I go along.
Your design of course takes into account none of _my_ elaborate plans,
but since I haven't checked them in yet they're fair game.
But I'm a bit nervous about impedence matching a giant code drop.
My design is changing as I go along as well. I'm trying to shake out a
proper design for all of this with some real world sanity checking.
Aren't we all. :)
Post by David Seikel
The first code drop will just be a single toy, which is just a
prototype. A work in progress for commenting on. Later it should
probably be split up into a few library bits that can be left out of
the build if not needed.
Yay trail of breadcrumbs. I look forward to it.

Honestly one of the things that _should_ be high profile is toysh. That
needs (not an exhausting list, just big low hanging fruit off the top of
my head):

1) Command history.
2) Environment variable support.
3) Pipeline and redirect support.
4) Control flow (if/while/for/functions)
5) Job control.

What it _really_ needs is three months of my time where I sit down and
work on _nothing_ else, but short of doing a kickstarter or something I
don't see how I could afford it these days...

Still, od is at about the 2/3 mark. I'll cut a release once I get that
done, I think.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-09-06 03:02:28 UTC
Permalink
Sending this again, since it seemed to have been silently dropped
somewhere. No bounce, it just never made it to the mailing list. This
time with a link instead of an attached file, in case that was the
problem.
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
I'm adding a chunk at a time and checking it in. I have somewhat
elaborate plans, but they change as I go along.
Your design of course takes into account none of _my_ elaborate
plans, but since I haven't checked them in yet they're fair game.
But I'm a bit nervous about impedence matching a giant code drop.
My design is changing as I go along as well. I'm trying to shake
out a proper design for all of this with some real world sanity
checking.
Aren't we all. :)
Post by David Seikel
The first code drop will just be a single toy, which is just a
prototype. A work in progress for commenting on. Later it should
probably be split up into a few library bits that can be left out of
the build if not needed.
Yay trail of breadcrumbs. I look forward to it.
Here's a code drop, warts and all. I should have done this a month ago,
which is the last time I looked at it. Though the stuff I did a month
ago was mostly adding lots more comments. Keep in mind what I said
above, this is a work in progress, proof of concept, playground,
packaged up as one big toy, to be self contained until the mess is
cleaned up. This "boxes" toy itself will go away, to be replaced by
individual editor / pager toys and library bits. Nothing is set in
stone, lots of mess inside, there's bugs, but at least it shows the
general direction my mind is wandering in. As a bonus, it actually
works, you can edit stuff.

Please don't actually include this in toybox yet. Just look at it and
sneer / giggle, depending on your nature. Drop it into the toys
directory to try it out, it's just one big toy.

If you want to see how it can be used to build specific editors, start
at the end of the source code and work backwards. Reading the lengthy
comments at the beginning would also be useful.

I've not even looked at it in the last month, just thought it was past
time to show the code. I'll get back to working on it when I can.

I put it on github, simply coz github is where I put all my stuff, and
I suspect my previous emails large attachment was the reason it got
dropped. If and when it's ready for including in toybox, and Rob wants
to include it, then it can be added to the official toybox repo and I
can drop the github version. But since it's on github now, I might as
well keep that up to date, "release often".

https://github.com/onefang/boxes
--
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/20120906/29588c31/attachment.pgp>
Roy Tam
2012-09-06 03:31:43 UTC
Permalink
Post by David Seikel
Sending this again, since it seemed to have been silently dropped
somewhere. No bounce, it just never made it to the mailing list. This
time with a link instead of an attached file, in case that was the
problem.
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
I'm adding a chunk at a time and checking it in. I have somewhat
elaborate plans, but they change as I go along.
Your design of course takes into account none of _my_ elaborate
plans, but since I haven't checked them in yet they're fair game.
But I'm a bit nervous about impedence matching a giant code drop.
My design is changing as I go along as well. I'm trying to shake
out a proper design for all of this with some real world sanity
checking.
Aren't we all. :)
Post by David Seikel
The first code drop will just be a single toy, which is just a
prototype. A work in progress for commenting on. Later it should
probably be split up into a few library bits that can be left out of
the build if not needed.
Yay trail of breadcrumbs. I look forward to it.
Here's a code drop, warts and all. I should have done this a month ago,
which is the last time I looked at it. Though the stuff I did a month
ago was mostly adding lots more comments. Keep in mind what I said
above, this is a work in progress, proof of concept, playground,
packaged up as one big toy, to be self contained until the mess is
cleaned up. This "boxes" toy itself will go away, to be replaced by
individual editor / pager toys and library bits. Nothing is set in
stone, lots of mess inside, there's bugs, but at least it shows the
general direction my mind is wandering in. As a bonus, it actually
works, you can edit stuff.
Please don't actually include this in toybox yet. Just look at it and
sneer / giggle, depending on your nature. Drop it into the toys
directory to try it out, it's just one big toy.
If you want to see how it can be used to build specific editors, start
at the end of the source code and work backwards. Reading the lengthy
comments at the beginning would also be useful.
I've not even looked at it in the last month, just thought it was past
time to show the code. I'll get back to working on it when I can.
I put it on github, simply coz github is where I put all my stuff, and
I suspect my previous emails large attachment was the reason it got
dropped. If and when it's ready for including in toybox, and Rob wants
to include it, then it can be added to the official toybox repo and I
can drop the github version. But since it's on github now, I might as
well keep that up to date, "release often".
https://github.com/onefang/boxes
I did a brief trial and I hit segfault.

$ gdb --args ./toybox_unstripped boxes -m less LICENSE
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/roy/toybox/toybox_unstripped...done.
(gdb) r

[press page down for few seconds, then press up arrow for few seconds]

Program received signal SIGSEGV, Segmentation fault.
formatLine (view=0x8069168, input=0x0, output=0x806919c)
at toys/other/boxes.c:843
843 int len = strlen(input), i = 0, o = 0;
(gdb) bt
#0 formatLine (view=0x8069168, input=0x0, output=0x806919c)
at toys/other/boxes.c:843
#1 0x0804f1dd in moveCursorAbsolute (view=0x8069168, cX=0, cY=10, sX=0, sY=0)
at toys/other/boxes.c:951
#2 0x0804f367 in moveCursorRelative (view=0x8069168, cX=0, cY=10, sX=0, sY=0)
at toys/other/boxes.c:1011
#3 0x0804f479 in upLine (view=0x8069168, event=0x0) at toys/other/boxes.c:1442
#4 0x0804fb63 in handleKey (view=0x8069168, i=2, keyName=<optimized out>,
buffer=0xbffffad8 "\033[A") at toys/other/boxes.c:1593
#5 0x0805008d in editLine (view=0x8069168, X=-1, Y=-1, W=-1, H=-1)
at toys/other/boxes.c:1785
#6 0x08050288 in boxes_main () at toys/other/boxes.c:2482
#7 0x0804b262 in toy_exec (argv=0xbffffd58) at main.c:104
#8 0x0804b29d in toybox_main () at main.c:118
#9 0x0804b262 in toy_exec (argv=0xbffffd54) at main.c:104
#10 0x0804b29d in toybox_main () at main.c:118
#11 0x0804affa in main (argc=5, argv=0xbffffd54) at main.c:159
David Seikel
2012-09-06 03:49:38 UTC
Permalink
Post by Roy Tam
Post by David Seikel
Sending this again, since it seemed to have been silently dropped
somewhere. No bounce, it just never made it to the mailing list.
This time with a link instead of an attached file, in case that was
the problem.
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
I'm adding a chunk at a time and checking it in. I have somewhat
elaborate plans, but they change as I go along.
Your design of course takes into account none of _my_ elaborate
plans, but since I haven't checked them in yet they're fair game.
But I'm a bit nervous about impedence matching a giant code drop.
My design is changing as I go along as well. I'm trying to shake
out a proper design for all of this with some real world sanity
checking.
Aren't we all. :)
Post by David Seikel
The first code drop will just be a single toy, which is just a
prototype. A work in progress for commenting on. Later it
should probably be split up into a few library bits that can be
left out of the build if not needed.
Yay trail of breadcrumbs. I look forward to it.
Here's a code drop, warts and all. I should have done this a month
ago, which is the last time I looked at it. Though the stuff I did
a month ago was mostly adding lots more comments. Keep in mind
what I said above, this is a work in progress, proof of concept,
playground, packaged up as one big toy, to be self contained until
the mess is cleaned up. This "boxes" toy itself will go away, to
be replaced by individual editor / pager toys and library bits.
Nothing is set in stone, lots of mess inside, there's bugs, but at
least it shows the general direction my mind is wandering in. As a
bonus, it actually works, you can edit stuff.
Please don't actually include this in toybox yet. Just look at it
and sneer / giggle, depending on your nature. Drop it into the toys
directory to try it out, it's just one big toy.
If you want to see how it can be used to build specific editors,
start at the end of the source code and work backwards. Reading
the lengthy comments at the beginning would also be useful.
I've not even looked at it in the last month, just thought it was
past time to show the code. I'll get back to working on it when I
can.
I put it on github, simply coz github is where I put all my stuff,
and I suspect my previous emails large attachment was the reason it
got dropped. If and when it's ready for including in toybox, and
Rob wants to include it, then it can be added to the official
toybox repo and I can drop the github version. But since it's on
github now, I might as well keep that up to date, "release often".
https://github.com/onefang/boxes
I did a brief trial and I hit segfault.
$ gdb --args ./toybox_unstripped boxes -m less LICENSE
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html> This is free software: you are
free to change and redistribute it. There is NO WARRANTY, to the
extent permitted by law. Type "show copying" and "show warranty" for
details. This GDB was configured as "i486-linux-gnu".
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/roy/toybox/toybox_unstripped...done.
(gdb) r
[press page down for few seconds, then press up arrow for few seconds]
Program received signal SIGSEGV, Segmentation fault.
formatLine (view=0x8069168, input=0x0, output=0x806919c)
at toys/other/boxes.c:843
843 int len = strlen(input), i = 0, o = 0;
(gdb) bt
#0 formatLine (view=0x8069168, input=0x0, output=0x806919c)
at toys/other/boxes.c:843
#1 0x0804f1dd in moveCursorAbsolute (view=0x8069168, cX=0, cY=10,
sX=0, sY=0) at toys/other/boxes.c:951
#2 0x0804f367 in moveCursorRelative (view=0x8069168, cX=0, cY=10,
sX=0, sY=0) at toys/other/boxes.c:1011
#3 0x0804f479 in upLine (view=0x8069168, event=0x0) at
toys/other/boxes.c:1442 #4 0x0804fb63 in handleKey (view=0x8069168,
i=2, keyName=<optimized out>, buffer=0xbffffad8 "\033[A") at
toys/other/boxes.c:1593 #5 0x0805008d in editLine (view=0x8069168,
X=-1, Y=-1, W=-1, H=-1) at toys/other/boxes.c:1785
#6 0x08050288 in boxes_main () at toys/other/boxes.c:2482
#7 0x0804b262 in toy_exec (argv=0xbffffd58) at main.c:104
#8 0x0804b29d in toybox_main () at main.c:118
#9 0x0804b262 in toy_exec (argv=0xbffffd54) at main.c:104
#10 0x0804b29d in toybox_main () at main.c:118
#11 0x0804affa in main (argc=5, argv=0xbffffd54) at main.c:159
No segfault here when I try that, nor with different files. As I said,
it has bugs. I have seen other cases before when NULL lines are passed
around near that code. Guess I've not got them all. Might help to
mention what terminal proggy you are using, it's size in characters,
toybox version, OS, etc. Something is different between you and me.

The point of this code drop is a heads up on the basic design, not to
pick out every little bug. There's lots of them, we will be at that
forever. lol
--
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/20120906/513c558d/attachment.pgp>
Roy Tam
2012-09-06 03:56:17 UTC
Permalink
Post by David Seikel
Post by Roy Tam
Program received signal SIGSEGV, Segmentation fault.
formatLine (view=0x8069168, input=0x0, output=0x806919c)
at toys/other/boxes.c:843
843 int len = strlen(input), i = 0, o = 0;
(gdb) bt
#0 formatLine (view=0x8069168, input=0x0, output=0x806919c)
at toys/other/boxes.c:843
#1 0x0804f1dd in moveCursorAbsolute (view=0x8069168, cX=0, cY=10,
sX=0, sY=0) at toys/other/boxes.c:951
#2 0x0804f367 in moveCursorRelative (view=0x8069168, cX=0, cY=10,
sX=0, sY=0) at toys/other/boxes.c:1011
#3 0x0804f479 in upLine (view=0x8069168, event=0x0) at
toys/other/boxes.c:1442 #4 0x0804fb63 in handleKey (view=0x8069168,
i=2, keyName=<optimized out>, buffer=0xbffffad8 "\033[A") at
toys/other/boxes.c:1593 #5 0x0805008d in editLine (view=0x8069168,
X=-1, Y=-1, W=-1, H=-1) at toys/other/boxes.c:1785
#6 0x08050288 in boxes_main () at toys/other/boxes.c:2482
#7 0x0804b262 in toy_exec (argv=0xbffffd58) at main.c:104
#8 0x0804b29d in toybox_main () at main.c:118
#9 0x0804b262 in toy_exec (argv=0xbffffd54) at main.c:104
#10 0x0804b29d in toybox_main () at main.c:118
#11 0x0804affa in main (argc=5, argv=0xbffffd54) at main.c:159
No segfault here when I try that, nor with different files. As I said,
it has bugs. I have seen other cases before when NULL lines are passed
around near that code. Guess I've not got them all. Might help to
mention what terminal proggy you are using, it's size in characters,
toybox version, OS, etc. Something is different between you and me.
Terminal Program: PuTTY
Windows size: 80 * 25 chars
Toybox version: hg head
OS: Linux 3.2 (Debian wheezy)
File: Toybox LICENSE file
Post by David Seikel
The point of this code drop is a heads up on the basic design, not to
pick out every little bug. There's lots of them, we will be at that
forever. lol
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
_______________________________________________
Toybox mailing list
Toybox at lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Rob Landley
2012-07-02 03:20:24 UTC
Permalink
Post by David Seikel
Post by Rob Landley
I'm adding a chunk at a time and checking it in. I have somewhat
elaborate plans, but they change as I go along.
Your design of course takes into account none of _my_ elaborate plans,
but since I haven't checked them in yet they're fair game.
But I'm a bit nervous about impedence matching a giant code drop.
My design is changing as I go along as well. I'm trying to shake out a
proper design for all of this with some real world sanity checking.
Aren't we all. :)
Post by David Seikel
The first code drop will just be a single toy, which is just a
prototype. A work in progress for commenting on. Later it should
probably be split up into a few library bits that can be left out of
the build if not needed.
Yay trail of breadcrumbs. I look forward to it.

Honestly one of the things that _should_ be high profile is toysh. That
needs (not an exhausting list, just big low hanging fruit off the top of
my head):

1) Command history.
2) Environment variable support.
3) Pipeline and redirect support.
4) Control flow (if/while/for/functions)
5) Job control.

What it _really_ needs is three months of my time where I sit down and
work on _nothing_ else, but short of doing a kickstarter or something I
don't see how I could afford it these days...

Still, od is at about the 2/3 mark. I'll cut a release once I get that
done, I think.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-07-01 17:14:15 UTC
Permalink
Post by Rob Landley
I'm adding a chunk at a time and checking it in. I have somewhat
elaborate plans, but they change as I go along.
Your design of course takes into account none of _my_ elaborate plans,
but since I haven't checked them in yet they're fair game.
But I'm a bit nervous about impedence matching a giant code drop.
My design is changing as I go along as well. I'm trying to shake out a
proper design for all of this with some real world sanity checking.

The first code drop will just be a single toy, which is just a
prototype. A work in progress for commenting on. Later it should
probably be split up into a few library bits that can be left out of
the build if not needed.
--
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/20120702/4e4fef02/attachment-0002.pgp>
Rob Landley
2012-07-01 16:58:05 UTC
Permalink
Post by David Seikel
Post by Rob Landley
Post by David Seikel
Oh yeah, my infrastructure is aiming
at sed to. All fairly similar at the basic level anyway.
What does interactive line editing have to do with sed, a line-by-line
regex stream processor I previously wrote the busybox implementation of?
Just wondering.
I'm writing generic text editing functions. They don't care if it's a
full screen editor, line editor, or stream editor driving them, they do
text editing. Ed, ex, vi, and sed all have "select lines with a regex,
do some editing function on them". Lots of other things they have in
common to. Including the ability to run "scripts" of their own
commands over text.
So you're writing command line history infrastructure for shells.

And you're writing the pluming behind "more" and "less".

And you're writing the plumbing behind sed.

And you're writing vi, but it's also going to do emacs and joe and ex
and ed.

And you're writing scripting infrastructure.

And you're writing midnight commander.

And it's all one big thing which you're going to deliver all at once in
a giant patchbomb.

Good luck?
Post by David Seikel
I read through the relevant standards and compiled lists of what they
do that is common, and what they do that is not so common. Did the
same with the documentation for joe, microemacs, nano, and midnight
commanders editor. Also included more, less, and readline.
Not gonna be all things for all people, but there's enough common stuff
for generalization to work out for us.
I'm adding a chunk at a time and checking it in. I have somewhat
elaborate plans, but they change as I go along.

Your design of course takes into account none of _my_ elaborate plans,
but since I haven't checked them in yet they're fair game.

But I'm a bit nervous about impedence matching a giant code drop.
Post by David Seikel
The toybox sed (as of 0.3.0) is a stub with "hello world" in it.
What I've checked in is, yes.
Post by David Seikel
None
of the others have been written yet. I think my stuff could be useful
to them all, and toysh as well (readline type stuff).
I have yet to see, let alone review, a line of code from this.

I still have pending todo items from Elie and Georgi, which I'd be
working on if I hadn't gotten distracted into working on od.

Speaking of od, more notes on that:

-j has to support non-seekable input, such as pipes (cat | od -j 123).

What does -j do when you have multiple files? Ah, _concatenated_ input
files. So xlseek() is wrong on multiple counts: because if seek fails
you need to fall back to read(), and because you may skip more than one
entire input file. And this can't be "skip input blocks" because the
skip isn't required to be block aligned.

If the output of od gets dropped (-EPIPE), what happens? Should it retry
short writes, which implies xprintf() should do an xmprintf() into a
malloc buffer and then do a writeall() on it, although I really am
trying to get automatic retry in there with sigaction(SA_RESTART) but
that doesn't protect you against _short_ writes, just spurious zero
length writes, and yes you can get that with "cat | cat" when you kill
-STOP and then kill -CONT them...

Really? -A defaults to _octal_? The spec doesn't say (explicitly says
the default is undefined) but the gnu/dammit one does and busybox picked
it up from that, so...

Currently trying to figure out when I should I increment the error exit
return code. (I.E. what corner cases count as an error...)


Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-07-01 06:13:43 UTC
Permalink
Post by Rob Landley
Post by David Seikel
Oh yeah, my infrastructure is aiming
at sed to. All fairly similar at the basic level anyway.
What does interactive line editing have to do with sed, a line-by-line
regex stream processor I previously wrote the busybox implementation of?
Just wondering.
I'm writing generic text editing functions. They don't care if it's a
full screen editor, line editor, or stream editor driving them, they do
text editing. Ed, ex, vi, and sed all have "select lines with a regex,
do some editing function on them". Lots of other things they have in
common to. Including the ability to run "scripts" of their own
commands over text.

I read through the relevant standards and compiled lists of what they
do that is common, and what they do that is not so common. Did the
same with the documentation for joe, microemacs, nano, and midnight
commanders editor. Also included more, less, and readline.

Not gonna be all things for all people, but there's enough common stuff
for generalization to work out for us.

The toybox sed (as of 0.3.0) is a stub with "hello world" in it. None
of the others have been written yet. I think my stuff could be useful
to them all, and toysh as well (readline type stuff).
--
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/20120701/7ee44168/attachment-0002.pgp>
Rob Landley
2012-07-01 01:02:55 UTC
Permalink
Post by David Seikel
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...
I don't care about emacs or vi, but vi is apparently mandatory,
though hideous,
It's in posix, and is the only text editor that is unless you count
"ed". That means I'd need a reason _not_ to do it. (I might eventually
wind up doing ed, since sed is halfway there...)
Actually, vi includes an ex mode, and ex includes an ed mode. Think ed
might just come for free with vi.
Busybox has gone more than a decade without having that, and nobody's
ever complained that I noticed. But they do have a separate ed
implementation because explicitly it's in posix.

Me, I use the "v/y/p" commands that are missing from busybox vi because
it's the cut and paste functionality. (I only know a dozen or so vim
commands. before that it was Joe, but joe and ctrl-s do not combine
portably, and wordstar bindings wanted ctrl-s...)
Post by David Seikel
Oh yeah, my infrastructure is aiming
at sed to. All fairly similar at the basic level anyway.
What does interactive line editing have to do with sed, a line-by-line
regex stream processor I previously wrote the busybox implementation of?

Just wondering.
Post by David Seikel
Post by Rob Landley
Post by David Seikel
and basic emacs should be trivial, with a full emacs being
more hideous. Simple emacs, yep easy to do, could almost do it now.
Microemacs subset, most likely I'll do it. Full emacs, not gonna
happen.
Microemacs is what Linus uses, apparently. That probably makes it a
http://kernel.org/pub/linux/kernel/uemacs/
There's also "MicroGnuEmacs", which changed it's name to mg coz Richard
"GNU/Linux dammit" Stallman apparently objected.
"A bad thing exists".

Don't care?

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Dennis McCunney
2012-07-20 04:34:43 UTC
Permalink
Post by David Seikel
Actually, vi includes an ex mode, and ex includes an ed mode. Think ed
might just come for free with vi.
On Unix back when I learned it (AT&T Sys V R2 in the 80's), vi, ex, and
view (read-only mode) were links to the same underlying executable.
Which personality it assumed depended upon the name it was called by,
and you could change modes on the fly.

I haven't Looked Stuff Up, so I don't know offhand how much difference
there is between ex and ed, though my recollection is that ex is a
superset of ed, so ed more would be a restricted portion of ex.
Dennis McCunney
2012-07-20 04:34:43 UTC
Permalink
Post by David Seikel
Actually, vi includes an ex mode, and ex includes an ed mode. Think ed
might just come for free with vi.
On Unix back when I learned it (AT&T Sys V R2 in the 80's), vi, ex, and
view (read-only mode) were links to the same underlying executable.
Which personality it assumed depended upon the name it was called by,
and you could change modes on the fly.

I haven't Looked Stuff Up, so I don't know offhand how much difference
there is between ex and ed, though my recollection is that ex is a
superset of ed, so ed more would be a restricted portion of ex.
David Seikel
2012-07-01 00:01:02 UTC
Permalink
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...
I don't care about emacs or vi, but vi is apparently mandatory,
though hideous,
It's in posix, and is the only text editor that is unless you count
"ed". That means I'd need a reason _not_ to do it. (I might eventually
wind up doing ed, since sed is halfway there...)
Actually, vi includes an ex mode, and ex includes an ed mode. Think ed
might just come for free with vi. Oh yeah, my infrastructure is aiming
at sed to. All fairly similar at the basic level anyway.
Post by Rob Landley
Post by David Seikel
and basic emacs should be trivial, with a full emacs being
more hideous. Simple emacs, yep easy to do, could almost do it now.
Microemacs subset, most likely I'll do it. Full emacs, not gonna
happen.
Microemacs is what Linus uses, apparently. That probably makes it a
http://kernel.org/pub/linux/kernel/uemacs/
There's also "MicroGnuEmacs", which changed it's name to mg coz Richard
"GNU/Linux dammit" Stallman apparently objected.

/me snickers.
--
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/20120701/6f35e37c/attachment-0002.pgp>
David Seikel
2012-06-30 23:14:13 UTC
Permalink
On Sun, 1 Jul 2012 09:10:27 +1000 David Seikel <onefang at gmail.com>
Post by David Seikel
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
There are times scrolling existing text would be nice. Keep in
mind that's half of what "less" does".
I did not mean the functionality of scrolling text, I meant using
escape sequences for scrolling text. It already scrolls text, it
just does a screen redraw instead of trying to figure out which
bit of the screen it can scroll with escape sequences first before
drawing the rest.
I'm currently debugging a horrible fedora-only build issue where
running a shell script snippet via /bin/bash inserts stuff at the
start of the $PATH for some reason. (Maybe /etc/profile? Fedora is
horribly overcomplicated.) This, like everything else, breaks cross
compiling.
I'm running it under kvm, where screen writes are extremely
expensive due to the 2D sdl graphics card emulation.
Scrolling the screen is a bitblt, but redrawing the screen is slow
enough that I can see the characters redraw in the xterm.
This means cursoring down in another less implementation will be
essentially instantaneous in otherimplementations, and will take a
couple seconds per cursor-down key in the one you're proposing.
Saving redrawing half a line is useless, but redrawing the entire
screen unnecessarily rather than moving the lines of text up/down is
still pretty noticeable.
Post by David Seikel
This is one of the reasons I was checking if we ever have to deal
with slow connections. Fast ones can handle complete redraws for
paging and scrolling, and that keeps the code simple. Optimized
redraws can come later if we feel it's needed.
Optimizing redraws is more complicated than it's worth, but
_avoiding_ redraws is a pretty common case that can be expensive in
certain contexts. (Scrolling up or down, happens a lot.)
It is on my TODO to see what optimizations I can do simply. I want to
get it correct first though.
Post by Rob Landley
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...
I don't care about emacs or vi, but vi is apparently mandatory, though
hideous, and basic emacs should be trivial, with a full emacs being
more hideous. Simple emacs, yep easy to do, could almost do it now.
Microemacs subset, most likely I'll do it. Full emacs, not gonna
happen.
BTW, emacs dired I'll do, coz it just looks like a bit of midnight
commander which I want to do as well. So do one, done them both.
--
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/20120701/2c7240f2/attachment-0002.pgp>
Rob Landley
2012-06-30 23:36:55 UTC
Permalink
Post by David Seikel
Post by Rob Landley
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...
I don't care about emacs or vi, but vi is apparently mandatory, though
hideous,
It's in posix, and is the only text editor that is unless you count
"ed". That means I'd need a reason _not_ to do it. (I might eventually
wind up doing ed, since sed is halfway there...)
Post by David Seikel
and basic emacs should be trivial, with a full emacs being
more hideous. Simple emacs, yep easy to do, could almost do it now.
Microemacs subset, most likely I'll do it. Full emacs, not gonna
happen.
Microemacs is what Linus uses, apparently. That probably makes it a
reasonable target:

http://kernel.org/pub/linux/kernel/uemacs/

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-30 23:10:27 UTC
Permalink
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
There are times scrolling existing text would be nice. Keep in mind
that's half of what "less" does".
I did not mean the functionality of scrolling text, I meant using
escape sequences for scrolling text. It already scrolls text, it
just does a screen redraw instead of trying to figure out which bit
of the screen it can scroll with escape sequences first before
drawing the rest.
I'm currently debugging a horrible fedora-only build issue where
running a shell script snippet via /bin/bash inserts stuff at the
start of the $PATH for some reason. (Maybe /etc/profile? Fedora is
horribly overcomplicated.) This, like everything else, breaks cross
compiling.
I'm running it under kvm, where screen writes are extremely expensive
due to the 2D sdl graphics card emulation.
Scrolling the screen is a bitblt, but redrawing the screen is slow
enough that I can see the characters redraw in the xterm.
This means cursoring down in another less implementation will be
essentially instantaneous in otherimplementations, and will take a
couple seconds per cursor-down key in the one you're proposing.
Saving redrawing half a line is useless, but redrawing the entire
screen unnecessarily rather than moving the lines of text up/down is
still pretty noticeable.
Post by David Seikel
This is one of the reasons I was checking if we ever have to deal
with slow connections. Fast ones can handle complete redraws for
paging and scrolling, and that keeps the code simple. Optimized
redraws can come later if we feel it's needed.
Optimizing redraws is more complicated than it's worth, but _avoiding_
redraws is a pretty common case that can be expensive in certain
contexts. (Scrolling up or down, happens a lot.)
It is on my TODO to see what optimizations I can do simply. I want to
get it correct first though.
Post by Rob Landley
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...
I don't care about emacs or vi, but vi is apparently mandatory, though
hideous, and basic emacs should be trivial, with a full emacs being
more hideous. Simple emacs, yep easy to do, could almost do it now.
Microemacs subset, most likely I'll do it. Full emacs, not gonna
happen.
--
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/20120701/53ce6ac5/attachment-0002.pgp>
Rob Landley
2012-06-30 23:00:08 UTC
Permalink
Post by David Seikel
Post by Rob Landley
There are times scrolling existing text would be nice. Keep in mind
that's half of what "less" does".
I did not mean the functionality of scrolling text, I meant using escape
sequences for scrolling text. It already scrolls text, it just does a
screen redraw instead of trying to figure out which bit of the screen
it can scroll with escape sequences first before drawing the rest.
I'm currently debugging a horrible fedora-only build issue where running
a shell script snippet via /bin/bash inserts stuff at the start of the
$PATH for some reason. (Maybe /etc/profile? Fedora is horribly
overcomplicated.) This, like everything else, breaks cross compiling.

I'm running it under kvm, where screen writes are extremely expensive
due to the 2D sdl graphics card emulation.

Scrolling the screen is a bitblt, but redrawing the screen is slow
enough that I can see the characters redraw in the xterm.

This means cursoring down in another less implementation will be
essentially instantaneous in otherimplementations, and will take a
couple seconds per cursor-down key in the one you're proposing.

Saving redrawing half a line is useless, but redrawing the entire screen
unnecessarily rather than moving the lines of text up/down is still
pretty noticeable.
Post by David Seikel
This is one of the reasons I was checking if we ever have to deal with
slow connections. Fast ones can handle complete redraws for paging
and scrolling, and that keeps the code simple. Optimized redraws can
come later if we feel it's needed.
Optimizing redraws is more complicated than it's worth, but _avoiding_
redraws is a pretty common case that can be expensive in certain
contexts. (Scrolling up or down, happens a lot.)
Post by David Seikel
Post by Rob Landley
Basically, "vi" and "less" are my two initial use cases for this.
Emacs ain't in posix. If it's a really trivial additional binding
(basically a .config file), fine. But I personally will never use it,
and no standard requires it.
I would not use vi or emacs, so it's gonna do what ever I like as an
editor as well as those two. Once it can deal with the horrid vi
command and insert modes, which are no longer needed, just ancient
historic artefacts, then a simple emacs editor is just a matter of
different key bindings.
If you say so...
Post by David Seikel
It's gotta scratch my itches as well, or it's not worth my time.
Oh sure.
Post by David Seikel
And people will scream if I leave out emacs. shrugs
I honestly don't care, but if it's easy to do...

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Bastian Bittorf
2012-07-02 08:19:04 UTC
Permalink
Post by Rob Landley
I think we can assume that a serial connection will be 115k or
so.
No - even hardware from these days uses 9.6k baud sometimes.

bye, bastian
Roy Tam
2012-07-02 08:29:10 UTC
Permalink
Post by Bastian Bittorf
Post by Rob Landley
I think we can assume that a serial connection will be 115k or
so.
No - even hardware from these days uses 9.6k baud sometimes.
yeah, the holy cisco switches and routers.
Post by Bastian Bittorf
bye, bastian
_______________________________________________
Toybox mailing list
Toybox at lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Roy Tam
2012-07-02 08:29:10 UTC
Permalink
Post by Bastian Bittorf
Post by Rob Landley
I think we can assume that a serial connection will be 115k or
so.
No - even hardware from these days uses 9.6k baud sometimes.
yeah, the holy cisco switches and routers.
Post by Bastian Bittorf
bye, bastian
_______________________________________________
Toybox mailing list
Toybox at lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Bastian Bittorf
2012-07-02 08:19:04 UTC
Permalink
Post by Rob Landley
I think we can assume that a serial connection will be 115k or
so.
No - even hardware from these days uses 9.6k baud sometimes.

bye, bastian
David Seikel
2012-06-30 20:42:13 UTC
Permalink
Post by Rob Landley
Post by David Seikel
One thing I'm wondering about. A lot of these editors where written
for the days of really slow serial connections.
I think we can assume that a serial connection will be 115k or so.
Works for me. B-)
Post by Rob Landley
Post by David Seikel
Not worrying about these things means we don't complicate the code
with lots of optimizations for how much we output, or using fancy
ANSI escapes for scrolling existing text and such. I think we can
get away with that.
There are times scrolling existing text would be nice. Keep in mind
that's half of what "less" does".
I did not mean the functionality of scrolling text, I meant using escape
sequences for scrolling text. It already scrolls text, it just does a
screen redraw instead of trying to figure out which bit of the screen
it can scroll with escape sequences first before drawing the rest.

This is one of the reasons I was checking if we ever have to deal with
slow connections. Fast ones can handle complete redraws for paging
and scrolling, and that keeps the code simple. Optimized redraws can
come later if we feel it's needed.
Post by Rob Landley
Basically, "vi" and "less" are my two initial use cases for this.
Emacs ain't in posix. If it's a really trivial additional binding
(basically a .config file), fine. But I personally will never use it,
and no standard requires it.
I would not use vi or emacs, so it's gonna do what ever I like as an
editor as well as those two. Once it can deal with the horrid vi
command and insert modes, which are no longer needed, just ancient
historic artefacts, then a simple emacs editor is just a matter of
different key bindings.

It's gotta scratch my itches as well, or it's not worth my time. And
people will scream if I leave out emacs. shrugs
--
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/20120701/4f20285e/attachment-0002.pgp>
David Seikel
2012-06-28 21:31:17 UTC
Permalink
I got a very simple editor working now. It can load a file, navigate
within it, move the cursor, insert characters, delete them, and save the
file. The keys are currently bound to commands via an array, but I plan
on making a "bind key" command to.

For microemacs, wordstar help window, and later for midnight commander,
there's "split the screen into boxes" stuff.

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.

There's a few bugs and missing features to iron out, but I think I'll
show it to you when I got those sorted.
--
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/20120629/9b385476/attachment-0002.pgp>
Rob Landley
2012-06-30 19:52:56 UTC
Permalink
Post by David Seikel
One thing I'm wondering about. A lot of these editors where written
for the days of really slow serial connections.
I think we can assume that a serial connection will be 115k or so.
Post by David Seikel
Not worrying about these things means we don't complicate the code with
lots of optimizations for how much we output, or using fancy ANSI
escapes for scrolling existing text and such. I think we can get away
with that.
There are times scrolling existing text would be nice. Keep in mind
that's half of what "less" does".

Basically, "vi" and "less" are my two initial use cases for this. Emacs
ain't in posix. If it's a really trivial additional binding (basically a
.config file), fine. But I personally will never use it, and no standard
requires it.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-25 21:04:54 UTC
Permalink
I've gone through the features of those editors we have mentioned in
this thread, and compiled a list of most of those features. Separated
them into "basic infrastructure" "basic editing", "advanced editing",
and "code editing". It's a long list, even if you leave out advanced
and code editing. On the other hand, a lot would just be options to
common functions, or is already covered by the full screen handling
library.

So now to come up with a design for the generic editing library that
can cater for most of that. And leaves scope for more advanced stuff
to be bolted on.

One thing I'm wondering about. A lot of these editors where written
for the days of really slow serial connections. I see three use cases
for this - direct console / xterm access (including on your smart
phone), ssh over the Internet or local network, and high speed serial
connection to an embedded computer on your desk (or emulator). I don't
know if serial over modem access would be common. So there's a fair
amount of "cater to really slow connections" stuff which I don't
think we need. Also a fair bit of "cater for dumb terminal" which the
basic "anything modern can understand ANSI escapes" design principle
leaves out.

Not worrying about these things means we don't complicate the code with
lots of optimizations for how much we output, or using fancy ANSI
escapes for scrolling existing text and such. I think we can get away
with that.
--
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/20120626/49c785a8/attachment-0002.pgp>
David Seikel
2012-06-21 05:40:16 UTC
Permalink
Post by Rob Landley
Post by David Seikel
Post by Rob Landley
No, they have an implementation of screen. The first one I used
(circa 1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed
it over to a second pair of maintainers who handed it over to the
gnu project. So it's a bit like Gold and Patch and Grub and EGCS
so on: somebody wrote a thing that worked and the Gnu project
managed to take it over and plaster their name all over it as the
versions they ship bloat and lose reliability.
perhaps
http://tmux.sourceforge.net/
could be an interesting alternative
Doing a "less" or "vi" implementation is 90% of doing screen. You
have a text buffer that displays on the screen. You write at the
current cursor position to update that text buffer.
That's pretty much what screen and less both do. I'd like to get them
to share infrastructure to do it, which means writing some kind of
lib/buffer.c.
That's what I'm working on, common infrastructure for such purposes.
--
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/20120621/a6e63ef0/attachment-0002.pgp>
Andre Renaud
2012-06-19 03:10:59 UTC
Permalink
Post by Rob Landley
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.
There is a BSD-licensed terminal multiplexer - 'tmux'. It's
conceptually the same as GNU screen, but I'm assuming it's a
completely clean code base.

Regards,
Andre
Rob Landley
2012-06-21 05:14:51 UTC
Permalink
Post by David Seikel
Post by Rob Landley
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.
The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.
perhaps
http://tmux.sourceforge.net/
could be an interesting alternative
Doing a "less" or "vi" implementation is 90% of doing screen. You have a
text buffer that displays on the screen. You write at the current cursor
position to update that text buffer.

That's pretty much what screen and less both do. I'd like to get them to
share infrastructure to do it, which means writing some kind of
lib/buffer.c.

Rob

P.S. Sorry for the delay. Thunderbird is just _eating_ itself since the
last ubuntu package update. It sits there at 100% cpu for six hours and
then downloads _some_ of the outstanding messages. Today, it gave me 3
days worth of email at once, after telling me i didn't have any.

My new netbook, I'll be setting up a different mail client, I just have
to figure out which one...
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-06-17 11:32:09 UTC
Permalink
Post by Roy Tam
On Fri, Sat Jun 16 08:47:05 PDT 2012 David Seikel
Post by David Seikel
On Fri, 15 Jun 2012 21:20:11 +1000 David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. ?Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
That's exactly what I did, and that worked fine. ?Still, shows
there's a problem in toybox. ?The name "toyboxes" failed, coz it
got confused with "toybox", the name "boxes" worked. ?I can't think
off the top of my head of any other cases where a command we might
want to support has it's name being a subset of the name of some
other command we might want to support, but it could happen.
maybe we can have a simplified GNU SCREEN with it? ;-)
Does GNU own screen? ?Careful with such assumptions around here.
Yes they did.
http://www.gnu.org/software/screen/
It's hosted there, but I don't think they own it.
--
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/20120617/259245ef/attachment-0002.pgp>
Rob Landley
2012-06-18 14:38:17 UTC
Permalink
Post by Roy Tam
Post by David Seikel
Post by Roy Tam
Post by David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
That's exactly what I did, and that worked fine. Still, shows there's
a problem in toybox. The name "toyboxes" failed, coz it got confused
with "toybox", the name "boxes" worked. I can't think off the top of my
head of any other cases where a command we might want to support has
it's name being a subset of the name of some other command we might
want to support, but it could happen.
Post by Roy Tam
maybe we can have a simplified GNU SCREEN with it? ;-)
Does GNU own screen? Careful with such assumptions around here.
Yes they did.
http://www.gnu.org/software/screen/
No, they have an implementation of screen. The first one I used (circa
1993) was from Sun.

The wonkypedia article says the first pair of maintainers handed it over
to a second pair of maintainers who handed it over to the gnu project.
So it's a bit like Gold and Patch and Grub and EGCS so on: somebody
wrote a thing that worked and the Gnu project managed to take it over
and plaster their name all over it as the versions they ship bloat and
lose reliability.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Roy Tam
2012-06-17 11:20:12 UTC
Permalink
Post by Roy Tam
Post by David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. ?Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
That's exactly what I did, and that worked fine. ?Still, shows there's
a problem in toybox. ?The name "toyboxes" failed, coz it got confused
with "toybox", the name "boxes" worked. ?I can't think off the top of my
head of any other cases where a command we might want to support has
it's name being a subset of the name of some other command we might
want to support, but it could happen.
Post by Roy Tam
maybe we can have a simplified GNU SCREEN with it? ;-)
Does GNU own screen? ?Careful with such assumptions around here.
Yes they did.
http://www.gnu.org/software/screen/
I do have a note on my design docs that it might be possible to
implement something like screen or tmux, and a warning not to turn into
curses or twin. lol
The design goal is to support things like full screen text viewers,
editors, and midnight commander. ?Being a generalised full screen text
UI library is out of scope. ?Side by side boxes, status lines, menus,
scrolling text, text editing, these things are in scope. ?A centred
popup widget for selecting options and entering command parameters is
borderline in scope, I'm gonna see if I can leave it out at first.
Arbitrary text "windows" that you can drag around with the mouse,
cacalib support, these things are out of scope.
Screen and tmux do happen to fall within the scope of what is supported
by the library design though. ?There's a nohup toy, so it might be
possible. ?That's about the limit of my thoughts in how to support
screen or tmux. ?I'm not going out of my way to support them, but it
may be possible anyway.
So far the code has ended up being a lot simpler than I expected. ?B-)
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
_______________________________________________
Toybox mailing list
Toybox at lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
David Seikel
2012-06-17 06:13:15 UTC
Permalink
Post by Roy Tam
Post by David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
That's exactly what I did, and that worked fine. Still, shows there's
a problem in toybox. The name "toyboxes" failed, coz it got confused
with "toybox", the name "boxes" worked. I can't think off the top of my
head of any other cases where a command we might want to support has
it's name being a subset of the name of some other command we might
want to support, but it could happen.
Post by Roy Tam
maybe we can have a simplified GNU SCREEN with it? ;-)
Does GNU own screen? Careful with such assumptions around here.

I do have a note on my design docs that it might be possible to
implement something like screen or tmux, and a warning not to turn into
curses or twin. lol

The design goal is to support things like full screen text viewers,
editors, and midnight commander. Being a generalised full screen text
UI library is out of scope. Side by side boxes, status lines, menus,
scrolling text, text editing, these things are in scope. A centred
popup widget for selecting options and entering command parameters is
borderline in scope, I'm gonna see if I can leave it out at first.
Arbitrary text "windows" that you can drag around with the mouse,
cacalib support, these things are out of scope.

Screen and tmux do happen to fall within the scope of what is supported
by the library design though. There's a nohup toy, so it might be
possible. That's about the limit of my thoughts in how to support
screen or tmux. I'm not going out of my way to support them, but it
may be possible anyway.

So far the code has ended up being a lot simpler than I expected. B-)
--
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/20120617/f7b33df7/attachment-0002.pgp>
Roy Tam
2012-06-17 05:14:34 UTC
Permalink
Post by David Seikel
Post by David Seikel
Then there would be a toy I'm calling toyboxes.
Hmm, seems toybox does not like toy names that partially match the
names of other toys. Every time I try to use "toyboxes", it finds
"toybox" instead.
why not use "boxes" as the name?
maybe we can have a simplified GNU SCREEN with it? ;-)

Best regards,
Roy
Continue reading on narkive:
Loading...