about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
...
* bugfix in rendering non-top zettelsKartik K. Agaram2022-02-081-1/+1
|
* Lua gotcha: iterating over strings yields stringsKartik K. Agaram2022-02-082-4/+4
|
* zet.tlv: expand editor to accomodate more textKartik K. Agaram2022-02-081-7/+12
| | | | | Still won't show up in view mode for now. Soon we'll be able to adjust zettel dimensions.
* typoKartik K. Agaram2022-02-081-1/+1
|
* zet.tlv: editing a single zettelKartik K. Agaram2022-02-081-7/+307
|
* gemini.tlv: consistent menuKartik K. Agaram2022-02-081-2/+2
|
* zet.tlv: clean up historyKartik K. Agaram2022-02-071-2590/+17
|
* move most Teliva menus to the rightKartik K. Agaram2022-02-072-6/+8
| | | | | | | | | | The problem I'm running into is that apps might want to perform their own editing. So I can't take up prime estate like the ctrl-e hotkey or a menu name of 'edit'. I'm still prioritizing rendering Teliva's edit and permissions menu. If the window is too narrow the app's settings will be overwritten and Teliva's hotkeys will be preferentially displayed. Seems safer.
* more Readme polishKartik K. Agaram2022-02-071-5/+8
|
* remove dropped functions from docsKartik K. Agaram2022-02-073-731/+5
|
* question raised during FOSDEM '22Kartik K. Agaram2022-02-071-0/+2
| | | | https://fosdem.org/2022/schedule/event/lastmilesandboxing
* lisp.tlv: clean up historyKartik K. Agaram2022-02-071-309/+26
| | | | Also a minor edit in doc:main.
* some more dead codeKartik K. Agaram2022-02-061-23/+0
|
* in fact, loadlib.c is all dead code nowKartik K. Agaram2022-02-062-299/+1
| | | | Now we can be sure apps can't call `require`.
* now all our supported platforms are POSIXKartik K. Agaram2022-02-062-14/+5
|
* drop all support for loading dynamic librariesKartik K. Agaram2022-02-062-338/+7
|
* drop module 'package'Kartik K. Agaram2022-02-064-49/+0
| | | | | | | Just like with `require`, we don't we don't know how to sandbox it. (Though we still have `require` because standard libraries outside apps need it. I need to make sure apps can't invoke `require`..)
* drop some more untested platformsKartik K. Agaram2022-02-061-16/+1
|
* drop USE_LINUX and similar definesKartik K. Agaram2022-02-062-15/+4
| | | | | How many levels of macros do we need. Also stop lying that we're using Linux in BSD.
* drop MinGWKartik K. Agaram2022-02-061-6/+1
| | | | | | | | I've never tested with it, and it is likely broken after all my changes to base Lua 5.1. Might as well be transparent about that. If you care about this platform, please let me know: http://akkartik.name/contact
* unused #defineKartik K. Agaram2022-02-061-1/+0
|
* more thoughts on sandboxingKartik K. Agaram2022-02-051-0/+8
|
* experimental app: zettelkastenKartik K. Agaram2022-02-041-0/+2963
| | | | | | | | | | | | | | | | | | | | 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.
* don't perturb cursor when drawing menuKartik K. Agaram2022-02-041-0/+3
|
* fix a couple of warningsKartik K. Agaram2022-02-031-0/+3
| | | | | It's not clear to me where my Linux gets strlcpy and strlcat from ¯\_(ツ)_/¯
* prose typos and editsKartik K. Agaram2022-02-031-3/+2
|
* fix a bug in kiloKartik K. Agaram2022-02-031-1/+1
| | | | Submitted upstream at https://github.com/antirez/kilo/pull/81.
* drop io.lines()Kartik K. Agaram2022-02-022-40/+5
| | | | | | | | | | | | | | | | | 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.
* tweak an entry in the audit logKartik K. Agaram2022-02-021-1/+1
|
* sandbox: no way to run arbitrary Lua code stringsKartik K. Agaram2022-02-021-96/+0
|
* include keys typed into audit logKartik K. Agaram2022-02-013-0/+18
| | | | | This will help people cross-correlate when the app performs specific calls.
* new potential threat vectorKartik K. Agaram2022-02-011-0/+3
|
* file permissions: decide based on calling functionKartik K. Agaram2022-02-014-15/+30
|
* copy realpath() from FreeBSD repoKartik K. Agaram2022-01-302-1/+245
| | | | | To sandbox apps robustly, we're going to need to always work with canonical absolute paths.
* try to get by with one feature macroKartik K. Agaram2022-01-295-11/+1
| | | | | | | | | | | | | | | | | 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
* new library: luafilesystem (lfs)Kartik K. Agaram2022-01-297-1/+1425
| | | | | | https://github.com/keplerproject/luafilesystem The new commander.tlv app demonstrates it working.
* fixup! redo lua vs proseKartik K. Agaram2022-01-291-15/+17
| | | | Forgot to include some hunks.
* more precise dependenciesKartik K. Agaram2022-01-291-2/+2
|
* incomplete lisp interpreter appKartik K. Agaram2022-01-272-0/+907
| | | | | 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.
* bugfix: editor was no longer saving anythingKartik K. Agaram2022-01-271-4/+2
| | | | | | 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).
* redo lua vs proseKartik K. Agaram2022-01-262-13/+19
| | | | | Previously we weren't dynamically selecting how to highlight a buffer after navigating with ctrl-g. That should work now.
* indentKartik K. Agaram2022-01-261-8/+8
|
* get Teliva working on FreeBSDKartik K. Agaram2022-01-262-3/+6
|
* rename the custom big picture view to doc:mainKartik K. Agaram2022-01-251-1/+2
|
* override big picture view with doc:bp if it existsKartik K. Agaram2022-01-251-2/+18
| | | | | | | | | | | 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.
* better default word at cursor for proseKartik K. Agaram2022-01-251-2/+2
|
* highlight [[wikiwords]] in proseKartik K. Agaram2022-01-251-24/+71
| | | | | These are just hints that there's something worth jumping to. The jumping still happens using ctrl-g.
* disable Lua colors in proseKartik K. Agaram2022-01-252-10/+54
|
* renameKartik K. Agaram2022-01-252-6/+6
|
* new section in big picture: prose (non-code)Kartik K. Agaram2022-01-251-4/+33
| | | | I've always found "Documentation" too pretentious.