要不跟我一样玩玩rust egui吧哈哈
1 个赞
准备研究纸质记录+电子存档的笔记方法，工作中有很多时候不方便随身带电脑记录。
1 个赞
确实很不方便，我都是用手机记录，为了快速，感觉需要制造一门速记记号才行。听说以前的记者就是这么做的。
1 个赞
对，速记记号，非常建议使用，可以提升很多效率。
打算实现一个 AI 多 Agent 系统，在 org-supertag 里。
尝试下在没有学范畴论的情况下理解 Monad，感觉我 19 年就看到过这个概念了。
顺便看看有没有时候研究一个这个 关于优化windows版本emacs的进展（2024-6-16更新，绕过了子进程/套接字数量限制。
1 个赞
准备认真学习下rust
放假后的我学不进去一点东西，哈哈，无数次的事实，已放弃，就开心过个年。
打算好好睡觉 
2 个赞
每年都计划一堆， 最后都是一个样
喝酒
4 个赞
我也差不多，还在休陪产假
学一下CRDT，看一下开源的在线协同编辑器源码
"玩"什么？
写本子，呃。。。。
看着大家丰富的寒假“技术宅”生活，慕了慕了
1 个赞
想写一个editor专门用来看大文件/日志
看大文件/日志更适合pager而不是editor
pager过于原始了。想要支持更丰富的功能所用到的技术和editor是趋同的，可以参考GitHub - tstack/lnav: Log file navigator
以及之前在群里灌水时产生的几个想法
大佬文件有多大？超大文件打开我倒是有主意
为了复现bug产生的日志一般是几百G，上T也不是没有。
最极端的一次是专门在服务内将某个位置的日志单独拿出来发到S3中，事后统计是3T多。
日志虽大，实际上大部份也没什么价值，一般情况grep+cut+vim就能应付。
是什么思路？vim打开大日志确实很慢。。机器性能受限的话会更糟糕
用类似 blink-search 的技术栈：
- 用Python后端去读大文件， 但是每次就读一屏的数据， 这样打开速度就是常量
- Emacs每次接受一屏的数据， Emacs渲染一屏非常快， 搜索传递给 Python 后端去做， 这样可以快速跳转
- 语法高亮直接在Python端实现， 用 tree-sitter 来渲染， 这样Python端传递数据给Emacs的时候附带颜色值， Emacs只渲染一个屏幕的 Overlay 性能没问题
1 个赞
这个思路很有意思，我只要实现一个indexer然后向emacs发送数据就行了。indexer甚至可以跑在远程的服务器上。