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: tabulated-list-mode needs incremental search option Date: Tue, 10 Nov 2020 22:00:10 +0300 Message-ID: References: <87361liqpt.fsf@gmail.com> <87v9edu11u.fsf@stupidchicken.com> 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="13454"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 10 20:05:15 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 1kcYx8-0003MJ-Rt for ged-emacs-devel@m.gmane-mx.org; Tue, 10 Nov 2020 20:05:14 +0100 Original-Received: from localhost ([::1]:33838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcYx7-00058u-1l for ged-emacs-devel@m.gmane-mx.org; Tue, 10 Nov 2020 14:05:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcYvU-0003cB-NX for emacs-devel@gnu.org; Tue, 10 Nov 2020 14:03:32 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:36853) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcYvS-000508-AC for emacs-devel@gnu.org; Tue, 10 Nov 2020 14:03:32 -0500 Original-Received: from localhost ([::ffff:197.157.34.177]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0009.000000005FAAE3FF.00007F1B; Tue, 10 Nov 2020 19:03:27 +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/10 14:03:25 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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:258985 Archived-At: * Stefan Monnier [2020-11-10 16:18]: > > In general I am advising that every application with choices offers > > among others the narrowing incremental search. > > Very well, but to me this is much too vague to know what it means. Drew also reminded me to express me better. The above statement refers to general applications and not only to Emacs. I am referring to real-time collection narrowing just as icomplete-mode or ido-mode or ivy, helm. > AFAICT, if every application uses `completing-read` when it has > a choice, then it does offer "narrowing incremental search" because > `icomplete-mode` (among other minibuffer completion schemes) does offer > something that narrow the search incrementally. I am using tabulated-list-mode to classify hyperdocuments and browse trees of information. That will arrive to GNU ELPA when polished. But first must come the `emacs-libpq' PostgreSQL database dynamic module which developers are working on it. One way to search is filtering results like in M-x list-packages with / a for example to filter by archive. That uses tabulated-list-mode Filtering the final result of matches is useful in any application offering larger selections. Completion frameworks are excellent improvement for Emacs to narrow the collection of items. Yet not all of them are developing with good principles of work. We think of minibuffer being minibuffer. Of course it can expand and become as large as main buffer. Yet historical and practical use is that we look and focus into minibuffer, it is down there, and it is mini. Above minibuffer there is modeline. People do look into modeline including me. What hapens when using ivy-mode is that modeline jumps up-down when completing. And I need to use external function (without knowing the license) to accommodate ivy to behave more useful. Some things are apparently pretty static in Emacs. For example Help menu and modeline. Does anybody expects Help menu to jump down to middle of screen? In the same way I do not expect modeline to jump in the middle of screen. Minibuffer completion that raises modeline does not enhance legibility, it enhances confusion. Good example how is that solved ind `M-x helm' may be seen here: https://emacs-helm.github.io/helm/images/helm-buffers-list.gif - minibuffer stays where it is, it does not enlarge - modline does not jump up and down - separate window is used for completion More about Helm: https://emacs-helm.github.io/helm/ icomplete-mode is far from being complete in the above context of making the legible visual non-disturbing selection. Here is short demonstration and comparison, video (17M): https://gnu.support/images/2020/11/2020-11-10/2020-11-10-20:10:49.ogv The demonstration is showing: - how Hyperscope for Emacs is using tabulated-list-mode to browse the tree and sets of hyperdocuments - entering sub-tree is done with arrow left, going up the tree is arrow right - if selection or collection is very long, browsing is tedious, it could be 15000 items, I have 19000 items now. - basic filtering is implemented, yet this does not replace the real time incremental matching (aka ivy, helm) - querying with ivy or helm or any completing-read function is possible. What is missing here is ivy-occur so when narrowing have been performed that user gets narrowed list. - there is comparison between ivy where modeline is jumping up and down because minibuffer is enlarging. Those elements of user interface considered static (even if they are not) are not supposed to jump up and down, it confuses user. I do use external function to remedy it and hope that ivy will get it internally. Manual does not warn users that modeline is to jump up and down when using minibuffer. - helm mode shows that modeline remains where it is expected to be just as it is explained to users in the Emacs Manual. As tabulated-mode-list can be used for selection of items, for listing of items, it is good to have real-time incremental narrowing function. Difference between the tabulated-mode-list feature (narrowing incremental real time matchin) and minibuffer completing framework functions is that the first uses full screen and does not mess the modeline and general user interface. In this application it would be better to remain in full screen and to narrow by using minibuffer. When using completing frameworks there are visual disturbances to screen: - screen is divided in half either by modeline jumping up or by split window - minibuffer is not mini any more - modeline jumps up and down With the new feature I am proposing we would enable Emacs Users to create full screen menus and selections from menu. Jean