--show_grouped and --rebuild_grouped use variants of --title, --project etc. that start with 'by'. In practice this is confusing and not useful. Would be better to just support the existing element names that are already supported and used with --add, --find etc. Also, can just leave old by_* ones in place and be backward-compatible.
"Why do you care about another TODO organizer? Because you want to work quickly from the command line to add, delete and find TODO items, move into a text editor to do more involved editing of items, and move seamlessly between the two. If that sounds like how you work, or might want to work, Organize-m is for you."
Then include very brief install instructions.
Then add two cookbook examples and links to full cookbook and full documentation.
Refactor (5fc06ab): added getitem() to class Item for cleaner access to arbitrary Element values
Feature Request (d978f48): modified command line for --show_grouped, --rebuild_grouped and --show_elements to take modifiers of --title, --area, etc. instead of --by_title, --by_area, etc. This supports consistent use of non --by* forms everywhere so there is less to remember and CLI is simpler and more consistent.
Refactor (8a3a7e8): Major restructuring of Enums in element.py, orgm.py and organizem.py -- made all of them derive from Element enums as much as possible. Total DRY now -- nothing repeats but everything is declared once
Feature Request (17ca8c4):
-- Modified --show_elements, --show_grouped and --rebuild_grouped to group by priority
-- Modified --show_elements, --show_grouped and --rebuild_grouped to group by due_date
-- Modified --show_elements, --show_grouped and --rebuild_grouped to take an optional action argument for sort order of the groups, based on group labels. Default sort order is ascending, but --desc flag can be used for descending order
-- Modifed --show_elements, --show_grouped and --rebuild_grouped to support --next as an alias for --due_date, i.e. - to show items with due_dates closest to current date
In combination with --find and --rebuild_grouped and --backup, this supports a very flexible system allowing users to create and save different filtered and grouped views of the data and recombine them arbitrarily
cmd to specifiy a specifc action points to a specific data file
ability for actions to apply to one or all data files
The idea is to support use cases like one file for work TODOs and another for personal, etc. Also, n a business environment you could have different TODOs with different backup policies, etc.
Algo is correct but it has loops for every list/list and list/str comparison. Is there a way to convert str to list, use sets, use list.extend() or map or helper functions or something to make is shorter. Matt P challened me on this.
This would let the same app work as cmd line, in text editor or in web app
All would use same data (somehow) so wherever you went you could have any option in synch
This would make the program hugely more useful because data would be available anywhere you had a browser
Note that low-budget but still awesomely useful alternative exists -- work locally and then run a shell script/batch file to copy updated *.dat file to a Dropbox folder or drop.io or Yahoo etc. Internet storage. If user just remembers to run this one low-tech step then their data is available wherever they go and they always work the same way -- CLI and editor
Very brittle right now. Adding --priority took about 3 hours and required about 20 code changes and new unit and manual tests.
What we want is to drive elements from config and have them auto load using:
setattr, getattr
loaded into has that knows its keys (these are the elements)
kwargs where we need to take them in separately
Second phase is that they are user configurable with defaults in the config file, so have standard defaults elements but users can change this however they want
Index
-- inverted index dict, keys are words, values are:
[item element hashes | element having term | position of term in element value]
-- store in separate index file, as serialized Py object, pickle
To search
-- load index
-- match keys to each search term, either exact or regex
-- match means successful match of all terms in sequence
-- unhash each value into YAML item
-- return matched, unhashed items to stdout
New commands
--find --fulltext [--regex] {element type} {'match terms'}
--rebuild_index
Currently have to change hard-coded .dat file name in lib/organizem.py. This is bound to lead to checking this in with wrong path
What we want:
-- config to set standard and test .dat file path
-- cmd line switch to set something global that organizem.py init() checks to configure itself for that operation as using one or another config, standard or test
-- cmd line switch(es) to toggle this so it can move between standard and test
-- Leave this undocumented, but eventually this becomes a feature for users
Currently each deployment directory just has one config file, and it stores the most recent data file location
So if you want multiple windows open and each pointing at a different data file, you need a separate deployment directory for each. Which is kind of weak
Better would be a command 'create_application MY_APP' that would create a named config file
The main config file would change to only store mappings of app names to that app's config file
Commands could now lead with an application name and when parsed and executed that application file's config will be uses (so reads and writes will go against the data file for that application)
If commands omit an application name, the default name will be used and the default data file will be used
So, usage now looks something like this:
./orgm.py create_application work
./orgm.py work -D -F work.dat
./orgm.py work -a -t "This is an item added to the work.dat file in the 'work' application"
./orgm.py create_application personal
./orgm.py work -D -F personal.dat
./orgm.py work -a -t "This is an item added to the personal.dat file in the 'personal' application"
There is also a 'set_application MY_APPLICATION' call so that you can open a window, set the application, and then all calls will use that as the default. NOTE THAT YOU CAN'T USE MORE THAN ONE APPLICATION IN THE SAME DEPLOYMENT DIRECTORY WITHOUT TOGGLING THIS OR EXPLICITLY PASSING THE APPLICATION ON EACH CMD LINE CALL