打算好好睡觉 
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甚至可以跑在远程的服务器上。
哈哈哈， 大佬要实现吗？ 大佬实现的话， 我就不做了。
我对大文件的需求不够刚， 但是以前想过， 理论上完全可行。
打算等年底忙完之后开始写
为什么要用python读，直接用Emacs的文件接口打开大文件是不是存在性能问题？如果是为了(2)感觉不太必要，搜索只需要传递起始位置和方向。
我不太了解tree-sitter如何做增量解析，如果浏览过去的行数超过了一定的界限，会不会吃很多内存？维护一个prune变量是否有难度？
提一个不太正经的建议：这种超大型的日志，或许可以在储存的时候就考虑分段编码索引，而不是在检查的时候才去分段处理。
分段策略，按长度等分不太必要，应该按用户感兴趣的点去拆分（比如匹配到的点），像helm那样子，用多个buffer在不同的偏移开同一个文件，在搜索的时候二分查找buffer list，找最近的buffer去做增量搜索。不管做不做持久化，一定要考虑buffer回收的策略。
你说的对，UX应该按这个思路来。
issue里主要描述的是一些技术细节。当时应该是看了 Text Buffer Reimplementation, a Visual Studio Code Story 和 Rope & SumTree 后产生的想法。
关键是你打不开呀
哈哈哈哈， 大佬这是给我做硬广了， 论坛还是讨论Emacs吧。 
1 个赞