ivy相对于Helm的优点?


#41

精辟总结 :+1:

补充一点,还要batteries included,helm另外一个问题就是插件太分散了


#42

在上这个论坛之前都不知道ivy :joy: 因为一直用ido,所以更喜欢ivy。


#43

不是不喜欢minibuf, 而是不喜欢在狭小的空间内展现过多信息, 感觉很拥挤.

需要装插件, 而且还满足不了全部需求(独立窗口显示), 用helm既可以独立窗口(我的首选), 又可以独立frame(即ivy-posframe功能), 还不用装其他插件. 这个对比很明显, 这应该不是偏见.

另外, 我刚看了一下ivy-posframe, 它好像不用minibuf做输入了, 有点类似于vscode的Ctrl-p. 前面说了, 我希望用minibuf输入, 保持emacs基本的习惯, ivy-posframe明显不满足需求. 而helm的独立frame依然在用minibuf做输入, 体验比较一致.

关于ido, 我应该算是ido的老用户了, 八年以上了, 现在还是天天用(hack了一下), 但是确实习惯不了ivy对minibuf的使用方式. 所以, 现在是ido与helm配合.

helm确实臃肿, 它的一些功能我也不用, 不过目前感觉不到慢, 也许慢的那部分正好是我不用的.

另外, ivy一个很烦人的问题就是1里面提到的, 用它就要全系统用, 把emacs内置的icomplete关掉, 这个作为第三方插件, 给用户的干扰较大.

ivy确实简洁犀利, 有点像vim给我的感觉.


#44

helm-ag 配置 rg 后端确实好用, 1、特别喜欢这两个命令:helm-do-aghelm-do-ag-this-file;不知道 rg.elcounsel-rg 有没有类似功能。 2、如果使用 rg 后端在搜索时还是使用 -E gbk 这样的参数搜索 gbk 编码的文件。


#45

olor-rg 已经有这种功能呢。


#46

哈哈,我去试试,:grinning:


#47

哈哈,ivy-posframe还是用 minibuffer 做输入,只不过把显示重定向到一个 child-frame了


#48

不过看了大家的讨论,大多数人选择用哪个,都是因为顺眼或者顺手 :joy:


#49

原来如此。我上午试了一下,childframe和原frame的minibuf里都在显示内容,后者显示的是残缺不全的内容,有点像icomplete的补全内容,不过只显示了一部分,不知道怎么回事,当时也没有截图。


#50

确实,大多数人都是根据第一印象吧,没有真正深入使用过。


#51

rg.el有这功能哈,而且更强大些。


#52

好吧,确实没怎么用过rg.el,待会去试试。

很多时候可能是习惯使然,习惯了一种方式之后就懒或者难得去尝试一些其他方式,就好像helmivy之间的选择,我倒是两个都在用。

好像歪楼了,:grin:


#53

一开始用的 helm,很快就发现这货骨子里就是个菜单(menu),这种交互会抢占输入焦点,干扰太严重了。我使用补全是当做辅助功能的,在输入过程中大部分时候脑子里都是清楚要输入哪些内容的,无论补全不停地崩出多少东西我可能压根都不去看一眼,只是有时候迷糊了会在补全列表找一下。helm 感觉太霸道了,不好调教,ivy 比较简单很容易配置成我想要的效果。


#54

传说中的脑补


#55

我两个都在用

  • ivy 我用来替代一些内置命令,比如 find-file 什么的,因为这个时候我希望能有一个快一点没那么多会抢占注意力的元素的补全
  • 切换 buffer 或者像你说的那种需要大批量模糊搜索的场景,我用 helm ,因为它显示的信息更多,信息的组织方式更高效(就比如显示每个分组名称的那一条东西)

我用得很开心


#56

ivy 最主要的特点是补全出现在 minibuffer,不会乱开窗口,总是在那一个地方,你可以预期到他。 helm 就有点不受控制了。


#57

我都是用popwin统一控制窗口位置的,虽然有些窗口好像不受控制


#58

用shacke吧


#59

我是用了helm很久,才转到ivy有点讽刺,发现ivy就提供了刚刚够用的功能,而helm总给我一种面对一座山的感觉,用了不到1%的感觉,力不从心的错觉。大概是我的精神洁癖吧。Ivy满足了我们这类极简功能主义用户的智能补全需求吧。要说功能,helm更全更多。


#60

Exactly! 跟我当初的感觉一模一样。也许都有点洁癖