relsqui / doily Goto Github PK

No one's gonna understand this one but me, which is fine, because no one needs to. Depending on how I implement the prompt thing, I could set up a framework to do the inventory project as a series of prompts. (Maybe even do some clever stuff with finding bullet points or other kinds of tags in previous posts.)

This is squarely in the realm of "serves my personal needs and if other people find it useful, cool."

Basically this is this: ls .local/share/doily/dailies/ | tail -n 1 | sed 's#^#.local/share/doily/dailies/#' | xargs grep "^ *\*" except with an absolute path instead of relative. And maybe a configuration option to change the regex if you want to mark your goals in other ways.

Here's what I have so far for a template:

my_plugin::info() {
    # Information about the plugin itself goes here.
    case $1 in
        name) echo "My Plugin" ;;
        author) echo "Plugin Author <[email protected]>" ;;
        plugin_version) echo "v.0.1.0" ;;
        min_doily_version) echo "v.0.1.0" ;;
        max_doily_version) echo "v.1.0.0" ;;
        description) echo "Demonstrates some example boilerplate for doily plugins." ;;
        help) echo "This should really be longer and might call for a docstring." ;;
    esac
}

my_plugin::provides() {
    # This tells doily what hooks and commands the plugin provides.
    case $1 in
        hooks) echo "pre-write post-write" ;;
        commands) echo "foo bar" ;;
    esac
}

my_plugin::hooks() {
    # Register functions to be triggered by different hooks.
    case $1 in
        pre-write) my_plugin::before_writing ;;
        post-write) my_plugin::after_writing ;;
    esac
}

my_plugin::commands() {
    # Register functions to be triggered by commands.
    case $1 in
        foo) my_plugin::command_foo ;;
        bar) my_plugin::command_bar ;;
        baz) my_plugin::command_baz ;;
    esac
}


# The rest of these are just the functions referred to above.

my_plugin::before_writing() {
    echo "Have fun writing!"
}

my_plugin::after_writing() {
    echo "I hope that was very productive."
}

my_plugin::command_foo() {
    echo "You typed the foo command!"
}

my_plugin::command_bar() {
    echo "You typed the bar command!"
}

my_plugin::command_baz() {
    echo "You typed the baz command!"
}

This would just entail checking before doing the chmods and printing an appropriate message, to make it more obvious when something has changed.

Thinking about how cluttered my doily output is right now, though, I think it's also worthwhile to start organizing that. Make the difference between messages from the main script and from plugins clear, for example. That would be pretty easy; just trap plugin output in the main script and preface it with [show_streak] or whatever. And then [doily] for the main one.

This is blocking on the directory restructuring and (obviously) the command system. These need to be built-ins, otherwise you get bootstrapping problems.

• list
  • show plugins which are available to install
  • requires a configuration entry telling it where (on the web) to look
  • don't show plugins that are already installed (or do, but differently)
• describe
  • give the description for a plugin (installed or not, but say which)
• install
  • fetch a remote plugin and install it
• uninstall
  • remove a locally installed plugin

Other plugin-related functionality is in the config and version commands which are in the general builtin list (#21).

Comments in the default config file make a lot of assertions about what will happen if you change your settings after the first time you run Doily. All of these can and should be tested automatically.

I'm not totally sure what that looks like on a project like this. Will take some mulling over.

It should be pretty easy for the streak plugin, after it's found the current streak, to keep going backwards and find the longest streak to compare to.

There's no reason for this to be core when it doesn't have to be.

This could just be a row of asterisks after writing, or a series of . and o representing days written on and not written on, displaying after closing a daily file.

I think this is harder than it sounds because it requires paying attention to sequential dates in bash. Either that, or there's a clever way to do it I haven't thought of.

This is mostly for backup purposes, although conceivably one could use it to make writings public.

The install script is pretty good at it now, the main script should be better.

All that detail is good, but it doesn't all need to be there shouldn't only be there. Move Copy it over here (or something).

That is, rather than having today's writing go in 2017-02-12, put it in 2017/02/12. This makes it way easier to operate on a month or a year at a time if you want to (for statistics, for example). For the same reason, it makes it slightly harder to examine all the files at once.

I'm not sure if this should be an option, or if it's just better.

It will make setting permissions a little more complicated, but only a little.

It's nice to know when exactly you were writing, especially when you come back after a pause. Given modification times, we could even note how long the gap was!

We might want to have some time formatting options. It wouldn't be necessary to implement this feature, but it wouldn't be that hard to add since we're just going to make a call to time anyway. (I'm not too worried about sanitization, since there's no one to hose but yourself.)

Here's a SO post relevant to the time gap thing: http://stackoverflow.com/questions/8903239/how-to-calculate-time-difference-in-bash-script

This is kind of a no-brainer. Features to include off the top of my head:

• Word count (obviously).
• Various goals for the today: yesterday+average, amount needed to catch up, rounded versions of each of those, etc. Give you lots of points to hit.
• Maybe inspirational stuff?

A heredoc is the wrong place for this, but I haven't moved it because I don't actually know what the right one is. Comments encouraged.

I got some pretty reasonable feedback that it's not obvious what it's for. Maybe add some use cases and/or filesystem before and after.

I have no idea how to do this, but you're never too old to learn.

Needs more brainstorming about how to deal with filenames and the like.

Now that the actual data files are getting buried somewhat, should there be a command (or something) to browse and reread them? Or at least drop into the directory? Or is this overkill for something that's just files on disk?

It would make it easier to read stuff that had been shared with you, at least. And wouldn't require navigating through dot directories. Hell, even right now I'm feeling lazy about doing that and I haven't even moved to the new directory scheme yet. So this is probably a good idea, but I'm not sure what it should look like or how it should work.

These are git-like, so: doily install my_plugin, doily configure, and so on. A few vital ones should be builtins:

• everything in the plugin system (#20)
• config (drops you into editing doily config, or with plugin name the plugin config if applicable)
• version (optional plugin name gives that version instead)
• help (optional plugin name gives its help instead)
• read (takes date, rereads a daily)
• search (searches dailies for a string/regex)

Others are provided by plugins using a syntax I haven't decided on yet.

This is mostly for NaNoers, but also anyone else who's trying to hit a goal for writing quantity.

It's a wc one-liner, of course, but if it's part of Doily then it knows where to look for the files.

The interesting part of this is actually the interface. Should it be an option (e.g. doily -w)? A git-style subcommand (doily words)? A separate command (doily-words)?

I'm leaning towards the last one. It seems clearest.

I'm still playing fast and loose with backwards compatibility right now, but I should pick a time to knock that off.

Let's nip some spaghetti in the bud. Stuff like the git repository and the streak counter aren't part of the main function of doily, so they can very reasonably live in their own files. This is true of most of the other enhancements in the issue tracker, too. So how should we organize them? Questions:

• How to turn on/off these extra pieces. Right now this information lives in top-level booleans in the config directory; if we're going to add arbitrary ones, it might make more sense to have instead a list of options to turn on. This keeps the config file readable and makes it way easier to maintain.
• How to call them from the main script. No good having a nice generalized opt-in list in the config file if we have to manually test for and call each one by name from the main script. We can use the list of options to choose what to source and what functions to call, but we still need to know when to call them.
  • So far it looks like most of them are no more complicated than "do this before writing" (prompt (#9), timestamp (#8)) or "do this after writing" (git, streak counting).
  • One exception is the word counter (#5), which is really wants to be its own command. See notes in that issue.
• Where to put configuration for the options! git, for example, can automate commit messages or not, and the writing prompts will have lots of choices. Asking the user to go fiddle with a million files by hand seems excessive.

Here's one way this could look:

• Add a /plugins directory and put files with extra options in there.
• Add a section to the config where you can list the plugins you want to turn on, by name. (Probably just a space-separated list, there's no reason to allow spaces in plugin names.)
• Standardize the interface for those plugins so that we can automatically call them at predetermined hook points (e.g. my_plugin::pre_write()).
  • Have one of the hooks be defining a command-line option, so that the word counter can implement doily --word-count or whatever.
• Use an option to drop the user into doily config file automatically (in the same way that it already drops them into daily files). This has a couple of benefits:
  • We can store the config files in a standard place without making the user type out the weird path.
  • We can easily have separate config files for particular plugins.

Normally this would be the point at which I decide that this is getting out of hand for a bash script, but most of it is still just filesystem manipulation and calling external commands ...

This is my test for the plugin system (since it's already written), so it may as well be in the milestone. Adding an issue for it is half formality and half giving me a place to leave notes about it.

For example: there should be a maximum length of the streak ticker. Possibly it should be configurable, but at any rate we can initialize it with the number of dailies in the directory. (Although if we do that we have to check to make sure each file exists, in case extra files got added.)

Also, turn off git in the default configuration.

Much like the one for $EDITOR, just note that it's best to set it elsewhere but it can be set here if need be.

I'd like to use a different vim config when I'm writing in doily than when I'm writing code (notably, no autoindent, and maybe map hjkl to g+hjkl). I'm pretty sure I could do that with command-line options (if nothing else, specifying a different config file or something).

(Including the options in the editor variable won't work, and I don't want to have a more specific variable like an alternative configuration file, because it should work for different editors.)

This could be a preset, random, internet-sourced, or the end of the previous file.

This should talk about the style guide, comment boilerplate, and test helpers, for starters.

Found a bug in those lines that would have been readily testable.

This is premature, but noting it so I don't forget it.

I like lists. Remembering to update the readme, or the inline configuration documentation, is cool, but being able to go down a list and notice you haven't done it yet is better. When I'm ready to assemble release builds, I should make this list and then keep using it.

First pass:

• Updated changelog
• Updated inline configuration documentation
• Updated readme
• Ran linter
• Wrote applicable tests
• Ran applicable tests
• Updated appropriate issues

I did some manual testing, but should write some automatic ones for regression.

A would-be user should be able to download one thing, run it, and have everything be arranged appropriately for them to be able to just call doily and have it go. Or as close to that as is feasible.

Elly's Make example demonstrates one way to automatically moosh together separate files into one for downloading and unpacking. This could for example be used to build a script that automatically deposits the script and the initial config in their places (obviating the need to check for this in the main script, even).

Where are those places, though?

• The config file's place is already defined (would have to move that logic over, but an install script is a better place for it anyway).
• The executable can go in ~/bin for a normal user, but we'd have to instruct the user to put that in their path if it isn't already. No getting around that, though. (Technically we could append to .bash_rc and source it, but that seems a bit invasive.)
• For a superuser installing systemwide, /usr/local/bin seems to be appropriate for software that's not being managed by the packaging system. Default config in /usr/local/etc I think, but I'm not sure about the plugin hierarchy we're discussing (#11). /usr/local/lib maybe? /usr/lib is mostly C-looking libraries but seems to have some application-specific stuff in there too.

What does the interface look like?

Something along the lines of:

wget github-yadda-yadda/install-doily.sh
bash install-doily.sh

maybe, with an optional --user for installing just for yourself? Or is that that default?

To make testing and debugging easier.

finn@black-heron:~$ doily read last
/home/finn/.local/share/doily/dailies/ is a directory

In general the commands could stand to be more robust.

For anyone who's curious how long they spend writing, words written per time, etc.

Here's some inspiration.