| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Was printing over passing tests for some reason.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
I think this may be all the tests. Now to make them pass..
|
| | |
|
| |
|
|
| |
I actually got all tests to pass on the first try.
|
| |
|
|
|
| |
This isn't the ideal implementation either. Pure spaghetti. But I need
to clean up the debug prints to see that.
|
| |
|
|
|
|
|
| |
I want to support cursor movement across wrapped lines, and the old
implementation doesn't seem on the right track for that.
Interesting that this required me to add the new symmetric test.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I should have documented that I'd never actually seen that code path
trigger before. Here's a minimal test that did it just now:
function test_foo()
return a+1
end
E2: [string "test_foo"]:2: attempt to perform arithmetic on global 'a' (a nil value)
A simple missing variable doesn't do it since it just evaluates to nil.
Without this commit, the above test was silently continuing to the main
app after failing tests.
|
| |
|
|
| |
..before a change in approach.
|
| | |
|
| |
|
|
| |
I can't believe I didn't notice this until now.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Turns out arrow keys are considered `isprint()` on Mac.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Let's see how much we need to tweak this solution.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
It's still just in app control; I'm resisting the urge to introduce
"smarts".
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
Lua has some Javascript-esque gotchas here. Too quick to coerce between
types.
|
| | |
|
| | |
|
| | |
|
| | |
|