From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: feature/icomplete-vertical Date: Mon, 5 Oct 2020 14:23:41 +0200 Message-ID: <20201005122341.7palvy6vjjfmy6sl@Ergus> References: <20200920130435.heye7bk73pm252km@Ergus> <83sgbczj0i.fsf@gnu.org> <83lfh4zfml.fsf@gnu.org> <838sd4z6lz.fsf@gnu.org> <20201001164804.mqqyxtet4ttweuyv@Ergus> <20201005044823.b2ougsrgcpvsuj74@Ergus> <87h7r9ghyp.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22082"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gregory Heytings , Eli Zaretskii , emacs-devel , Yuan Fu , Juri Linkov To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 05 14:26:57 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 1kPPZx-0005cW-0T for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 14:26:57 +0200 Original-Received: from localhost ([::1]:37252 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPPZw-00045L-2Y for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 08:26:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPPX5-0002Oq-Hc for emacs-devel@gnu.org; Mon, 05 Oct 2020 08:23:59 -0400 Original-Received: from sonic305-2.consmr.mail.bf2.yahoo.com ([74.6.133.41]:40177) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kPPX2-00050Z-Na for emacs-devel@gnu.org; Mon, 05 Oct 2020 08:23:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1601900631; bh=ZzLWsVZcku1C9NeNHRrIcDNvnkggl/BODEpEvytKZ6g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=ca5DAdjq+mClYl7LgaiSmCaVIONI8PIJxC/VgQcuitFb5b5e7BI2YEZeAPivT+MDQPI0aoDaZA6Buj+8qioSvCD5dcZ/Ef/BBdjcWKn6ox7RPEz4Pn0t8UH3zDJjsmSww0yQyPKQO5bjipAoPS0h0v+/WqwDfHDSQHUQIch9V0eXx4U4Y40DvrzLdhLLWznKwMbZAr8QVsmreT+sV8F2Gp+FDRA0GGlrUNZiK8M8Kerfb4cswatAoiFBSZKfWTJCnk/8SvB7M/XwHFNJno1Ddi2OLVLoHyb6I0bWdOxB1a8ALj9osNAEEzgL6dsSLA7gAzMnTOfSqoMOITjamkSxlg== X-YMail-OSG: 6Pid1hYVM1mf95HI11QY7R0GLT1olrwEtChhaD9HMNe6aF693c7F7ulvY8gA.fS GyJEzccaX6cvqkSs4jWkqPuzV8mTbMnrIyqlbBlwNjsLozzLfURdbR3e.W848ES4GVh1bh2ANoEh XEy674VmpVsxErEWUuUHb4YWEu2.k47WWUt6mBTAsh.ysm6tAYQ2m8AHX2FwBjRVPg5h_y.jFPyP tkUc6uLGkDattLOKMthZZTUD9.Smjr7exUlIvllGh..36n9T98_mwUTyAArRNFojIVa_EzoyPBW8 bNXWVMXvtu2c.zfbwZ2_PIATCxrZ4o2ICMom7SM2PhDm00kynZsTeoGXLpr1rMYJNbtzz2lpQYoD LOWzzYU5eo0vV0UFhsPpsYv4xwnSpJarfK75QpurgNoiqD55d03twTWPZW_We9enkndl8kHPoFMn Ub6DaS2PkN67Xlb6BT.aAR0Lv9H0iFBFnCrVxvrjIrTZRfb9Lvp2lBTJuh1rqr9Yi8YdtMB0SU38 QBgDeCwzxThMS5OoSFn7Q4aDTuNzWRINb2Jhh9Ez52DwMNOGJGykmvTzVKNwWfxL9GNYTIE0u8fC hAjMCQ_L_TyY8sv9eihNlcua4EFUF3n0_dQwAEyGWCwJXuOkZOadGHRdn0a5tPkut2GIiN3jd7Z_ QLYWdYHij7wl73C9AKJK7Kx6DGHFsMRR0CAWV8He7Vg2PkdhL39xVffTzMx8bfzveZRFHaPlBdio ji7Hn.AlP4S2aUFz3c4.tW0JIDUT8qYZ.DV6eFzI57qp.T0NdS8lvCcq6sLtCqdhfRPhp0UYtqrv 6RRkdHA3XM0dLOXW5SKedoi._Cjs7sVq0AHXNdKM.N Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Mon, 5 Oct 2020 12:23:51 +0000 Original-Received: by smtp424.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6a9cb786ee82eea5d115467b51f4061a; Mon, 05 Oct 2020 12:23:50 +0000 (UTC) Content-Disposition: inline In-Reply-To: <87h7r9ghyp.fsf@gmail.com> X-Mailer: WebService/1.1.16718 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Received-SPF: pass client-ip=74.6.133.41; envelope-from=spacibba@aol.com; helo=sonic305-2.consmr.mail.bf2.yahoo.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/05 08:23:51 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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:257118 Archived-At: Hi Joao The changes you show are the old version of the branch where I was trying some experiments... I should have called it "scratch" to that first version. I understand your concerns now. But not, this is not the new version I cleaned all of it in a recent forced push some weeks ago. Please give a look at the new version. It is simpler and doesn't give any change in the interface. Ergus On Mon, Oct 05, 2020 at 10:06:22AM +0100, Jo�o T�vora wrote: >Ergus writes: > >> On Mon, Oct 05, 2020 at 12:47:39AM +0100, Jo�o T�vora wrote: >> >> Hi Joao: >> >> Please look at the previous messages in this same thread to see the >> problems with your approach. >> >> So far there is: >> >> 1) The problem when using different font in minibuffer reported by >> Jixiuf 2) the long line issue from Gregory (but also mentioned before) >> 3) the ellipsis issue mentioned by Eli >> 4) The prompt issue (which seems is not going to be solved as it is more >> a design choice or a feature than a real issue) >> 5) Respect the user customs max-mini-window-height and >> resize-mini-windows so we shouldn't call enlarge-window and as an >> core package we must not conflict with such customs. >> 6) The removal of {} in vertical mode because in that case they are >> redundant. >> 7) The compatibility with packages like maple-minibuffer reported by >> Dimitry. >> 8) The case when using multiline separator. >> 9) Move the first candidate to a newline instead of keeping it inline. >> >> The patch I propose is not complex at all considering all the above >> conditions. The only complexity comes from the height calculation in >> pixels which is something that will need to be done in any case either >> for 1, 2, 3 or 4. > >Thanks for listing these again, for my benefit. I've not been following >this very closely, and needed a summary to give me context after trying >your patch again, as you requested. > >To be clear: I'm not "against" this functionality or even against it >becoming a part of Emacs or Emacs core. I think solving the problems >you list above is fine (though I haven't been by them, at least not yet) > >I'm not too much concerned about the complexity of implementation (such >as the height calculation). I am concerned the changes to the user >interface, of which your patch seems to bring many, or at least more >than I would have expected. It seems to be that your solution mixes >bugfixes and new features, which is what I object to. I think your >solution could be trimmed down so that it solves _only_ the technical >problems you list above without adding new user interfaces. > >In other words, don't see why the points above, which sound like >basically bugs, need any new "defcustom". This is why I asked you to >(re)list them. Then I can start with my naive implementation and fix >them one by one, without adding new interfaces. Of course, then I will >be repeating some work you've already done, so this is why I'm arguing >for this separation in _your_ work. > >Could you structure your work so that one part fixes the above problems, >and another part adds the new features, like customizing bracket types >and such, and is should be discussed as a separate matter. > >After my sig, some comments that illustrate my points. > >I took this diff with git diff master...feature/icomplete-vertical > >Jo�o > >> -(defcustom icomplete-separator " | " >> - "String used by Icomplete to separate alternatives in the minibuffer." >> - :type 'string >> - :version "24.4") >> +(defcustom icomplete-vertical nil >> + "Enable `icomplete' vertical mode." >> + :type 'bool >> + :version "28.1") > >I would think it more elegant to keep `icomplete-separator` as the entry >point to verticality. Certainly it should be possible to analyse the >string and decide whether it implies verticality and needs special >worries. > > (defcustom icomplete-hide-common-prefix t > "When non-nil, hide common prefix from completion candidates. >@@ -97,6 +97,12 @@ icomplete-first-match > "Face used by Icomplete for highlighting first match." > :version "24.4") > >> +(defface icomplete-common-match '((t :inherit 'highlight >> + :underline t >> + :weight bold)) >> + "Face used by Icomplete for highlighting common completion." >> + :version "28.1") > > >What is a "common match"? Is this exclusive to icomplete verticalness? >Doesn't seem so, is this not a side feature? > >> -(defcustom icomplete-minibuffer-setup-hook nil >> +(defvar icomplete-ellipsis nil) >> + >> +(defcustom icomplete--minibuffer-setup-hook nil >> "Icomplete-specific customization of minibuffer setup. > >Why has this minibuffer hook been made an internal variable? > >> - (define-key map (kbd "") 'icomplete-forward-completions) >> - (define-key map (kbd "") 'icomplete-backward-completions) > >Why have these been removed from icomplete-fido-mode-map? Also, I have >C-r and C-r in that map, will it work in the verticality? I would hope >it would, as it does not in my naive verticality implementation. > >> -;;;_ > icomplete-minibuffer-setup () >> -(defun icomplete-minibuffer-setup () >> +;; Vertical functions >> + >> +(defcustom icomplete-separator-vertical " \n" >> + "String used by Icomplete to separate alternatives in the minibuffer." >> + :type 'string >> + :version "28.1") >> + >> +(defcustom icomplete-list-indicators-vertical (cons "" "") >> + "Indicator bounds to list alternatives in the minibuffer." >> + :type 'string >> + :version "28.1") >> + >> +(defcustom icomplete-require-indicators-vertical (cons "" "") >> + "Indicator bounds for match in the minibuffer when require-match." >> + :type 'string >> + :version "28.1") >> + >> +(defcustom icomplete-not-require-indicators-vertical (cons "" "") >> + "Indicator bounds for match in the minibuffer when not require-match." >> + :type 'string >> + :version "28.1") > >These are examples of "interface bloat" that do not seem to directly >address the 9 problems you listed in the beginning of the message >(again, I am not against these features per se, mind you) > >> +(defvar icomplete--vertical-mode-map > >If this keymap is "internal" (as indicated by the two "--") how am I >supposed to customize the keybindings? > >> +(defcustom icomplete-list-indicators-horizontal (cons "{" "}") >> + "Indicator bounds to list alternatives in the minibuffer." >> + :type 'string >> + :version "28.1") >> + >> +(defcustom icomplete-require-indicators-horizontal (cons "(" ")") >> + "Indicator bounds for match in the minibuffer when require-match." >> + :type 'string >> + :version "28.1") >> + >> +(defcustom icomplete-not-require-indicators-horizontal (cons "[" "]") >> + "Indicator bounds for match in the minibuffer when not require-match." >> + :type 'string >> + :version "28.1") > >Again, these seem like improvements that are not directly related to >verticality. (Maybe they are very good improvements, but still... > >Jo�o >