Frequently Asked Questions
About Morg
What is Morg?
Morg is a list manager that:
- Allows you to create arbitrary lists of items to any level of nesting
- Allows you to associate items with any number of properties
- Define custom properties, tailoring your time management to your tastes
- Stores its data in an SQLite database
- Syncs your lists across devices without a third-party server
- Can encrypt your lists so they're readable only by you
- Has a command-line interface as well as a GUI
Why write yet another list manager?
Because I couldn't find any others that quite fit the bill. Every one of the others I tried were either too complicated, too limited, or too tied in to a particular methodology. Furthermore, most seemed to need an Internet connection in order to work and relied on a third-party server for syncing. I tend to be leery of such an arrangement.
The closest I came to a solution was Emacs's Org Mode. Unfortunately, I was not particularly enthused by the MobileOrg app. Moreover, I found its approach to syncing between phone and laptop rather clunky. And, although I generally like Emacs and use it all day long on my desktop, Org Mode's interface did not suit me.
Why is it called "Morg?"
Initially, I thought of calling it "Borg" because, well, you know, they do bring order to chaos.
Then, as I am fond of recursive acronyms, "Mnorg" came to mind. It's a play on Emacs's Org Mode and stands for "Mnorg's Not Org" (the "Mn" in "Mnorg" is pronounced the same as "mnemonic," i.e., a silent "M").
In the end, I just dropped the "n." Think of it as a contraction of "morgue," which gives the program a fitting, albeit cheesy, tag line:
Using Morg
What all do I need to be able to run Morg?
You will need the following packages installed on your system:
- Fossil
- Python 2.7
- SQLite 3
- APSW
How do I install Morg?
For now, there is no neat package that you can install. Instead, you have to check-out the source code, which requires Fossil to be installed on your system.
First, create directories for storing the Fossil repository and Morg source code:
cd
mkdir fossil morg
Now, you can clone the Morg repository and check-out the sources:
fossil clone http://chiselapp.com/user/morgdude/repository/morg \
~/fossil/morg.fossil
cd ~/morg
fossil open ~/fossil/morg.fossil
fossil update rel
At this point, you should have the Morg sources in ~/morg. Under that will be a subdirectory named py, which has the main program, viz., morg.py.
That's it: Morg is now installed and you can use it by running ~/morg/py/morg.py.
How do I use Morg?
At this time, Morg only sports a command-line interface. You can launch it by running the morg.py program. Use the --help option to get usage information. In particular, without any arguments, Morg will drop you into interactive mode, prompting you to type in commands until you exit the program.
You can use the help command to get a list of available commands. Passing the name of one of the available commands to the help command will print details about that command.
As these are early days, the only real command you can run is new, which allows you to create new items and properties.
Eventually, Morg will have commands to search the database, edit items, and to remove items and properties. Eventually, we will also build a spiffy GUI for the application so you don't have to deal with the cryptic command-line interface unless you want to run a quick query without having to fire up the GUI.
Design and Implementation
Why are you using Fossil, an obscure version control system, instead of something more well known like SVN, git, or Mercurial?
I wanted to be able to do initial development without the need for a server. That pretty much ruled out SVN.
I am using git at work. While I appreciate some of its features, I find it somewhat tiresome. When it comes to version control, I firmly believe that, like plumbing, it should not stick out the walls. Put another way, I don't want to be an expert mechanic and have a full theoretical understanding of internal combustion engines to be able to drive my car.
While git may be perfect for the Linux kernel and other large projects that have adopted it, it is overkill for Morg, which will never reach that scale (in fact, I will probably be its only developer and user). So, I wanted a simpler DVCS that would afford me the luxury of ignorance.
So far, I am happy with Fossil. I really like:
- its built-in wiki, which makes it easy to produce version-controlled documentation like this FAQ;
- its built-in bug tracker and the ability to link between check-in comments and bug reports;
- its Web interface for viewing timelines, check-ins, diffs, wiki pages, etc.;
- the ease of setting up a server for pushing and pulling code;
- the clean separation between repositories and working copies and the fact that the entire repository is a single SQL database.
Fossil is certainly not perfect. Some annoyances include:
- Confusing merge markers and lack of tracking merge conflicts to serve as reminders in case they're not explicitly resolved. This means you have to read the output of an update command very carefully and remember the files that have conflicts because Fossil won't keep track of that for you. Additionally, since there's no explicit conflict resolution step, you have to clean up the temporary files related to the merge conflict yourself.
- No commit mails. The RSS feed doesn't quite work for me; I'd much rather have an email show up in my inbox letting me know of commits and other activity on a repo. Apparently, a hooks feature is in the works; so this shortcoming may soon be a thing of the past.
- The schism between what you can do using the Web interface and the command line. Some features of the system seem to be accessible only via the Web interface (e.g., amending check-in comments) while others only work via the command line. In other words, the software has two different and disjoint user interfaces, something I find annoying and (for some reason) disconcerting.
- The command set seems to be a bit of a hodge-podge. Shouldn't open be better termed checkout? Is close really necessary?
- Minor bugs such as the inability to include enumerations in check-in comments because lines with '#' in them get filtered out.
- Sometimes, documentation can be a little thin and some of it is downright confusing (what the hell does the second paragraph of the help merge command mean?).
Despite these warts, all in all, I like Fossil. It doesn't impose an undue cognitive load and allows me to concentrate on Morg development instead of having to slow down to think about version control.
I have never used Mercurial. So I cannot comment on it.
NOTE: If you like another version control system (SVN, git, Mercurial, whatever), please continue to use it for your projects. I am not trying to put them down in any way. I am only pointing out why I am using Fossil for Morg. In other words, use what you like and don't tell me about it; I don't care about your opinion.