Re: lib/54510 (libedit: filename completion broken in quote/double quaote)

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

The following reply was made to PR lib/54510; it has been noted by GNATS.

From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: abhinav%netbsd.org@localhost, Rin Okuyama <rokuyama.rk%gmail.com@localhost>
Subject: Re: lib/54510 (libedit: filename completion broken in quote/double quaote)
Date: Fri, 03 Jan 2020 18:32:39 -0500

 Rin Okuyama <rokuyama.rk%gmail.com@localhost> writes:
 > (2) In fn_complete(), unescacpe_string() is invoked via
 > find_word_to_complete(). After that, the cursor position and end of
 > buffer are substituted to *point and *end, respectively, that are
 > calculated based on the string before unescaped. Doesn't this break
 > 3rd party softwares that provide completion_matches and/or
 > attempted_completion_function?
 
 Indeed, I was about to submit a new bug when I noticed this comment.
 This patch *does* break things for application-specific completion
 functions, because it strips backslashes from the input word whether
 that's appropriate or not.  In the Postgres project's "psql"
 application, one of the things we want to do is tab-complete
 metacommands that start with backslashes, for instance "\pa<TAB>"
 should produce "\password".  That works fine with readline, and it
 worked with libedit up till this patch; but now the completer just
 sees "pa" so it doesn't know what to do.
 
 Given the precedent of other nearby behaviors, maybe the right
 fix is to skip the unescaping when attempted_completion_function
 is non-NULL.  I haven't tried to code that though.
 
 (We've worked around this, for the moment, by the expedient of
 ignoring the supplied text altogether in favor of looking into
 rl_line_buffer [1].  But that's an ugly hack so I'd like to
 revert it.)
 
 			regards, tom lane
 
 [1] https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommitdiff;h=
 =3Dddd87d564508bb1c80aac0a4439cfe74a3c203a9