Signal feed
Post
Remote status
Context
7@WandererUber if your going the vim route, you could go all the way and allow custom keybinds like <leader>a to attach an image instead of having to type the full command
@WandererUber re vim: i think most people make keybinds for commands they type a lot in vim. though it can be pretty specific to the individual in question.
re fedi client: are you making a tui client? if so, are you using a tui framework (iirc rust and go have some pretty well-liked ones)? depedning on how vim like you want it to be, you might also consider just having the client be a lua plugin for nvim. not sure if you actually get much lift from that though. also i imagine you meant two different commands, one for emojis and one for attached images... i suppose for the former, you could have completions kickin on typing : in insert mode like in nvim with cmp. for the latter it could be more like a normal mode command
@WandererUber thats a cool, if ambitious, project - best of luck with that. i wanna say ive seen a few others use terminal clients for fedi (probably p) but i doubt they supported anything besides text. as an aside, ive always wanted to try making a fork of bloatfe with mathjax support but its low on my project priority list
@WandererUber i assumed you would be using libcurl regardless since notcurses is a c library (though it has bindings for other languages so maybe not)... it might be worth doing a practice project on something simpler than fedi to get your frontend bearings.
i would use bloatfe more if it was on here the way pleromafe is. i have a local bloatfe that i run every now and then, but i want to do some other minor tweaks besides the math rendering before making that my primary fe. i also want to see how much i can get away with writing in go since i prefer that to javascript
Replies
6@WandererUber "how hard can it be" are famous last words that even i am guilty of lol. in your case, i think you just need to see the mastodon/pleroma api endpoints that the current frontends use hit them from your client - the harder/mroe tedious part is designing all the UI around that imo. in my case, im not gonna do a reimplementation, but i will probably have to bundle something like katex (which is faster than mathjax supposedly). the go stuff is more arpund things like filtering quoasts, serving htmx-style interactivity, etc. i dont really have a solid plan, just some rough ideas in my head.
@WandererUber re ui, idk about you but im not a design guy so i find that tedious. less so the actual implementation. i think pleromafe has a neutered tree-view but i dont use it much.
re katex, yeah that was my point. i like go but not enough to re-implement something like katex in it, so the js will have to be bundled. plus it will br something that happens client side for the mlst part... unless i pre-render server side somehow... maybe i could re-write it afterall (but not really)
re convenience features, on frontends like pleromafe and soapbox, i have to use some niggerlicious regex filters to drop quoasts, and i think id be able to do something cleaner programmatically so that the end result is similar to the hide-repoasts toggle (possibly on a per user basis). and yeah it will be pretty hard to avoid js entirely for the features i want, but i wanna limit it as much as possible
@WandererUber re bearings, one of my first big c ui projects was/is a jellyfin client in gtk, (still WIP) and i found a lot of value in some excursions with other smaller frontend-y projects that were simpler to reason about
We can't find the internet
Attempting to reconnect
Something went wrong!
Attempting to reconnect
