Skip Menu |

This queue is for tickets about the Term-ReadLine-Perl CPAN distribution.

Report information
The Basics
Id: 57122
Status: open
Priority: 0/
Queue: Term-ReadLine-Perl

People
Owner: Nobody in particular
Requestors: chm [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in:
  • 1.0302
  • 1.0303
Fixed in: (no value)



Subject: %attribs tie in Perl.pm is incomplete
From the Devel::REPL shell, I can access the Term::ReadLine and try to print the Attribs hash (tied with Term::ReadLine::Perl::Tie) and I get the following error: $ keys %{$_REPL->term->Attribs} Runtime error: Can't locate object method "FIRSTKEY" via package Term::ReadLine::Perl::Tie" at (eval 310) line 5. A look at the Perl.pm source I see that all the needed TIEHASH accessors have not been implemented. Creating a fuller implementation: package Term::ReadLine::Perl::TieHash; sub TIEHASH { bless {} } sub DESTROY {} sub STORE { my ($self, $name) = (shift, shift); $ {'readline::rl_' . $name} = shift; } sub FETCH { my ($self, $name) = (shift, shift); $ {'readline::rl_' . $name}; } sub EXISTS { my ($self, $name) = @_; return exists $readline::{'rl_' . $name}; } { my (@rl_keys); sub FIRSTKEY { @rl_keys = sort grep { m/^rl_\w/ } keys %readline:: ; my $key = substr shift(@rl_keys), 3; return wantarray ? ($key, ${'readline::rl_' . $key}) : $key; } sub NEXTKEY { my $key = substr shift(@rl_keys), 3; return wantarray ? ($key, ${'readline::rl_' . $key}) : $key; } } Resulted in a successful call: $ keys %{$_REPL->term->Attribs} $ARRAY1 = [ 'History', 'HistoryIndex', 'MaxHistorySize', 'NoInitFromFile', 'OperateCount', 'attempted_completion_function', 'basic_commands', 'basic_word_break_characters', 'bind', 'completer_word_break_characters', 'completion_function', 'correct_sw', 'default_selected', 'delete_selection', 'filename_list', 'first_char', 'getc', 'last_pos_can_backspace', 'margin', 'max_numeric_arg', 'readline_name', 'screen_width', 'scroll_nextline', 'set', 'special_prefixes', 'start_default_at_beginning', 'term_set', 'vi_replace_default_on_insert' ]; As the new functionality should be a strict superset of the existing tie. I would like to see this folded into the official readline support. Hope this helps. --Chris
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #57122] %attribs tie in Perl.pm is incomplete
Date: Sat, 1 May 2010 15:50:06 -0700
To: Chris Marshall via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Sat, May 01, 2010 at 03:26:00PM -0400, Chris Marshall via RT wrote: ... Show quoted text
> Resulted in a successful call:
Do I read it correctly that you are not interesting in getting the correct result, but only in "getting no error"? You assume that everything which is prefixed by rl_ is an option variable. I'm not so sure... Yours, Ilya
On Sat May 01 18:50:19 2010, nospam-abuse@ilyaz.org wrote: Show quoted text
> On Sat, May 01, 2010 at 03:26:00PM -0400, Chris Marshall via RT wrote: > > ...
> > Resulted in a successful call:
> > Do I read it correctly that you are not interesting in getting the > correct result, but only in "getting no error"?
No, when I was coding the FIRSTKEY/NEXTKEY stuff I had a choice between only iterating over elements that had been specifically assigned via the tie or over all the possible keys matching the pattern used in the existing tie. I chose to return all the readline::rl_* possibilities rather than just the specifically assigned ones. It would be easy to implement the same with only the FETCH/STORE'd attributes. Show quoted text
> You assume that everything which is prefixed by rl_ is an option > variable. I'm not so sure...
Me either, but most likely much less sure than you.... I'm fine with coding the other extreme. Without knowing more about the Perl readline usage and any compatibility issues with Gnu readline, I thought that more information would be better. I'm not a perl guru, but it seemed like the main difference between a "show everything" implementation and the conservative "show only what was put it" version was that it would be easy to list all possible Attribs---correct or not. The STORE/FETCH-only implementation would allow only Attribs that one explicitly knew about. (Choosing the conservative approach would probably be better for encapsulation, etc. At the time I was frustrated because I could not learn what the current Attribs were.) I still feel that a more complete TIEHASH implementation would be a valuable addition to Term::ReadLine::Perl. Regards, Chris
I've attached the more conservative implementation (not guaranteed to be free of bugs) that returns the result: $ keys %{ $_REPL->term->Attribs } $ARRAY1 = [ 'completion_function', 'attempted_completion_function' ]; From my perldl2 shell where these are the two attributes assigned by hand. As expected, no others were returned by this implementation. --Chris
Subject: TieHash.pm
package Term::ReadLine::Perl::TieHash; { sub TIEHASH { bless {} } sub DESTROY {} my $_rl_keys = {}; sub STORE { my ($self, $name) = (shift, shift); $ {'readline::rl_' . $name} = shift; $_rl_keys->{$name} = 1; # record key } sub FETCH { my ($self, $name) = (shift, shift); $ {'readline::rl_' . $name}; } sub EXISTS { my ($self, $name) = @_; return exists $_rl_keys->{$name}; } my @_keys; sub FIRSTKEY { @_keys = keys %{ $_rl_keys }; # reset iterator return each %{ $_rl_keys }; } sub NEXTKEY { return each %{ $_rl_keys }; } } sub SCALAR {} 1;
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #57122] %attribs tie in Perl.pm is incomplete
Date: Sat, 1 May 2010 21:26:36 -0700
To: Chris Marshall via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Sat, May 01, 2010 at 08:42:12PM -0400, Chris Marshall via RT wrote: Show quoted text
> > You assume that everything which is prefixed by rl_ is an option > > variable. I'm not so sure...
... so this is why I did not implement it before. Show quoted text
> Me either, but most likely much less sure than you....
Somebody needs to run over all $rl_* variables and check that they make sense as user-settable keys. Show quoted text
> I'm not a perl guru, but it seemed like the main > difference between a "show everything" implementation > and the conservative "show only what was put it" > version was that it would be easy to list all possible > Attribs---correct or not.
Some things are Attribs, some are not. I see no sense in returning a wrong answer... Show quoted text
> The STORE/FETCH-only implementation would allow > only Attribs that one explicitly knew about.
Yes. And you propose a way to auto-discover the keys. Would make a lot of sense - provided it returns a correct result. ;-) Show quoted text
> I still feel that a more complete TIEHASH implementation > would be a valuable addition to Term::ReadLine::Perl.
Sure. But yours is not... Your effort is very appreciated, Ilya
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #57122] %attribs tie in Perl.pm is incomplete
Date: Sat, 1 May 2010 21:28:00 -0700
To: Chris Marshall via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Sat, May 01, 2010 at 09:10:26PM -0400, Chris Marshall via RT wrote: Show quoted text
> Queue: Term-ReadLine-Perl > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57122 > > > I've attached the more conservative implementation > (not guaranteed to be free of bugs) that returns > the result: > > > $ keys %{ $_REPL->term->Attribs } > $ARRAY1 = [ > 'completion_function', > 'attempted_completion_function' > ]; > > From my perldl2 shell where these are the two > attributes assigned by hand. As expected, no > others were returned by this implementation.
This IMO serves absolutely no purpose... Yours, Ilya
On Sun May 02 00:26:48 2010, nospam-abuse@ilyaz.org wrote: Show quoted text
> On Sat, May 01, 2010 at 08:42:12PM -0400, Chris Marshall via RT wrote:
> > > You assume that everything which is prefixed by rl_ is an option > > > variable. I'm not so sure...
> > ... so this is why I did not implement it before. >
> > Me either, but most likely much less sure than you....
> > Somebody needs to run over all $rl_* variables and check that they > make sense as user-settable keys.
I guess I see one point could be that exposing new TIEHASH features could break code that depended on them being missing. Then maybe this should be classified as a feature request. Show quoted text
> > I'm not a perl guru, but it seemed like the main > > difference between a "show everything" implementation > > and the conservative "show only what was put it" > > version was that it would be easy to list all possible > > Attribs---correct or not.
> > Some things are Attribs, some are not. I see no sense in returning a > wrong answer... >
> > The STORE/FETCH-only implementation would allow > > only Attribs that one explicitly knew about.
> > Yes. And you propose a way to auto-discover the keys. Would make a > lot of sense - provided it returns a correct result. ;-) >
> > I still feel that a more complete TIEHASH implementation > > would be a valuable addition to Term::ReadLine::Perl.
> > Sure. But yours is not... > > Your effort is very appreciated, > Ilya >
On Sun May 02 00:31:05 2010, nospam-abuse@ilyaz.org wrote: Show quoted text
> On Sat, May 01, 2010 at 09:10:26PM -0400, Chris Marshall via RT wrote:
> > Queue: Term-ReadLine-Perl > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57122 > > > > > I've attached the more conservative implementation > > (not guaranteed to be free of bugs) that returns > > the result: > > > > > > $ keys %{ $_REPL->term->Attribs } > > $ARRAY1 = [ > > 'completion_function', > > 'attempted_completion_function' > > ]; > > > > From my perldl2 shell where these are the two > > attributes assigned by hand. As expected, no > > others were returned by this implementation.
> > This IMO serves absolutely no purpose...
Yes, this definitely errs on the too minimal size. Thanks again for the Term::ReadLine::Perl module. It has made possible command completion on win32 for the PDL shell. I can see that a correct implementation for this will take more effort than my proposed quick fixes. Regards, Chris
On Sun May 02 00:26:48 2010, nospam-abuse@ilyaz.org wrote: Show quoted text
> On Sat, May 01, 2010 at 08:42:12PM -0400, Chris Marshall via RT wrote:
> > > You assume that everything which is prefixed by rl_ is an option > > > variable. I'm not so sure...
> > ... so this is why I did not implement it before. >
> > Me either, but most likely much less sure than you....
> > Somebody needs to run over all $rl_* variables and check that they > make sense as user-settable keys.
I tried a review of the rl_* variables in readline.pm and came up with the following categories and descriptions: User Configuration: MaxHistorySize maximum size the history array may grow NoInitFromFile if defined on require then skip .inputrc max_numeric_arg maximum numeric argument allowed Possible User Config: default_selected ??? does not appear to be set but controls redisplay ??? delete_selection ??? internal alias for var_DeleteSelection ??? start_default_at_beginning set user cursor to start at beginning of default text vi_replace_default_on_insert preselect default for first insert only ReadLine Information: readline_name name of program for .initrc usage screen_width width readline thinks it can use on screen Completion Config/Info: basic_word_break_characters word break characters completer_word_break_characters word break characters completion_function name/ref of the current completion function special_prefixes chars here and completer_word_break_characters stay part of word ReadLine User subs: rl_basic_commands sub to set and array of basic commands to complete rl_bind sub to bind keymap functions rl_set sub to set mode variables ReadLine Internal subs: rl_filename_list filename list completion function rl_getc readline getc function Internal only: History internal array of lines previously input HistoryIndex internal history pointer index OperateCount internal correct_sw internal fix to correct line length first_char internal flag last_pos_can_backspace internal config stuff margin internal margin for display scroll_nextline internal config for scroll stuff, settable term_set internal terminal control sequences Of these, the ones listed "User Configuration" should definitely be in the Attribs hash. I think the ones under "Possible User Config" could be as well but I don't know enough about usage to decide. The "ReadLine Information" gives useful internal config about the readline instance so I think they should be user accessible (read only?). The "Completion Config/Info" section seems to be mostly useful for implementers of readline completion stuff. The subs probably need to be documented but don't seem useful as Attribs entries. I wouldn't include the "Internal Only". Hope this helps get the ball rolling on this. Maybe if the various items are more clearly categorized, I could write the basics up as some POD for Term::ReadLine::Perl. Right now, you can't even see that readline() can take a second, optional preput argument. --Chris
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #57122] %attribs tie in Perl.pm is incomplete
Date: Sat, 16 Oct 2010 23:19:36 -0700
To: Chris Marshall via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Sat, Oct 16, 2010 at 06:12:28PM -0400, Chris Marshall via RT wrote: Thanks a lot for very important classification! ... Show quoted text
> Of these, the ones listed "User Configuration" should > definitely be in the Attribs hash. I think the ones > under "Possible User Config" could be as well but I > don't know enough about usage to decide.
Is there any chance to unify them with how T::R::Gnu has its state accessable? Yours, Ilya
On Sun Oct 17 04:06:27 2010, nospam-abuse@ilyaz.org wrote: Show quoted text
> On Sat, Oct 16, 2010 at 06:12:28PM -0400, Chris Marshall via RT wrote: > > Thanks a lot for very important classification! > > ...
Apologies for the format problems. It looked fine when I cut and pasted into the Update ticket window. Then it all got smushed. Is there some other way to respond to tickets and better control the formatting? Show quoted text
> > Of these, the ones listed "User Configuration" should > > definitely be in the Attribs hash. I think the ones > > under "Possible User Config" could be as well but I > > don't know enough about usage to decide.
> > Is there any chance to unify them with how T::R::Gnu has its state > accessable?
It appears that T::R::Gnu makes all the internal state available via the Attribs hash. Part of the goal here was to give T::R::Perl a similarly working Attribs hash. Given the lack of POD documentation for T::R::Perl, I don't think such an "include everything" approach would work without much effort. However, fixing the Attribs return value bug with the listed values and adding some POD for that is doable. Cheers, Chris
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #57122] %attribs tie in Perl.pm is incomplete
Date: Sun, 17 Oct 2010 10:10:26 -0700
To: Chris Marshall via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Sun, Oct 17, 2010 at 08:41:39AM -0400, Chris Marshall via RT wrote: Show quoted text
> > Is there any chance to unify them with how T::R::Gnu has its state > > accessable?
> > It appears that T::R::Gnu makes all the > internal state available via the Attribs > hash. Part of the goal here was to give > T::R::Perl a similarly working Attribs > hash. > > Given the lack of POD documentation > for T::R::Perl, I don't think such an > "include everything" approach would > work without much effort. However, > fixing the Attribs return value bug > with the listed values and adding some > POD for that is doable.
My question was whether the semantic of keys to %Attribs would be the same if one exports using the current names. Ilya
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #57122] %attribs tie in Perl.pm is incomplete
Date: Sun, 17 Oct 2010 10:11:51 -0700
To: Chris Marshall via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Sun, Oct 17, 2010 at 08:41:39AM -0400, Chris Marshall via RT wrote: Show quoted text
> Apologies for the format problems. It looked > fine when I cut and pasted into the Update ticket > window. Then it all got smushed. Is there some > other way to respond to tickets and better > control the formatting?
I do not use this system, so I have no suggestions. Ilya
On Sun Oct 17 13:10:41 2010, nospam-abuse@ilyaz.org wrote: Show quoted text
> On Sun, Oct 17, 2010 at 08:41:39AM -0400, Chris Marshall via RT wrote:
> > > Is there any chance to unify them with how T::R::Gnu has its state > > > accessable?
> > My question was whether the semantic of keys to %Attribs would be the > same if one exports using the current names.
Still unclear here but it looks like there are a number of variables and routines from T::R::Perl that have correspondences to values in T::R::Gnu. Are you suggesting Attribs return the values to the T::R::Gnu keys where applicable? --Chris
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #57122] %attribs tie in Perl.pm is incomplete
Date: Mon, 18 Oct 2010 16:00:03 -0700
To: Chris Marshall via RT <bug-Term-ReadLine-Perl [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Mon, Oct 18, 2010 at 01:07:48PM -0400, Chris Marshall via RT wrote: Show quoted text
> Queue: Term-ReadLine-Perl > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57122 > > > On Sun Oct 17 13:10:41 2010, nospam-abuse@ilyaz.org wrote:
> > On Sun, Oct 17, 2010 at 08:41:39AM -0400, Chris Marshall via RT wrote:
> > > > Is there any chance to unify them with how T::R::Gnu has its state > > > > accessable?
> > > > My question was whether the semantic of keys to %Attribs would be the > > same if one exports using the current names.
> > Still unclear here but it looks like there are > a number of variables and routines from T::R::Perl > that have correspondences to values in T::R::Gnu. > > Are you suggesting Attribs return the values to > the T::R::Gnu keys where applicable?
The whole idea of Attribs is that one can command a back-end without knowing which one it is (at least to some extend). So if some variables are mirrored in Attribs, they should better have a compatible meaning (if possible). Ilya