about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
...
* can again edit notes on changesKartik K. Agaram2021-12-111-4/+4
|
* .Kartik K. Agaram2021-12-111-0/+2
|
* delete an old file for comparisonKartik K. Agaram2021-12-111-120/+0
|
* handle non-existent fileKartik K. Agaram2021-12-111-1/+5
|
* bring back commandline argsKartik K. Agaram2021-12-111-1/+18
|
* snapshot: migrate all sample apps to new formatKartik K. Agaram2021-12-118-1215/+1027
|
* snapshot: writing working?Kartik K. Agaram2021-12-113-45/+112
| | | | | | This is a complete mess. I want to abstract reading multiline strings behind a function, but the lookahead requirements for that are quite stringent. What's a reasonable abstraction here?
* snapshot: key/value lines after multiline stringsKartik K. Agaram2021-12-112-29/+44
|
* snapshot: start reading a new formatKartik K. Agaram2021-12-114-27/+119
| | | | | | | | | | | | | | | I really wanted to avoid getting into defining or parsing new file formats. However, using the entire power of Lua is not ideal, as described earlier in Konrad Hinsen's bug. In addition to everything else, it's a vector for arbitrary code execution when someone loads an untrusted image. I could use JSON, but it requires ugly string escaping. Seems cleaner to just use YAML. But YAML is complex and needs its own dependencies. If I'm going to do my own, might as well make the multi-line string format really clear. I can't yet write the new format.
* clearer description of editing experienceKartik K. Agaram2021-12-104-4/+12
|
* commentKartik K. Agaram2021-12-081-0/+2
|
* minor colorscheme tweakKartik K. Agaram2021-12-081-1/+1
|
* display line numbersKartik K. Agaram2021-12-081-12/+29
| | | | | Not my aesthetic choice, but essential at the moment for quickly interpreting Lua errors.
* fix a use-after-freeKartik K. Agaram2021-12-081-2/+2
| | | | Introduced Nov 28. Let's see if my intermittent segfaults stop now.
* couple more primitives after Advent day 8Kartik K. Agaram2021-12-081-0/+22
|
* .Kartik K. Agaram2021-12-072-3/+3
|
* make it easy to print arrays:Kartik K. Agaram2021-12-071-0/+11
| | | | map(l, prn)
* new primitive: array appendKartik K. Agaram2021-12-071-3/+9
|
* new primitive: string splitKartik K. Agaram2021-12-071-0/+13
|
* cleanerKartik K. Agaram2021-12-071-2/+2
|
* slightly improve experience on Konrad Hinsen's bugKartik K. Agaram2021-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Steps to reproduce: * Run teliva with some app. * Press ctrl-e to edit the app. * Select some function. * Press ctrl-g and type in some Lua keyword like 'function' or 'while' (Since the first word in a function is often 'function', it becomes the default if you press ctrl-g immediately after entering the editor for a function.) * Type nothing. Run the app. Desired behavior: app continues to run. The definition for the keyword is silently ignored (in future we may want to provide an error message) Behavior before this commit: app silently exited with non-zero status, and refused to restart thereafter until the .tlv file was manually edited to delete the definition for the Lua keyword. Behavior after this commit: app throws an error message like these: * For `function`: ``` src/teliva: x.tlv:99: '(' expected near '=' sorry, you'll need to edit the image directly. press any key to exit. ``` * For `while`: ``` src/teliva: x.tlv:99: unexpected symbol near 'while' sorry, you'll need to edit the image directly. press any key to exit. ``` You still need to edit the .tlv file manually, but the steps for recovery are a bit more discoverable. To fix this properly I also need to fix a looming security hole I've been thinking about for some time. The long-term goal of Teliva is to put the human running apps in control of what they do, by sandboxing accesses to the file system, network and so on. However, even after we build gates on all of Lua's standard libraries, we're still parsing .tlv files as Lua, with all of its power available. Solution: load .tlv files as some sort of JSON-like subset of Lua. Maybe I should just use JSON, and rely on code that's already in Teliva, even if I'm introducing a new notation in the process.
* map/reduce/filter helpersKartik K. Agaram2021-12-061-0/+44
|
* fix colors in startup errorsKartik K. Agaram2021-12-061-0/+1
|
* slightly more obvious menu copyKartik K. Agaram2021-12-063-9/+44
| | | | Still sucks, though..
* improve backspace copyKartik K. Agaram2021-12-061-2/+2
|
* tweak solarized-esque schemeKartik K. Agaram2021-12-061-1/+1
|
* more configurable colorsKartik K. Agaram2021-12-067-33/+140
| | | | | Also start using 256 colors, under the assumption most people will have them.
* grey rather than harsh white backgroundKartik K. Agaram2021-12-042-6/+7
|
* clearer usage messageKartik K. Agaram2021-12-041-1/+1
|
* start showing call stack on errorsKartik K. Agaram2021-12-047-47/+69
| | | | | | | | It turns out Lua has been providing us this information all along! I'd just not created the space on screen to show it. Make it persist better. Kilo now no longer tracks its own status messages, which is a regression in a rare condition.
* another fix for colorsKartik K. Agaram2021-12-031-2/+2
| | | | | I'd assumed that assume_default_colors updates fg/bg -1, but it doesn't. Looks like I can't ever use -1 colors.
* elaborate a little more on install instructionsKartik K. Agaram2021-12-032-3/+29
| | | | | Thanks to Mariano Guerra for the Nix command, and to Konrad Hinsen for the Guix command.
* support the comment/uncomment hotkey on MacsKartik K. Agaram2021-12-032-2/+3
| | | | | | | ^/ works on Linux but not on Mac ^- emits the same character code on Mac ^_ seems to be the underlying character code, and works on both ctrl-7 also emits the same character code
* less ambiguous menusKartik K. Agaram2021-12-032-9/+9
| | | | | Doesn't make sense to use '/' as a delimiter when we have hotkeys involving '/'.
* get rid of `Esc` hotkeyKartik K. Agaram2021-12-033-10/+9
| | | | | For a variety of historical reasons, terminals pause every time you press `Esc`. Let's get rid of that lag.
* typosKartik K. Agaram2021-12-031-3/+3
|
* experimenting with different keysKartik K. Agaram2021-12-031-0/+2
| | | | | | | | | | | | | | On a Thinkpad X13, the `delete` key emits `^[[3~` outside of Teliva. Within Teliva, ncurses converts it to character code 330 (0x14a), which it fails to recognize as KEY_BACKSPACE. Why? My backspace is converted to character code 263, which ncurses does recognize as KEY_BACKSPACE. ctrl-h is character code 8. Both 330 and 263 are valid Unicode code points, which feels really ugly and ambiguous.
* stop showing frequent save messagesKartik K. Agaram2021-12-031-1/+1
|
* show ^h in a couple more menusKartik K. Agaram2021-12-031-0/+2
|
* improve support for backspaceKartik K. Agaram2021-12-034-19/+24
| | | | | | | I still don't understand the entire state space here, so I'm trying to err on the side of improving discoverability of the `ctrl-h` escape hatch. Without requiring too wide a window to show all hotkeys on the menu.
* error message when no app is providedKartik K. Agaram2021-12-031-194/+6
| | | | Also strip out a bunch of Lua's commandline parsing.
* .Kartik K. Agaram2021-12-031-2/+3
|
* describe the manual process to obtain a dark bgKartik K. Agaram2021-12-031-0/+8
| | | | https://github.com/akkartik/teliva/issues/1
* legible colors across all terminal configurationsKartik K. Agaram2021-12-031-1/+1
| | | | | | | | | | | | | So far I've been trying to make Teliva follow the default colorscheme of the terminal, but that easily ends up with illegible color combinations. New plan: always start with a light background within Teliva. People who want a dark background will currently need to mess with C sources. This should somewhat fix https://github.com/akkartik/teliva/issues/1. It's still not clear whether the default should be a dark or light background. While dark background is more common in terminals, I believe newcomers to terminals will prefer a light background. Then again, I'm biased since I use a light background in my terminals.
* show state of screen on runtime errorKartik K. Agaram2021-12-031-0/+7
| | | | This is essential when debugging.
* .Kartik K. Agaram2021-12-031-1/+1
|
* extract a helperKartik K. Agaram2021-12-031-18/+32
|
* more speculatively efficient advent.tlvKartik K. Agaram2021-12-021-6/+3
|
* fix a slight portability issue, maybeKartik K. Agaram2021-12-021-1/+1
| | | | | | | | When installing using NixOS[1], the screen looks wrong. It looks like attrset(A_NORMAL) does not undo color changes with some versions of dependencies. [1] https://github.com/marianoguerra/marianoguerra.github.io/blob/master/advent-of-future-of-code/days/day-02.md
* stop inserting ctrl- keys into programsKartik K. Agaram2021-11-301-4/+2
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-14 17:53:51 +0000