auto_sheet

[TSFoster]

This only turned out to be 20 odd lines of actual code. Works as described in #69. Tests and documentation also written.

[samg]

Sorry I haven't gotten a chance to merge and release this yet. It looks good, but I want to play around with it a bit before releasing it. I'll be out of town for about a week but should be able to get it up on rubygems after that.

Thanks!

[TSFoster]

No worries! I've been using it for the last 2 week and I haven't come across any issues. It works fine in my workflow, but it might be nice to have a -s/--sheet argument for in and resume to override it.

[samg]

I've been playing around with this a little bit (sorry it's taken so long). It seems to work pretty well for the workflow you've described, though I agree there's some edge cases that could make it confusing for other users (e.g. I'm in one directory, cd to another, run t out and it tells me I'm not checked into that sheet since the sheet changed when I ran cd)

It's got me thinking about a more generic way to implement this feature. I'm thinking of making it possible for users to implement their own autosheet script (similar to how custom formatters work). This would allow you to easily implement the behavior in #69 and completely customize it to your workflow. Another user might want to select sheets based on git branches and could easily write an autosheet script that does that.

I need to think a little more about what the best programming interface would be (e.g. ruby class that gets loaded in to timetrap, shell script that outputs a sheet name or nothing, etc.) but I think this would allow this level of flexibility and convenience while accommodating many possible workflows.

Let me know what you think.

[TSFoster]

I like this idea. How do you imagine it would work? Timetrap asks each autosheet class in some weighted order to name a sheet to use, and it uses the first non-nil answer, and -s/--sheet overrides it? Or each class could be given the answer from the previous class (e.g. directory autosheet returns "Project A", branch autosheet given 'Project A' and returns "Project A (bugfixing)")?

Can you think of other potential scripts? Geolocation? Time of day?

Do you plan on merging this branch in the meantime? Do you plan on coding this up? I'm not sure when I'd find the time/motivation to do it myself, although I imagine I would eventually.

[UnderpantsGnome]

@samg have you made any headway on the direction you'd like to go with this? It's something I would like to see timetrap be able to do as well. Though I definitely prefer a plugable option since the way this PR deals with it isn't the direction I would want to go.

If you want someone to lend a hand here, let me know.

[samg]

@UnderpantsGnome - I haven't made any progress on auto_sheet yet, and it would be great if you wanted to take a crack at it.

I think what would make them most sense would be to allow users to create their own autosheet ruby class that lives in a file in the ~/.timetrap directory, similar to how custom formatters work. I'd considered making the autosheet interface an external script that timetrap would execute, but it seems wasteful to cause timetrap to spawn another process each time it's invoked, especially when it's so easy to shell out from Ruby.

It might make sense to allow multiple autosheet classes to be defined and chosen through configuration. This would make it easy for users to share their autosheet classes with each other (e.g. https://github.com/samg/timetrap_formatters style) or for timetrap to ship with a few autosheet classes that could cover some common use cases (e.g. sheet by git branch, sheet by directory, etc.)

I'm imagining it might look something like this, though I haven't put much thought into this specific interface.

# ~/.timetrap/auto_sheet/day_of_week.rb

class ::Timetrap::AutoSheet::DayOfWeek
  def initialize(current_sheet_name)
    # There might be some use cases where knowing the current sheet would be useful.
    # Not sure if there's other information it would make sense for timetrap to pass in.
    @current_sheet_name = current_sheet_name
  end

  def sheet_name
    # Name the sheet based on the day of the week
    Time.now.strftime('%A')
  end
end

Again this is just some rough ideas about it, and there may be a way to do it that makes more sense. There probably should be some mechanism provided that allows the user to override the autosheet behavior for a specific check in.

Thanks!

[UnderpantsGnome]

@samg I've been under the weather, but I think I have some time to take a shot at this.

Are you thinking there would only be one autosheet active like formatters or some way of chaining them?

I know for my use case I would only want one specified, probably in ~/.timetrap.yml

[samg]

I can't think of a use case where chaining autosheet-ers would make sense. I think only one should be active at a time (like formatters), though it would be nice to be able to distribute several of them so users can choose which one they want to use.

[samg]

I've ported this code into an autosheet class in https://github.com/samg/timetrap/commit/b13061a8d1750c3d2b58523bfca967da7f9a2acb.

I named the class YamlCwd. Let me know if you have a better idea for what to call it.

You'll be able to get this behavior by adding auto_sheet: yaml_cwd to your .timetrap.yml in the next version.