about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
...
* toot-toot: a few more testsKartik K. Agaram2021-12-221-1/+16
| | | | ..before a change in approach.
* .Kartik K. Agaram2021-12-221-29/+19
|
* more precise control over menu orderKartik K. Agaram2021-12-226-12/+26
| | | | I can't believe I didn't notice this until now.
* gemini: back buttonKartik K. Agaram2021-12-221-0/+8
|
* .Kartik K. Agaram2021-12-221-1/+1
|
* .Kartik K. Agaram2021-12-221-8/+4
|
* fix arrow keys in big picture view on MacKartik K. Agaram2021-12-211-5/+5
| | | | Turns out arrow keys are considered `isprint()` on Mac.
* gemini: linksKartik K. Agaram2021-12-211-19/+101
|
* bugfix: ensure definition to edit has some nameKartik K. Agaram2021-12-211-4/+6
|
* less confusing nameKartik K. Agaram2021-12-212-12/+10
|
* arrow keys in big picture viewKartik K. Agaram2021-12-212-12/+105
|
* gemini: echo urls while typing inKartik K. Agaram2021-12-211-0/+3
| | | | Let's see how much we need to tweak this solution.
* gemini: slightly cleaner rendering of owner inputKartik K. Agaram2021-12-211-0/+7
| | | | | | | This still only works if I remove the call to `refresh()` inside `Wgetch()`. With that call no keystrokes are displayed. Looks like ncurses doesn't include user input when refreshing the window. Unclear if there's an easy way to support that while keeping the menu visible.
* nail down trusted Teliva channels a little moreKartik K. Agaram2021-12-219-14/+16
| | | | | | | | | | | | | | | | | | | | | | In each session, Teliva has to bootstrap a trusted channel with the computer owner while running arbitrarily untrusted code. So let's get really, really precise about what the trusted channel consists of: - the bottom-most row of screen containing the menu - the keystrokes the owner types in - ncurses COLOR_PAIR slots 254 (menu) and 255 (error) One reason the menu colors are important: we don't want people to get used to apps that hide the menu colors by setting default foreground/background to invisible and then drawing their own menu one row up. The error COLOR_PAIR I don't see any reason to carve out right now, but it seems like a good idea for Teliva the framework to not get into the habit of apps doing some things for it. I'm not sure how realistic all this is (I feel quite ill-equipped to think about security), but it seems worthwhile to err on the side of paranoia. Teliva will be paranoid so people don't have to be.
* keep Teliva apps from pretending to be TelivaKartik K. Agaram2021-12-212-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kind of a subtle idea. Teliva the framework is intended to be trustworthy software that people install on their computers. The apps people run using Teliva may be less trustworthy. The whole point of Teliva is to provide a sandbox for running code before you trust it. One way (of many) apps can be malicious is by subtly getting between what people see and reality. Imagine, for example, an app that draws a fake menu bar and offers a different hotkey to edit source code. When someone presses that hotkey they think they're using the standard Teliva editor but they're really using an editor within the app, which the app uses to hide its most malicious bits from view. Down the road Teliva will have more bits of UI, such as for asking for permission to read sensitive data. It's important that people understand what they're granting permission to, that apps can't tamper with the communications channel between them and Teliva. This is likely just one of many ways for an app to break out of its sandbox. Teliva isn't sandboxed yet. I'm just taking my first steps on this journey. In particular, there are other mechanisms for asking for user input besides `getch()`. I don't yet have a big-picture view of the Teliva sandbox. It seems clear that I need to educate people on the difference between different parts of screen. Depending on the app you install, most of the screen may be a dark forest. It'll be important to know where the safe path is, where you can speak to trusted advisors while in the forest.
* minor tweaksKartik K. Agaram2021-12-213-22/+3
|
* gemini: ctrl-g to open a new pageKartik K. Agaram2021-12-211-67/+115
|
* start of a gemini browserKartik K. Agaram2021-12-201-0/+357
|
* fix stale readmeKartik K. Agaram2021-12-201-4/+3
|
* document dbgKartik K. Agaram2021-12-182-0/+4
|
* toot-toot: save prose somewhereKartik K. Agaram2021-12-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is still quite klunky. Don't expect toot-toot to be a complete text editor. In particular, it'll happily lose toot data if you try to edit the app while editing a toot. Teliva is paranoid about avoiding data loss, but toot-toot.tlv is not. Mostly I just want toot-toot to interact with the clipboard. The only reason save exists is that copying directly from within the app inserts spurious line breaks. So now I'm saving to file, then `cat`ing file, then copying each toot out. I initially tried to use ctrl-s for the save hotkey, but that conflicts with terminal flow-control, and it's not obvious how ncurses manages IXON. And I don't want to go around ncurses and do something that's very likely to be unportable. Even ctrl-w, I worry that there are terminals out there that will close tab or something stupid like that. Feature wish list: - a hook to execute after exit. Just calling os.exit() doesn't work because the screen still clears any final prints when Teliva exits. Not sure how to handle this. Ncurses doesn't seem to have anything beyond endwin() for cleaning up after itself. - a hook to execute before exit, for things like asking for confirmation/save - a place for 'flash' notification messages, like that the file was saved
* pay more attention to where we display the cursorKartik K. Agaram2021-12-183-1/+4
| | | | | It's still just in app control; I'm resisting the urge to introduce "smarts".
* streamline an app; pull useful stuff into templateKartik K. Agaram2021-12-182-8813/+87
|
* drop ASan from MakefileKartik K. Agaram2021-12-181-2/+2
| | | | | Accidentally added at some point. It's a useful debugging aide, but I don't want to require the additional dependencies on a first run.
* mention programming framework in ReadmeKartik K. Agaram2021-12-181-0/+6
|
* ctrl-u: clear proseKartik K. Agaram2021-12-172-2/+98
|
* bug: handle digits in proseKartik K. Agaram2021-12-171-4/+686
| | | | | Lua has some Javascript-esque gotchas here. Too quick to coerce between types.
* clean up cursor_upKartik K. Agaram2021-12-171-4/+29
|
* two implementations of cursor_upKartik K. Agaram2021-12-171-0/+1830
|
* better copy on test failuresKartik K. Agaram2021-12-171-1/+4
|
* correct count of test failuresKartik K. Agaram2021-12-171-1/+1
|
* keep tests from messing up big pictureKartik K. Agaram2021-12-171-0/+19
|
* one more protection against Lua stack leakKartik K. Agaram2021-12-171-6/+6
|
* experimental support for test errorsKartik K. Agaram2021-12-171-3/+8
|
* start of a test frameworkKartik K. Agaram2021-12-172-0/+6633
| | | | | Follows https://github.com/akkartik/wart, https://github.com/akkartik/mu0, https://github.com/akkartik/mu1 and https://github.com/akkartik/mu.
* yet another stab at reorganizing stack assertionsKartik K. Agaram2021-12-171-9/+14
|
* .Kartik K. Agaram2021-12-171-0/+3
|
* .Kartik K. Agaram2021-12-171-4/+4
|
* more protection against data lossKartik K. Agaram2021-12-172-3/+13
|
* .Kartik K. Agaram2021-12-171-13/+0
|
* protect against data loss in some rare situationsKartik K. Agaram2021-12-161-3/+32
| | | | | | | | | | | Examples: - you try to write file but disk is full - you have two Teliva files being edited at the same time Both are situations where it's impossible to avoid some data loss. However, we should now at least have some valid state of the .tlv file saved to disk where we'd previously end up with a zero-size file or garbage.
* fix another leak in the Lua stackKartik K. Agaram2021-12-161-2/+9
| | | | | This fixes a segfault when scanning through a long history of recent changes (say > 20 changes)
* more consistently show notes in recent changesKartik K. Agaram2021-12-161-1/+5
| | | | | | | | | Teliva emits timestamps in multi-line format end in a newline. As a result, notes get rendered on the next line and are then immediately overwritten by the contents of the definition. This bug was masked by my hacky 'original' timestamps which don't use multi-line format.
* stop leaking on the Lua stack, reduxKartik K. Agaram2021-12-162-11/+26
| | | | | An empty stack is too rigorous a line to hold. Instead we'll just ensure we leave the stack the way we found it.
* Revert "stop leaking on the Lua stack"Kartik K. Agaram2021-12-162-3/+2
| | | | | | | This reverts commit 7c1b9d0b91295323b5ed5ec3e09b46566288bc75. The 'big hammer' isn't good enough. The recent changes view seems to need state on the stack across invocations of the editor.
* expand Teliva's "standard library"Kartik K. Agaram2021-12-161-0/+96
| | | | | | | | Lua is often not very functional. Available primitives often mutate data destructively rather than create new values. Perhaps I shouldn't be trying to go against the grain. We'll see. The above changes are based on using Teliva intensively for 2 weeks of Advent of Code 2021. But that isn't quite the ideal use case for Teliva.
* .Kartik K. Agaram2021-12-161-2/+2
|
* stop leaking on the Lua stackKartik K. Agaram2021-12-162-2/+3
| | | | | ..even if at the expense of leaking on the heap. Because the Lua stack has very limited space (~20 slots). When it overflows, we segfault.
* show all functions in big pictureKartik K. Agaram2021-12-131-2/+6
| | | | We were missing functions in some larger programs.
* tweak Hanoi colors yet againKartik K. Agaram2021-12-133-1/+1
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-14 07:30:54 +0000