Emacs: 智能感知和操作光标处的语法对象


#30

color-rg.el 也换成 pulse 了, 哈哈哈


#31

https://github.com/manateelazycat/thing-edit/commit/21c1bd1a7dbb98f51577cd10951208755e250fab 你的函数我内置了.


#32

OK, 谢谢! 这样我就可以去掉自己的配置了,没有提交 PR,论坛提供也算contribution 了 :grinning: 不过,我没有过多测试哈,你要多 review 下啦


#33

replace 函数我改了一下


#34

嗯,good。有没有考虑增加copy 整个 buffer的函数?


#35

我一般用 (mark-whole-buffer), 主要是我用的很少.

不过我不排斥你发PR, 哈哈哈哈.


#36

这个简单呀,review 下吧,哈哈哈

  (defun thing-copy-whole-buffer (&optional kill-conditional)
    "Copy content of the current buffer.
If `KILL-CONDITIONAL' is non-nil, kill object,
otherwise copy object."
    (interactive)
    (save-excursion
      (thing-edit-internal (point-min) (point-max) kill-conditional)))

  (defun thing-cut-whole-buffer ()
    "Cut content of the current buffer."
    (interactive)
    (thing-copy-whole-buffer t))

  (defun thing-replace-whole-buffer ()
    "Replace the current buffer with the content."
    (interactive)
    (thing-replace 'buffer))

突然想到一个问题,thing-edit 似乎没有考虑 narrow 的 case,当然绝大多数情况是够用了。另外对于内容很多的情况下 minibuffer 显示就不大好了。


#37

minibuffer 你有啥建议? 我没想到更好方案, 主要觉得不移动光标拷贝就已经让我自己很爽了.

narrow 的情况其实不用去考虑, 没人抱怨就是因为没人那么用, 哈哈哈哈


#38

很多工具浏览 kill-ring的时候超出限值都会截断,比如:counsel-yank-pop

我觉得可以参考。 甚至只是给个简单的 message ,如:Copy the current symbol,应该足够用了。


#39

Copy 可以这样做, 已经有高亮提醒了, cut和replace如果不提醒有时候还是不方便.


#40

我就喜欢你这种一言不合就飚代码的老司机, 已经合并了: https://github.com/manateelazycat/thing-edit/commit/6b35788a45f554c1233a6f94614b74a0a8693b35


#41

干这行太久的老毛病,前提是自己略知一二才行呀 :joy:

嗯,Cut、Replace 提醒我没有仔细考虑。话说没有上 melpa,更新起来还是挺麻烦呀,我是不是该考虑下straight之类的呢……


#42

submodule不错啊

别用straight, 没有shadow clone下载半年


#43

其实我就觉得 submodule 配合我写的 magit-submodule-add 和 magit-submodule-remove 最好用.


#44

这就是我一直弃用straight的原因,不过如果是极少量的包也还凑合。submodule 确实可以考虑……


#45

这个是鸡生蛋蛋生鸡的问题了?:joy::joy::joy::joy::joy:


#46

用quelpa-use-package作为补充其实也不错


#47

submodule 真的比那些乱七八糟的包管理器好太多了, 啥限制都没有. 缺啥就 magit-submodule-add, 试用好 commit, 不好直接 magit-submodule-remove 就可以了.

我真的就不明白, 那些包管理器搞那么多功能, 然后限制又大, 真麻烦.

我就两种途径, github (magit / submodule), emacswiki (auto-install.el ), 虽然现在都是用的 github.


如何优雅得为不从package.el安装的包生成autoloads?
#48

嗯,我研究下。谢谢!


#49

我的理解是,MELPA 存在的价值在于有个集中审核、管理的类似官方市场,package 内置也方便了其推广使用。虽然审核和管理做得还不够好,但是已经有很大进步。就像其他语言基本都有一套包管理系统是一样的道理。

目前大多数代码库都是依赖于 github(或者其他基于 git 的系统),用起来是最灵活的。Golang 的包管理基本就是基于 git 的,用起来很爽很方便。不过同样也有问题,就是太容易开发和引入第三方库,导致库的水平参差不齐,需要费很大劲才能找到质量好的库,用着用着还被废弃了,头大得很。其实我这是在吐槽开源的问题吧,扯远了~~~