CalebJohn

Looks like they are working on multi-finger swipe for the keyboard, the library seems to support it [0].

> The library also supports recognizing two-finger simultaneous swipe input through the SwipeEngine::recognize_multi method.

[0]: https://gitlab.futo.org/keyboard/swipe-library#inputs

If I'm understanding the problem correctly, this should be solved by pnpm [1]. It stores packages in a global cache, and hardlinks to the local node_packages. So running install in a new worktree should be instant.

[1]: https://pnpm.io/motivation

With that feature the external editor is launched via Joplin, so the editing is still happening in the ecosystem. You can’t just open the notes from outside Joplin.

He mentions input latency[1] as one of 4 aspects of being fast that were considered during development. I’m not aware of how that was tested, but would trust that it outperforms Iterm2 in that regard.

[1] https://www.youtube.com/watch?v=cPaGkEesw20&t=3015s

I should have been more clear in my original comment.

I don't think that the conflict detection/resolution needs to live inside the CRDT data structure. Ultimately you might want to bake it in out of convenience, but it should be possible to handle separately (of course the resolution will ultimately need to be written to the CRDT, but this can be a regular edit).

Keeping the conflict resolution in the application layer allows for CRDT libraries that don't need to be aware of human-in-the-loop conflicts, and can serve a wider range of downstream needs. For example, a note app and a version control system might both be plain text, but conflict resolution needs to be handled completely differently. Another example would be collaborative offline vs. online use cases, as noted above, they are very different use cases.

> Algorithmically, this is an interesting problem but it should be quite solvable. Just, for some reason, nobody has worked on this yet. So, thanks for writing this post and bringing more attention to this problem!

I'm skeptical that an algorithmic solution will be possible, but I can see this being handled in a UX layer built on top. For example, a client could detect that there's been a conflict based on the editing traces, and show a conflict resolution dialog that makes a new edit based on the resolution. The tricky part is marking a conflict as resolved. I suspect it could be as simple as adding a field to the crdt, but maybe then it counts as an algorithmic solution?

[1] https://josephg.com/blog/crdts-go-brrr/

I used an 8-bit PIC micro a couple years ago for power applications (think non-IoT lighting). The specific microcontroller we used had nice peripherals for sensing, and controlling diodes, but no FPU. I remember looking into getting something external to handle the PID, but the cost and board layout constraints made it challenging.

They have a solution for that, a session link. They pass a token through a query parameter that validates to your account. You set that as the default search engine for each browser, no need to repeatedly sign in.

https://kagi.com/search?token=<some-token>

I think this is the post you're referring to.

https://tailscale.com/blog/more-throughput/

Kagi uses multiple search APIs (including their own) and implements their own ranking and mixing of results. Basically you get the same results with spam removed, with some truly unique results from the in-house engine.

It is, the QR code spec details a few specific masks that are available. The one which produces the best QR code is chosen (best in this case means most clear/easiest for a scanner to read. So, no large blocks of white or black).

Wikipedia has a pretty good visual of this. https://en.m.wikipedia.org/wiki/QR_code#Encoding

They plan to integrate Firefox Sync with Thunderbird (android and desktop)[1]

[1]: https://developer.thunderbird.net/planning/roadmap#firefox-s...

I use the below to get that behavior when working with txt files.

    autocmd BufNewFile,BufReadPost *.txt noremap  <buffer> <silent> k gk
    autocmd BufNewFile,BufReadPost *.txt noremap  <buffer> <silent> j gj
    autocmd BufNewFile,BufReadPost *.txt noremap  <buffer> <silent> 0 g0
    autocmd BufNewFile,BufReadPost *.txt noremap  <buffer> <silent> $ g$

If you want this for all filetypes, just remove everything before "noremap".

    noremap  <buffer> <silent> k gk
    noremap  <buffer> <silent> j gj
    noremap  <buffer> <silent> 0 g0
    noremap  <buffer> <silent> $ g$

Not the whitepaper, but here's some resources that I saved for myself to read that might be helpful.

https://www.freelists.org/post/luajit/How-does-LuaJITs-trace...

http://lua-users.org/lists/lua-l/2011-02/msg00742.html

Out of curiosity I ran the same test on a linux laptop with the Ryzen 7 PRO 6850U CPU.

    python 3.10: 60s
    python 3.11: 46s
    pypy 3.9.12:  6s

Looks like pypy performs comparatively better on x86_64

You're not the only one, "The Lisp Curse"[1] essentially says the same thing (but spends a lot more time praising/criticizing the "lisp hacker").

> The expressive power of Lisp has drawbacks. There is no such thing as a free lunch. > - The Lisp Curse

[1]: http://winestockwebdesign.com/Essays/Lisp_Curse.html

A lot of people in this thread seem to share my desire to replace some of what bash does with scripts. Which is why I wrote a utility to allow writing scripts in-between pipes [1].

The basic idea is to call this tool anytime you would be setting up a complex chain of unix pipes, and instead do the scripting in a an interactive environment that allows you to see output as you type. It's just a toy implementation right now and only supports python, but could eventually support any scripting environment (even bash).

I don't really see this as a serious tool, but it can be useful for the odd shell job. Or just for those who like immediate evaluation on every key stroke ;)

[1]: https://github.com/CalebJohn/shell-coupler

Not yet, but plug-ins are on the roadmap[1] and it's my understanding that the plug-in system will be powerful enough to add support for things like backlinks.

[1]: https://github.com/laurent22/joplin/issues/3723