| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
An empty stack is too rigorous a line to hold. Instead we'll just ensure
we leave the stack the way we found it.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
..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.
|
|
|
|
| |
We were missing functions in some larger programs.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Not my aesthetic choice, but essential at the moment for quickly
interpreting Lua errors.
|
|
|
|
| |
Introduced Nov 28. Let's see if my intermittent segfaults stop now.
|
| |
|
| |
|
|
|
|
| |
map(l, prn)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
Still sucks, though..
|
| |
|
| |
|
|
|
|
|
| |
Also start using 256 colors, under the assumption most people will have
them.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
I'd assumed that assume_default_colors updates fg/bg -1, but it doesn't.
Looks like I can't ever use -1 colors.
|
|
|
|
|
| |
Thanks to Mariano Guerra for the Nix command, and to Konrad Hinsen for
the Guix command.
|
|
|
|
|
|
|
| |
^/ 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
|
|
|
|
|
| |
Doesn't make sense to use '/' as a delimiter when we have hotkeys
involving '/'.
|
|
|
|
|
| |
For a variety of historical reasons, terminals pause every time you
press `Esc`. Let's get rid of that lag.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Also strip out a bunch of Lua's commandline parsing.
|
| |
|
|
|
|
| |
https://github.com/akkartik/teliva/issues/1
|