| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
| |
I made the changes reverted here out of a mistaken sense that
big-picture edits would interfere with Teliva's memory of what is
currently being edited (teliva_editor_state).
|
| |
|
|
|
| |
Previously we weren't dynamically selecting how to highlight a buffer
after navigating with ctrl-g. That should work now.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Going to big picture from doc:bp still goes to the default
auto-generated big picture view.
While doc:bp provides some programmability, it's also far klunkier than
the default view. Rendering is worse, and it's always in edit mode
because I'm trying to avoid complicating the UX with a notion of
rendered markup. That means cursor movement is less convenient. It's
also easy to accidentally edit the big-picture view.
|
| | |
|
| |
|
|
|
| |
These are just hints that there's something worth jumping to. The
jumping still happens using ctrl-g.
|
| | |
|
| | |
|
| |
|
|
| |
I've always found "Documentation" too pretentious.
|
| |
|
|
| |
This is long overdue.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
First step: when a "definition" starts with "doc:" it's not a
definition, just a buffer. Stop trying to interpret it as Lua.
|
| | |
|
| |
|
|
| |
http://gnats.netbsd.org/56664 reported.
|
| |
|
|
|
|
|
|
| |
NetBSD still uses curses by default. One _could_ install ncurses, but I
don't have access to a NetBSD box with permissions to install ncurses,
so I'm experimenting to see how far we can get with just curses. So far
most of the apps seem to work, with the exception of one bug that I'll
commit next.
|
| |
|
|
|
| |
I'm kinda sorta able to get lcurses running on NetBSD 9.2 without this
particular hack.
|
| | |
|
| | |
|
| |
|
|
| |
We still only have OpenBSD working.
|
| |
|
|
|
|
|
| |
Basic procedure:
- save/restore `menu` around call of a function (directly or
indirectly called by `update`) that encapsulates some state change
- override `menu` inside the function to correspond to its update loop
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This implies it must be side-effect free. We still need to figure out
how to convey that to the computer owner.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
No way to select between them. That complicates the UI too much when we
do so much with the cursor. But it's still useful to suggest things to
type in after ctrl-g.
|
| |
|
|
|
| |
I think this is significantly slowing things down. Perhaps we should
sample or something.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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')
|
| | |
|
| |
|
|
|
|
|
| |
Still highly non-ideal. Lua is a dynamic language, and has low ability
to detect syntax errors within functions.
Perhaps I should run a test call after every edit.
|
| |
|
|
| |
I believe kilo kinda naturally enforces that. We'll see.
|
| | |
|
| | |
|
| | |
|