From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: <jakanakaevangeli@chiru.no>
Cc: Christophe <ch.bollard@laposte.net>,
50470@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>
Subject: bug#50470: 27.1; 'company-mode' 'eshell'
Date: Fri, 10 Dec 2021 08:10:43 -0500 [thread overview]
Message-ID: <jwva6h8vcbd.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87wnkc3fa6.fsf@miha-pc> (jakanakaevangeli@chiru.no's message of "Fri, 10 Dec 2021 11:50:09 +0100")
> 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
next prev parent reply other threads:[~2021-12-10 13:10 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-08 6:23 bug#50470: 27.1; 'company-mode' 'eshell' Christophe via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-08 16:00 ` bug#50470: eshell Christophe via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-08 16:07 ` Christophe via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-09 1:57 ` bug#50470: 27.1; 'company-mode' 'eshell' Dmitry Gutov
2021-09-09 5:48 ` Christophe via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-09 12:06 ` Dmitry Gutov
2021-09-09 13:09 ` Christophe via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-09 23:30 ` Dmitry Gutov
2021-09-10 5:11 ` Christophe via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-05 22:06 ` Dmitry Gutov
2021-12-10 10:50 ` jakanakaevangeli
2021-12-10 13:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-12-13 2:45 ` Dmitry Gutov
2021-12-13 3:14 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-23 3:23 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-24 1:50 ` Dmitry Gutov
2022-01-25 23:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-04 22:29 ` Dmitry Gutov
2022-06-05 0:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-05 0:36 ` Dmitry Gutov
2022-06-05 0:53 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-05 23:45 ` Dmitry Gutov
2022-06-06 1:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-06 9:07 ` Dmitry Gutov
2022-06-07 15:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-07 22:39 ` Dmitry Gutov
2023-03-17 6:26 ` Jim Porter
2023-03-18 1:01 ` Dmitry Gutov
2023-03-18 6:36 ` Jim Porter
2023-03-19 18:39 ` Jim Porter
2023-03-20 0:30 ` Jim Porter
2023-03-20 1:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-21 2:30 ` Jim Porter
2023-03-28 0:41 ` Dmitry Gutov
2023-03-28 4:06 ` Jim Porter
2023-03-28 6:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-28 17:43 ` Drew Adams
2023-03-28 19:35 ` Jim Porter
2023-03-28 21:21 ` Dmitry Gutov
2022-06-05 23:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-07 22:10 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwva6h8vcbd.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=50470@debbugs.gnu.org \
--cc=ch.bollard@laposte.net \
--cc=dgutov@yandex.ru \
--cc=jakanakaevangeli@chiru.no \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.