On Mon, 22 Dec 2014 22:21:26 -0600 Rob Landley <[email protected]> wrote:
> > > On 12/21/14 17:42, enh wrote: > > On Sun, Dec 21, 2014 at 1:07 PM, James McMechan > > <[email protected]> wrote: > >> On 12/20/2014 05:55:45 PM, David Seikel wrote: > >>> > >>> On Sat, 20 Dec 2014 19:30:01 -0600 Rob Landley <[email protected]> > >>> wrote: > >>> > >>>> > >>>> > >>>> On 12/19/14 18:52, David Seikel wrote: No idea how the quoting in your reply got built, nothing I actually said is quoted. > >>>>> On Fri, 19 Dec 2014 16:43:51 -0800 enh <[email protected]> wrote: > >>>>> > >>>>>> i was thinking about writing a trivial termcap implementation > >>>>>> that just returns the xterm-color answers and using the BSD > >>>>>> less, but i didn't realize that even the BSDs use the GNU less. > >> > >> > >> fortunately n-curses devolves tremendously when you don't try to > >> support every terminal type under the sun efficiently... > > > > (very off-topic at this point, but vim doesn't use ncurses under any > > circumstances. moreover, it turns out that vim actually has all > > kinds of different fallbacks and as long as you don't misconfigure > > it like i did, it builds and runs fine out of the box on Android. > > it has a minimal tgetstr/tgoto/tputs implementation *and* a few > > built-in termcap subsets, including xterm. it's an 8.3MiB binary > > unstripped or 2.1MiB stripped for aarch64, though, so probably not > > of much interest to you guys :-) ) > > I plan to implement vi over the next year, but it's one of the four > realy big commands required by posix (sed, awk, sh, vi) and I've been > debugging sed against real-world data for _weeks_ now. (It's easy to > knock out a simple 90% implementation. It's really hard to make > something do everything right in all the cases people are going to > throw at it.) > > There are some others (the kernel build requires bc now, if I'm doing > "less" and "vi" I should be able to do "screen", and "rsync" is really > useful...) but right now I'm focused on the list for 1.0, and there > are a lot of smaller commands (and the giant backlog of pending > cleanups) that could get knocked off the list faster... "Rsync" isn't in my scope, but I agree, it being in toybox would be very useful, I hope someone works on that. > By the way, the generic line editing infrastructure is useful not just > for shell command line editing, and obvious stuff like less, screen, > and vi, but even "watch" needs it to work quite right. (And if you're > supporting unicode, the difference between doing "more" and "less" > _right_ isn't as big as you'd think...) > > If "less" is a priority, that actually helps prioritize the rest of > them. Once I've written the basic "navigate a line" infrastructure > (with querying screen size via ansi probe fallback, and reassembling > escape sequences that got decoupled going over serial line; I fixed > both of these in busybox several years ago), then stacking them isn't > quite as big a deal. Even less of a big deal since I've already done a lot of these things for toybox, and hanging out for things to filter through Robs TODO list of DOOM so that we can complete them. "Screen" / "tmux" (I prefer tmux at this stage) is something my boxes infrastructure could handle as well, so it's on my TODO to look at. I've done the "no need for curses / termcap" thing. I've done the "basic navigate a line" infrastructure. I've done the "figure out screen size with fallbacks" thing. I've done the "generic line and screen editing" thing. I've tied it all together. I've done the basic emacs, less, joe, less, mcedit, more, nano, vi thing. I've done a brian dead sh to show how my infrastructure would fit that use case. I've done the research for the non basic editing stuff that I've not implemented yet. I've even implemented a few non basic editing commands. It's been going on for a long time now (over two years) can you at least put the boxes stuff into pending please, so that we can all work on it? Then people wont keep bringing up less, vi, and all those others that I have a basic working implementation of, as if there's been no work done on them. Would be nice if we all worked on one implementation, instead of investigating them / working on them separately. "Boxes is good enough for pending" means we can move on. "Boxes is shit" means I can give up and find other things to do, someone else can work on them. "Boxes is not quite good enough for pending and Rob's not been telling me what needs to be fixed for years" means it's in limbo for two years and I'm getting frustrated with that lack of progress. I know others where waiting on some progress here two years ago. They might have given up waiting. OK Rob, you told me one thing that was wrong, it was too big for you to grok in one sitting. It has to be, it covers a lot of ground. I broke of the smallest stand alone part I could and submitted that, and still no movement with it. Please put boxes (or at least that bite sized handlekeys bit) in pending, or put it out of it's misery. We can help you write this stuff if you let us Rob. Delegate responsibility to me if you like, or not. Let me and any one else that wants to work on these things, work on it in pending, bitch at us if our idea of perfection (or even our temporary horrid hack) doesn't meet your idea of perfection. Maybe in another two years it will be good enough for moving out of pending, but at least progress happens, people can use it, people can file bug reports, or fix it. This current limbo isn't working for anyone. Especially now that you think sed is almost good enough. Now would be a great time for me to read through the way you handle files and lines in sed, with a view to reusing that infrastructure in boxes. Then the next bite sized bit could be file / line handling, and could happen soon. It's especially frustrating watching other peoples submissions going in easily, and pretty much nothing happening for boxes for over two years. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
