| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://merveilles.town/@akkartik/107742821323590471
What we have so far:
a representation (see 'zettels')
parent/child
next/prev sibling
(todo: misc cross-links)
ability to render zettels in multiple columns based on 'view_settings'
all zettels render with same size
alternate backgrounds between zettels for legibility
skip rendering duplicates (if we ever hit cycles)
a highlighted 'current zettel'
ability to move current zettel
by screen location (arrow keys)
by network structure (h/j/k/l)
Still can't edit zettels or load/save from/to disk.
|
| | |
|
| |
|
|
|
| |
It's not clear to me where my Linux gets strlcpy and strlcat from
¯\_(ツ)_/¯
|
| | |
|
| |
|
|
| |
Submitted upstream at https://github.com/antirez/kilo/pull/81.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'd already dropped the variant without a filename. But even the variant
with a filename is very easy to use in a way that is confusing to use in
the presence of sandboxing:
* call io.lines()
* Sandboxing saves an error, io.lines() returns nil
* Caller (usually a loop) raises an error.
* We show the error and not the sandboxing failure.
* Worse, there's no way to adjust permissions from within Teliva,
because we can't ever get to that menu while there's an error.
Best solution I can come up with: encourage a separate step for
translating filename to file handle. That way it's more obvious that we
need to check for errors.
|
| | |
|
| | |
|
| |
|
|
|
| |
This will help people cross-correlate when the app performs specific
calls.
|
| | |
|
| | |
|
| |
|
|
|
| |
To sandbox apps robustly, we're going to need to always work with
canonical absolute paths.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
https://github.com/keplerproject/luafilesystem
The new commander.tlv app demonstrates it working.
|
| |
|
|
| |
Forgot to include some hunks.
|
| | |
|
| |
|
|
|
| |
I'm not sure what I'm doing here just yet. This is just an experiment of
the editing experience. The .tlv app doesn't actually do anything yet.
|
| |
|
|
|
|
| |
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.
|
| | |
|