I would add that Orgmode in Emacs is used by many in nearly the same way. Freemind and mindmappers in general are basically just visual outliners. For me, you get enough of the visual aspect with Orgmode (and OP's example doesn't even really use special visual aspects of a mindmapper) and the kicker is that Orgmode has features that make it more useful than Freemind. Two that come to mind are (1) orgmode search/agenda functionality allow searches that isolate a specific set of nodes in the agenda -- with each agenda node potentially from different part of document, or even spread among multiple files, and (2) in Emacs you're doing all of the editing in a first class editor.
Orgmode does have import and export capability for Freemind, check out the commands beginning 'org-freemind-'. To convert OP's python.mm file to org you can open it in Emacs and then run command <alt-x>org-freemind-to-orgmode .
I have installed FreeMind many times over the years, but I also fall back on org-mode and Dropbox. The quick mouse and arrow navigation and visual layout of FreeMind is appealing, but once you're invested in org-mode, it's hard to let go. I also use a lot of inline web links with descriptions, and that doesn't seem to be supported by the mind map tools.
That said, this post is a reminder that I should be tracking more documentation and code snippets in this way.
Not sure, but I think jury nullification may apply only in criminal cases, essentially because of guarantee that defendant can't be tried more than once for same crime. With obvious misapplication of law by jury in a civil case I don't believe there's anything to prevent correction of the error.
Right, the alternative is to just sort of guess how much you need to ctrl-u/d or j and k to get to a specific line. Also, I guess it depends on screen size. I usually have plenty so the line numbers' usefulness outweighs the extra space required, at least for me.
I'm the main developer of VimOrganizer. I'm sure other people have had this reaction, but it mostly results from not fully understanding what Org-mode is and how it works. Org-mode is many things to many people, with a feature set that's deep and wide, and even many Org-mode users don't know everything it does, barely scratch the surface.
Regarding the issue of running an Emacs server alongside VimOrganizer: Would you rather a tiny Vim project try to duplicate all of Orgmode's functionality when (1) only a small percentage of Org-mode directly involves editing text, (2) many of the major Org-mode features are basically batch operations that export and/or evaluate an entire file at a time, and (3) Emacs is lightweight and functions well as a server for Org-mode batch operations, and (4) Vim's stated philosophy is to co-exist and interoperate with other apps in the Unix toolchain?
It's a matter of not reinventing the wheel. Org-mode is a pretty large project, probably approaching 100k lines of code. It's been around many years, heavily developed the entire time and it still presents a quickly moving target, new features and bugfixes added almost daily. What sense does it make to try to duplicate tens of thousands of lines of non-editing related code in a fledgling Vim project? Why not make use of Emacs/Orgmode as a server, a function it does well, and leverage the entire Orgmode project?
Although most heavy VimOrganizer uses would want to keep an Emacs server running, they don't ever need to edit a file in Emacs. At most they need to do some minor configuration in the .emacs config file, but that can be done by editing the .emacs file in Vim.
I agree EVIL is pretty good, feels much better to me than Viper/Vimpulse. One issue with any Vim emulation in Emacs is the need to create vim-like keybindings for add-ons, like Org-mode. If you don't do this, and if you use many Emacs add-ons, you'll enter Emacs ctrl-key hell despite having decent Vim emulation.
Below is newsgroup thread with basics of adding Vim-style keybindings to Emacs/EVIL for Org-mode. I chose to make these sample bindings same as those I use in analogous functions in VimOrganizer. (I'm the author of VimOrganizer.)
The way I understand it, it means missed days, opportunities and chances. Every day you try to trick the system (meaning life), it teaches you by taking away a day from you. Now it can take that day in a good way (you learnt something) or it can take that day in a bad way (you wasted a valuable 24 hours of your life that you'll never get back).
Sounds fine, but -- to me -- like many of the other points in the piece, it applies equally both before and after graduation from college. I think a lot of college kids fool themselves into thinking what they do during college doesn't matter; they'll start anew and turn over a new leaf when they graduate and "adult life begins". It doesn't work, those sorts of rationalizations are similar to New Year's Resolutions, which also don't work. Adult life doesn't start with a blank slate after college graduation; college kids are already living their lives and, to use the author's own term, amassing their own life debt.
The problem is that these people (and others) don't know enough to realize their economic predictions are worthless. There is truth to the old saw, "Economists are good at predicting recessions. They've predicted eight of the last three. . . "
In many cases the prognosticators are fully aware that their predictions are worthless but persist in the facade to build up a reputation. It takes only a few lucky coincidences to get set up for life. People love to hear bold predictions.
[edit: Not sure why the downvote, since I was just trying to clarify concepts. "Literate programming" was invented and clearly defined by Don Knuth, and it muddies the water to suggest that merely doing good comments is a "literate programming style". Good commenting should be part of every programming "style", and literate programming does not primarily focus on "good commenting", focus is on two concepts described in Wikipedia article below, (1) tangling" of a primary source into machine-compilable form and (2) "weaving" of a primary source into print-formatted form suitable for human understanding.]
Merely having "English narrative" does not get you to literate programming. You can call it a "literate programming style", which is fine, but it's important to understand what true "literate programming" actually requires:
'Literate programming tools are used to obtain two representations from a literate source file: one suitable for further compilation or execution by a computer, the "tangled" code, and another for viewing as formatted documentation, which is said to be "woven" from the literate source.'
http://en.wikipedia.org/wiki/Literate_programming
Tools like Javadoc are related to the second part of literate programming above, and allow for creating some formatted documentation from source code. ( http://en.wikipedia.org/wiki/Javadoc ) They don't get you all of the second part of a literate "woven" program, though, which includes text with all of the source of a program in a format suitable to be read like a book or literary essay.
Tools like Javadoc also have absolutely nothing to do with the first idea in literate programming (above), which is to have an ultimate source document where code is organized and presented in manner best suitable for human understanding, not in manner that's tailored for machine compilation (e.g., for machine-compilation the code may need to be separated into different units or files, whereas in literate source that would not be done unless it were an aid to understanding).
All that is not to say that trying to be a little more "literate" with comments in regular source code is not a good thing. But it's important to understand that "literate programming" is a clearly defined practice that requires much more than good-quality commenting.
I think the better systems of literate programming allow you to change code in either place. I.e., you can edit the "literate code", which is "tangled" to create a directly compilable codebase. Or you can edit the "tangled" codebase, and have changes there be "untangled" to the literate form of the project.
I'm not sure whether this is an issue merely for the new versus the experienced programmer. It is an issue I see as even more important to debugging, where all the debugging tools a programmer uses are geared towards working with the compilable codebase, not the literate one. To make things work smoothly you need to be able to edit the compilable codebase and have changes be reflected in its untangled (i.e., literate) form.
Where is the link between the graphical analysis (investors as a whole are bad at timing the market) and the subsequent quotes, (e.g., Bogle saying "I do not know anybody who has done it successfully and consistently. . . .")
It is a far cry from knowing that investors _as a whole_ don't market time well, but that has nothing to do proving that some skilled specific investors might not be good market timers.
For the record, I do think there's evidence out there that does show that even the "best" market timers succeed largely because of chance or luck, but it's not something you can get to from the data offered here. Because there are individuals who do succeed at timing the market. The question is whether they succeed due to skill or luck. . .
They're both part of the same story: that individual investors are bad at this, and professional managers aren't any good at it either.
Fair point though, that was definitely a conceptual leap of some distance there between the two.
The skill vs. luck argument is actually better investigated by looking at a separate data set: that of the persistence of performance over time for the same manager. We'll do a story about that sometime in the future.
I would add that Orgmode in Emacs is used by many in nearly the same way. Freemind and mindmappers in general are basically just visual outliners. For me, you get enough of the visual aspect with Orgmode (and OP's example doesn't even really use special visual aspects of a mindmapper) and the kicker is that Orgmode has features that make it more useful than Freemind. Two that come to mind are (1) orgmode search/agenda functionality allow searches that isolate a specific set of nodes in the agenda -- with each agenda node potentially from different part of document, or even spread among multiple files, and (2) in Emacs you're doing all of the editing in a first class editor.
Orgmode does have import and export capability for Freemind, check out the commands beginning 'org-freemind-'. To convert OP's python.mm file to org you can open it in Emacs and then run command <alt-x>org-freemind-to-orgmode .