hesitz

Nice, great way to organize information.

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 .

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.

I think the point is that it's harder to see what line number you want to jump to if you don't have line numbering on. . . .

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

http://thread.gmane.org/gmane.emacs.orgmode/52815/focus=5281...

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.

I wish I understood what that sentence is supposed to mean. "Life debt"? It seems to be in code, or shorthand, or jibberish.

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

I wonder if you got things fully figured out. What "verbosity" are you talking about: (1) words in non-source sections or (2) code in source blocks? The code in source blocks is basically identical to code you would have in a normal source file. As far as words outside source blocks, I think org-mode is cleaner than other software that tries to do similar things, e.g., most LaTeX markup is not present in the org document itself, instead it's added automatically when exported. Also, various parts of the document can be entirely collapsed from view, expanded only when needed.

In any case, the idea is not to "read" the org file itself, the "literate" part of things comes about from (1) "tangling" embedded source blocks to compilable format, and (2) exporting the org document to pdf, html or some other format that is nicely formatted for reading (or publishing, like the document that was referenced in this post).

Please understand I wasn't necessarily defending SOPA as written; I was merely objecting to people who were naively saying, "This is what it says and there is no other way of interpreting it". (Mostly, perhaps, because I think it's dangerous to assume SOPA-advocates intend this SOPA provision to apply in a nefarious (or ridiculous) way. Ascribing ill-motives to your opponents is not helpful when trying to resolve things in way that's acceptable to both sides. . .) Also, it's not clear to me that Turar rewrote it, seems to me he's simply rephrasing what he sees as part of its meaning and asking how it makes sense. . . It is virtually always dangerous to look at a single provision of a statute in isolation. It is often important to know how it interacts with or how its own interpretation is affected by other provisions in its Act or other laws that already exist.

Regarding interpretation of your TOS: it's a complicated world. It would be nice if the general public was aware of and expert in the law of contracts and licensing, specifically as applied to software and in context of mass-consumer-products. Unfortunately, we live in a complicated world. Moreover, in many cases (perhaps "most" if they're ones that actually get to court and have lawyers on both sides) there simply is no absolute answer as to "what the law requires".

It's often hard for non-lawyers to understand just how incapable language is of defining a system of rules that can be definitively applied to always determine a single result in every situation. The truth of the matter is that in many cases even a lawyer who is expert in a field can't tell you "what the law requires". The lawyer can give an "opinion" regarding how the law applies to your specific factual situation. That opinion would presumably include an indication of different possible legal outcomes, along with the lawyer's confidence-level in each possible outcome. . .

But tell me, how would it have helped you if you yourself were absolutely certain (and correct) that Apple was misapplying its TOS and was in breach of contract? Even if you were right, contesting their decision is not an economically viable route for you. As I said in previous comment, this sort of disparity in "bargaining power" has been common for decades if not hundreds of years, it's a condition of the modern world. Yes, it's unfortunate and it would be nice if things worked differently. How exactly to change things is not so clear. Class actions arose as one method of addressing the problem, but as I said earlier they're not a very good solution. . .

On a slightly different note: As technical people here at HN, it's sometimes interesting to think of the big picture of computing as a whole, how amazing it is that a computer runs at all (much less that they run "well"), given the complexity of an OS, all the different types of software that run on it, and the prevalence of bugs in even simple systems. Increase this by orders of magnitude for all the computers running and cooperating on the internet and it becomes even more amazing. The legal world has an analogous wonder, I think. How can it be that a society runs at all when governed by a system of laws that is necessarily (and obviously) imperfect for its intended purpose (too complicated, incapable of unambiguously determining a single outcome in many cases, etc.)? I don't know, but things keep on working, more or less. Of course, improving the way things work is always a good goal. . . .

thepiratebay.org is one obvious example. Although this would seem to be a foreign site, it is actually a "domestic internet site" and a "U.S. directed site" under the terms of SOPA. This is because the '.org' domain (along with '.com' and some others) is a domestic top level domain under the terms of the SOPA. See Section 101. Definitions in the bill: http://thomas.loc.gov/cgi-bin/query/z?c112:H.R.3261:

Note that S.103 that we're talking about deals with "U.S. directed sites", among which, presumably most sites with domains of .com or .org would fall, since registrant for those domains is under U.S. jurisdiction, giving U.S. "minimum contacts" sufficient to assert its authority over the site. That's my reading, anyway.

It's impossible to completely avoid ambiguity and vagueness in law. Lawyers don't enact laws, legislators do. And lawyers don't "tolerate ambiguity"; lawyers exist in large part because it takes experts to know how enacted laws will be interpreted by courts (in part because of their inevitable vagueness and ambiguity). Legislators can and usually do try to lessen ambiguity and vagueness in laws they enact, with varying degrees of success. (Like I said, there will virtually _always_ arise factual situations where a law previously though unambiguous and clear turns out to be not to have been unambiguous and clear _enough_. It is the nature of language and rule-making. E.g., how does one supposedly clear and unambiguous law interact with another clear and unambiguous law when they conflict and require different things? Or another example, how should a court interpret a particular statutory provision that, as written, appears to conflict with the general intent of the Act the provision is in? Interpret the particular provision as it reads in isolation? or interpret the provision in a way that seems somewhat odd when it's read in isolation but which makes perfect sense within its Act as a whole?)

I don't know about your iPhone TOS. You could do some research and/or retain a lawyer to get a legal opinion on what the law requires, which is presumably what a court would do if confronted with your case. If the issue (or a nearly identical issue) has previously been litigated, then the previous court decision will have some (varying) degree of precedential value for your own case.

In case of you and your iPhone issue, this is nothing new. Many everyday situations arise where there simply is no practical way to dispute another party's interpretation of a contract or license. This sort of "do what you can until somebody stops you" has been going on forever. (Class actions exist as one way to avoid this problem in situations where numerous individuals with limited resources are wronged in same way by a more powerful defendant, but the solution they provide is limited at best.)

What do you mean by "not particularly limited" in scope? It seems to me the intent of the provision is that more is required to run afoul of the provision, e.g., that a site also be "designed or operated primarily for the purpose" of enabling or facilitating illegal activity.

I give you that the provision is ambiguous. If so, then that is the problem. Say "The provision is ambiguous." Don't say that it clearly allows third parties to shut down sites like Youtube or Khan Academy. Whether it does or not depends on which way you resolve the ambiguity. (I don't think anyone really believes the current ambiguity would be resolved in court as you or Sal Khan say it must be. The problem is that there is a small risk it could be interpreted that way, which is too much risk to take with something so important.)

Also, I assume SOPA-advocates would be willing to make this provision more clear, to remove the ambiguity. What is your response if the SOPA-advocates amend the language to unambiguously limit the language to avoid the criticism that "it allows shutdown of _any_ site that merely enables or facilitates", so it clearly also requires that the site have been designed with the purpose of aiding that illegal activity? What is your criticism then? Is SOPA okay then?

I agree. It's unpleasant to see him simply ignore the limiting language. He focuses over half the video on the "enables, or facilitates" clause, spreading the false impression that the provision says _any_ site that "enables or facilitates" could be taken down under SOPA. I am a lawyer, but it doesn't (or shouldn't) take a lawyer to see that the provision has fairly strong requirements other than just "enabling" or "facilitating" other violations.

Sorry, but I think spreading popular arguments along these lines is a bad thing. It leaves the SOPA-advocates with the strong response, "Read more closely, you've misread the provision." Now it may be that the provision as a whole is too broadly written, poorly written, too vague and uncertain, but when the SOPA-opponent makes the original mistake of misreading entirely it's hard to win back the desired position of being an authority on why SOPA is bad.

In Vim there are many benefits from having multiple buffers open within the same Vim instance. Buffers share session data of the Vim instance they're in. This has a lot of different benefits, including automatically sharing whatever options or settings have been set (many dynamically or temporarily set), sharing of Vim registers, macros, and command history, all of which are heavily used when editing (if OS handled they would generally share a single clipboard register), Vim-controlled navigation between buffers and windows, Vim-controlled scripting between multiple buffers, Vim-controlled searches of multiple buffers, and more.

Because there are so many benefits of having multiple buffers/files open within the same Vim instance it makes sense to have multiple buffers viewable at once, not to have only one viewable at a time. You lose a lot of editing power if buffers are not open in same Vim instance; it doesn't make sense to open a new file separately in different Vim instance. Moreover, many times split windows are useful to show two different views of the _same_ buffer at once.

"I've been contemplating a rather severe letter in response, but I haven't gotten to it as I don't believe anything I can say to him will be effective."

I doubt whether anything you say to _him_ would be effective. But why not write a response and then post the three letters (your first, his reply, your response) to a blog or website? If you publicly reveal the weakness of his position it could have some effect.

To me the important issue in the 'mimic' thing is that the kid is not a one-in-a-million special kind of genius. (At least you can't tell that from the video.) Instead, he's just a smart sixth grader. I think this is important because we should realize that what this kid did is something most smart sixth graders can do, if they have the interest and devote themselves to it. So we can hold him up as a model to other sixth-graders and say, "Hey, you can do this too."

We're talking about both (1) his presentation and (2) his programming skills. Other kids should be encouraged by his presentation, instead of thinking, "Cool, but unfortunately he's a genius (or super-special, or etc.); I could never do that myself."

I also don't like this, although it's no big deal, and it happens with a few other settings (e.g., 'number'). One way around it is to forget about using the 'set' command entirely and to assign all settings using the setting variable directly. Every setting has a corresponding variable that can be accessed by prefixing with &, so to set paste off you can just do ':let &paste=0'.

What's more, you can press <ctrl-D> to view the whole list of possible completions at one time. For example, enter ':colo ' then press <ctrl-D> and you'll see a list of all the colorscheme names. (The space in ':colo ' is important, since if you press ctl-D with just ':colo' Vim will just show you the 'colorscheme' completion. . . )

Something like the 'NoSQL' project might be just what you're looking for: http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20P...

This 'NoSQL' has absolutely no similarity to the 'NoSQL' databases of the last few years (and predates them all by many years). Instead it's a tool to manage databases of plain text files in the Unix environment. Seamlessly ties together several parts of Unix toolchain, with Awk as the centerpiece. Has surprising features, like searches with joins between tables (i.e., files).

I'll also second that the Aho Kernighan Awk book is a beautiful piece of work.

I'm the author of that clone. I'm making progress, and it's building up to a fairly nice subset of org-mode, but it's not something that would satisfy any truly hardcore org-mode power user. At least not any time in the near future.

The previous poster complained that none of the Vim plugins that try to mimic or clone org-mode "seem complete". That is definitely the wrong way to look at things. Org-mode is a huge app that's been heavily developed for six or seven years now. In some ways org-mode is probably like Microsoft Word: probably 75% of its users access only about 25% of its features, although many of them access a different 25%.

Why try to develop an org-mode clone in Vim, then? Mostly as a personal project I started for fun. I tried switching to Emacs just so I could use org-mode. Even with Viper and Vimpulse add-ons Emacs felt too clunky to me. I had previously worked on a Vim outliner and I knew that part wouldn't be too hard to replicate in Vim. I decided not to stop there and I've gone on to a lot of other features, although it's a fledgling project. In particular, I need to get some decent documentation done. There are a ton of features in my clone that users have no idea are even there. I think so far most of them (like most org-mode users?) use it mostly for simple outlining.

The Vim clone uses a file format compatible with org-mode and actually calls out to an Emacs server to have org-mode do exports to LaTeX/PDF, HTML, etc. So pure document authoring (as opposed to PIM/task management stuff), is one task that the Vim clone probably can do a decent job of now. Adding footnote support is on the list (there's already a Vim footnote plugin that I plan to modify to work with the org-clone).

"org-mode developers, in turn, just ask a relevant big question: 'why use separate files when you can conveniently stick the stuff in one file, dammit?'"

It surprises me that you could come away from org-mode thinking that the developers thought you should stick everything in one file. One of the main strengths of org-mode is the way it frees you to put stuff into separate files, wherever you want, and then use the agenda to consolidate them into a single view.

Having said that, yes, org-mode is freaking awesome.

Don't the various methods of attaching to a remote desktop work well enough? I sometimes work in an IDE remotely on Windows using the native RDC or just VNC. Works great, smooth and fast, I would be happy to work that way for a couple of days if I was without my own machine. I don't see a big upside to sinking huge time and effort into a Web IDE when remote desktops fill most of the important use cases.

Also, how many developers are you thinking will be sharing the server using a Web IDE? For any compiled language I see compilation steps as big CPU hogs, severely limiting shared usage. Even with interpreted languages I suspect there would be CPU-sharing problems. Again, remote desktop seems a better solution.

This is a really great set of articles, top notch overview along with practical advice on idiomatic VimScript and examples that you're not likely to find anywhere else. I find something new almost every time I refer back to these. Just now in scanning through the article on Vim dictionaries I noticed the section on using dictionaries to pass optional arguments. I hadn't written much code using optional arguments last time I read it and probably didn't even notice this section. But lately I've been using optional arguments, wasted time dealing with exactly the problems the author points out, and see the appropriateness of his advice to use dictionaries to pass optional args. This is one example among several where these articles provide excellent advice about good coding practices in VimScript that I haven't seen anywhere else.

Off topic a bit, but for help on legal writing I think the work by Bryan Garner is the best I've seen. Simple, direct, full of great advice and examples. Great stuff:

http://www.lawprose.org/bryan_garner/books.php

On a slightly different note -- and if your LaTeX needs aren't too complex -- I'm working on a clone of Emacs' Org-mode that runs in Vim. Org-mode has a kick-ass export to LaTeX/PDF that adds a good portion of the markup based on your outline structure and some other simplified markup ( http://orgmode.org/manual/Structural-markup-elements.html#St... ), so a lot of the messy LaTeX markup can be left out of your main document.

I originally started work on my Org-mode clone in Vim because:

(1) I was a Vim user and couldn't quite make the switch to use Emacs' Org-mode, (2) I loved Org-mode's export to LaTeX/PDF, and (3) when I switched back to Vim from Org-mode I gave LaTeX-suite a try, but it felt a little too "low-level" for me.

So my thought was to write a simple outliner in Vim that was basically file-compatible with Org-mode (which was not too difficult), then call out to an Emacs server when I wanted to print to LaTeX/PDF. (Same principle works to export to nicely formatted HTML document or any other export Org-mode has.) This works very smoothly; assuming I have my Emacs server running initiating the export from Vim is just as fast and easy as if I were working directly Emacs.

Now I'm moving on to the more difficult task of duplicating other functionality in Org-mode, but if you just want a great way to author LaTeX docs in Vim my clone is already a decent solution for many uses. You can alter the LaTeX preamble defaults and enter LaTeX commands directly in the Vim Org-mode file, but I'm not sure how usable it is for more complex documents. Could do a little checking into Org-mode newsgroups to find out. . .

Anyway, for info on Org-mode's LaTeX publishing functionality see here: http://orgmode.org/manual/LaTeX-and-PDF-export.html#LaTeX-an...

For a blurb about my Org-mode clone you can check here: http://www.vim.org/scripts/script.php?script_id=3342

Best way to get it is from github: https://github.com/hsitz/VimOrganizer

Caveat: The project is in its early state, there isn't much documentation, and there are of course bugs and incomplete features. But for a basic export to LaTeX PDF or HTML all you need to do is (1) start up an Emacs instance to work as your server, (2) write or load an Org-mode outline into Vim that has the VimOrganizer ftplugin, and (3) issue command :OrgToPDF or :OrgToHTML.

Very sorry, my mistake. I thought I had checked and confirm that it did appear to the right and I must have looked too quickly. No, I don't think there is a way to swap those columns. (At least not through Vim 7.2, Vim 7.3 introduced relative line numbering and maybe it has a teak in addition to that -- but I doubt it.) It's not too hard to adjust line indenting so it defaults to minimum that is greater than 1, say 2 or 3, but that would be sort of an ugly hack, inserting blank spaces into your document for mere purpose of viewing more space between line column and text.