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: About zcomplete Date: Sun, 20 Feb 2022 14:27:08 +0100 Message-ID: <20220220132708.lvuzvg2fyfpp6k76@Ergus> References: <20220220040515.zum3iodtpscj23j3.ref@Ergus> <20220220040515.zum3iodtpscj23j3@Ergus> <87wnhp4wu3.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="648"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Juri Linkov To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Feb 20 14:30:42 2022 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 1nLmIU-000AaQ-8M for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Feb 2022 14:30:42 +0100 Original-Received: from localhost ([::1]:51970 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nLmIS-000273-8u for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Feb 2022 08:30:40 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35348) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nLmFr-0000Wv-FF for emacs-devel@gnu.org; Sun, 20 Feb 2022 08:27:59 -0500 Original-Received: from sonic304-9.consmr.mail.bf2.yahoo.com ([74.6.128.32]:45845) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nLmFm-0002R5-Sw for emacs-devel@gnu.org; Sun, 20 Feb 2022 08:27:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1645363668; bh=L554CqqGN4AWzfZTkm5T8v5L85DBkZ70Jsv+bGTgu88=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=HRTYpIXEFfNtx/W5yRogknIDtA47WFJWHsOb14rgIhhJAmZ0MeLlVxIRmele3MEL39/W6lYZlOqFyshnmRIRV06+UIlDupTGrfHwNLTX6De6C2kOIBZo1v5Neu33qvvPrDzaQwgC8tLSoi8E9ExnJyaiNFMnwLa8ms25VM1kVE9jUa5Dap9etZG619kL4/JeTaBjoQx6il9+/JVnWkr03VfH8T0ChqtYqD1LUgZcSf36UzOiSgKUnZ83xk6u2mCe5Hkc45n9RkkuLFFLYnqyI/uLKVZzi7geM+QAml03OkVEYUIJMd/OkC2Zz8roVQ6K61o9OMz/QSVEHXWne1tnKw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1645363668; bh=XjW8IxXHPfypSEW6gDpFnwI/MPFpESKvFJprYWcGnyg=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=HmjIl4ryLLf+DNjq1H15MmH6MidaL0X8VrBtt1H9ofttvYD3uINqciVuih7CyMoxixDok49Pmgc1153opXHwBmX6V7ytJ/CIoo0fGj/+H3ePyO3CbfiusAG+YY1puI0TROk39d+qW8MsxUhcYt+R4Xzq3+ST5gEkq/Xszt0UJiArgJYLoytTt9EME3zwLts234ccjpDRalHMU4u95ErqylBqJxUECYW64yS7VsHzfFFcW+nxsL20RnsTwvj2Lbziz+9Mn3/yR6rpL4iTMJ8BONUGyMS8mosiZRORsnjHAPuIfuJWffzNGtimr+RKVD4ZdTr82DIDmf78W68qSxXHxQ== X-YMail-OSG: uEXobe8VM1mGUiMqFqx5lHNoJFT4kdVSiCBp_KbNhfjXu0pFQDIEkCCHEYJU_03 MQiCAN2.GKaXp7mgLJ2iAgR9362ZLNcJriatpflSkMmYOVaWpRdBLg33iYW1HwH5hQdlbqBTCVqk pIT4XijQP17al8uu1XAuF61e3VCwUIeDGwVC9eOo4jfQCIJm6whHycxNSI22X68h2EhWLXZ4tAmz 5YaDCepRjk8dQRatRDzFm4GkQMRfzwAE7wPWw1.Xn7EMLCSW8U4A6SEkzjWl85xJ2j0ErFFxFigA 23BBXaUZ2yG9JNxTi5seyFxXh_TTjbSrdN3qCQQHeaom3E3uSNzvh1RK6pzgQZv8WDyA8E549sqp vuuzU5SVlvLS9hiXCq_GEwuqAuwF2XhdPMoVuw0ZZ8leprIFD8wzPL8nmHvdnUOPw8RuClPWTNBQ sQ_CWOAlkxjk4l2WFK9Uj4IiCIHCSOr7WOo8la3lidRxGurlaFfnM5OBCCdouNkulW_DX9F5MnnC dE0wotcQNyElbsTe3UVxlBmky5XpdpgMUvrcHIr7gtLcnH2GPY4_rv5i4kAsmJmLQ6r0VKgSsoCn trA0PfoS_14cd8NFtAdWH51g4wTztFK0HCA8MyjpNGsnyeeC6ZNrVv16JRRWwnZ__nhmYbMALrpW 8pDtLC5UUxBoMI33H_6dpY6fhB_k2hrSzgn.gDAq7Wix4u3DfoKUiTUfbD0A.QJrd4szbImO9f0T zzUQY1N_sgHBkZgW0tqfFv9AULK1TjlhpXRuQvkTIdU8kMRtJPf8Vp5pZ9NeWNSYSXhvsX9_fdIo ykrXtMk4hH9d7x8Dy6Rqgwo3m.7dUhcgQVkaedN2HO X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Sun, 20 Feb 2022 13:27:48 +0000 Original-Received: by kubenode506.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 55ce22e8db434cee97ba90476fe4456c; Sun, 20 Feb 2022 13:27:46 +0000 (UTC) Content-Disposition: inline In-Reply-To: <87wnhp4wu3.fsf@posteo.net> X-Mailer: WebService/1.1.19797 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.128.32; envelope-from=spacibba@aol.com; helo=sonic304-9.consmr.mail.bf2.yahoo.com 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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:286514 Archived-At: On Sun, Feb 20, 2022 at 11:11:00AM +0000, Philip Kaludercic wrote: >Ergus writes: > >> Hi recently I have been trying to move back to default completion. As >> I had many issues with fido and icomplete. >> >> The default completion system received a nice improvement recently with >> the completion-autoselect... and I am wondering a simple mode like >> this may be added to vanilla (or at least it gives an idea to a better >> lisper to implement something better, this is just a proof of concept.) >> >> ``` >> (require 'simple) >> (require 'minibuffer) >> >> (defvar-keymap zcomplete-map >> :doc "Keymap used in *Completions* on zcomplete" >> :parent completion-list-mode-map >> "z" nil >> "n" nil >> "p" nil >> "q" nil >> "g" nil >> "h" nil >> "DEL" nil >> ) > >When completion-auto-select was first added, there was a discussion >about adding automatic narrowing in the *Completions* buffer. Given a >mode like zcomplete, that decides to unbind all single-character >bindings, this might be possible (as an alternative to what you do in >zcomplete--try-on-minibuffer). > >Whether or not this should be coupled to removing the mode line of the >completion buffer is a different question. > Actually a more `urgent` thing in my opinion may be to allow *Completions* to update without needing to narrow first. Then I could add a post-command-hook in the minibuffer to update *Completions* when it is visible. With that we only need a highlight and the zsh experience may be almost done with minimal changes. >> (defun zcomplete--try-on-minibuffer () >> "Try to execute the binding on minibuffer." >> (switch-to-minibuffer) >> (if-let ((command (lookup-key (current-active-maps) >> (this-single-command-keys)))) >> (progn >> (minibuffer-hide-completions) >> (call-interactively command) >> t) >> ;; back to completions >> (switch-to-completions) >> nil)) >> >> (defun zcomplete--completions-pre-hook () >> "Try on minibuffer when the command is not in *Completions* map." >> (when (eq this-command 'undefined) >> (zcomplete--try-on-minibuffer))) >> >> (defun zcomplete--hack (data context signal) >> "Alternative to command-error-default-function. >> This will try to execute on minibuffer, else emits the error" >> (unless (and (string= (buffer-name) "*Completions*") >> (zcomplete--try-on-minibuffer)) >> (command-error-default-function data context signal))) >> >> (defun zcomplete--completions-setup-hook () >> "To call on completions setup." >> (add-hook 'pre-command-hook #'zcomplete--completions-pre-hook nil t) >> >> (setq-local command-error-function #'zcomplete--hack) >> (setq-local mode-line-format nil) >> (use-local-map zcomplete-map)) >> >> (define-minor-mode zcomplete-mode >> "Completion highlight mode to enable candidates highlight in the minibuffer." >> :global t >> :group 'minibuffer >> >> (if zcomplete-mode >> (progn >> (setq completion-auto-select t) > >This should probably be reverted when zcomplete-mode is disabled. > Agree. But we need to cache the original value tho... I have been thinking to implement a general solution for that issue similar to connection-local-variables, because it is a general issue many packages need to deal with. >> ;; (overlay-put zcomplete-overlay 'face 'zcomplete) >> (add-hook 'completion-setup-hook #'zcomplete--completions-setup-hook t)) >> >> (remove-hook 'completion-setup-hook #'zcomplete--completions-setup-hook))) >> >> (provide 'zcomplete) >> ``` >> >> It lacks some features (like highlight the current candidate or >> automatically update completion buffers when visible) to be really a >> zsh-like feature, but at least we don't need to press C-g every time we >> want to edit the minibuffer. >> >> With this a tab shows the completions and goes there, and any attempt to >> edit or not defined command tries to execute on the minibuffer... >> >> Parts of this could be implemented with advises, but I know we try to >> avoid those on vanilla code. > >If something like this would be added to the core, it would be better to >patch the relevant sections directly. > >> WDYT? >> Best, >> Ergus >> >> > >-- > Philip Kaludercic >