| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
This will help people cross-correlate when the app performs specific
calls.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I fucking hate feature macros. Egregious discharge of our
division-of-labor-obsessed society. People should be able to introduce
names. People should be able to give up names to lower levels of
abstraction when they encounter conflicts.
Feature macros seem to exist[1] to support more than two levels of
abstraction. You try to build, one of your libraries fails to build
because of a conflict between it and one level down. You don't want to
modify this library. Just fucking https://catern.com/change_code.html
already. But no, I have to litter my code with feature macros even
though I just want the abstraction the original library provides.
[1] https://man7.org/linux/man-pages/man7/feature_test_macros.7.html
https://lwn.net/Articles/590381
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
I believe kilo kinda naturally enforces that. We'll see.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extremely cruddy implementation:
- I'm still unclear on how to represent the advice function:
- How to handle errors when loading user configuration?
Currently I refuse to start.
- Whole function? More errors to handle in header and so on. What if
the function is renamed?
- Just body? Needs more structured editing support.
- Lots of duplication, particularly between the permissions in the menu
and the permissions screen.
I don't know how to show the hostname at the time of connect() or
bind(), so networking is going to remain a boolean for now. It's also
unclear what effective constraints we can impose on what gets discussed
with a specific hostname. Everything outside the computer is out of
one's control.
One trick I learned is for consistently grabbing ASan logs on abort:
It's always safe to redirect stderr with ncurses!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Zero guarantees of compatibility at this point.
|
| | |
|
| |
|
|
|
|
|
| |
In the process we now also have a mechanism for Teliva to overlay errors
while apps run. Might make sense to make that available to apps as well.
But I'm starting to realize that any app access to the Teliva areas of
the screen is fraught with risk.
|
| |
|
|
|
|
|
| |
Our sandboxing model is a blunt caricature, just two booleans. But let's
see how far this gets us.
Still doesn't persist, and definitely has no effect.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Current plan:
- two booleans to gate file and network access, respectively
- false shows as green, true shows as orange
- if _both_ booleans are true, then both show as red to indicate that
there are no protections.
|
| |
|
|
|
|
|
|
| |
It looks like attron doesn't actually enable colors near 256, even
though https://linux.die.net/man/3/attron suggests it does.
> COLOR_PAIR values can only be OR'd with attributes if the pair
> number is less than 256.
|
|
|
It should now be easier to diff against the Lua 5.1 sources upstream.
|