| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|