relsqui / doily Goto Github PK
View Code? Open in Web Editor NEWA script for managing daily writing.
License: MIT License
A script for managing daily writing.
License: MIT License
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
describe
install
uninstall
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:
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:
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:
Here's one way this could look:
my_plugin::pre_write()
).
doily --word-count
or whatever.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:
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?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.