From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#50470: 27.1; 'company-mode' 'eshell' Date: Fri, 10 Dec 2021 08:10:43 -0500 Message-ID: References: <87h7evegav.fsf@debian-BULLSEYE-live-builder-AMD64> <154bd0e9-2779-5a28-5587-a845a982e39f@yandex.ru> <815516d6-262b-4ef1-786e-ec5b4199847c@yandex.ru> <87wnkc3fa6.fsf@miha-pc> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24173"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Christophe , 50470@debbugs.gnu.org, Dmitry Gutov To: Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 10 14:11:52 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1mvfgk-00065F-TP for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Dec 2021 14:11:51 +0100 Original-Received: from localhost ([::1]:41482 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvfgj-00009C-JK for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Dec 2021 08:11:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54844) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvffz-0008Vd-71 for bug-gnu-emacs@gnu.org; Fri, 10 Dec 2021 08:11:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34326) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mvffy-0008CJ-Ap for bug-gnu-emacs@gnu.org; Fri, 10 Dec 2021 08:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mvffx-00052d-S2 for bug-gnu-emacs@gnu.org; Fri, 10 Dec 2021 08:11:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Dec 2021 13:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50470 X-GNU-PR-Package: emacs Original-Received: via spool by 50470-submit@debbugs.gnu.org id=B50470.163914185419363 (code B ref 50470); Fri, 10 Dec 2021 13:11:01 +0000 Original-Received: (at 50470) by debbugs.gnu.org; 10 Dec 2021 13:10:54 +0000 Original-Received: from localhost ([127.0.0.1]:45872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvffq-00052F-6c for submit@debbugs.gnu.org; Fri, 10 Dec 2021 08:10:54 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvffo-000520-F6 for 50470@debbugs.gnu.org; Fri, 10 Dec 2021 08:10:53 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id ECF6F805D6; Fri, 10 Dec 2021 08:10:45 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 56CCE8044E; Fri, 10 Dec 2021 08:10:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1639141844; bh=3Pxb2B6k9JX/d6x0Qu/JqvG+4pjCXG6mmda1DatTmSQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=YLS9mwedBKH20o1slVCRYzeUdt4n5rgNXv+o5BCImJfoZomb44UeWTxF0laT9IJwg ZRqLgegSHs5031zHuwfgpAXYLDCkVrIyLBUfD/5QTf6YAunZ75CVTKO2d7nHZdk5RX MGORHuxg+Rk2OrfM62a3QaAQ2EwZi/HcwpzobCc+zirRTLbZwnSRIdIFt/zuAH77X4 Yw9RKCYwhK+4ynN184+7GlzvJswsVIbgBekm+/uLPb6huLvktguSdpFR2BzZLXqF2v sUUJQMc9z+n1gaqswlTqaZyW+H1/t7/PPI2w0kMjhEl4oKaJYgNwuZjs0ioviy42R/ KSdw8uepKzfLA== Original-Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2957B1207BE; Fri, 10 Dec 2021 08:10:44 -0500 (EST) In-Reply-To: <87wnkc3fa6.fsf@miha-pc> (jakanakaevangeli@chiru.no's message of "Fri, 10 Dec 2021 11:50:09 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:222061 Archived-At: > In my package capf-autosuggest, I run completion-at-point-functions > somewhat like this: > > (let (;; `pcomplete-completions-at-point' may illegally use > ;; `completion-in-region' itself instead of returning a collection. > ;; Let's try to outsmart it. > (completion-in-region-function > (lambda (start end collection predicate) > (throw 'illegal-comp-in-region > (list start end collection :predicate predicate)))) > ;; Prevent `pcomplete-completions-at-point' from inserting a TAB > (buffer-read-only t)) > ;; `ielm-complete-filename' may illegaly move point > (save-excursion > (condition-case nil > (catch 'illegal-comp-in-region > (run-hook-wrapped 'completion-at-point-functions ...)) > (buffer-read-only nil)))) > > This way, old style capf functions are prevented from inserting a TAB or > moving point. Hmm... capf itself tries to "solve" that problem in the following way: (defvar completion--capf-misbehave-funs nil "List of functions found on `completion-at-point-functions' that misbehave. These are functions that neither return completion data nor a completion function but instead perform completion right away.") (defvar completion--capf-safe-funs nil "List of well-behaved functions found on `completion-at-point-functions'. These are functions which return proper completion data rather than a completion function or god knows what else.") (defun completion--capf-wrapper (fun which) ;; FIXME: The safe/misbehave handling assumes that a given function will ;; always return the same kind of data, but this breaks down with functions ;; like comint-completion-at-point or mh-letter-completion-at-point, which ;; could be sometimes safe and sometimes misbehaving (and sometimes neither). (if (pcase which ('all t) ('safe (member fun completion--capf-safe-funs)) ('optimist (not (member fun completion--capf-misbehave-funs)))) (let ((res (funcall fun))) (cond ((and (consp res) (not (functionp res))) (unless (member fun completion--capf-safe-funs) (push fun completion--capf-safe-funs)) (and (eq 'no (plist-get (nthcdr 3 res) :exclusive)) ;; FIXME: Here we'd need to decide whether there are ;; valid completions against the current text. But this depends ;; on the actual completion UI (e.g. with the default completion ;; it depends on completion-style) ;-( ;; We approximate this result by checking whether prefix ;; completion might work, which means that non-prefix completion ;; will not work (or not right) for completion functions that ;; are non-exclusive. (null (try-completion (buffer-substring-no-properties (car res) (point)) (nth 2 res) (plist-get (nthcdr 3 res) :predicate))) (setq res nil))) ((not (or (listp res) (functionp res))) (unless (member fun completion--capf-misbehave-funs) (message "Completion function %S uses a deprecated calling convention" fun) (push fun completion--capf-misbehave-funs)))) (if res (cons fun res))))) (defun completion-at-point () "Perform completion on the text around point. The completion method is determined by `completion-at-point-functions'." (interactive) (let ((res (run-hook-wrapped 'completion-at-point-functions #'completion--capf-wrapper 'all))) ...)) Maybe this should be improved/refined? Stefan