diff options
Diffstat (limited to '')
-rw-r--r-- | boxes.c | 169 |
1 files changed, 168 insertions, 1 deletions
@@ -196,6 +196,100 @@ GLOBALS( | |||
196 | * everything all the time. And to avoid screen redraws. | 196 | * everything all the time. And to avoid screen redraws. |
197 | */ | 197 | */ |
198 | 198 | ||
199 | /* Robs "It's too big" lament. | ||
200 | |||
201 | > So when you give me code, assume I'm dumber than you. Because in this | ||
202 | > context, I am. I need bite sized pieces, each of which I can | ||
203 | > understand in its entirety before moving on to the next. | ||
204 | |||
205 | As I mentioned in my last email to the Aboriginal linux list, I wrote | ||
206 | the large blob so I could see how the ideas all work to do the generic | ||
207 | editor stuff and other things. It kinda needs to be that big to do | ||
208 | anything that is actually useful. So, onto musings about cutting it up | ||
209 | into bite sized bits... | ||
210 | |||
211 | You mentioned on the Aboriginal Linux list that you wanted a | ||
212 | "readline", and you listed some features. My reply was that you had | ||
213 | basically listed the features of my "basic editor". The main | ||
214 | difference between "readline" and a full screen editor, is that the | ||
215 | editor is fullscreen, while the "readline" is one line. They both have | ||
216 | to deal with a list of lines, going up and down through those lines, | ||
217 | editing the contents of those lines, one line at a time. For persistent | ||
218 | line history, they both have to save and load those lines to a file. | ||
219 | Other than that "readline" adds other behaviour, like moving the | ||
220 | current line to the end when you hit return and presenting that line to | ||
221 | the caller (here's the command). So just making "readline" wont cut | ||
222 | out much of the code. In fact, my "readline" is really just a thin | ||
223 | wrapper around the rest of the code. | ||
224 | |||
225 | Starting from the other end of the size spectrum, I guess "find out | ||
226 | terminal size" is a small enough bite sized chunk. To actually do | ||
227 | anything useful with that you would probably start to write stuff I've | ||
228 | already written though. Would be better off just using the stuff I've | ||
229 | already written. On the other hand, maybe that would be useful for | ||
230 | "ls" listings and the like, then we can start with just that bit? | ||
231 | |||
232 | I guess the smallest useful command I have in my huge blob of code | ||
233 | would be "more". I could even cut it down more. Show a page of text, | ||
234 | show the next page of text when you hit the space bar, quit when you | ||
235 | hit "q". Even then, I would estimate it would only cut out a third of | ||
236 | the code. | ||
237 | |||
238 | On the other hand, there's a bunch of crap in that blob that is for | ||
239 | future plans, and is not doing anything now. | ||
240 | |||
241 | In the end though, breaking it up into suitable bite sized bits might | ||
242 | be almost as hard as writing it in the first place. I'll see what I | ||
243 | can do, when I find some time. I did want to break it up into three | ||
244 | bits anyway, and there's a TODO to untangle a couple of bits that are | ||
245 | currently too tightly coupled. | ||
246 | |||
247 | */ | ||
248 | |||
249 | /* Robs contradiction | ||
250 | |||
251 | On Thu, 27 Dec 2012 06:06:53 -0600 Rob Landley <rob@landley.net> wrote: | ||
252 | |||
253 | > On 12/27/2012 12:56:07 AM, David Seikel wrote: | ||
254 | > > On Thu, 27 Dec 2012 00:37:46 -0600 Rob Landley <rob@landley.net> | ||
255 | > > wrote: | ||
256 | > > > Since ls isn't doiing any of that, probing would just be awkward | ||
257 | > > > so toysh should set COLUMNS to a sane value. The problem is, | ||
258 | > > > we're not using toysh yet because it's still just a stub... | ||
259 | > > | ||
260 | > > I got some or all of that terminal sizing stuff in my editor thingy | ||
261 | > > already if I remember correctly. I remember you wanted me to cut it | ||
262 | > > down into tiny bits to start with, so you don't have to digest the | ||
263 | > > huge lump I sent. | ||
264 | > | ||
265 | > Basically what I'd like is a self-contained line reader. More or less | ||
266 | > a getline variant that can handle cursoring left and right to insert | ||
267 | > stuff, handle backspace past a wordwrap (which on unix requires | ||
268 | > knowing the screen width and your current cursor position), and one | ||
269 | > that lets up/down escape sequences be hooked for less/more screen | ||
270 | > scrolling, vi line movement, shell command history, and so on. | ||
271 | |||
272 | Which is most of an editor already, so how to break it up into bite | ||
273 | sized morsels? | ||
274 | |||
275 | > There's sort of three levels here, the first is "parse raw input, | ||
276 | > assembling escape sequences into cursor-left and similar as | ||
277 | > necessary". (That's the one I had to redo in busybox vi because they | ||
278 | > didn't do it right.) | ||
279 | > | ||
280 | > The second is "edit a line of text, handling cursoring _within_ the | ||
281 | > line". That's the better/interactive getline(). | ||
282 | > | ||
283 | > The third is handling escapes from that line triggering behavior in | ||
284 | > the larger command (cursor up and cursor down do different things in | ||
285 | > less, in vi, and in shell command history). | ||
286 | > | ||
287 | > The fiddly bit is that terminal_size() sort of has to integrate with | ||
288 | > all of these. Possibly I need to have width and height be members of | ||
289 | > struct toy_context. Or have the better_getline() take a pointer to a | ||
290 | > state structure it can update, containing that info... | ||
291 | |||
292 | */ | ||
199 | 293 | ||
200 | struct key | 294 | struct key |
201 | { | 295 | { |
@@ -837,7 +931,80 @@ void formatCheckCursor(view *view, long *cX, long *cY, char *input) | |||
837 | } | 931 | } |
838 | 932 | ||
839 | // TODO - Should convert control characters to reverse video, and deal with UTF8. | 933 | // TODO - Should convert control characters to reverse video, and deal with UTF8. |
840 | // TODO - We get passed a NULL input, apparently when the file length is close to the screen length. See the mailing list for details. Fix that. | 934 | /* FIXME - We get passed a NULL input, apparently when the file length is close to the screen length. - |
935 | |||
936 | > On Thu, 6 Sep 2012 11:56:17 +0800 Roy Tam <roytam@gmail.com> wrote: | ||
937 | > | ||
938 | > > 2012/9/6 David Seikel <onefang@gmail.com>: | ||
939 | > > >> Program received signal SIGSEGV, Segmentation fault. | ||
940 | > > >> formatLine (view=0x8069168, input=0x0, output=0x806919c) | ||
941 | > > >> at toys/other/boxes.c:843 | ||
942 | > > >> 843 int len = strlen(input), i = 0, o = 0; | ||
943 | > > >> (gdb) bt | ||
944 | > > >> #0 formatLine (view=0x8069168, input=0x0, output=0x806919c) | ||
945 | > > >> at toys/other/boxes.c:843 | ||
946 | > > >> #1 0x0804f1dd in moveCursorAbsolute (view=0x8069168, cX=0, | ||
947 | > > >> cY=10, sX=0, sY=0) at toys/other/boxes.c:951 | ||
948 | > > >> #2 0x0804f367 in moveCursorRelative (view=0x8069168, cX=0, | ||
949 | > > >> cY=10, sX=0, sY=0) at toys/other/boxes.c:1011 | ||
950 | > > >> #3 0x0804f479 in upLine (view=0x8069168, event=0x0) at | ||
951 | > > >> toys/other/boxes.c:1442 #4 0x0804fb63 in handleKey | ||
952 | > > >> (view=0x8069168, i=2, keyName=<optimized out>, buffer=0xbffffad8 | ||
953 | > > >> "\033[A") at toys/other/boxes.c:1593 #5 0x0805008d in editLine | ||
954 | > > >> (view=0x8069168, X=-1, Y=-1, W=-1, H=-1) at | ||
955 | > > >> toys/other/boxes.c:1785 #6 0x08050288 in boxes_main () at | ||
956 | > > >> toys/other/boxes.c:2482 #7 0x0804b262 in toy_exec | ||
957 | > > >> (argv=0xbffffd58) at main.c:104 #8 0x0804b29d in toybox_main () | ||
958 | > > >> at main.c:118 #9 0x0804b262 in toy_exec (argv=0xbffffd54) at | ||
959 | > > >> main.c:104 #10 0x0804b29d in toybox_main () at main.c:118 | ||
960 | > > >> #11 0x0804affa in main (argc=5, argv=0xbffffd54) at main.c:159 | ||
961 | > > > | ||
962 | > > > No segfault here when I try that, nor with different files. As I | ||
963 | > > > said, it has bugs. I have seen other cases before when NULL lines | ||
964 | > > > are passed around near that code. Guess I've not got them all. | ||
965 | > > > Might help to mention what terminal proggy you are using, it's | ||
966 | > > > size in characters, toybox version, OS, etc. Something is | ||
967 | > > > different between you and me. | ||
968 | > > | ||
969 | > > Terminal Program: PuTTY | ||
970 | > > Windows size: 80 * 25 chars | ||
971 | > > Toybox version: hg head | ||
972 | > > OS: Linux 3.2 (Debian wheezy) | ||
973 | > > File: Toybox LICENSE file | ||
974 | > | ||
975 | > I'll install PuTTY, try toybox hg head, and play with them later, see | ||
976 | > if I can reproduce that segfault. I use the last released tarball of | ||
977 | > toybox, an old Ubuntu, and a bunch of other terminal proggies. I did | ||
978 | > not know that PuTTY had been ported to Unix. | ||
979 | > | ||
980 | > But as I mentioned, not interested in a bug hunt right now. That will | ||
981 | > be more appropriate when it's less of a "sandbox for testing the | ||
982 | > ideas" and more of a "good enough to bother using". Always good to | ||
983 | > have other terminals for testing though. | ||
984 | |||
985 | Seems to be sensitive to the number of lines. On my usual huge | ||
986 | roxterm, using either toybox 0.4 or hg head, doing this - | ||
987 | |||
988 | ./toybox boxes -m less LICENSE -h 25 | ||
989 | |||
990 | and just hitting down arrow until you get to the bottom of the page | ||
991 | segfaults as well. -h means "pretend the terminal is that many lines | ||
992 | high", there's a similar -w as well. 80x25 in any other terminal did | ||
993 | the same. For that particular file (17 lines long), any value of -h | ||
994 | between 19 and 34 will segfault after some moving around. -h 35 makes | ||
995 | it segfault straight away. Less than 19 or over 35 is fine. Longer | ||
996 | files don't have that problem, though I suspect it will happen on | ||
997 | shortish files where the number of lines is about the length of the | ||
998 | screen. | ||
999 | |||
1000 | I guess that somewhere I'm doing maths wrong and getting an out of | ||
1001 | bounds line number when the file length is close to the screen length. | ||
1002 | I'll make note of that, and fix it when I next get time to beat on | ||
1003 | boxes. | ||
1004 | |||
1005 | Thanks for reporting it Roy. | ||
1006 | */ | ||
1007 | |||
841 | int formatLine(view *view, char *input, char **output) | 1008 | int formatLine(view *view, char *input, char **output) |
842 | { | 1009 | { |
843 | int len = strlen(input), i = 0, o = 0; | 1010 | int len = strlen(input), i = 0, o = 0; |