From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#12638: 24.2.50; FR: Some suggestions for icomplete-mode Date: Wed, 24 Oct 2012 09:09:11 -0400 Message-ID: References: <87391ieck9.fsf@gmail.com> <87mwzdrly5.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1351084220 15912 80.91.229.3 (24 Oct 2012 13:10:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2012 13:10:20 +0000 (UTC) Cc: 12638@debbugs.gnu.org To: Jambunathan K Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 24 15:10:27 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TR0j4-0000MH-Qg for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Oct 2012 15:10:27 +0200 Original-Received: from localhost ([::1]:43151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TR0iw-0002xZ-Mg for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Oct 2012 09:10:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51325) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TR0ip-0002w2-7u for bug-gnu-emacs@gnu.org; Wed, 24 Oct 2012 09:10:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TR0ij-00068M-Ew for bug-gnu-emacs@gnu.org; Wed, 24 Oct 2012 09:10:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TR0ij-00066Q-Br for bug-gnu-emacs@gnu.org; Wed, 24 Oct 2012 09:10:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TR0kc-0003na-2c for bug-gnu-emacs@gnu.org; Wed, 24 Oct 2012 09:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Oct 2012 13:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12638 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12638-submit@debbugs.gnu.org id=B12638.135108428214554 (code B ref 12638); Wed, 24 Oct 2012 13:12:02 +0000 Original-Received: (at 12638) by debbugs.gnu.org; 24 Oct 2012 13:11:22 +0000 Original-Received: from localhost ([127.0.0.1]:58978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TR0jw-0003mf-EX for submit@debbugs.gnu.org; Wed, 24 Oct 2012 09:11:21 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:33137) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TR0js-0003mO-9f for 12638@debbugs.gnu.org; Wed, 24 Oct 2012 09:11:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu0/O+LFW/2dsb2JhbABEsEiDSYEIghUBAQQBViMFCws0EhQYDSSIHAWxSog/kEQDozOBWIMF X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="202612710" Original-Received: from 206-248-177-86.dsl.teksavvy.com (HELO pastel.home) ([206.248.177.86]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 24 Oct 2012 09:09:12 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 073CC58CA3; Wed, 24 Oct 2012 09:09:11 -0400 (EDT) In-Reply-To: <87mwzdrly5.fsf@gmail.com> (Jambunathan K.'s message of "Wed, 24 Oct 2012 01:38:02 +0530") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:65964 Archived-At: > Speaking of screen estate, I would like to get full view of the > candidate, including prefix. We could add a config var for it, but the default should be to use the shorter display eliding the shared prefix. > This helps me make sense out of the candidate particularly when > partial completion [I meant substring] is on. I don't understand: when substring completion is used, icomplete already displays the full name (since there's no shared prefix to elide). > Implementation wise, I may have taken a different (probably amateurish) > route. Comments below. > +(defcustom icomplete-decorations > + '( "{" "}" " | " " | ..." "[" "]" " [No match]" " [Matched%s]") > + "List of strings used by icomplete to display alternatives in minibuffer. > +There are 8 elements in this list: > +1st and 2nd elements enclose the prospects. > +3rd element is the separator between prospects. > +4th element is the string inserted at the end of a truncated list of prospects. > +5th and 6th elements are used as brackets around the common match string which > +can be completed using TAB. > +7th element is the string displayed when there are no matches. > +8th element is displayed if there is a single match." > + :type '(repeat string) > + :version "24.3" > + :group 'icomplete) I don't think I want to have every such little bit customizable. E.g. I haven't heard anyone objecting to [...] and {...}, and the "No match" and other such messages in the normal completion aren't customizable either. So, I'd only provide customization for the separator " | ". > +(defcustom icomplete-cycle t > + "Non-nil if cycling is to be enabled in `icomplete-mode'. > +When cycling is enabled, keys \"C-j\", \"C-s\" and \"C-r\" are > +bound to `icomplete-this-match', `icomplete-next-match' and > +`icomplete-prev-match' respectively." > + :type 'boolean > + :version "24.3" > + :group 'icomplete) Why didn't you use the patch I provided? By using a new keymap, users can easily configure which keys they want to add/disable/... > @@ -149,7 +178,7 @@ > "Return strings naming keys bound to FUNC-NAME, or nil if none. > Examines the prior, not current, buffer, presuming that current buffer > is minibuffer." > - (when (commandp func-name) > + (when (commandp (intern-soft func-name)) > (save-excursion > (let* ((sym (intern func-name)) > (buf (other-buffer nil t)) Actually, a better patch just removes this test, since the test is already performed right before calling the function (and the old code behaved as if the test was never there, since it received a string and a string is always a valid command). > +;;;_ = icomplete-name > +(defvar icomplete-name nil > + "Minibuffer user input.") Why? It's only set and never used. > +;;;_ = icomplete-matches > +(defvar icomplete-matches nil > + "Stored value of completion candidates that are on display. > +This is set by `icomplete-exhibit', modified by > +`icomplete-this-match', `icomplete-next-match' and > +`icomplete-prev-match' and cleared by `icomplete-try'.") Why not use completion-all-sorted-completions? > +;;;_ = icomplete-most-try > +(defvar icomplete-most-try nil > + "Value of `completion-try-completion'. > +When there are multiple matches, it signifies common match string > +which can be completed using TAB.") > + > +;;;_ = icomplete-try > +(defvar icomplete-try nil > + "Part of `icomplete-most-try' that is displayed at the prompt. > +Same as `icomplete-most-try' but with whole of `icomplete-name' > +stripped from front, when possible.") Why? Recomputing them from completion-all-sorted-completions has never been a performance problem. > + (local-unset-key "\C-j") > + (local-unset-key "\C-s") > + (local-unset-key "\C-r")) You've just removed the C-j, C-s, and C-r bindings that the user has painstakingly installed in his minibuffer-local-completion-map. > + (local-set-key "\C-j" 'icomplete-this-match) > + (local-set-key "\C-s" 'icomplete-next-match) > + (local-set-key "\C-r" 'icomplete-prev-match)) And you make it impossible for the user to choose other keybindings for icomplete's commands. BTW, if you use completion-all-sorted-completions rather than a new icomplete-specific variable, then icomplete-this-match can be added to minibuffer.el (named minibuffer-force-complete-and-exit) where it can be useful even for people who don't use icomplete. > +(defun icomplete-this-match () > + "Input first of the displayed matches to minibuffer prompt. > +See `icomplete-matches'." > + (interactive) > + (delete-region (minibuffer-prompt-end) (point)) > + (when icomplete-matches > + (insert (car icomplete-matches))) > + (exit-minibuffer)) I think it should still call test-completion and obey minibuffer-completion-confirm if that test fails. Stefan