marksweiss / organize-m Goto Github PK

TODO

• build .zip and tar
• update release notes
• update upload to downloads page

RELEASE NOTES

1. Added support for priority Item Element
2. Fixed bug in ordering of groups of items with --rebuild_grouped
3. Added support for configurable data file
4. Added support for configurable backup file
5. Improved display of group labels for --show and --rebuild grouped
6. Added general set configuration ability to public API
7. Refactoring to a clean MVC design to support future scenarios like CGI or Google Apps support
8. Refactored Item and Element to be totally generic and driven only by Element config in new element.py. This makes it very easy to add new elements.

• map to orgm commands to have color-coded commands in the shell

• document all pubic methods and args
• all public methods should have ePyDoc documents
• use ePyDoc ot generate code documentation
• add doc/codedoc to repo

In emails in Yahoo email. Then rerun unit and manual tests

--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

• [NOT DONE] also support an additional convenience arg: --next
• these will list in date descending order
• [NOTE DONE] additional feature is a modifer (like --regex) for --asc and --desc

• Need sort predicates and tests (uggh)

• 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

• --set_conf to switch between them
• 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

• make this another --set_option* star option from cmd line
• just sets a flag in persisted options that is checked on all writes
• --add, --add_empty
• --regroup
• when set all edits trigger replacing file at backup location with newly changed .dat file
• uses same backup locations as now -- set_options if set or default if not

• move tests into their own directory
• move data file into its own directory?
• move everything under organizem parent directory

NOTE: Need to balance code design with ease of use for average user, who needs only to know how to run orgm.py and edit the text file

• 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

• Use Matt P.'s caribou as example

• 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