aboutsummaryrefslogtreecommitdiffstatshomepage
diff options
context:
space:
mode:
-rw-r--r--boxes.c169
1 files changed, 168 insertions, 1 deletions
diff --git a/boxes.c b/boxes.c
index 11c3de8..1b857a4 100644
--- a/boxes.c
+++ b/boxes.c
@@ -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
205As I mentioned in my last email to the Aboriginal linux list, I wrote
206the large blob so I could see how the ideas all work to do the generic
207editor stuff and other things. It kinda needs to be that big to do
208anything that is actually useful. So, onto musings about cutting it up
209into bite sized bits...
210
211You mentioned on the Aboriginal Linux list that you wanted a
212"readline", and you listed some features. My reply was that you had
213basically listed the features of my "basic editor". The main
214difference between "readline" and a full screen editor, is that the
215editor is fullscreen, while the "readline" is one line. They both have
216to deal with a list of lines, going up and down through those lines,
217editing the contents of those lines, one line at a time. For persistent
218line history, they both have to save and load those lines to a file.
219Other than that "readline" adds other behaviour, like moving the
220current line to the end when you hit return and presenting that line to
221the caller (here's the command). So just making "readline" wont cut
222out much of the code. In fact, my "readline" is really just a thin
223wrapper around the rest of the code.
224
225Starting from the other end of the size spectrum, I guess "find out
226terminal size" is a small enough bite sized chunk. To actually do
227anything useful with that you would probably start to write stuff I've
228already written though. Would be better off just using the stuff I've
229already 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
232I guess the smallest useful command I have in my huge blob of code
233would be "more". I could even cut it down more. Show a page of text,
234show the next page of text when you hit the space bar, quit when you
235hit "q". Even then, I would estimate it would only cut out a third of
236the code.
237
238On the other hand, there's a bunch of crap in that blob that is for
239future plans, and is not doing anything now.
240
241In the end though, breaking it up into suitable bite sized bits might
242be almost as hard as writing it in the first place. I'll see what I
243can do, when I find some time. I did want to break it up into three
244bits anyway, and there's a TODO to untangle a couple of bits that are
245currently too tightly coupled.
246
247*/
248
249/* Robs contradiction
250
251On 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
272Which is most of an editor already, so how to break it up into bite
273sized 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
200struct key 294struct 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
985Seems to be sensitive to the number of lines. On my usual huge
986roxterm, using either toybox 0.4 or hg head, doing this -
987
988./toybox boxes -m less LICENSE -h 25
989
990and just hitting down arrow until you get to the bottom of the page
991segfaults as well. -h means "pretend the terminal is that many lines
992high", there's a similar -w as well. 80x25 in any other terminal did
993the same. For that particular file (17 lines long), any value of -h
994between 19 and 34 will segfault after some moving around. -h 35 makes
995it segfault straight away. Less than 19 or over 35 is fine. Longer
996files don't have that problem, though I suspect it will happen on
997shortish files where the number of lines is about the length of the
998screen.
999
1000I guess that somewhere I'm doing maths wrong and getting an out of
1001bounds line number when the file length is close to the screen length.
1002I'll make note of that, and fix it when I next get time to beat on
1003boxes.
1004
1005Thanks for reporting it Roy.
1006*/
1007
841int formatLine(view *view, char *input, char **output) 1008int 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;