很难从产品细节去判断，因为两边UI一开始的设计逻辑就非常不同，差异大到我可以说自己坚守ivy的最大原因就是习惯。很多从helm跳到ivy最后又放弃跑回去helm的人表示ivy细节做得很不贴心，可是我从ivy跳到helm的那段时间也是各种不习惯，最后适应不了就回来ivy了。
我认为ivy的操作逻辑可能更贴近emacs思维，用tab补全, enter选择并执行，helm的tab是用来执行各式各样的action让我很不习惯。细节比较真的就是实际用个几天就知道合不合胃口了。
补充一点，ivy只是个补全候端，所以前端显示candidate也不一定要使用minibuffer，ivy的wiki上有教学怎么在overlay, 正常buffer里面显示ivy补全选项
helm的可扩展性太强了，感觉已经超出了一个minibuffer补全框架需要的范围，过度设计反而搞得自己代码很臃肿。
helm里的completion source …换到ivy里也就是一个function或者list的事
试试rg.el和 counsel-rg，体验很好。
说几点吧
这些用ivy很好扩展，用helm反而要麻烦些。
其实很多高手还在用ido + vertical方式，和ivy就很像。主要还是符合原生Emacs本身的逻辑和习惯吧。
ivy现在也准备规范化开发进程了
排版好乱啊, 这种格式该怎么排版?
counsel-ag error message · Issue #1287 · abo-abo/swiper · GitHub, 也不是完全没法解决, 只不过解决方法比较野蛮. 同时我在helm目录里搜了一下icomplete, 没有结果, 看上去helm跟它井水不犯河水, 没有影响.
可能跟个人习惯有关, 我看到那么大的minibuf有种不适感, 简单点说, 有点像把一个窗口的标题栏变成了半个屏幕那么高, 然后在里面显示了很多有用信息, 心理上感觉很憋得慌. 我是希望如果有足够多的信息要展现, 就用独立的窗口或者frame, 否则会有压抑感.
单独窗口显示和frame显示, helm内部都支持了, 所以不需要扩展就可以使用.
另外, 关于emacs本身的习惯问题, 对我来说, 还是前面那句: 输入时, 少量辅助信息可以在minibuf里展示, 如果有足够多的信息要展现, 就用独立的窗口或者frame. 比如内置的icomplete和ido, 默认不显示太多内容, 也不占多大地方, 而当信息很多时就用其他窗口来展现, 比如icomplete或ido补全时按tab, 会单独开一个窗口显示所有补全项. 至于ido-vertical, 没有集成到emacs里, 用的人也不多, 算不上emacs的经典使用习惯吧?
helm还是用minibuf来输入的, 这个体验没变, 它同时把大量的辅助的预览信息用其他窗口显示, 我感觉这个操作很自然. 对于ivy, 其swiper命令也用了类似的模式, 一边在minibuf输入, 同时在其他窗口里显示预览信息, 但是它在minibuf里显示的信息太多了.
我说的headline不是emacs自身的headline, 而是在helm结果里, 分割多个后端结果集的那个line. 比如helm有个类似helm-buffer-and-recentf(实际不是这个名字), 效果是, 一部分结果是来自buffer list, 另一部分是来自recentf, 它会在结果集里把两部分明确分开, 每个结果集前面会有个类似headline的东西, 该line高度比正常文字大1号(单独的face可定制), 其文字内容就是当前的后端名字或简要说明. 只有一个后端的时候, 也会显示该line(应该也可以选择隐藏). 我感觉这个界面直观得不行, 比较喜欢.
说到多后端, 此时结果会很多, 独立窗口才能显示更多的内容, 而minibuf地方有限, 当然, 可以让它更大, 但是别扭.
helm也是有类似于transformer的东西, 自己写的补全函数可以自己实现transformer. 其优势是, helm自带的大部分命令都已经实现了该transformer, 不需要自己定制就有了.
分析下来, 不知道你说的哪些用ivy很好扩展, 而helm不行的, 看上去helm不需要扩展就有了这些功能.
我不认为ido+vertical符合原生Emacs本身的逻辑和习惯, 原因见第2点.
没想到写了这么多, 这两个东西都挺优秀, 感觉好像在鸡蛋里挑骨头, 选择多了, 就开始精挑细选矫情了, 哈哈.
我用 Anything 和 Helm 的一个最方便的是，我喜欢把 buffer, awesome-tab group, recenty, elisp library, mfind 多个后端做成一个自定义的 helm 搜索。
然后我一般只是把我想要找的字符串输进去，helm 按照我的自定义的优先级，从前往后找。 但是我没有在 ivy 发现能够集成多个后端的设计，感觉要把每个后端单独绑定一个按键，我现在年纪大了，不想记那么多快捷键。 Helm我只用配置好了，一个快捷键就能够搜索到我所有想去的地方。
第二个，我比较喜欢展示空间比较大的地方，这样内容多了，视野足够开阔，minibuffer不管怎么搞，都很矮，东西特别多但纵向空间又小的情况下，心理负担特别大。
简单来说，Anything和Helm最让我习惯的是：
这也许是我尝试了 ivy 还是觉得 Helm 好用的最重要的两个原因。
也许ivy高手能够解答我上面的疑惑。
minibuffer和buffer其实是一个很模糊的概念，如果你用过hydra或者transient，你会发现他们的popup是没有modeline，而且贴在minibuffer上方，看起来就像是minibuffer的一部分，然而他们是buffer。
我觉得是因为helm默认把candidates显示在输入的上方，ivy则是把candidates显示在输入法下方，所以一般用ivy看prompt就好了，不怎么用headerline这种东西
没用过多后端的功能，比较类似的应该是ivy的virtual buffers功能，不过我都是选择关掉，多个后端容易在过滤candidates时候产生干扰选项，而且一点都不KISS。有没有多个后端特别有用的例子？
参考你楼上的帖子, 哈哈.
没怎么用过这两个插件. 我还是比较习惯emacs的经典布局和窗口比例, 小小的minibuf在下面, 可能我思想太传统.
我觉得也可能是因为helm有足够的空间来展示这些信息, 所以发挥余地更大, 可以更直观一点.
多个后端其实很简单啊， 比如我的 Helm 配置： lazycat-emacs/init-helm.el at d2cf876b0674a5cbf54ab19e25479c68723d222e · manateelazycat/lazycat-emacs · GitHub
不管你的初始是什么目的，你只用一股脑把你想要搜索的东西丢进去，Helm只要配置的后端能够搜索到，它都能够匹配到你要去的地方，这样脑负担特别小，只要把后端配置好，Helm自动会根据后端的实现情况来决定是同步还是异步搜索，这也是当年创建Anything的最主要目的。
我看到大家一直在用ivy，觉得ivy反应速度快，或者ivy有很多高级玩法。
但是我看了那么久的论坛，我没有看到ivy可以同时匹配多个后端的情况，我想这就是我发这个贴想要得到的答案。
Helm虽然多个后端，或者某些后端会拖慢速度，但是Helm最大的优势是你几乎不用管那个后端去找到你想要找到的文件或者位置，你只用一个快捷键就可以做到从小范围到大范围的智能搜索。
而且我觉得大家讨论Helm和Ivy性能的时候忽略了一个重要的问题，Ivy快并不是因为他的代码多好，而是它的一个功能只对应一个后端，而Helm往往是多个后端一起搜索的，如果是初学者，很容易因为配置不好而导致Helm很慢，像我这样只配置自己用的后端，不用的不加的方式，其实每次都是秒开。
也许大家能够纠正我对ivy的认识。
一直挺想用helm来克隆mac上alfred的功能, 体验可能不能与之媲美, 不过至少大部分功能应该可以实现.
*helm-xxx* buffer我尝试用ivy的时候发现这个作者放了很多自己的私货进去，比如hydra，avy都放进去了。后来才把这些依赖去掉单独分包成ivy-hydra等等。
我还是比较喜欢helm，因为我觉得helm展示grep结果方式更舒服，而且也可以选择某几个文件进行grep，在看日志的时候特别有用。而且helm有个helm-split-window-inside-p的选项，多个window时看起来更舒服点。
你说的没错，ivy现在没有简单的方法可以达成这件事，以前有人在github上问过类似的问题
combine switch-to-buffer, recentf, bookmarks together #347
Question: combine counsel-git and recentf #1970
我想依照abo-abo的理念他应该也不会特地做这样的功能
谢谢大家的热情讨论，我觉得我找到了答案，能够解决我问这个问题的原因。
Helm/Anything的设计理念是用统一的输入和匹配的方式做一个框架，所有后端的操作都是一样的，唯一的差别是大量文件的后端需要做异步更新（mdfind) 的时候，后端实现会比较复杂吓人。
Ivy的设计理念是，每个命令只绑定一个后端，但是通过不同的交互方式把每种后端的特性发挥到极致，但是因为不同后端的交互方式不一样，导致多个后端合并在一起时几乎不可能，因为即使补全捏合在一起了，但是针对不同补全的交互行为缺很难捏合（比如 swiper 和 counsel-find-file的交互行为就很难统一）。
所以，本质上是两个框架的交互设计理念不一样，而不是哪一个更快更慢 （单后端Helm一样也飞快，多后端ivy不见得比Helm快）。
Helm因为统一交互行为，所以Helm插件的特性可能不会极致，但是正式因为交互行为统一，所以多后端的搜索很容易在统一框架上互相配合而做到多后端的模糊匹配。
Ivy因为每个命令都是单一的后端，所以很容易把单一功能的方便性发挥到极致，同时因为每个命令只有一个后端，所以不管怎么讨论，ivy一定是比Helm快的。
讨论到这里，我觉得比较清晰了。
像我这种风格随意，比较喜欢一个按键搞定模糊搜索的，我觉得Helm比较合适，因为多后端的优势非常明显，至于速度，我的建议把那些平常用不着的后端去掉，像我这样集成常用后端即可 lazycat-emacs/init-helm.el at d2cf876b0674a5cbf54ab19e25479c68723d222e · manateelazycat/lazycat-emacs · GitHub ，真要用单独的某个后端，单独调用。这样速度就飞快了。
如果像很多ivy高手，注重绝对速度，同时喜欢只用一个后端的同学，ivy无疑会比Helm好很多。
最后谢谢大家的高质量回复，学习到很多。
company 和 auto-complete
company有单独的company-xxxx命令
auto-complete好像没有
现在company应该用的更多
我认为楼上纯粹是不太喜欢minibuffer，大可以用posframe来代替。ido+vertical在国外是很流行的，这也是ivy的由来之一。抛开习惯问题不谈，ido、ivy本身来说都很优秀，设计简洁，代码稳定，易于扩展，功能也足够。helm也许更功能更多，但是代价就是更多的资源占用和更多的代码。两者都用过多年，你就会明白其中的道理。helm很多看似很强大的功能对很多人不一定有用或者说用得上。这也是为什么ivy越来越流行的原因吧。就我个人而言，我宁可使用ido也不愿全部转用helm，顶多某些功能借用，比如helm-swoop，helm-ag等。大多数情况下，helm真的是越用越慢。
当然，还是那句话，开源的世界本身就是自由的，你大可以根据自己的喜好选择自己最喜欢的东西。
懒猫何不暂且放下自己的习惯或者某些偏见，安静试用一段，会更有体会，然后选择最适合自己的。我就是在使用ido、helm、ivy多年后做现在的选择。
可能是我本身是Anything的开发者吧，习惯已经养成了，很难改变。 偏见倒不至于，只要是好的插件我都愿意尝试，只不过想看看各位ivy高手是怎么用ivy， 我用过一段时间的ivy，只不过我最终的选择还是Helm
感谢大家的回复，此贴不是引战帖，看到了很多ivy高手的回复，比我自己折腾的彻底，最近太忙了，暂时还是选择Helm。
如果有一天有一个新的插件具备如下特点，我估计大家会更喜欢用：
哈哈哈，也许我这种老年人，以后的口味也会换掉，说不定呢。
最后，谢谢大家，讨论的很彻底，很受益。