about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* slack: start rendering unicodeKartik K. Agaram2021-08-301-24/+25
|
* .Kartik Agaram2021-08-3061-6942/+16397
|
* .Kartik K. Agaram2021-08-302-5/+5
| | | | Open question fixed.
* first rendering of non-latin scriptKartik K. Agaram2021-08-302-2/+127
| | | | | Open question: why does column 0 get cropped? The spacing also seems excessive. Are we taking up 3 grid points?
* .Kartik K. Agaram2021-08-301-1/+63
|
* fix bad terminology: grapheme -> code pointKartik K. Agaram2021-08-2915-193/+210
| | | | | | | | | | Unix text-mode terminals transparently support utf-8 these days, and so I treat utf-8 sequences (which I call graphemes in Mu) as fundamental. I then blindly carried over this state of affairs to bare-metal Mu, where it makes no sense. If you don't have a terminal handling font-rendering for you, fonts are most often indexed by code points and not utf-8 sequences.
* .Kartik K. Agaram2021-08-292-8/+8
|
* .Kartik K. Agaram2021-08-293-8/+12
|
* load Font in a non-contiguous area of memoryKartik K. Agaram2021-08-295-13/+44
|
* .Kartik K. Agaram2021-08-2913-26/+3
|
* .Kartik K. Agaram2021-08-291-1/+1
|
* .Kartik K. Agaram2021-08-291-3/+3
|
* improve translation scriptsKartik K. Agaram2021-08-292-8/+38
|
* .Kartik K. Agaram2021-08-291-2217/+2217
|
* inline SubX translationKartik K. Agaram2021-08-294-132/+98
| | | | | We can't really translate purely SubX code anyway at the top-level. Stop exposing those scripts.
* retreat to 640KBKartik K. Agaram2021-08-293-17/+5
|
* build still brokenKartik K. Agaram2021-08-293-2/+30
| | | | | Now we load all the code, but it overwrites the extended BIOS area. 640KB is no longer enough. Need to rethink loading strategy.
* import a few more unicode blocks from UnifontKartik K. Agaram2021-08-292-6/+8527
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | shell/ is currently broken; we've overflowed available contiguous space for code. Block names based on https://www.compart.com/en/unicode/block: 0x0000 - 0x007f Basic Latin 128 0x0080 - 0x00ff Latin-1 Supplement 128 0x0100 - 0x017f Latin Extended-A 128 0x0180 - 0x024f Latin Extended-B 208 0x0250 - 0x02af IPA Extensions 96 0x02b0 - 0x02ff Spacing Modifier Letters 80 0x0300 - 0x036f Combining Diacritical Marks 112 0x0370 - 0x03ff Greek and Coptic 135 0x0400 - 0x04ff Cyrillic 256 0x0500 - 0x052f Cyrillic Supplement 48 0x0530 - 0x058f Armenian 91 0x0590 - 0x05ff Hebrew 88 0x0600 - 0x06ff Arabic 255 0x0700 - 0x074f Syriac 77 0x0750 - 0x077f Arabic Supplement 48 0x0780 - 0x07bf Thaana 50 0x07c0 - 0x07ff NKo 62 0x0800 - 0x083f Samaritan 61 0x0840 - 0x085f Mandaic 29 0x0860 - 0x086f Syriac Supplement 11 0x08a0 - 0x08ff Arabic Extended-A 84 0x0900 - 0x097f Devanagari 128 0x0980 - 0x09ff Bengali 96 0x0a00 - 0x0a7f Gurmukhi 80 0x0a80 - 0x0aff Gujarati 91 0x0b00 - 0x0b7f Oriya 91 0x0b80 - 0x0bff Tamil 72 0x0c00 - 0x0c7f Telugu 98 0x0c80 - 0x0cff Kannada 89 0x0d00 - 0x0d7f Malayalam 118 0x0d80 - 0x0dff Sinhala 91 0x0e00 - 0x0e7f Thai 87 0x0e80 - 0x0eff Lao 82 0x0f00 - 0x0fff Tibetan 211 0x1000 - 0x109f Myanmar 160 0x10a0 - 0x10ff Georgian 88 But don't trust the block sizes above. Thanks to gdb[1] for this helper: define z print 2 * (0x$arg1 - 0x$arg0 + 1) end e.g: (gdb) z 10a0 10ff 192 [1] https://sourceware.org/gdb/current/onlinedocs/gdb/Define.html
* render wide glyphs in the fontKartik K. Agaram2021-08-292-5/+36
|
* bugfix in commit 8e182e394Kartik K. Agaram2021-08-291-1/+3
| | | | | Any command in shell that rendered the screen resulted in an infinite loop. But it took me forever to even realize it was an infinite loop.
* .Kartik K. Agaram2021-08-291-28/+50
|
* .Kartik K. Agaram2021-08-291-8/+7
|
* .Kartik K. Agaram2021-08-291-3/+3
|
* .Kartik K. Agaram2021-08-291-1/+2
|
* width-aware drawing primitivesKartik K. Agaram2021-08-296-52/+215
| | | | No support yet for drawing wide graphemes.
* .Kartik K. Agaram2021-08-286-29/+21
|
* .Kartik K. Agaram2021-08-281-59/+44
|
* support unused screen-cells in fake screensKartik K. Agaram2021-08-282-0/+31
| | | | | | We'll need this when rendering 16-bit glyphs. They'll occupy two 8x16 display units on screen, but the grapheme is a single unit as far as fake screens are concerned.
* .Kartik K. Agaram2021-08-281-179/+187
|
* .Kartik K. Agaram2021-08-284-80/+80
| | | | Convert some old code to current idioms.
* font data structure now supports 16-bit glyphsKartik K. Agaram2021-08-283-138/+266
| | | | We can't yet render the latter 8 bits.
* reorganize font before adding non-ASCIIKartik K. Agaram2021-08-274-240/+240
|
* compute-offset: literal indexKartik K. Agaram2021-08-253-5/+132
|
* .Kartik K. Agaram2021-08-251-6/+6
|
* another long-overdue bugfixKartik K. Agaram2021-08-222-3/+87
| | | | | | | If I forgot a 'var', Mu would interpret the ':' in the var declaration as a named block, and all parsing after would be thrown off. Perhaps I should use separate characters for defining blocks vs vars.
* fix a long-standing bug in Mu's translatorKartik K. Agaram2021-08-222-0/+47
| | | | | | | | | | | | | | | | While all test pass, this change is disquieting. When I first designed Mu I deliberately chose to exclude literal strings from most primitive instructions both for type-checking and to avoid silently passing through strange constructions. Nobody really needs to add a string to a number, and am I sure no SubX instruction will cause a memory safety issue when passed a string literal instead of a number? But clearly I have no tests encoding this desire. And any string literal could be replaced by an integer literal containing the exact same value, so what are we protecting against anyway. Let me fix the bug for now. If I run into problems I'll come back and do this right.
* start throwing error on labels too far for /disp8Kartik K. Agaram2021-08-222-0/+70
| | | | | | | | | | | | | | | | | | | | | While I'm doing this I might as well lay out a story I don't seem to have told before in this commit log. I translated Mu programs to Linux before I did so to bare metal like I do in the top-level these days. The translator programs still run from the linux/ directory. However they don't always have good error messages. As long as I was translating to Linux this wasn't a huge deal because I always translated Mu programs using the bootstrap translator in linux/bootstrap/ -- which has great error messages. However, linux/bootstrap/ can't build bare-metal programs because boot.subx uses real-mode instructions that aren't supported. As a hack I created a script called misc_checks that at least tries to run everything besides boot.subx -- even though translation can never succeed. If I run it and get to errors about unknown variables I know everything besides boot.subx raised no errors. Having labels too far in /disp8 args is is the single biggest reason we need the misc_checks hack. Hopefully it's now obsolete.
* .Kartik K. Agaram2021-08-222-3/+4
|
* start throwing error on duplicate labelKartik K. Agaram2021-08-2224-76/+385
| | | | | | | | | | One less error that's only in the bootstrap phase. On the other hand, for simplicity I got rid of the ability to override the Entry label. One less special case, but we're also going further from the ability to run subsets of layers. We haven't really been exercising it for a long time, though (commit 7842, March 2021 when we made baremetal the default).
* .Kartik K. Agaram2021-08-222-16/+12
|
* .Kartik Agaram2021-08-1594-14489/+19517
|
* move gap buffer code to top-levelKartik K. Agaram2021-08-154-2026/+0
| | | | Now that it's been used in a second app without needing any changes.
* minimize repaints when navigating between channelsKartik K. Agaram2021-08-151-0/+13
|
* .Kartik K. Agaram2021-08-151-1/+1
|
* correct menu when first entering search modeKartik K. Agaram2021-08-151-0/+7
| | | | Test required.
* .Kartik K. Agaram2021-08-151-15/+12
| | | | Make it more obvious that we always do a full repaint if dirty is set.
* keep cursor stable when switching to thread viewKartik K. Agaram2021-08-151-8/+37
| | | | Test required.
* missing code: selecting a thread in channel viewKartik K. Agaram2021-08-151-3/+11
| | | | Test required. And a clean fixture.
* no, we can't just sort lines in the slack archiveKartik K. Agaram2021-08-141-9/+12
| | | | | Comments contain indices back to the parent. Reordering items completely messes up the indices.
* slack: navigation for thread screensKartik K. Agaram2021-08-141-0/+123
|