| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
I've been reluctant to do this until now because it makes it more
difficult to grant an app the ideal permissions. Here's what I use:
return string.find(filename, 'toot') == 1
But I'm also trying to keep people from looking to the app to figure out
what permissions to give it :/
|
| |
|
|
|
|
|
|
|
| |
Rather than invest LoC in asking for confirmation or an undo feature,
just have people restart to clear the page.
I fucking suck for how many ways I can come up with to lose data in a
text editor. It really should have been fucking obvious that clearing
the page so easily was a footgun just waiting to happen.
|
| |
|
|
|
| |
Now life.tlv and gemini.tlv are also minimizing how much of the standard
library they pull in, just to be easy to read.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The ordering is topological; nodes come before their dependencies.
Also some more helpful functions in the template for new apps.
|
| |
|
|
|
| |
In particular, I merged take_out in anagrams.tlv with all_but in
graphviz.
|
| |
|
|
|
| |
Now the REPL isn't about deciding what to calculate, but just what nodes
to calculate it for.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Joint work with Sumeet Agarwal. In the process we discovered several
bugs in our fake window helpers for tests. Thanks Sumeet!
Previous prototypes:
- https://archive.org/details/akkartik-2min-2020-12-06
- https://merveilles.town/@akkartik/105759816342173743
|
| | |
|
| |
|
|
|
|
| |
Perhaps this is a bad idea. It feels arbitrary, what methods Lua happens
to include in string and table objects without having to go through the
respective modules.
|
| |
|
|
|
|
| |
They may take more or less from it (sieve.tlv in particular takes
nothing since call depth doesn't help at all there), but what they take
is in the right order so that you can compare across apps.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Tasteful apps should only perform side-effects through 'window'
arguments rather than the 'curses' module directly. It's ok however to
read constants like curses.A_NORMAL or curses.stdscr().
There are some limitations, unfortunately. Ncurses wasn't designed with
testability in mind. For example, there's no way to curs_set or
assume_default_colors without the 'curses' module. Oh well.
|
| |
|
|
|
|
| |
This is for what the app does, as opposed to 'doc:main', which is also
intended to include commentary about the internal organization of the
app.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This opens up a whole new can of worms: Teliva's ability to show clear
error messages hinges on apps having decent error handling.
I suppose that's ok. A new app someone downloads that throws out strange
error messages and puts them in the equivalent of the console doesn't
exactly engender trust. It's reasonable to treat poor error handling as
breakage.
Here's my running list of open questions from working on the permissions
screen so far:
- how to teach people to care about the difference between:
- permissions known to be unsafe
- permissions unknown to be safe
- how to show syntax errors in the permissions screen
- how to detect syntax errors in the permissions screen (lots of stuff
only shows up when running)
- how to deal with apps with poor error handling (this commit; punt for now)
- how to engender skepticism in people towards what apps tell them
("oh, just go into the permissions screen and type ___ to fix this error")
- how to help people judge the quality of their permissions
(mode == 'r' vs mode ~= 'w')
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
| |
..before a change in approach.
|
| | |
|
| |
|
|
| |
I can't believe I didn't notice this until now.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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".
|
| | |
|
| | |
|
| |
|
|
|
| |
Lua has some Javascript-esque gotchas here. Too quick to coerce between
types.
|
| | |
|
| | |
|
|
|
Follows https://github.com/akkartik/wart, https://github.com/akkartik/mu0,
https://github.com/akkartik/mu1 and https://github.com/akkartik/mu.
|