Bug #61483 for Term-ReadLine-Perl: TAB completion for dir/filenames inserts extra space before done

Mon Sep 20 09:20:18 2010 chm [...] cpan.org - Ticket created

Subject:

TAB completion for dir/filenames inserts extra space before done

When using Term::ReadLine::Perl with re.pl and doing TAB completion of file and directory names results in a space being inserted following a successful directory completion (even if the directory has possible files or directories within). The hoped-for (preferred) behavior is demonstrated by using Term::ReadLine::Gnu for the readline implementation as illustrated here. bash$ ls -R test # list the example directory test: a/ b/ c/ test/a: test/b: test/c: bash$ PERL_RL=Perl re.pl $ test/<TAB> # yields this... $ test/ | # where the cursor is at the bar and a # space character has been inserted after # the top level directory name bash$ PERL_RL=Gnu re.pl $ test<TAB> # yields this... $ test/ $ test/<TAB><TAB> # yields this a/ b/ c/ In order to use the path completion with the Perl readline you have to delete by hand the extra space before getting the further completions. Another related point: the list of possible completions for a directory with Term::ReadLine::Perl lists the full path so far prepended to the list of directory entries. This can lead to problems with interactive display for deep directories with long pathnames.

Mon Sep 20 14:42:58 2010 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #61483] TAB completion for dir/filenames inserts extra space before done
Date:	Mon, 20 Sep 2010 11:42:47 -0700
To:	Chris Marshall via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Mon, Sep 20, 2010 at 09:20:19AM -0400, Chris Marshall via RT wrote: Show quoted text

> When using Term::ReadLine::Perl with re.pl and > doing TAB completion of file and directory > names results in a space being inserted following > a successful directory completion (even if the > directory has possible files or directories > within).

Patches welcome! Show quoted text

> Another related point: the list of possible completions > for a directory with Term::ReadLine::Perl lists the > full path so far prepended to the list of directory > entries. This can lead to problems with interactive > display for deep directories with long pathnames.

This is slightly more complicated. E.g., the same happens when one lists (package) variables in Perl debugger (if one has package Foo::Bar::Baz, listing by doing $Foo::Bar::Baz::<TAB> gets an unwindy display). So instead of "blindly" fixing this, the first question is: can one somehow generalize this situation, and have some "higher level" support for this in the completion framework? Then redirect these two situations through the framework? Yours, Ilya

Mon Sep 20 14:42:59 2010 The RT System itself - Status changed from 'new' to 'open'

Mon Sep 20 22:35:25 2010 chm [...] cpan.org - Correspondence added

On Mon Sep 20 14:42:58 2010, nospam-abuse@ilyaz.org wrote: Show quoted text

> On Mon, Sep 20, 2010 at 09:20:19AM -0400, Chris Marshall via RT wrote:

> > When using Term::ReadLine::Perl with re.pl and > > doing TAB completion of file and directory > > names results in a space being inserted following > > a successful directory completion (even if the > > directory has possible files or directories > > within).

> > Patches welcome!

First comes the bug report, then the patch.... Show quoted text

> > Another related point: the list of possible completions > > for a directory with Term::ReadLine::Perl lists the > > full path so far prepended to the list of directory > > entries. This can lead to problems with interactive > > display for deep directories with long pathnames.

> > This is slightly more complicated. E.g., the same happens when one > lists (package) variables in Perl debugger (if one has package > Foo::Bar::Baz, listing by doing > $Foo::Bar::Baz::<TAB> > gets an unwindy display).

That suggests that there is a common mechanism for the problem or, at least, a common approach for completion display which yields this result. Show quoted text

> So instead of "blindly" fixing this, the first question is: can one > somehow generalize this situation, and have some "higher level" > support for this in the completion framework? Then redirect these two > situations through the framework?

That would be nice. I haven't had time to sit down and trace through all the code paths involved in the Term::ReadLine::Perl completion but once I sort out what is going on, I'd like to fix the "extra space" problem first. If I figure out something on the display part of the completion, I'll definitely follow up here with any results. Cheers, Chris

Tue Oct 05 09:23:39 2010 chm [...] cpan.org - Correspondence added

On Mon Sep 20 22:35:25 2010, CHM wrote: Show quoted text

> On Mon Sep 20 14:42:58 2010, nospam-abuse@ilyaz.org wrote:

> > On Mon, Sep 20, 2010 at 09:20:19AM -0400, Chris Marshall via RT wrote:

> > > When using Term::ReadLine::Perl with re.pl and > > > doing TAB completion of file and directory > > > names results in a space being inserted following > > > a successful directory completion (even if the > > > directory has possible files or directories > > > within).

> > > > Patches welcome!

3449c3449,3453 < $replacement .= $rl_completer_terminator_character if @matches == 1; --- Show quoted text

> if (@matches == 1) { > if ( $replacement !~ m{[/\\]} ) { # don't add space if

directory Show quoted text

> $replacement .= $rl_completer_terminator_character; > } > }

Show quoted text

> > This is slightly more complicated. E.g., the same happens when one > > lists (package) variables in Perl debugger (if one has package > > Foo::Bar::Baz, listing by doing > > $Foo::Bar::Baz::<TAB> > > gets an unwindy display).

> > That suggests that there is a common mechanism for the > problem or, at least, a common approach for completion > display which yields this result. >

> > So instead of "blindly" fixing this, the first question is: can one > > somehow generalize this situation, and have some "higher level" > > support for this in the completion framework? Then redirect these two > > situations through the framework?

It looks like modifying the display routine to use the real @matches including the common prefix would fix this. GNU readline appears to do something similar.

Tue Oct 05 09:37:17 2010 chm [...] cpan.org - Correspondence added

I don't know if this should go in a separate ticket but I noticed that Term::ReadLine::Perl appears to list matches with informative suffixes (such as * for executable files) but then it also inserts that extra character which works ok for directories but not so well for executable files etc., e.g.: Show quoted text

pdl> print 'a<TAB> pdl> print 'a/<TAB>

a/b/ a/e/ a/my.exe* Show quoted text

pdl> print 'a/m<TAB> pdl> print 'a/my.exe*

while using Term::ReadLine::Gnu yields this: Show quoted text

pdl> print 'a<TAB> pdl> print 'a/<TAB><TAB>

b/ e/ my.exe Show quoted text

pdl> print 'a/m<TAB> pdl> print 'a/my.exe'

where the common prefix has been stripped in the display of matches, there is an extra <TAB> to get the list of matches, and the close-quote is inserted after the completion. The TR::Gnu example does not have the extra info chars for the match list. I think those can be turned on but I'll have to follow up with that later... --Chris

Tue Oct 05 11:27:19 2010 chm [...] cpan.org - Correspondence added

On Tue Oct 05 09:37:17 2010, CHM wrote: Show quoted text

> I don't know if this should go in a separate ticket > but I noticed that Term::ReadLine::Perl appears to > list matches with informative suffixes (such as * > for executable files) but then it also inserts that > extra character which works ok for directories but > not so well for executable files etc., e.g.: >

> pdl> print 'a<TAB> > pdl> print 'a/<TAB>

> a/b/ a/e/ a/my.exe*

> pdl> print 'a/m<TAB> > pdl> print 'a/my.exe*

If you set $readline::var_CompleteAddsuffix=0 then no suffixes will be added which partially fixes the problem. Unfortunately, it also stops the trailing / on directories which prevents expansion of their contents... The / in a directory pathname is significant. The @=* on a file is not (informational, not actually part of the pathname). The GNU readline filename expansion makes this distinction.

Sun Oct 17 11:48:35 2010 chm [...] cpan.org - Correspondence added

Show quoted text

> > if (@matches == 1) { > > if ( $replacement !~ m{[/\\]$} ) { # no space if dir > > $replacement .= $rl_completer_terminator_character; > > } > > }

This is the corrected regex with $ added\ to match the end of line. This pattern includes directories with path expansions using win32 \ but T::R::Perl does file/dir expansions with / at the moment.

Sun Oct 17 11:58:40 2010 chm [...] cpan.org - Correspondence added

Show quoted text

> >

> > pdl> print 'a<TAB> > > pdl> print 'a/<TAB>

> > a/b/ a/e/ a/my.exe*

> > pdl> print 'a/m<TAB> > > pdl> print 'a/my.exe*

> > If you set $readline::var_CompleteAddsuffix=0 > then no suffixes will be added which partially > fixes the problem. Unfortunately, it also stops > the trailing / on directories which prevents > expansion of their contents...

It looks like CompleteAddsuffix relates to the file/directory match listing for the completion so the fix would be to put that into the match display and make sure it doesn't get in the actual expanded text. --Chris