On 01/01/2015 01:04 PM, dmccunney wrote: > On Thu, Jan 1, 2015 at 1:39 AM, David Seikel <[email protected]> wrote: > >> I have a simple test to decide if I like an editor as a result of these >> decades of random editor usage. If I can't sit down with the editor >> and figure out how to do basic editing and saving in less than a >> minute (sans documentation), then in my opinion it's a crap editor. >> Both TECO and vi fail this test miserably, though oddly enough I have a >> soft spot for TECO. > > These days, the general assumption is that you can open a file in an > editor with "<editor> <filename>", and that once up, cursor keys can > be used to move around in the file and that text can be added where > desired by typing it at the cursor location and deleted with Backspace > or Delete keys. > > Vi originated in the days when some of those assumptions might not be > true. Some early terminals on Unix systems didn't *have* cursor keys > or F-keys. The vi command set and separation between input and > command modes was a result.
Indeed. However, ubuntu's decision to only allow you to cursor around in insert mode when you call "vim" and to _disable_ that when you call it as "vi" (so the cursor keys instead crap B[ and such all over your text) is insane and stupid. And the fix is to delete /etc/vim/vimrc.tiny and make it a symlink to just "vimrc" in the same directory. And the fact you _need_ to do that on each new ubuntu install is just one more way that Mark Shuttleworth is trying to cram his personal preferences down people's throats. (Redirecting /bin/sh to point to dash instead of bash was still a dumber move, though.) > Given where Toybox will be used, it's a reasonable assumption folks > running the included editor will already know enough of the basics to > deal with vi, even if they may prefer something else, so "Can they > figure out basic editing and saving without docs" is a non-issue. > >> killall -KILL vi >> >> OK, yes I know about :qa as well, killall is much more satisfying. B-) > > You *could* simply remove vi from your system. :-) > >> Out of all the editors that I have implemented in boxes, I have used >> them all professionally, including the line editors buried inside emacs >> and vi. These days I prefer to use mc and mcedit for everything though, >> which is why boxes includes mcedit. So I'll dogfood mcedit, the rest >> I'll have to rely on others to tell me what I get wrong. > > We will. The big issue I can see is preserving "moded" editing in vi > and dispensing with it in the others. The design I worked out back in 2006 was to have a line editor function that handles cursor left/right and inserting, but returns to its caller if you hit cursor up or cursor down (or page up...), and then a calling function could stack lines for a text editor, or handle command history instead if that's what the caller was implementing. (It gets fiddly when "a line" can be multiple terminal lines because it's wrapping a long line, but you could call the function with an argument telling it whether or not to do that and have "I expanded to another line" or "I shrank a line" be return codes so the caller can adjust stack views and such".) That way vi would have a line stack (possibly with last line's display truncated because "you can show X vertical lines of content" could be an argument when it's called), and then when you go into editing mode you call it telling it to display on the bottom line and only one line of text (scroll left/right as necessary to have cursor on screen). That mode would similarly be what "less" uses, and "watch" would basically use it in reverse (the line that isn't wrapped content would be at the top instead of the bottom). I was going to wait until actually _implementing_ it to fluff out the design much more than that, because plans don't survive contact with reality and infrastructure in search of a user is bad. My plan was to start with a function to fetch a key given an array of possible understood escape sequences and return the index in the array of the escape sequence it saw, or the raw character if it was none of that. (That way I could use it to reimplement menuconfig, interpreting the cursor keys for me.) Then build the line editor function, and use the line editor function to implement command history for toysh. Then start on "watch" and "less" (stacking output in a display-only manner), then work my way up to vi. The boxes code wasn't quite layered the way I had in mind. (I tried to chop out the "read one escape sequence or character" function, but could never _find_ it as a separable entity.) I need to read through it more and see what bits of it I can adapt to what I was thinking or if I need to give up on what I was thinking, or what. And that's why it's still on the todo list, because wrapping my head around a design is not something I can do in 15 minute increments. It takes me at least 15 minutes to swap back in "where did I leave off with this" when I start poking at it again after a fairly short break, let alone months. But "sed" was a higer priority because when it comes to replacing busybox in a self-bootstrapping development environment, it was far and away the most frequently called remaining command toybox didn't implement, the top ten being: http://landley.net/notes-2013.html#13-08-2014 10 busybox dd 12 busybox gzip 46 busybox bzip2 81 busybox tar 85 busybox find 682 busybox diff 1041 busybox awk 1942 busybox sh 2024 busybox install 3202 busybox tr 16603 busybox expr 130099 busybox sed (Also why it's so hard to debug. 130k different invocations to match the output of, and sometimes when I fix one it causes regressions elsewhere...) >> I have no plans to implement TECO in boxes, vi and ed are already there. > > C source is available for a port of TECO if anyone wants to build it, > but I don't see a need in Toybox. Stallman used ITS TECO as the > implementation language for Editing MACroS, the lineal ancestor of Gnu > Emacs, because it was what was available. It was a language in which > he could implement an editor. It took over as the standard editor at > MIT's AI labs, and he realized how successful his efforts had been > when he no longer remembered how to do things in raw TECO. We have > other languages in which you can write editors now. I've read rather a lot of history of vi/emacs/teco (some of it on http://landley.net/history/mirror/ some not) and my rsponse to ALL of it is the same as Vogons Grandmothers and Bugblatter Beasts: "In brief: avoid." vi is interesting because it's ubiquitous and standardized by posix. Microemacs is interesting because it's ubiquitous and Linus Torvalds' personal editor. Last "intro to unix" class I taught at the local community college (many moons ago) I did the textbook's chapter on vi out of the syllabus I was given and then introduced everybody to nano. I have todo items like "look up what keybindings eclipse uses" because there's an entire generation of rebadged cobol developers filling out forms and calling it programming for the fortune 500 using that. (Java's flash in the pan popularity spike coincided with the "throw money at the problem" stage of Y2K last minute panicking, so Java became the new cobol and is now fossilized into enterprise procedure specification certification buzzword compliant whatsises.) If vi/uemacs/joe/nano are trivial extensions of the same basic infrastructure (sort of true modulo vi command mode), I have no problem implementing lots of sets of keybindings. But the first target is vi because it's the only one actually in posix. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
