Thanks for the reply.

1) That is fine, I just wanted to check.  A number of the perl extensions
   look more like examples than anything else.  So, I can imagine that it
   can get frustrating when issues are raised against them.

2) This doesn't really answer my question.  I am not sure if this is a
   passive aggressive way of stating that Bertrand and you are diametrically
   opposed to what I am doing, or if you didn't understand the questioin.
   The purpose of the extension is to have it run screen (with all of its
   complexity) for you.  If you don't like what I am doing, that is fine;
   per (1) it is easy for us to disagree and just go our seperate ways.
   
   If, on the other hand you are suggesting that there is a way for me to
   update ARGV in on_init, then I would be very interested in learning more.
   I looked through the code, and am pretty sure this isn't possible, that
   ARGV is read-only in the perl interface (as it probably should be).

3) Thanks for all the good suggestions.  I hadn't really thought about the
   fact that I was extending an object, and so didn't want to pollute the
   name space.  I also didn't see it as much of an issue as I wasn't using
   urxvtd.  But, you did catch issues that would affect urxvtd users, and
   so I have moved all read-write variables into $self.

   Similarly for $self->{'latency'} and urxvtd users, your suggestion is
   well noted and I implemented a timer.  The latency variable defaults to
   0.01 seconds, but the timer is still clearly the better implementaion. 

   Per the call methodology, it is just my convention to use the ampersand
   for in-scope functions.  I got used to using it in perl 4.  Once you
   understand the convention, I think it makes my code easier to support in
   a similar way to using an all-caps global variables convention.

I was originally looking for a unicode terminal as an edge case, to support
my julia programming language users, but it is really just a great terminal
emulator on it's own right.  Beyond the perl interface, it has a number of
other really great features, and I will be switching from mrxvt to urxvt as
my personal default emulator (with my screen extension, of course to replace
the mrxvt tabs).  Even with LANG=C, I think it holds it's own and more
against the competition.

Thanks for a really great piece of software.

-- 
Totten, William David (Bill)
biell @ pobox . com
http://pobox.com/~totten/

-----Original Message-----
Sent:  Wed, 17 Dec 2014 13:30:43 +0100
To: William Totten
From: Marc Lehmann
Date: Wed, 17 Dec 2014 21:39:57 EST
Cc: [email protected]
Subject: Re: perl extension for screen integration

On Tue, Dec 16, 2014 at 10:50:32PM -0500, William Totten <[email protected]> wrot
e:
>  1) Is this something people would like to distribute with the other
>     rxvt-unicode perl extensions?

If "people" means the rxvt-unicode maintainers, then our plans are to reduce
the number of extensions distributed with the package to the ones we
maintain ourselves, for a variety of reasons.

Our current plan is to introduce the ability to install extensions via CPAN
in the next or next-next release, so everybody can easily push urxvt
extensions via a common repository.

>  2) Are there any suggestions on a better way to run screen without
>     having to start a shell, then exec screen?

Bertrand nailed it.

As for:

3) Any critique/suggestions for the extension I didn't ask for?

The extension looks quite interesting, especially as it apparently
"automatically" senses screen. Some things really should be done
differently though:

                select(undef, undef, undef, $LATENCY);

I don't know how long $LATENCY typically us, but this freezes all urxvt
windows for the given time. The correct solution is to use a timer (via
the urxvt::timer class), i.e. something like:

   $self->{delayed_osc_response} = urxvt::timer
      ->new
      ->after ($LATENCY)
      ->cb (sub {
         delete $self->{delayed_osc_response};
         $self->screen (...);
         $self->init_screen;
      });

Also, $LATENCY is a global variable, and it is not the only one:

                $VSPLIT=1                               if($version>4.00);
                $FASTFOCUS=1                            if($version>4.01);
                $SILENTOPS=1                            if($version>4.01);
                $SO='rendition so'                      if($version>4.01);

This means that one invocation will overwrite the data of the
previous one. The correct solution would be to store all this data in
$self->{latency}, $self->{vsplit} and so on. Global variables must only be
used for behaviour that must needs be the same among all instances (for
example, %SCREEN_CMAP is read-only afaics and can be shared).

And lastly, a nitpick:

                &screen($self, ':mousetrack off')       if($version>4.01);

The perl 4 call syntax is deprecated and not needed since, whew,
1994. Since screen really is a method, this would be a more natural (but
not more correct) thing to do:

                $self->screen (':mousetrack off')       if($version>4.01);

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      [email protected]
      -=====/_/_//_/\_,_/ /_/\_\


_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode

Reply via email to