后面的话并非强调非要写文档什么的，如果我用到了你写的包，而且对我非常有帮助我是非常乐意深入研究的代码的，即使没有文档我也会研究。这只是个人意愿而已。当然快乐最重要这点我是非常赞同的。
我突然想起来一个事情……你们介意不介意比较友好的“搬运工”？
要考虑xx的奋斗，也要考虑和xx的行程……
1 个赞
你要搬运啥啊
Melpa上好些6000下載的包也只有個位數issues，這類包維護負擔還好。emacs-cquery 2700+/emacs-ccls 600+ 我倒是覺得負擔很重了，特別多把開發人員當客服使喚，問題描述不清、懶惰不敘述細節的人。
sort=downloads&asc=false前幾頁也有幾十萬下載幾十issues的……這種感覺就不錯。
做工具第一目標當然是爲自己方便，寫教程是很痛苦的。雖然整理思路有點好處，但總體是浪費，時間可以花在更有價值的地方。
“剛剛夠用，不多也不少”我很有感觸，也是這個心態在做。不過我沒有那麼好脾氣，不懂得如何提問的issues、我不想實現的功能我直接close的。不想看的東西看一眼已經是難受，過幾天等冷了再close，我實在沒有那個心情。
5 个赞
让我想起了当时不解的一段话：
And von Neumannn gave me an interesting idea: that you don’t have to be responsible for the world that you’re in. So I have developed a very powerful sense of social irresponsiblity as a result of von Neumann’s advice. It made me a very happy man ever since.
2 个赞
个人在思考，这是不是就是国内开源界不成熟的表现之一呢。如果有多个人维护一个项目应该就能避免这样的问题。当然，这样又会涉及到新功能开发意见不统一的问题，跟开公司是一样的，需要权衡。这里也凸显了 Stallman 和 Linus 这样人物的伟大。
这个和emacs的哲学不符, emacs是提供无限扩展, 满足各种用户的需求. 如果只是够用, emacs不会是这个样子.
也许你说的不是emacs相关项目.
Emacs确实是刚刚够用啊，很多重要的功能都是用户通过扩展的第三方包实现的
这个估计是 YY 出来的哲学。GNU 的官网上完全没有这种说明，我也不知道 Emac上的文档有提过这种说法。
第一，参考emacs官方手册第一句，可扩展这个词，如果只是支持扩展，不会把它写在一句话描述里。
第二，实际使用中，多少人看中了它的扩展性和可定制性。
emacs明显是扩展和定制取胜，刚刚够用是ide。没有spacemacs以前，估计每个emacs用户的配置都不一样，就是说100个用户可能就有100种配置。
刚刚够用不需要考虑可扩展性，可扩展性本来就是要考虑各种各种需求的适配，官方对各种插件的支持非常给力，很多功能改进都是在支持新的插件，这个工作量极大。
还有刚刚够用就不会提供那么多可配置参数让人配置，emacs几乎是无所不能配置。
这两项工作从开发角度看工作量都非常大，可能占emacs整个项目一大半的工作量，而且还在不遗余力地支持。
IDE是“刚刚够用”的反面。为了满足各种用户的需要，IDE开发者需要大量的精力开发、维护各种功能。Emacs因为是可以扩展的，开发者不需要自己费劲满足用户的各种需求，只要维护核心部分。用户自己可以自己扩展Emacs满足需要。
扩展性是核心设计上的决定，跟实现功能多少没有直接关系。“很多功能改进都是在支持新的插件”，举个例子？
Emacs不需要人为地“维护”其扩展性和配置参数，所谓“emacs整个项目一大半的工作量”这个结论不知道你是从哪里得出的。
最后，“刚刚好”指的是实现的功能多寡，我觉得跟扩展性没有什么关系。就算有关系，也是跟你说关系的相反：更好的扩展性方便开发者实现一个刚刚好的工具，如果用户有额外需求可以自己添加，不用麻烦开发者。
举一个现在的，tramp在开发一个异步分支，核心开发基本是在全力支持。发现线程缺少一些功能，还有minibuf的多线程用户交互，这些基础设施不就是给插件用的吗？这方面工作量不小，还有最开始多线程的加入。
elisp本身的也是为了插件和扩展服务，如果不支持插件，elisp就没有存在的必要了。
像微软的windows自身功能永远都是那么点，从xp到win10，但它对第三方驱动和应用的兼容测试可是花了很多精力。
ide最容易做到刚刚够用，一方面它不开发很多人用不到的功能，就是不考虑小众需求，只面向主流用户，同时每个功能都只有一种使用方式，不支持什么定制或者仅支持非常简单的定制。
从我的角度看，这些基础设施算是Emacs扩展其能力，跟兼容性没关系。
Elisp只是一个语言，跟插件没关系。是Emacs作为编辑器的设计使它有强大的扩展性。
window搞第三方兼容跟插件更没关系了，驱动是为了兼容硬件，跟插件没关系。我也没听说过windows为了什么应用改window代码的，只不过是向下兼容罢了。
基础扩展能力并不好做，相当于提供二次开发，跟windows系统类似。把自己内部几乎所有功能整理成api，给外部使用，这个兼容性不好做，十几个api感觉不到，几千个，几万个就感觉到了，工作量很大，emacs有几千个，windows有几万个。
如果这是一项简单的工作，那么就是比vscode简单了，那vscode功能应该很轻松完全兼容emacs。而且emacs的克隆品也会很容易出现，事实上不是，vim都有成熟的克隆了，emacs的一直进展缓慢，因为它太复杂了，做的东西太多了，曾经的xemacs是有接近全职的人在开发，现在也维护不动了。
windows自己做兼容不单是自己单方面做的，他要跟成千上万的第三方应用做兼容性测试和问题调试，这个团队也很大，网上可以找到资料。
https://www.emacswiki.org/emacs/EmacsImplementations
GNU Emacs 自己也不过是个克隆。上面沒提到的除了 Rust 的 Remacs 外，Haskell 也在做他們的 Emacs clone — 義
1 个赞
这种态度，值得我们后辈学习，尤其是要自己动脑子来解决问题，emacs毕竟不是开箱即用的ide，这句话很受用。
本帖子里说的刚刚够用指的是现在的GNU Emacs, 所以我指的是这个emacs.
为什么举例nvim, 是因为nvim几年时间就达到跟vim不相上下的程度, 如果emacs够简单, 它的克隆品也会很快达到这个成熟度, 比如Remacs和Haskell那个, 甚至会出现一个基于electron的emacs. 但看上去好像很难.