From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.devel Subject: Re: Recommendation for CAPF setup when you don't know completion string in advance Date: Mon, 10 May 2021 23:33:44 -0400 Message-ID: References: Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31868"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 11 05:34:26 2021 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 1lgJAA-0008Cl-6q for ged-emacs-devel@m.gmane-mx.org; Tue, 11 May 2021 05:34:26 +0200 Original-Received: from localhost ([::1]:51342 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lgJA9-0007y0-1m for ged-emacs-devel@m.gmane-mx.org; Mon, 10 May 2021 23:34:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42364) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lgJ9a-0007HI-TX for emacs-devel@gnu.org; Mon, 10 May 2021 23:33:50 -0400 Original-Received: from mail-qv1-xf2c.google.com ([2607:f8b0:4864:20::f2c]:37589) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lgJ9Z-0007Xv-7X for emacs-devel@gnu.org; Mon, 10 May 2021 23:33:50 -0400 Original-Received: by mail-qv1-xf2c.google.com with SMTP id z1so9527019qvo.4 for ; Mon, 10 May 2021 20:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xDA83rVftM7uSzVhyUBfd5O5guy7rod3fBQL0InJwKk=; b=jOqRQgYSIoLNFreimKiX5nyPNETrMfiCWs5T2pA0YPazCgqdAkQsLa+afaqS08kjxF EULvG7BfWE96v3xKhNrphfLmsiWvYS4WLKvIitQX0GSbiSZxEw5wYDszG3/wxJ5sI8oa 8t5peGspAsMnUn88n0+pf3x/gKTYI9dKIb1zJ4D09bz4UzCaliuq+7Q9UawzyzX8k1p8 Kt8IGmLC3xfkYrQm6p1hpSHLcY2StwD53w1F95KS1cI7PsiClqM5yvdySo/fYp2gxE+X Fht3sJ/bOgUswM5FhhZMwWcc1PIGFSelMOPtxbPHhM9RkTZOLHOI7z4QmZ5XHm/c0J4x n+Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xDA83rVftM7uSzVhyUBfd5O5guy7rod3fBQL0InJwKk=; b=ecsRXCWaZgQ3SsaQB0jCSYPESrrOdtQncCahhFrQAPtqgo5U1Ms0QqeHkgJqpnAYoI Kmj9sW7RPMcd9Dfib9zavHdBl71c55Jyd1kd5IHPLGJBRHCAkWgTHOu1med+55N3xQim wkbg7nZxPGaThfr+LLQ5o9/L+3m8NWjeK4DkzEu6a8NHIVgAoAb81HZemCkNl4ojgwvj Si040C/kVWHXodrqEAZGjBk08PRSrFok1y9edm61NlZWfU55BBf1z6mVJjmWGhmfH2RW CdkjhcH9C9ZI+GG7+yCEsOvWbSWzn2vuJoerPGZ2f8dURhkb2lrw9oX08L/zX2ajK+uk LScg== X-Gm-Message-State: AOAM530hRAhm4fQ+IwTbvMdu0NC87Ew61kjJWZ3w/uEbnQrTnOsB62IV GYuY/lD/J9qzuZjDKJtphA8= X-Google-Smtp-Source: ABdhPJwESU1fRYJG+ZqP8juwUq4clPH2MSvLfHnHboPefJmalLg9MKdYz2gqh30X/5HYFSRsdsFMNQ== X-Received: by 2002:ad4:5588:: with SMTP id e8mr27094292qvx.10.1620704026003; Mon, 10 May 2021 20:33:46 -0700 (PDT) Original-Received: from smtpclient.apple (cm-134-228-25-135.buckeyecom.net. [134.228.25.135]) by smtp.gmail.com with ESMTPSA id f7sm14283779qtm.41.2021.05.10.20.33.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 May 2021 20:33:45 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3654.80.0.2.43) Received-SPF: pass client-ip=2607:f8b0:4864:20::f2c; envelope-from=jdtsmith@gmail.com; helo=mail-qv1-xf2c.google.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, 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:269142 Archived-At: > On Apr 3, 2021, at 7:49 PM, Stefan Monnier = wrote: >=20 >> So it=E2=80=99s a quandary: I won=E2=80=99t yet know `beg=E2=80=99 = and `end=E2=80=99 until _after_ >> interacting with iPython. Is there any way to =E2=80=9Crevise=E2=80=9D= =E2=80=98beg=E2=80=99 and =E2=80=98end=E2=80=99 in >> a collection function returned from a CAPF? >=20 > Indeed, that's a problem. > You might be able to get away with the following: >=20 > Make your CAPF function return a beg..end that covers "the whole line" > and which returns a completion table in the form of a function. > That function will then defer to the iPython code for the grunt of its > work and will return the "real" boundaries via the > `completion-boundaries` method. This will probably require some = caching > in the completion table so we don't call iPython too many times for > a single completion (like once for `completion-boundaries`, once for > `try-completion`, once for `all-completions`, etc...). Thanks for these good suggestions. I have been attempting a solution = along these lines, and I think the performance is fine. I notice that = CAPF first asks for metadata (which are static here), then for the = boundaries. At that point, I don=E2=80=99t know the boundaries, so I = talk to the iPython process, and ask it for all the completions for the = entire line, given my position within it. It returns these, along with = the portion of the full line it has decided to complete. =46rom this, I = compute and return the boundaries. Then, in subsequent calls to my = table lambda, CAPF proceeds with its various ACTION's. =20 Pseudo-code for the completion table function I=E2=80=99m building: (lambda (string pred action) (when (no-result-yet-cached-or-cached-string-is-substring-of-string) (if (eq action 'metadata) `(metadata =E2=80=A6) (unless last-prefix ;; talk to ipython and save the completion info ) (if (eq (car-safe action) 'boundaries) ; munge the boundaries `(boundaries from . to) ; using saved data from ipython (complete-with-action action completion-alist string pred))))) The problem I have encountered is in the final call to = `complete-with-action=E2=80=99. The original string may be an entire = line, such as: for i in ran[Tab] and iPython correctly figures out to complete just a portion of that = string; say ran -> range. I tell CAPF about these boundaries (in this = case, 9 . 0). If, however, I later call complete-with-action (which = just calls try-completion, all-completions, etc.) with the entire line = string (=E2=80=9Cfor in ran=E2=80=9D), together with a completion-alist = that contains iPython=E2=80=99s sub-string completions (like = =E2=80=9Crange=E2=80=9D), it thinks there is no completion. If instead = I just peel off the part of the full line that needs completing = (=E2=80=9Cran=E2=80=9D) and pass that to complete-with-action as STRING, = it recognizes that there's a good completion now, but then _replaces the = entire line_ with the result. How do I get = complete-with-action/try-completion/test-completion/all-completions etc. = to respect my boundaries?