about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 1617Kartik K. Agaram2015-06-217-43/+40
|
* 1616 - merging keyboard and events into 'console'Kartik K. Agaram2015-06-2110-346/+222
| | | | | Only core layers currently passing. Console apps are probably still broken.
* 1615Kartik K. Agaram2015-06-211-1/+1
|
* 1614Kartik K. Agaram2015-06-214-11/+3
|
* 1613 - edit: first event in event loopKartik K. Agaram2015-06-212-4/+63
| | | | No way to quit yet, though.
* 1612Kartik K. Agaram2015-06-201-0/+7
|
* 1611 - switch to keyboard+mouse eventsKartik K. Agaram2015-06-205-10/+42
|
* 1610Kartik K. Agaram2015-06-201-29/+82
| | | | Reorg.
* 1609Kartik K. Agaram2015-06-201-0/+2
|
* 1608Kartik K. Agaram2015-06-201-5/+0
|
* 1607Kartik K. Agaram2015-06-201-2/+2
|
* 1606Kartik K. Agaram2015-06-201-32/+43
| | | | Rip out keyboard for now, add notion of cursor.
* 1605Kartik K. Agaram2015-06-201-23/+43
| | | | | | | | | | | | | More editor experiments. a) I'm starting out with just a doubly linked list of characters as the editor data structure. Haven't actually started using it yet. b) Rather than provide a top-left-bottom-right bounding box up front, I think I want to allow the bounding box to flow indefinitely down given top, left and right. The old approach mimics traditional windowing systems, while the new one mimics html flowing; I want a single scrollbar for all my rendered elements within a single column.
* 1604Kartik K. Agaram2015-06-201-1/+2
|
* 1603Kartik K. Agaram2015-06-191-6/+15
|
* 1602Kartik K. Agaram2015-06-191-21/+31
| | | | | I forgot to check for nulls before writing prev pointers in doubly linked lists. Tests were accidentally passing.
* 1601Kartik K. Agaram2015-06-192-2/+25
|
* 1600Kartik K. Agaram2015-06-193-0/+7
|
* 1599Kartik K. Agaram2015-06-1912-63/+62
|
* 1598Kartik K. Agaram2015-06-193-5/+27
| | | | | Some tests weren't actually running for the past 5 days. Performed 5 why's.
* 1597 - port more helpers from arc versionKartik K. Agaram2015-06-194-1/+615
|
* 1595Kartik K. Agaram2015-06-181-1/+1
|
* 1594 - removing from start/end of duplex listKartik K. Agaram2015-06-181-4/+67
| | | | | | | | | | This uncovers an issue with this interface to duplex lists: the caller needs to check the result and invalidate any other pointers if it's null (i.e. the list is now empty) We *could* try to encapsulate the list in a header to help the caller manage header pointers. But heck, let's see if writing tests helps call-sites stay on the straight and narrow.
* 1593Kartik K. Agaram2015-06-182-1/+77
|
* 1592Kartik K. Agaram2015-06-181-0/+36
|
* 1591Kartik K. Agaram2015-06-182-3/+60
|
* 1590 - inserting into doubly linked listKartik K. Agaram2015-06-181-0/+62
|
* 1589 - doubly linked listKartik K. Agaram2015-06-181-0/+74
|
* 1588 - undo 1587Kartik K. Agaram2015-06-171-22/+1
|
* 1587 - experimental rendering of recipe namesKartik K. Agaram2015-06-171-1/+22
| | | | | But this is getting too complex too fast. Let's get a simple editor working first without color.
* 1586Kartik K. Agaram2015-06-172-2/+2
|
* 1585Kartik K. Agaram2015-06-1714-29/+29
|
* 1584Kartik K. Agaram2015-06-171-1/+1
|
* 1582Kartik K. Agaram2015-06-172-0/+46
|
* 1581Kartik K. Agaram2015-06-171-1/+1
|
* 1580Kartik K. Agaram2015-06-162-9/+12
|
* 1579Kartik K. Agaram2015-06-161-0/+11
|
* 1578 - editor inside 2-column layoutKartik K. Agaram2015-06-161-17/+67
|
* 1577 - vocabulary for drawing bordersKartik K. Agaram2015-06-161-24/+65
|
* 1576Kartik K. Agaram2015-06-161-0/+50
|
* 1575Kartik K. Agaram2015-06-161-0/+8
|
* 1573Kartik K. Agaram2015-06-165-3/+51
|
* 1572Kartik K. Agaram2015-06-162-4/+50
|
* 1571Kartik K. Agaram2015-06-161-2/+87
|
* 1570Kartik K. Agaram2015-06-161-1/+31
|
* 1569Kartik K. Agaram2015-06-162-3/+28
|
* 1568 - starting on editor widget in ernestKartik K. Agaram2015-06-161-123/+15
|
* 1566 - fake mouse clicks in scenariosKartik K. Agaram2015-06-155-1/+197
|
* 1565Kartik K. Agaram2015-06-142-32/+5
|
* 1564 - a better way to support string literalsKartik K. Agaram2015-06-144-7/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our new heuristic is: all string literals are the same. If they contain newline before non-whitespace, we scan for comments assuming there might be code inside: foofoofoo [ ... # ']' inside comment ignored ] If they contain non-whitespace first, then we ignore comments assuming it's just a regular string: foofoofoo [abc#def] # valid string literal The big hole in this approach: foofoofoo [ # what about comments here containing ']'? ... # abc ] Currently this reads as a 'code comment' and terminates before the newline or '?' and will probably trigger errors down the line. Temporary workaround: don't start code strings with a comment on the same line as the '['. Eventually we'll tighten up the logic. We're still not using the new heuristic in scenarios, but that's up next.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-23 04:28:33 +0000