From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: Feature branches review please Date: Fri, 6 Nov 2020 00:33:56 +0300 Message-ID: References: <20201104161200.tyeo2r5jibdahukb.ref@Ergus> <20201104161200.tyeo2r5jibdahukb@Ergus> <234bba7f-fd5c-ed39-8a5e-8a6ce3125bf1@inventati.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12790"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/+ (1036f0e) (2020-10-18) Cc: Manuel Uberti , emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 05 22:40:48 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kamzu-00039R-46 for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Nov 2020 22:40:46 +0100 Original-Received: from localhost ([::1]:53610 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kamzt-0003Ud-24 for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Nov 2020 16:40:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kamyb-0002K3-KA for emacs-devel@gnu.org; Thu, 05 Nov 2020 16:39:26 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:55821) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kamyZ-0007XD-MZ for emacs-devel@gnu.org; Thu, 05 Nov 2020 16:39:25 -0500 Original-Received: from localhost ([::ffff:197.157.0.43]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0003.000000005FA47109.00000524; Thu, 05 Nov 2020 21:39:20 +0000 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/05 08:59:12 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258762 Archived-At: Alright, it is in master branch, I have it. When I do: {C-h v RET icomplete-separator RET} then I get option to customize. When I enter there: \n without quotes I get this completion: ~doe/\nntp/\ntor etc. so it deos not work well as intended from customize. You maybe wish to verify that for users. Did you try changing it in customize yourself? So it will not work with the advise. It is not well made customization, OK? I consider that bug. If I do in customize {C-q C-j} then I get new line in customize which then does work. Not everybody will know how to tweak that. This of course works directly: (setq icomplete-separator "\n") It does not work smooth as ivy. I wish it could. I am supposed to click TAB even if it matches, clicking ENTER creates new buffer with half of the file name. Ivy allows me to click enter if I am on the match which is faster. icomplete-mode works well with M-j so far. I am asking myself what is the big difference between icomplete and ido now. icomplete is doing what difference? By your advise I have also changed the third parameter for ido-decorations to: {C-q C-j and I have also got vertical ido completion. I expect to be able to move in vertical line, not only type letters. Feeling is rigid, I cannot move up and down with familiar keys likes C-n or C-p like I can do in ivy-mode or in helm My feeling is that icomplete-mode is downgrade of ido-mode as it has less keybindings, or better, icomplete is not complete. Both ido-mode and icomplete-mode are so much worse than ivy mode. Why ivy-mode cannot enter Emacs as it is GNU ELPA? And then in Emacs there are two packages doing basically the same function, ido-mode and icomplete-mode. I cannot know why. I am giving you my opinion and review as user who would like to have: narrowing incremental search with movements up and down, actions and X-completing-read function. Here is video and comparison between ido-mode, icomplete-mode, ivy-mode and helm-mode, size 59M, about 9 minutes: https://gnu.support/images/2020/11/2020-11-05/2020-11-06-00:03:17.ogv Let us first see ido-mode C-j did not work as expected. I am used to ivy-mode, my fault. Maybe it is separator. Even with my customization, C-j is not working. What does ido-mode map says? There is no ido-mode-map and no description of mode map as I expect to get it with {C-h m} but I can see in the source that key bindings are well defined. ido-mode selects text only partially, does not automatically choose from selection if it matches. I may be familiar with ivy/helm and expect that when I press enter on the match that it should work. I have to complete it myself in full by using TAB, coming to EOL so that ido-mode recognizes it. Not what I expect. Only horizontal works for ido-mode. Visually ido-mode can work vertically if third parameter of ido-decorations is changed to C-q C-j but it does not function in selection. So why icomplete vertically when you can improve ido-mode in the same way to be vertical? It looks as more mature package. Then I have tried icomplete in vertical mode. I cannot move with familiar keys up and down. So I cannot see what is down. That is what I expected. Then I have tried again with ido-mode. And it was better, more visible files. Then I've tried again icomplete-mode and I got confused as I could not see nothing by moving up and down, it is far from my vertical related expectations. Then I have tested horizontal I complete and it gives me feeling of not being nearly close to ido-mode. But is better than vertical. But ido-mode is much better than icomplete-mode. Now to ivy-mode. What you see on video with M-o are actions. That is so useful. Let us say you create icomplete-find-files, you may want to delete, rename, copy and do other actions with files. counsel package utilizs ivy-mode to create exactly that, to cd, open, open externally, open as root, to open read only, to delete, to copy, move or mkdir. Those are actions, very necessary and common in other completion frameworks. Then I have checked helm-find-files which is definitely the best. No question about it. But ivy-mode is light, it is in GNU ELPA (easier to install on multiple machines) and way better than ido or icomplete. Summary of these four reviewed: 1. helm-find-files, best but overkill, and outside of Emacs GNU ELPA 2. ivy-mode and counsel are in GNU ELPA, ivy works great. 3. ido-mode works well, it has user functions and looks pretty mature 4. icomplete-mode reinvents the wheel and is already in Emacs. I get surprised. I was reviewing it some days before and I did not get what it is as it looked like bad version of ido-mode. Thank you. Jean