I recently was working with some code that had an onClick event handler on the <TR> of each row
of a table. In one of the columns, a <TD>, there were icons that also had onClick’s on them. Something like:
<table><tronClick='foo()'><tdonClick='bar()'><!-- some icons --></td><td></td><td></td> ...
Now if the icons in the first <TD> were clicked, I wanted bar() to fire, but not foo(). Normal behavior is to execute them both.
Turned out there is a simple solution for this with jQuery. Only tested in Firefox, but presumably this works across the board because jQuery is awesome that way.
Add a class to the <TD> called no-event-bubble-up:
rxvt-unicode (commonly called urxvt) already has 88 color support, and for most things, this is fine. But I recently just found the CSApprox plugin for vim, which lets you use Gvim themes in console vim. CSApprox actually does a pretty good job interpolating for 88 colors too, but it is best at 256.
So here’s my build log of compiling rxvt-unicode with the 256 color patch on Ubuntu Hardy, and debianizing (packaging) it.
# I keep all custom deb's here, use any directory you want
# Make a place for rxvt-unicode
# Get the source
apt-get source rxvt-unicode
# Apply 256 color patch, it's included with the source
patch -p1 < doc/urxvt-8.2-256color.patch
# Make sure you have all depdencies to build it
sudo apt-get build-dep rxvt-unicode
# Build it
dpkg-buildpackage -us -uc -rfakeroot
This will actually build three separate packages:
All I care about is rxvt-unicode, but you might want -lite or -ml. If
someone more adept in Debian package building than I am can tell me how
to just compile one of these versions, that’d be great. :)
# Install it!
sudo dpkg -i rxvt-unicode_8.4-1_amd64.deb
# As always, your arch may be different. Replace amd64 with whatever is
# appropriate for you.
Now we need to make terminfo aware that rxvt-unicode supports 256 colors. The default terminfo entry you’ll have for rxvt-unicode will say 88, and that won’t be right for your new version.
infocmp -L rxvt-unicode > rxvt-unicode.terminfo
# Change the following from:
# lines_of_memory#0, max_colors#88, max_pairs#256,
# lines_of_memory#0, max_colors#256, max_pairs#32767
# Make .terminfo dir if you don't already have it
install -d .terminfo
# Rebuild terminfo for rxvt-unicode
tic -o .terminfo/ rxvt-unicode.terminfo
That should do it.
To test it out, use this 256colors2.pl script (it’s the same one included in the xterm distribution). Download it, set it executable, open a fresh urxvt terminal, and run:
The output should look like:
Any program that supports 256 colors that had to fallback to 88 or even 8 colors can now be used in all its glory.
Does this make your consoling experience better? Let me know, post a comment.
Update (09-21-2008): I have a followup to this article here.
You’ve probably been told that in Ruby classes are always open and any code can come along and redefine your methods in any way it pleases. Indeed, this is true.
What’s not true, despite every reference I’ve read saying the contrary, is that you can’t prevent this from happening.
Ruby provides a method_added() callback that is invoked every time a method is added or redefined within a class. It’s part of the Module class, and every Class is a Module. There are also two related callbacks called method_removed() and method_undefined().
This means you could detect when other code has redefined a method, and do something about it! How about redefining that method (again) to point back to your original code? Indeed, this works.
I’ve encapsulated the details of this in a new module I call Immutable. It provides one class method called immutable_method(). Provide it a list of methods you don’t want touched and it’ll make sure they can’t be redefined. Hence, immutable.
require'rubygems'require'immutable'moduleFooincludeImmutabledeffoo:fooendimmutable_method:fooend# Now re-open Foo and redefine foo()moduleFoodeffoo:bazendendincludeFoofoo# => :foo
foo() returns :foo, not :baz, even though we redefined foo() to return :baz.
If this makes you think of Java’s final method modifier, you’d be almost right in saying immutable_method is similar. But there’s one important difference: with immutable_method you can still redefine methods in subclasses. This makes sense, as one can argue that if you want to reimplement or extend a method, a child class is the only place where you should be doing that anyway. I tend to agree, call me a purist.
Why would this be useful to you? I don’t know. But I can tell you what motivated me.
My motivation for writing something that provides what some may call “evil” functionality (heh, and monkey patching isn’t evil?) of closed methods/classes came from my trials of trying to improve Rails loading time by reimplementing some ActiveSupport methods in C (Ruby extension).
I absolutely needed my C versions of certain methods to be present, and not clobbered by ActiveSupport.
So why didn’t I just load my extension after ActiveSupport? Because by then it is too late. Rails is already loaded, along with slow running methods that get called over 10,000 times during initialization.
I’m starting to put this in ~/.bashrc of all my servers now:
# Set screen window titlecase"$TERM" in
screen)PROMPT_COMMAND='echo -ne "\033k$HOSTNAME\033\\"' ;;
When I log into the machine, the screen window title (which displays on the hard status line, and in turn my urxvt window title bar) automatically changes to the hostname of the machine I’m logged into. I used to set this manually, but now I don’t have to, yay!
If your distro doesn’t set up your environment so ~/.bashrc is sourced upon login, you’ll want to put this into ~/.bash_login instead.
To get this code on a lot of servers at once, save the above snippet to a file called “prompt-command.sh” and execute:
for i in hostname1 hostname2 hostname3; do cat prompt-command.sh | ssh $i 'cat >> ~/.bashrc'; done
Of course, change “hostname1”, “hostname2”, etc… to the real hostnames of your machines.