GNU bug report logs - #60464
29.0.60; Regression - pcomplete-arg fails with argument 'last

Previous Next

Full log

Message #32 received at 60464 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Jim Porter <jporterbugs <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 60464 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#60464: 29.0.60; Regression - pcomplete-arg fails with
 argument 'last
Date: Sun, 1 Jan 2023 18:34:53 +0100

On 1/1/23 18:28, Gregory Heytings wrote:
> 
>>> After working a bit more on this bug, I concluded that what Stefan 
>>> initially suggested, to use the string representation of the value, is 
>>> safer than trying to extract the string corresponding to the argument 
>>> that the user typed in from the command line.
>>
>> This approach seems totally wrong to me.
>>
> Feel free to suggest something else.

Yes, I did. The command line string should be returned.

>> Also the approach is pointless. Why would the caller of the function 
>> want to get the string representation, given that the original value is 
>> available as text property?
>>
> Because the pcomplete functions, in particular pcomplete-here-using-help, 
> expect strings.

Of course. The only reason is to return a value of the correct type. But
you then as well return "foo".

>> I suggest you go back to the way you implemented this before and return 
>> the actual command line string with the value attached as text property. 
>> I don't see why that should be less safe. It is just a matter of 
>> determining the correct buffer boundaries.
> 
> Perhaps I should have explained what I mean by "less safe": it is 
> unexpectedly complex to compute the correct buffer boundaries in all 
> cases.  If you don't believe me, try it yourself.

I believe you that doing this correctly is non trivial. But this doesn't
justify going with your hack.

Daniel

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.