[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Recommendation for CAPF setup when you don't know completion string in a

From: JD Smith
Subject: Recommendation for CAPF setup when you don't know completion string in advance
Date: Sat, 3 Apr 2021 18:23:28 -0400

I’m endeavoring to more fully link completion in python-shell-mode directly to those provided by iPython, when it is running as the inferior shell.  Modern versions of iPython have fantastic built-in completion capabilities when run in a terminal, but they are not well exploited by python.el.  

Here’s the logical flow I’m trying to achieve:

  1. Take the entire line from point back to the iPython prompt (call it `line’), and hand it to iPython’s internal completer:  get_ipython().Completer.complete(line_buffer=line,cursor_pos=len(line)): 
  2. This returns both the sub-text iPython has chosen to complete (a trailing portion of the line), and a list of completions.  
  3. Use this sub-text length to set the `beg’ and `end’ parameters that a CAPF needs to return, and the returned completions list as the `collection’.

In principle I could just do this directly in the CAPF, i.e. interact with the iPython process, compute `beg’ and `end’, return them with the completion list as the collection. But as Programmed Completions node says: 

Supplying a function for collection is strongly recommended if generating the list of completions is an expensive operation. Emacs may internally call functions in completion-at-point-functions many times, but care about the value of collection for only some of these calls.

So it’s a quandary: I won’t yet know `beg’ and `end’ until _after_ interacting with iPython.  Is there any way to “revise” ‘beg’ and ‘end’ in a collection function returned from a CAPF?  If not, other ideas I could try?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]