Gilles Ruppert

a.k.a. elduderino78

TextMate & Subversion 1.5 Update Problem With Conflict

We recently upgraded to Subversion 1.5 server at BBC Worldwide. I ended up upgrading my client at the same time with the latest OSX binary from Colabnet. One weird thing started to happen though: whenever there were conflicts, TextMate wouldn’t allow me to use the ‘Resolve Conflicts with FileMerge…’.

Long story short: the interactive mode keeps TextMate from getting all the data so you don’t get the .rxxx & .mine files which are needed for FileMerge to show you the differences.

To fix this is:

  1. go into your TextMate Subversion Bundle
  2. go to the Update to Newest (HEAD) command and add --non-interactive after '#{svn}' update

You can see the resulting code here (change on line 14).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
require_cmd "${TM_SVN:=svn}" "If you have installed svn, then you need to either update your <tt>PATH</tt> or set the <tt>TM_SVN</tt> shell variable (e.g. in Preferences / Advanced)"

"${TM_RUBY:-ruby}" -r "$TM_SUPPORT_PATH/lib/shelltokenize.rb" <<END
 svn = ENV['TM_SVN'] || "svn"
 ruby = ENV['TM_RUBY'] || "ruby"
 support = ENV['TM_BUNDLE_SUPPORT']
 paths = TextMate.selected_paths_array

 # TODO: Ideally, we'd like to use a tooltip for one and not others, but we can't switch from a tooltip
 # to dynamic HTML output (or maybe we could double-fork a process?)
 # if ((paths.size == 1) and not (File.directory? paths[0]))
 #   puts %x{#{svn} update #{TextMate.selected_paths_for_shell}}
 # else
     update = IO.popen("'#{svn}' update --non-interactive #{TextMate.selected_paths_for_shell}", 'r')
     format = IO.popen("'#{ruby}' -- '#{support}/format_status.rb'", 'w')
     update.each_line { |line| format.puts(line) }
 # end
END

# force TM to refresh the current file..
rescan_project

jQuery Plugin autoInputValue - Default Input Values Made Easy

We all know the problem: the designers are struggling to get the form elements in the space they have or they decide that having labels next to input fields is not really necessary… Instead the label is displayed inside the input field & supposed to disappear when the user clicks or focuses on the field.

I’ve come across this quite often lately, so I quickly put a little jQuery plugin together to make my life a bit easier.

It works on input fields and it works just like any other jQuery plugin.

All you need to do is call the plugin with the selectors you are interested in, i.e. $('input:text.email').autoInputLabel();

The options are specified in an object literal & can be:

  • blurColor - colour of the text when the label is displayed
  • focusColor - colour of the active text, i.e. user input
  • value - the label that should be displayed

By default, the plugin displays the value of the value attribute. If there is none, it checks whether there has been a value provided by the user. Otherwise it looks for the label associated with the input field (that is probably hidden, otherwise why would you use the plugin?). The label needs to be associated to the input field with the for attribute.

The plugin only works on <input type="text"> fields.

You can download the latest version from my public svn repository