bug#50470: 27.1; 'company-mode' 'eshell'

[Jim Porter]

On 3/19/2023 11:39 AM, Jim Porter wrote:
> Ok, here we are.
Here's an updated patch based on some off-list comments from Stefan. 
Most of them are just small doc/naming tweaks, but a couple are worth 
mentioning here, I think:

On 3/19/2023 12:15 PM, Stefan Monnier wrote:
>> -  (when (memq (char-after) eshell-glob-chars-list)
>> +  (when (and (not (bound-and-true-p eshell-parse-for-completion-p))
>
> Can we (cheaply) arrange so that the var is always defined at this
> point (same for the other uses further down in the patch)?
> Maybe by moving the `defvar` elsewhere (e.g. next to
> `eshell-parse-argument-hook`)?

It's a bit ugly, but I'm trying to follow the conventions in Eshell: 
since completion is an optional extension module for Eshell, other 
modules jump through hoops like this to allow the module to be not-loaded.

Another way to do this (arguably more Eshell-y) would be:

  (when (and (eshell-using-module 'eshell-cmpl)
             eshell-parsing-for-completion)

But that seemed a little overly-verbose for this...

>> +              (if (bound-and-true-p eshell-parse-for-completion-p)
>> +                  "(unevaluated subcommand)"
>
> Any reason we don't return the actual string that we're trying to
> parse instead (i.e. here, the subcommand)?

I wanted something where we could be pretty sure that Pcomplete wouldn't 
treat it specially, since it should be "opaque" to Pcomplete. I changed 
this to be a propertized string with just the NUL character:

  (propertize "\0" 'eshell-argument-stub TYPE)

That should be pretty unlikely to trigger anything in Pcomplete. 
(Arguably, Pcomplete should have some way of marking an argument as "not 
real", but I'm not sure anything outside of Eshell would need that...)

0001-Avoid-parsing-some-Eshell-forms-when-performing-comp.patch
Description: Text document