我为什么不想把自己的Emacs插件放到MELPA上?


#21

后面的话并非强调非要写文档什么的,如果我用到了你写的包,而且对我非常有帮助我是非常乐意深入研究的代码的,即使没有文档我也会研究。这只是个人意愿而已。当然快乐最重要这点我是非常赞同的。


#22

我突然想起来一个事情……你们介意不介意比较友好的“搬运工”?


#23

要考虑xx的奋斗,也要考虑和xx的行程……


#24

你要搬运啥啊


#25

Melpa上好些6000下載的包也只有個位數issues,這類包維護負擔還好。emacs-cquery 2700+/emacs-ccls 600+ 我倒是覺得負擔很重了,特別多把開發人員當客服使喚,問題描述不清、懶惰不敘述細節的人。

sort=downloads&asc=false前幾頁也有幾十萬下載幾十issues的……這種感覺就不錯。

做工具第一目標當然是爲自己方便,寫教程是很痛苦的。雖然整理思路有點好處,但總體是浪費,時間可以花在更有價值的地方。

“剛剛夠用,不多也不少”我很有感觸,也是這個心態在做。不過我沒有那麼好脾氣,不懂得如何提問的issues、我不想實現的功能我直接close的。不想看的東西看一眼已經是難受,過幾天等冷了再close,我實在沒有那個心情。


#26

让我想起了当时不解的一段话:

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.


#27

个人在思考,这是不是就是国内开源界不成熟的表现之一呢。如果有多个人维护一个项目应该就能避免这样的问题。当然,这样又会涉及到新功能开发意见不统一的问题,跟开公司是一样的,需要权衡。这里也凸显了 Stallman 和 Linus 这样人物的伟大。


#28

这个和emacs的哲学不符, emacs是提供无限扩展, 满足各种用户的需求. 如果只是够用, emacs不会是这个样子.

也许你说的不是emacs相关项目.


#29

Emacs确实是刚刚够用啊,很多重要的功能都是用户通过扩展的第三方包实现的


#30

这个估计是 YY 出来的哲学。GNU 的官网上完全没有这种说明,我也不知道 Emac上的文档有提过这种说法。


#31

第一,参考emacs官方手册第一句,可扩展这个词,如果只是支持扩展,不会把它写在一句话描述里。

第二,实际使用中,多少人看中了它的扩展性和可定制性。


#32

emacs明显是扩展和定制取胜,刚刚够用是ide。没有spacemacs以前,估计每个emacs用户的配置都不一样,就是说100个用户可能就有100种配置。

刚刚够用不需要考虑可扩展性,可扩展性本来就是要考虑各种各种需求的适配,官方对各种插件的支持非常给力,很多功能改进都是在支持新的插件,这个工作量极大。

还有刚刚够用就不会提供那么多可配置参数让人配置,emacs几乎是无所不能配置。

这两项工作从开发角度看工作量都非常大,可能占emacs整个项目一大半的工作量,而且还在不遗余力地支持。


#33

IDE是“刚刚够用”的反面。为了满足各种用户的需要,IDE开发者需要大量的精力开发、维护各种功能。Emacs因为是可以扩展的,开发者不需要自己费劲满足用户的各种需求,只要维护核心部分。用户自己可以自己扩展Emacs满足需要。

扩展性是核心设计上的决定,跟实现功能多少没有直接关系。“很多功能改进都是在支持新的插件”,举个例子?

Emacs不需要人为地“维护”其扩展性和配置参数,所谓“emacs整个项目一大半的工作量”这个结论不知道你是从哪里得出的。

最后,“刚刚好”指的是实现的功能多寡,我觉得跟扩展性没有什么关系。就算有关系,也是跟你说关系的相反:更好的扩展性方便开发者实现一个刚刚好的工具,如果用户有额外需求可以自己添加,不用麻烦开发者。


#34

举一个现在的,tramp在开发一个异步分支,核心开发基本是在全力支持。发现线程缺少一些功能,还有minibuf的多线程用户交互,这些基础设施不就是给插件用的吗?这方面工作量不小,还有最开始多线程的加入。

elisp本身的也是为了插件和扩展服务,如果不支持插件,elisp就没有存在的必要了。

像微软的windows自身功能永远都是那么点,从xp到win10,但它对第三方驱动和应用的兼容测试可是花了很多精力。


#35

ide最容易做到刚刚够用,一方面它不开发很多人用不到的功能,就是不考虑小众需求,只面向主流用户,同时每个功能都只有一种使用方式,不支持什么定制或者仅支持非常简单的定制。


#36

从我的角度看,这些基础设施算是Emacs扩展其能力,跟兼容性没关系。

Elisp只是一个语言,跟插件没关系。是Emacs作为编辑器的设计使它有强大的扩展性。

window搞第三方兼容跟插件更没关系了,驱动是为了兼容硬件,跟插件没关系。我也没听说过windows为了什么应用改window代码的,只不过是向下兼容罢了。


#37

基础扩展能力并不好做,相当于提供二次开发,跟windows系统类似。把自己内部几乎所有功能整理成api,给外部使用,这个兼容性不好做,十几个api感觉不到,几千个,几万个就感觉到了,工作量很大,emacs有几千个,windows有几万个。

如果这是一项简单的工作,那么就是比vscode简单了,那vscode功能应该很轻松完全兼容emacs。而且emacs的克隆品也会很容易出现,事实上不是,vim都有成熟的克隆了,emacs的一直进展缓慢,因为它太复杂了,做的东西太多了,曾经的xemacs是有接近全职的人在开发,现在也维护不动了。

windows自己做兼容不单是自己单方面做的,他要跟成千上万的第三方应用做兼容性测试和问题调试,这个团队也很大,网上可以找到资料。


#38

https://www.emacswiki.org/emacs/EmacsImplementations

GNU Emacs 自己也不过是个克隆。上面沒提到的除了 Rust 的 Remacs 外,Haskell 也在做他們的 Emacs clone —


#39

这种态度,值得我们后辈学习,尤其是要自己动脑子来解决问题,emacs毕竟不是开箱即用的ide,这句话很受用。


#40

本帖子里说的刚刚够用指的是现在的GNU Emacs, 所以我指的是这个emacs.

为什么举例nvim, 是因为nvim几年时间就达到跟vim不相上下的程度, 如果emacs够简单, 它的克隆品也会很快达到这个成熟度, 比如Remacs和Haskell那个, 甚至会出现一个基于electron的emacs. 但看上去好像很难.