Rename `t` to `timetrap`

[allolex]

This avoids a conflict with @sferik's t command-line Twitter client.

I know this is a little controversial since a single-letter executable is so much easier, but I thought I'd let you know and propose letting users create their own aliases. (I've got mine aliased to u.)

[sferik]

Technically, @samg had it first (timetrap predates t by a couple years). Despite being the author of t, I’m generally of the opinion that Unix commands should be at least two-letters in length (e.g. ls, cp, mv, rm, etc.). Commands shouldn’t occupy the single-letter namespace. That should be reserved for aliases, so a user can alias a longer command name (e.g. timetrap) to a single-letter (e.g. t). Unfortunately, I had not thought deeply about this issue until after t was released…and I’ve never thought of a good alternative name.

Anyway, I agree you should change the name, but not because it clashes with t but because it’s generally not a best practice.

[samg]

I think I'd be inclined to agree in theory with @sferik that single letter executables aren't ideal. The t command fits well with timetrap's philosophy of allowing all commands to be abbreviated (e.g. t in --at "10 minutes ago" is equivalent to t i -a "10 minutes ago") but it does more often lead to name collisions.

I'd be reluctant to remove the t command from timetrap since that would require all its users to set that alias after upgrading (or be confused as why the t executable is missing). I'm thinking what I should do is add an equivalent timetrap command which could potentially make things easier for those wanting to alias and/or use t for another program. Perhaps at some point in the future t could be deprecated in favor of user shell aliases.

[berkes]

Would it be an idea to output a DEPRECATION ERROR on the next "mayor" release; for it to be removed in another mayor release? E.g. 1.9.0 explains to users that t will be removed in 1.10.0?

That gives everyone a long while to get used to either using timetrap or aliasing it.

[allolex]

I'd considered just doing that, but the clash still makes you have to force the install. I do think having both is a nice compromise between the two options, and as you said, it does avoid breakage.

Re deprecation error: As much warning as possible would be a good for expectations management.

[samg]

I just pushed this change out in version 1.8.12. I'll definitely consider deprecation warnings in the future for the t command. Thanks!

[allolex]

Cool. Thanks for being so responsive!

[a-b]

I like t alias :(