玩了Emacs十几年, 写了很多 Emacs插件 , 有很多人都建议把我的Emacs插件放到 MELPA 上.
我一直以来的回答都是: NO
今天把原因写出来, 以后如果再有人问到我, 我就可以直接把这篇回答直接发过去, 不用反复的回答:
- 我十年前答应朋友 rgr 把 org-w3m.el 贡献到 Emacs 主分支的时候就耗费了我很多时间, 几乎是编码一晚上, 合并代码2个月的赶脚
- 后来听了 rgr 的建议, 把所有插件都放到 EmacsWiki 以后, 剩余的十多年时间, 我的邮箱都被各种 emacser 轰炸, 开源软件就是这样, 创造的时间很短, 但是维护的时间却远远大于创作的时间, 包括大家经常用的 multi-term.el、sdcv.el、auto-install.el、anything.el、auto-complete.el 等插件, 我都维护超过十年以上的时间, 虽然能够帮助全世界的 emacser 我真的超级开心, 但是维护插件真的需要耗费我个人非常多的时间
- 诚然 MELPA/Package.el 对于用户来说很方便, 也会让更多人知道我写的插件, 但是同时也意味着会有成百倍的用户给我提 issue 和 建议, 我是一个不喜欢拒绝别人的人, 如果成百倍的用户发送 issue 和 建议, 我一定会睡不着觉去完善我的插件, 那样势必会占用我陪家人的时间, 综合考虑, 我更希望更多的时间让家人开心, 而不是让全世界的 emacser 更开心, 虽然他们都很友善和可爱
- 写Emacs插件和弄懂各种插件的细节, 我花费了无数个日日夜夜, 虽然 MELPA 让 90% 的Emacs用户可以一键自动下载安装(包括依赖), 但是同时也成就了太多不动脑筋的用户, 遇到问题不会搜索和研究, 只会抱怨, 最终放弃 Emacs. Emacs从基因上毕竟不是开箱即用的IDE, 你开始可能不会Elisp编程, 但是到最后你一定要学会 Elisp 编程才会把Emacs这把屠龙刀打造的尽可能顺手. 所以, 我不希望大家都变成傻瓜化的 MELPA 用户, 那样只会让自己丧失解决Emacs问题的能力, 最后把更多用户推离Emacs, 而不是拥抱Emacs的哲学理念
- 我现在已经过了向世人证明我个人能力的那段日子, 接下来的几十年, 我希望花更多的时间去学习新的技术和陪伴家人, 而不是无穷无尽的折腾 Emacs, 折腾Emacs而不学习高深的技术, 就像一个永远只会淬炼刀剑的却没有时间练习剑法的工匠一样, Emacs这个工具始终是为了探索好奇心服务, Emacs本身不应该成为学习的目标
- 除了技术以外, 我对产品的细节有很多我自己的见解, 我更喜欢制作一些开箱即用和细节优雅的插件, 就是那种 刚刚够用, 不多也不少 的感觉. 不太喜欢像传统开源软件开发者一样, 做功能非常丰富的瑞士军刀, 即使很多功能作者都不用. 使用的人太多, 就会众口难调, 最后自己写的插件连我自己都不喜欢, 那样就太无趣了, 而且拒绝那些提出建设性意见的人, 我自己也有点于心不忍, 所以我的插件就留给那些和我有同样品味的 emacser 发掘吧, 物以类聚, 不互相勉强的状态最舒服
过去十几年活的很累, 总是给自己太多负担.
以后的日子, 我希望为自己的好奇心和个人习惯而活, 简单点, 喜欢我的作品我很高兴, 不喜欢我的作品欢迎你继续探索, 这样的日子最简单, 也最快乐.
44 个赞
cireu
2
猫哥的人生哲学, 受教了.
人的心力毕竟是有限的, 与其将有限的精力花在处理与自己几乎好不相识的人的关系上. 倒不如好好对待自己觉得在乎的人和事上. 赞一个!
不过我觉得放在 github 上也挺容易使用的, 还是有很多种"傻瓜"方式让我这种小白用 
1 个赞
用straight直接安装github插件很方便。同时也可以配合use-package用。
(use-package el-patch
:straight (el-patch :type git :host github
:repo "raxod502/el-patch"
:fork (:host github :repo "your-name/el-patch")))
2 个赞
我用自己写的cowboy.el，管理起来还挺爽的。
vim社区现在的思路就是依托于github，著名的宝管理插件plug，dein等都支持从github下载，感觉这个才是趋势啊
真全放在github上有这么个问题……
下……载……慢……啊
就算有浅克隆也不如直接下载快啊。除非基于GitHub Release……
因为你总不太可能给整个GitHub，至少是整个Emacs Lisp区做镜像吧……
而且网络问题不只天朝有
1 个赞
其实不光是vim，其他的包管理也都是基于记录下载和安装各个包的过程并且自动化，而不是直接托管代码。
前辈写得非常有道理，一个开源软件/包，对于个人来说维护起来确实是非常困难，特别是深受用户喜爱又很想做一些定制的Emacs包。其实也有一部分用户非常想对包进行一些改进（或者修复一些bug），但是又苦于不知道如何下手，这部分用户知道elisp的语法，知道做一些配置，但是没有办法深入开发完善你写的包。我自己就是这样的用户，平时在windows上使用cider，如果时间允许会修复几个windows上简单的bug，但是要再深入一点的话就不知道如何去修改了。
我个人觉得：授人以鱼不如授人以渔。
可以写一些Emacs插件开发的流程，插件开发的方法，常用的一些技巧，如何编写Major/Minor mode，如何做syntax highlight，如何做其他的一些功能。还有你开发的的一些插件是如何工作的，如何在你开发的插件的基础上做更多的工作，怎么样才能更好的去修复别人bug。这样可以改动更多的人来参与开源的事业，你一个人做肯定太累。
其实教材也挺多的，李杀就有专门的教程，关键还是自己花不花时间学吧
就是因为资料太少，而且还有很多是英文的，对于英文不太好的又是一道障碍。如果有很多资料自然学习不是问题，就像Java的书多得一塌糊涂，所以我那时候学习Java都是看中文书籍，而不是去看Java的源代码。不知道代码里面的思想光看代码，纯靠YY也行不太通吧。
可以把文档和教程写成书籍，既为其他的开发人员打开了一扇大门，又增加了收入，还节省了自己一个人维护N多项目的时间，何乐而不为呢。如果出书我个人是愿意买的。
这个我同意， 快乐最重要， 我做了好多package，但现在维护的几个都是我自己使用的， 做成package的一个重要目的是吸引志同道合的人形成开发团队， 如果无法形成团队，做不做包都无所谓
下面的话可能有点反直觉.
我觉得人还是要首先让自己活的快乐, 而不是为了取悦任何其他人, 只有自己最真诚, 对自己最诚实的状态下创作的东西才能打动别人, 任何其他的手段都经不起时间的考验.
所以, 我以后写的任何代码和文章首先会让我自己觉得有趣我才会去写, 如果别人喜欢看我很高兴, 不喜欢看我也觉得很正常 (人和人本来就不一样嘛), 而不是仅仅只是让别人开心.
我一向以来崇尚的快乐大法:
很多事情, 就是
关你屁事, 关我屁事
做点好玩的事情博得自己的开心最重要.
我相信每个人只有让自己先快乐, 这个操蛋的社会才能进步, 哈哈哈哈.
17 个赞