不能同意更多，特别是关于洁癖，我也有 
我甚至因为一个包没有包含正确的文件头或 autoload 而给作者 PR。而因为没有被采纳，干脆 fork 一个，以后都从我 fork 的 repo 安装（用 quelpa fetch），洁癖使然。
我 fork 的 repo 往往包含两个分支，一个 master 是我修改的分支，一个 upmaster （即 upstream master 的缩写）用来和上游保持一致，如果上游更新，我就把我的分支 rebase 到 upmaster 分支。我这也算是一种半自动吧 
。目前感觉这种方式比较适合我。
我在学习你 lazycat-emacs 的一些思路，学习还不久，elisp 还是半吊子水平:grinning:
请问tabbar有什么问题？能大概说一下吗？
我正在用，而且是melpa版的tabbar和tabbar-ruler。。。
照着你的方子把自己的init.el refactor了，确实清爽多了。因为手动安装包，对很多以前随意el-get的包的了解更深，一些不常用的东西都一并删除了。
能说一下这一步具体怎么做么？
这么简单的问题应该不用问的吧
在 dired 中 C-h m
搜索 mark 能够找到 dired-mark （m）
搜索 byte-comp 能找到 dired-do-byte-compile （B）
搜索 load 能找到 dired-do-load（L）
全选倒是不知道是哪一个
但写一个应该也不是很难
搜索 .el 然后 dired-mark 一下就可以了
m与*m 标记为"*"
** 标记所有可执行文件
*@ 标记所有软连接文件
*/ 标记所有目录(.与..除外)
*s 标记当前目录的所有
u与*u 删除标记 (u被我重定义为回到上层)
U与*! 删除所有标记
%d REGEXP 将所有文件匹配的文件标记为D(删除)
%m REGEXP 将所有文件匹配的文件标记为*
%g REGEXP <RET> 如果文件中的内容匹配正则表达示则标记之
*C-n 移动到下一个标记的文件
*C-p .....上...........
q quit
f <RET> open file 打开文件
o open file other window 在另一个窗口中打开文件
C-o open file other window (point in this window) ,在另个窗口打开文件,焦点仍在当前window
v view-file 只读打开(q 退出)
^ 上层目录 ,我改成了u,以方便操作
关于mark,将文件标记之后,一些处理文件的命令会对mark的所有文件
采取一致的行动,如删除等.
操作文件的命令,有以下规则
如果有前缀参数N 则对从当前文件开始的N个文件执行操作,负数则反向
否则对标记mark为*的文件,
否则 当前文件
C copy
(setq dired-copy-preserve-time t),copy时保留原文件的修改时间 如果cp -p
D delete ,经确认后马上删除
d detele 实际只是标记此文件为删除,执行x 才真正删除
R mv rename 重命名,移动文件
H 硬链接
M chmod ,如M 755 修改为755
G change group
O change owner
T touch file
Z compress or uncompress
L load lisp
A REGEXP ,在文件中search ,M-, 跳到下一个
Q REGEXP ,query-replace-regexp(`dired-do-query-replace-regexp').
子目录
i 同时打开目录
$ hide or show 当前目录
指定隐藏哪些文件 : C-o, toggle
g refresh all
l refresh mark的文件
k 隐藏指定文件
s 排序 字母,或date 间toggle
编辑,输入C-x C-q 切换到writable 模式,此时修改文件名,然后C-c c-c 提交
也或以移动文件,将文件名写成相应的路径名即可
设置在writable 模式下允许修改权限
(setq wdired-allow-to-change-permissions t)
C-td 会将目录中所有标记的文件生成缩略图,图片预览
w copy the file name
C-u0w copy 全路径名
dired 支持拖放,你可以在pcmanfm nautils 中将文件,拖动到dired buffer 中
正则表达式的应用
% R FROM <RET> TO <RET>' ;rename
% C FROM <RET> TO <RET>' ; copy
% H FROM <RET> TO <RET>' ; Hard link
% S FROM <RET> TO <RET>' ; soft link
FROM TO 是一个正则,另外在TO 中可以用\&引用FROM整个的匹配组,\数字匹配某一个组
如 % R ^.*$ <RET> \&.tmp <RET>' 重命名所有标记的文件为*.tmp
= diff
M-= diff 与backup
!与X 执行shell 命令,"*" 代表选中的文件名
如我想把abc 文件移动到/tmp
!cp * /tmp
!tar -cf a.tar *
!for file in * ; do mv "$file" "$file".tmp; done
与*类似但不相同的"?" 表示对mark的文件"分别" 运行这个命令
; image-dired
请教，是不是每次Clone下来之后都需要手动切换到每个插件的目录下去编译呢？（插件的编译方法不一样，eg. Auctex）
当后来删 submodule 的时候，怎么确保把已经不需要的依赖也一起删掉呢？
直接git checkout吧，不用的插件不要往自己的git仓库加，没啥完美方案可以自动管理
最近也想把自己包方案做成和你一样的手动管理。
有两个问题想请教一下：
（1）package.el 会自动下载被依赖的包吧？
比方说：我在github上逛，发现一个包比较有趣，然后magit-submodule-add到自己的仓库还是不够的。因为它可能还依赖别的包，所以得先研究那个作者的包依赖了哪些包，要先把那些包也magit-submodule-add下来。
（2）git里使用magit-submodule-add所提的目录，如果提供包作者的仓库被删除，我仓库里的那个xxxxxx@2eabe28 还有用吗？是不是就无效了？
（3）你说使用submodule后，即使随着插件数量越来越多, 你的emacs git仓库依然保持很小，方便自己 git clone 下来。
这点我不太理解：如果你在一台干净的机器上clone 你emcas仓库。对你的emacs仓库是很小（因为submodule是空目录），但是你不还得update submodule？这还不如直接把作者的代码放到你的仓库里（只放代码不放仓库）。
对于这种探索的包, 我建议先把插件及所有的依赖先 git clone 到一个临时目录, 然后用 load-file 手动 load 一下, 测试通过以后再用 magit-submodule-add 添加到自己的 emacs 仓库中, 避免不满意以后执行 magit-submodule-remove, 麻烦.
如果作者的仓库都删除了, 你啥包管理器方案都要重新来过, 这种小概率事件不用考虑.
我说的是自己的Emacs仓库不会随着你添加任何新的插件而变大, 比如你用 submodule 添加N个插件, 只是增加N个 submodule 的commit, 即使你更新插件版本, 只是更新了一个 submodule commit 的一行ID字符串的大小, 如果你直接把插件的代码拷贝进来, 第一你更新插件版本不方便, 第二, 如果插件的内容变动很大, 你的仓库更新也会越来越大, 因为你的commit记录了每个插件的内容变更.
对于第三点，我的意思是：采用submodule 和 采用完全复制某一个版本相比，clone的时间会有区别吗？（update submodule 是不是相当于把插件作者的整个git仓库download下来了，这是不是更慢了？）
clone 都是一样的慢, submodule 的好处是你发现作者修复了某个issue, 你直接 magit-pull-from-upstream 就直接更新了
如果你直接复制某一个版本, 下次更新你还需要下载新版本然后覆盖, 这时候你自己的Emacs仓库就会随着插件内容的更新越来越大
仔细先想这句话
submodule 不会随着插件版本升级带来的内容更新而显著增加自己Emacs Git仓库的体积
因为它只是更新插件 commit id
先不要急着回复我, 本地动手做一个实验你就明白了.
嗯，这个我明白：submodule在你的仓库里其实只是一个空目录，并不会有真正的内容。
问题是github仓库不是免费的么？我们有必要帮他节省硬盘吗？…
节省你自己重装系统后, clone 你自己 emacs 仓库的时间.
看上面的解释，我准备也改用submodule试一下。我是在Centaur Emacs基础上做的，自己加进去的包不多，awesome-bar/pair我也在用，可以用submodule方式管理，也方便升级。
我现在用的是install-elisp从git上安装，也挺方便的
当你clone下你的emacs配置仓库后，确实那两个submodule目录是空的。但是这样的emacs配置你是不能用的，因为缺少必要的package。接下来需要 git submodule **update** --init --recursive一下，这个过程会把你用到的package的仓库clone下来（这个过程会很慢，因为每个submodule 都是一个package的仓库，里面可能有几十年的提交记录）
注：我本地测试了这个过程，submodule 被 update下来之后，即便你断网仍然可以切换不同的revision，说明历年来所有的提交修改都在里面了。
所以我才说submodule会比直接复制某一个版本更慢：
重装系统后，虽然clone自己的emacs仓库是快了，但git submodule **update** --init --recursive 这个过程会很慢，因为这相当于把每个package仓库历年来的修改全部download下来。（PS：不确定这个命令是否有额外选项，可以不download整个仓库）
双方都把意思说的很清楚了，保持自己喜欢的方式吧