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

[Dmitry Gutov <dgutov@yandex.ru>]

It seems like this bug was fixed in bug#55204?

Or at least the problems scenarios are not reproducible anymore.

The downside compared to my latest patch is that it actually expanded 
~/Downl* into a bunch of completions (and the current behavior is "no 
completions"), but that seems minor.

It might be considered a regression, though.

On 26.01.2022 01:05, Stefan Monnier wrote:
> Hi John,
> 
> Could you explain to me some of the code of `pcomplete-parse-arguments`?
> I know that was many years ago but hopefully there's still some fond
> memories of how you designed it.
> 
> To be honest, the only part I sort-of understand are the first
> 5-6 lines.  Then comes the `(let ((begin (pcomplete-begin 'last)))` and
> after that I'm lost: it doesn't look like we're parsing arguments
> any more.
> 
> E.g. Why/when would pcomplete-stub contain a list rather than a string?
> 
> 
>          Stefan
> 
> 
> Dmitry Gutov [2022-01-24 03:50:59] wrote:
> 
>> Hi Stefan,
>>
>> On 23.01.2022 05:23, Stefan Monnier wrote:
>>> And the 100% untested patch below is a suggestion for how to try and fix
>>> those kinds of bugs.
>>> Can someone try and maybe make it work?
>>
>> I've tried the patch, and it seems to work already, as well as fix this
>> particular scenario. (Thanks!)
>>
>> Might as well install it, I think.
>>
>> There is a scenario that is more noticeably broken (yet actually better with
>> this patch): a modification of bug#18951. Instead of
>>
>>    ls *
>>
>> try
>>
>>    ls ~/Docu*
>>
>> ...and [on master] the result is that the asterisk is replaced with the
>>   "common part" of the possible completions automatically. If there is
>>   nothing to expand with, the asterisk is similarly deleted.
>>
>> With your patch, we get the "Buffer is read-only" error in *Messages*
>> instead, which is probably an improvement. Because it doesn't modify the
>> input, nor break Company completions long-term (after the asterisk is
>> removed).
>>
>> The offending functions is pcomplete-parse-arguments. There is some complex
>> global state going on there, but the following addition seems to fix the
>> problem:
>>
>> @@ -790,6 +804,9 @@ pcomplete-parse-arguments
>>   		   (common-stub (car completions))
>>   		   (c completions)
>>   		   (len (length common-stub)))
>> +              (unless pcomplete-allow-modifications
>> +                (setq pcomplete-stub (buffer-substring begin (point)))
>> +                (throw 'pcomplete-completions completions))
>>   	      (while (and c (> len 0))
>>   		(while (and (> len 0)
>>   			    (not (string=
>>
>>
>> Not sure if this new value of pcomplete-stub is always TRT, but it has
>> passed a bunch of my experiments successfully.
>