It's GREAT to see vimwiki at the top of Hacker News.
I've been using this for years, and keep all my notes in a wiki[0], written in GitHub flavour mark down, with syntax highlighting etc. in the editor. I guess it's not orgmode (which sounds amazing), but it seems really really good to me.
I created the vimwiki_markdown[1] gem which allows you to convert GH style markdown to HTML using the wiki. Now I might just call out to pandoc, but I didn't know about it at the time, and my gem works fine*
I love that you can have project specific wikis etc. It's just so great. I'll also link to the relevant section in my .vimrc[2] if you are going to go down the markdown route.
This definitely appeals to me for its simplicity, but the major downside to this approach (for me) is that you can't (easily) draw pictures.
So often when I am taking notes, the notes involve diagrams. Markdown is great at text, but has nothing for diagrams.
After a lot of thinking about this problem, I've decided to start using an iPad with an Apple Pencil and Microsoft OneNote. Here is an example of some notes I took when thinking about an AudioUnit plugin that would dilate time:
The engine is very good; it's recognized all my writing. The downside is that it is offline -- it happens in the cloud. This means it's a little delayed and sometimes it seems mysteriously unavailable completely.
Ha, I see your point. I used "offline" because it is happening in a way that is disconnected with my interactive usage. It doesn't analyze the handwriting as I write, it processes it in batch later, and this might even happen during a moment when I'm not connected to the internet. But I can see why this usage could be ambiguous or confusing.
While I never got on terms with orgmode, I cannot praise vimwiki high enough. It's intuitive and simple enough to not have very steep learning curve.
I use it with taskwiki [1] extension, which stores all the tasks in the awesome Taskwarrior [2] CLI task manager. With this, I have my tasks in my text files, searchable just a command away on the CLI or my mobile phone via the Android app.
I've setup vimwiki, taskwarrior (ubuntu),taskwarrior for Android and setup sync with a server.
How do you get the items you add in the Android App to show up in Vimwiki?
Being able to easily edit on the phone (iOS) side is what has kept me on something like Wunderlist. I prefer text files on my laptop and home machine, but it's not as easy to edit them on iOS.
Your comment inspired me to try all 3 tools in combination, and at first glance it seems like a very nice solution; certainly more effective than my current manual method.
A quick question for you though, if you don't mind: do you use taskwarrior just as a backend for taskwiki or do you use it in its own right aswell?
I like the idea of just being able to add todo items quickly from a shell without opening the task list but I imagine those items would not be reflected in my taskwiki list without some kind of taskwarrior hook.
On the contrary, taskwiki provides two-way sync, so they will show up in your taskwiki lists. The feature is called Viewport, and it's a header enhanced with a taskwarrior filter:
Say you have all your work tasks tagged with 'work'. Then your taskwiki file might look like this
This file contains all the work-relevant information.
=== My work tasks | +work ==
* [ ] Implement feature X
After saving that file, you will see the task in taskwarrior as well (with the tag assigned).
If you subsequently do:
$ task add +work Test feature X
The next time you open the taskwiki file, it will look like this(syncing happens when you open the file):
This file contains all the work-relevant information.
=== My work tasks | +work ==
* [ ] Implement feature X
* [ ] Test feature X
The power of this setup is that you can add a task on your phone (i.e. when the idea hits you in the public transport), have it automatically sync over the taskserver to your desktop, and when you open the taskwiki file relevant to the project, the task is there!
Diary - Hit leader-w leader-w, you automatically get a new page created with today's date to write in. leader-w i will get you to a diary index page. leader-w leader-i will auto-populate that index page.
Tables are auto-formatted to match the text you put into them.
All of this is entirely possible with plain text files, vimwiki just makes it easier to do. It's even compatible with markdown formatted files.
It has a few built-in syntaxes (including Markdown), and can render those out to HTML (including some generic templating for having static CSS/JavaScript).
And frankly, I simply consider it to be a wiki. I rarely if ever find the need to export it out. Makes for a great personal wiki if you're already in Vim.
I have successfully used the export feature to hand off project documentation I was keeping in vimwiki. This way they got a set of HTML files that anyone could view. Some of them did not use vim at all so while this meant the documentation would not be as easy to edit at least it was accessible.
I think I have started doing this 3 or 4 times but then stop because I can't get to my stuff all the time. todo.txt was my last try I think I just need to extend what todo.txt does for my needs..
Is there a recommended way to sync this with a remote server or service? My interest is to share the info between devices. I suppose I could just use a git repo, but wondering if there's a less manual way.
Dropbox works well, as does (oddly enough) iCloud. Syncthing also works well enough too. I simply simlink whichever choice I make back to my home directory, and it works as expected.
I personally didn't create Vimwiki and I didn't add the markdown support, I'm just the main contributor for the last couple of years. But thanks for the kind words anyway :)
Code contributions are the best way to support Vimwiki, since I can't spare as much time as I would like to work on it.
Just want to add my thanks for making this amazing plugin! I've been using it for four years and have always found it to be an invaluable part of my toolset.
I've used VimWiki for a couple years now. I use the most basic features (Enter, Backspace). The ability to instantly jump to the wiki is the most useful (Leader W W). My wiki is just a folder in my Dropbox so I can get to it on almost any computer.
When I started, VimWiki syntax was better supported than markdown. I've seen lots of markdown related pull requests come through, so maybe that's changed.
I use VimWiki for:
* Life goals (stretch and short term). I use it almost as a centering tool.
* Poetry
* Passages from books
* Book summaries (that I write)
* Lecture/Speech notes
* Notes on misc. items I want to explore
* Ideas for future science fiction short stories
Last summer I wrote a simple Awk script to extract VimWiki style definitions (Term::Definition) into TSV's for importing into Anki. I was frustrated that I couldn't fully automate this process without modifying Anki. Maybe someone else has figured this out?
This looks like Org mode for Vim, very exciting! I like the ability to export to an HTML page. It might be useful to export as doku/mediawiki, markdown, or other types of formatting.
For people, not familiar with org mode, the markup portion is a very very small subset of org mode. Org mode is a very powerful tool that is used for many more applications. People complaining about "usability" of org mode do not know where to begin "learning" org mode. The thing is that no one needs to "learn the whole org mode"; you take it in piece by piece, based on the features you need. I started off learning just the (1) org markup syntax, and exporting. You write once, and then export the same to HTML, PDF, markdown, plain ASCII text, etc. Then I learned (2) Org capture.. taking notes at whim of a moment, dumping all notes in a single file (you don't have to do it in a single file) categorized by tags. Then I wanted to take notes with "living code".. notes that contain the code as well as the code output. So that was learning (3) Org babel. Then I wanted the notes to generate files containing the code in those notes. Enter (4) Org tangle. One day I felt like why not experiment with (5) Org table that is plain text spreadsheet that can contain formulas too. It truly is a beautiful piece of software. At some point, I started tinkering with elisp, and started appreciating the org mode design even more. I felt a need to have some thing like the default ASCII exporter, but few of my own tweaks. (6) And I learnt how to design my own custom org exporter.
And I believe that all of that is probably less than 50% of the whole of org mode. I will learn more as and when I feel the need. If you feel lost, read the org mode manual or ask the org mode mailing list.
I really want to learn either Vim or Emacs but I've never been able to decide which one to learn. Every time I've tried to search about this topic I end up in petty wars. Help?
Even though I'm more of an Emacs user, I'd say if you're going to learn one, learn vi. Not vim, mind you: nvi, the original one (you can emulate it in vim with "set compatible"). Use it for a few months until you get muscle memory for it. Just about any UNIX-like system you'll work on, anywhere, has at least the old vi, and it's very useful to just have that muscle memory tucked away.
What's more, if you prefer the Emacs environment, you can run a vi-like editor in it (Evil). Emacs keybindings, on the other hand, are the default keybindings for GNU readline, which is used in a lot of shells and related programs. Additionally, I know that OS X allows you to use Emacs keybindings in any text field. (I am not a mac user, can't comment on this.)
(Disclaimer: I am a happy Spacemacs user, and it would take a lot to pry it away from me.)
I'd recommend learning vi, so you can learn how awesome modal editing is. Then, learn Emacs' basic commands for line editing (so as to make readline apps easier to work with). Once you've done that, evaluate whether a (Neo)vim with plugins or Spacemacs setup is better for you, then choose one of those.
I prefer the Emacs environment: I love TRAMP, org-mode, and the simplicity of getting a fully-featured IDE just by adding a list to my spacemacs configuration.
As a vim user, I have to disagree with the "Not vim" part. Learning only vi would lose too many of the advantages of vim.
Use vim, learn vim all the way. If/when you're working on an "old" vi (e.g. the one in busybox, for embedded developers), you'll need to drop some of the more advanced stuff, but you'll still be able to do what you want, edit some config file or such, though it may feel a bit awkward at times.
But when you're doing the heavy editing, you really want to use all of vim.
Disagree. I'm talking about building basic editor muscle memory and knowing the base set of ex commands that you can use literally anywhere. For that matter I'd say what's really important is that you learn ex.
I'd advise you to learn vim, for a couple of reasons.
The main one is the concept of composability [0] - in vim, you're speaking a mini-language. You have commands (delete, copy, make uppercase,...), and a number of movements (right, down, to the next occurrence of a word, to line 27,...) or objects (word, line, paragraph, html tag, text within quotes, ...) to work on. These can be combined in any way you like, any command can be applied to any movement or object. So if you have a plugin like vim-angry that adds a "C-style function parameter" text object, all the commands you know can be applied to that. In contrast, in emacs, you have a number of commands (kill-line, kill-word, ...), and that's it. You have to get by with those. If they didn't implement the command you'd like to use, tough luck.
A second (minor) reason for me is that I work in the embedded software world, and usually on an embedded linux, there's at least some variant of vim or vi available, while emacs is very rare.
Take my advice with a grain of salt : I've never really used emacs, so I can't compare from first hand. From what I've heard, emacs is also a very good editor. To me, the question "should I use vim or emacs" is more or less the same as "should I use firefox or chrome" - I'm a chrome guy myself, but I don't consider firefox to be crap, nor its users to be idiots. Internet explorer on the other hand,...
So my advice : learn vim. And if you don't, learn emacs. Just learn to use either one properly, and you'll be way faster at editing than people who don't use those.
I'm not sure I'm convinced by the composability argument. Isn't composable the default for text editors? Emacs (and most text editors) let you select a portion of text (Emacs calls this marking a region) and then decide what to do with it: delete it, cut it (Emacs calls this killing), convert to upper case, etc. Vim mostly uses the other order: Commands first, motion or text object later (except in visual mode where it's like other editors: Select something first, command later).
So you just need to implement a bunch of selection commands to get Vim-style composability. I think lots of these modern text editors like sublime or atom come with select word, select parenthesized expression, select paragraph, etc. If the editor is extensible you can define new selection commands and compose them with the existing commands that operate on a region, just like Vim. Emacs certainly has a bunch of marking commands.
The extra commands you mentioned in Emacs (kill-word, kill-line, etc.) are just for convenience: Shortcuts for common cases. In Vim you can delete to the end of the word with dw. In Emacs you could also do a 2 keystroke solution: do mark-word, delete-region (you could use backspace, Control D or delete for that second second thing since they "operate on the region of the selection is active", so C-@ <backspace> would do it). Unlike Vim you also have the option of a single chord with the convenience command kill-word.
Can you point me to some documentation from atom or sublime, where they explain which kinds of selections you can make? I wasn't aware that certain editors seem to have many modes of selection, and a quick web search doesn't reveal very much. I'd like to be able to make a comparison with vim's text objects and movements. My gut feeling tells me that vim will still have more "targets" for a command, and more accurate ones, but I'm biased.
But the "select text and then apply command", as I understand it, still has a major drawback compared to vim's way of working : the dot-command. In vim, you go "daa" (delete an argument - i.e. delete the argument, including the comma which separates it, if you have the vim-angry plugin). Then you move to another argument, you just press dot, and the same thing happens.
I should stop talking about editors I don't use. Let me focus on Emacs with some comments about Textadept (I've never used Atom and only tried Sublime Text for a day).
1. Yes, the ability to repeat with dot is advantage of the Vim model. Emacs just repeats the command part not the marking part too, not as useful as dot in Vim!
2. In Emacs every command accepts counts, just like Vim. Textadept doesn't offer counts, I believe. I think counts are probably an advantage of Vim and Emacs over most(?) other editors.
3. About Vim having more motions & text objects: Probably, but Emacs is close. Without extra packages you have: words, symbols and S-expressions (the names come from Lisp but these do something sensible in most languages: Symbol is usually identifier and S-expression is something like delimited expression: A string, a parenthesized expression, a block in curly braces or brackets, etc.), lines, sentences, and paragraphs. Texts packages add other targets like LaTeX environment. One thing definitely lacking in Emacs is that Vim usually offers two variants that differ slightly at the ends (like w vs e, or i( vs a(), those minor variations are pretty useful.
My point is just the saying other editors don't have the ability to combine commands with different things to operate on is obviously false, and claiming is unlikely to convert anytime to Vim. Instead Vim bloggers should focus on how Vim makes the basic composability idea even better with things like counts, repeatability of composed commands, and richer set of selection commands.
Regarding 1. Emacs does have keyboard macros. A bit more involved than just hitting dot, but they do let you compose an arbitrary sequence of operations (including selection) that can be repeated or saved and applied later.
it's the "a bit more involved" that makes it very weak in comparison. The power of the dot command is exactly that it takes one single keystroke to repeat the last action. You don't have to think in advance "I may want to repeat this action, let's add some keystrokes to store this in a macro." You don't have to push a few keys to repeat the action, just one single key.
I think I understand the advantage of composability. What I was saying is that it is not unique to Vim. Vim uses "command; motion-or-textobject" in normal mode where most editors use "select-what-you-want; command" (which is what Vim does in visual mode). If your editor has a good stock of selection commands (some have select word, line, paragraph, parenthesized expression, etc. -- I don't use atom but Emacs and Textadept have all those and more, like select LaTeX environment) and a good stock of commands that operate on the selection (like delete, cut, wrap in parenthesis, uppercase, etc.), I'd say you have composable editing.
I don't think the link you have addresses my point at all.
It seems pretty clear to me that it does indeed address your point.
That you can build up sophisticated actions just by knowing the primitives and text objects is the point, right? And not having to memorize different commands and different selections.
From the article:
But now let’s look at delete commands. Let’s say you want to delete a word, delete to the end of the line, delete to the end of the file, or delete to the end of a paragraph.
Emacs only has two of these functions: kill-word and kill-line. Atom has the same two, more or less: deleteToEndOfWord() and deleteLine().
Vim, though, is different. Vim only has one command: d, which is “delete.” What does it delete? You name it, literally. The d command gets combined together with those commands for movement: dw deletes to the next word, d$ to the end of the line, dG to the end of the file, and d} to the end of the paragraph.
This is where Vim’s composability leads to its power. Emacs and Atom don’t have commands for deleting to the end of a file or a paragraph — even when they have commands to move to those places. But in Vim, if you can move to a location, you can delete to that location.
And composability is about more than just power, it’s also about learnability and consistency. The command for copying text in Vim is y. Do you know how to copy to the end of the line/file/paragraph? Of course you do: It’s y$, yG, and y} respectively. The command for increasing the indent is >, so you instantly know >$, >G, and >}. Convert to lowercase is gu, so… sure enough: gu$, guG, gu}.
Well, maybe the author of that post just hasn't noticed the similarity between:
Vim normal mode grammar: command motion-or-textobject
Other editor's grammar: select-a-region command
(Also, Vim visual mode grammar: select-a-region command)
Emacs has lots of command that can select a region. They tend to be called mark-something. There are commands for selecting words, sentences, paragraphs, function definitions, S-expressions (the name comes from Lisp but they're defined to be something useful in every language, usually something like "any delimited construct in the language --strings, blocks, array literals, etc."). Once you select something you can apply many actions to it: you can delete it, uppercase it, rot13 it, sort the lines in it, wrap it in parenthesis, etc.
Maybe what tripped the author up is that additionally Emacs has other commands like kill-word, kill-line that are shortcuts for common combinations of a motion and a command. The author is correct in saying that these convenience commands are not composable, but they're nice shortcuts to have (and by the way, contrary to what the author says Emacs does have a kill-paragraph command).
So you to delete a word you can do:
Vim: dw
Emacs composable style: M-@ C-D (that is, mark-word delete-
region[^1])
Emacs shortcut: M-D (kill-word)
Atom composable style: Option-Shift-f backspace
Atom shortcut: Option-d
(I got the Atom ones by Googling, I don't if they are right, but if they're not, I'm pretty sure correct ones exist: Atom has both a composable way and a shortcut.)
Vim propaganda should stop saying other editors lack composable commands. Even notepad.exe lets me use any of its paltry motion commands[^2] available to select something and then use a generic delete command to delete whatever I selected. "Composability" is the default mode of operation of most text editors.
Vim propaganda should focus instead on the very real advantages than Vim's command model has. For example:
- dot repeats the whole command/motion pair. This is fabulous!
- Vim has counts so you can delete 9 words just as easily as 3 words. (Emacs also has them, but lots of editors don't, and they're superhandy.)
- Vim has lots of little variations of the motions and textobjects so you can pick exactly what you need, other editors tend to have fewer. For example, for words, Vim has w, e, aw, iw (and probably others I'm forgetting) which are related but a little bit different.
(Also, personally I think Vim bloggers should recognize that those non-composable commands like kill-word are nice optional shortcuts, that are actually a tiny advantage other editors have over Vim. Try playing VimGolf in Emacs --using the nice vimgolf Emacs package, because of course Emacs has a package for that-- and you'll see what I mean.)
----
[^1] OK, techinically C-D is delete-forward-char in the default keybindings, but when a region is active it acts as delete-region.
[^2] It's limited to character, word and line, I think. But people forget even the lowly notepad.exe has word motions (all text widgets on Windows do).
It's an interesting point you make, that other editors also turn out to have some form of composability. However, the fact that this is the first time I've heard somebody talking about this might have some underlying meaning.
Maybe vim is the only editor where people actually use the composability, because it's only in vim that it's actually usable :-)
In vim, the most common way to delete a word is also the composable way, and also the shortest (just two keys). In emacs, most people probably learn the shortcuts first, so they don't have the muscle memory for the composable style. The composable style is also two modifier keys longer.
So in emacs, first you learn it the "regular" way, with all the shortcuts, and then when you want to learn composability, you have to relearn all sorts of basic things, and spend more keystrokes, to have that.
In vim, you've learned some basic commands (dw, c$, yia, ...), and then I tell you about composability, and you understand how you can combine all those commands and movements you already know :-)
I agree with everything you said. It's certainly true that Vim (well, I guess this comes from vi) takes composability much more seriously than other editors.
I wish Emacs in particular took composability a little more seriously. Probably combining selecting an acting into a single repeatable command by default would be too un-Emacsy (after all, macros are very lightweight and there is evil mode), but it would be great to have all the fine-grained selection commands that Vim has. For example, AucTeX has a command to mark a LaTeX environment, but it also should have what Vim would call "inner LaTeX environment". As a more basic example, I wrote my own mark-line command because what I want to do with lines isn't always kill them! With builtins I think the best way to mark 5 whole lines starting from the one you're one is C-a C-SPC C-5 C-n, which is awful. With a mark-line command you just do M-5 M-L (depending of course on what you bind it too).
There have been attempts to bring better composability to Emacs besides Vi(m) emulators, in particular in a non-modal way. But the ones I've tried haven't fully convinced me. It's definitely possible to do it, but doing it properly might be a major undertaking. Maybe I should just start using evil again.
I was sort of in your situation a while ago and wanted to learn vim, but was a bit put off by all the legacy that it carries (also spoiled by sublime's multiple cursors).
I then discovered kakoune[1] and liked its design. I started getting familiar with it and using it more and more, and I think its core is much more solid than vim/emacs. It definitely doesn't have the same community support and plugins but it's already quite feature rich.
Vim is a useful skill to have because sometimes you need to configure a server. However, I'd encourage you to really learn a modern editor like Sublime before emacs, then visit emacs long enough to figure out if you want it.
It seems vim-notes is much more developed for taking general, self-encompassing notes, similar in style to Evernote. I don't see a way to inter-link the notes like vim's help, but it does have far more rich and powerful note-taking features.
I'd still use vim-wiki because it's intended to be a lightweight knowledge database similar to a mind-map, but more robust. It allows for quick, easy organization of ideas whereas vim-notes appears to be more for a formal writing process.
In all the orgmode threads, a viable replacement never comes up in any other editor, even for the basic features of note taking. Now here we have several commenters who have tried both and really like VimWiki. As an Emacs user who might like a modern feeling editor but stays mostly because of orgmode, seeing the enthusiasm here gives me hope that similar may be reachable in Visual Studio Code one day.
I keep personal notes in Dropbox. I formerly used plain text files, then I used my own syntax highlight format in GEdit. Then I started using Markdown in Sublime Text (with the "Sunburst" colour theme for making everything stand-out).
I tried vimwiki with the files stored in Dropbox but it didn't go anywhere. I liked the simplicity of just bunging stuff in a semi-structured .md file.
I worked with Markdown files in Dropbox for several years. However in the last year or two, I sometimes have occaison to read/write notes from my phone or tablet and Sublime Text is not available for those systems. I tried various Android editors like Markdawn and DroidEdit but nothing I was satisfied with.
These days I am slowly gravitating to Google Keep. It's simple but OK for my needs and I can use it cross-device - on desktop these is even a Chrome app which works like a desktop app.
Sunburst is such a good color scheme. I really like that the background is black.
I've made some changes like make the left gutter grey have grey background (so I know where it starts and ends) and some other changes for the way I like to see html, php, js and css. I might have broken the syntax for other languages.
Been using org-mode. Trying out vimwiki after seeing this and I like the simplicity of it better. It has enough features for me to remove the overhead of an emacs + evil install just for org-mode.
I don't necessarily find it more complex to get started on, but some of the vimwiki defaults with navigation and creating new pages are nice to me. Plus, it makes my workflow simpler, because org-mode was the only reason I was jumping into emacs.
This is really cool! I wrote a small go app awhile back to solve my personal wiki problem (https://github.com/esell/bookie) but since I am in vim most of the day, this seems like an even better solution. You could even just take the output and toss it up on Github pages or whatever if you wanted to share it.
I'm a huge fan of VimWiki and have years worth of data in my main wiki.
What are people using for their wiki on iOS? Right now I'm syncing with iA Writer. It works pretty well, but doesn't support links. It looks like Bear is promising -- it uses the same style links, but it doesn't sync with a folder of text files. Any others out there?
I have tried using this or orgmode at various points, but I haven't been able to find a good workflow for linking images/screen shots with notes (which I do quite often in Evernote). I use vim as my primary IDE, so I would love to find a solution for image links to let me use VimWiki as well.
What kind of workflow do you mean? Simply taking a screenshot and inserting a link to it would be pretty easy, at least in Emacs
;; There probably are better solutions already
;; available somewhere.
(defun org-insert-screenshot (filename)
(interactive "sFilename: ")
(let ((filename (concat filename ".png")))
;; import is from ImageMagick, change to whatever you like to use
(call-process "import" nil nil nil filename)
(insert (format "[[file:%s]]" filename))
(org-display-inline-images)))
I use this so much it became my to-go place to create step by step plan (a.plan) for any project I do. I would also bind :w with converting the wiki to html and have a cronjob to sync the html with the server so anyone can easily check the project I m working on and its progress
I've been using vimwiki for years - it's been an absolute life-saver - but had no idea it now supported markdown. Any one know of a tool to convert vimwiki syntax to markdown or can i just use markdown in new files and keep vimwiki in the old files?
Very cool, I was just searching this kind of thing.
I'd like to see if it would be easy to support ReST beside markdown. I'd like to reuse my current files instead of trying to convert them haphazardly...
you can navigate from within your existing markupdown* files in Vim by putting the cursor on the filename in your .md/.rst file, type gf, and Vim opens the target file.
I wanted to be able to use the links that I was going to write anyway in my .rst files, but they end in .html and when in vim you probably want to go to a .rst source file.
So you write them ending in .rst, and the makefile fixes that up before giving the file to rst2html. Proper nav within Vim and on the generated .html page.
Would work equally well with any capable programmer's editor that allows you to "go to the file under the cursor."
a) writing a syntax highlighting script for your notes files,
b) using tags to jump to documents and
c) using netrw for browsing your files?
Because if it is not, and even if it is just making it easier to do those things yourself, I would personally not even consider using it, having had some really nasty surprises with Vim plugins in the past. Yes, I do mean you, Powerline.
Actually there is. There is very neat solution whose name escapes me. It might not have all the featured of VimWiki, but it had others that were as cool.
Org mode has a 5 year advantage over vimwiki (2003 vs 2008) and significantly more contributors. Vimwiki only seems to have had meaningful contributions from others since Q3 2014 So maybe. Who knows.
Ah, but that assumes popularity is all that matters. I think that emacs's programming model and programming language are both superior to vim's, so it wouldn't surprise me to see that it takes longer to implement the same functionality with the same extensibility in vim than it would in emacs.
It also assumes that the average vim developer has roughly the same skill as the average emacs developer. Is that true, though? Obviously I'm biased, but it seems to me that emacs is far friendlier to the sort of user who demands the ability to extend his environment as he wishes.
Which leads me to the question of whether as many vim users are also vim developers, as emacs users are also emacs developers? I think that the former is fairly uncommon, whilst the latter is fairly common. Sure, there are emacs users who don't extend it, but my perception is that they are far rarer than vim users who just use their editor.
How so? Emacs has been extensible since it was written; vi wasn't until vim came around, and writing extensions in vimscript is pretty brutal compared to using elisp.
Does vim have an equivalent to gnus, magit, eww, erc, emms, slack-mode, info &c.? Probably a few of those, but of the ones it has are they as mature?
When I tried it (about 2 years ago), I found org a bit tedious for this particular use case: a personal wiki, made up of a bunch of small interlinked files, intended to be exportable to a plain HTML wiki-like set of pages. It's possible to do, but required fiddling and elisp writing on both the emacs side [1] and the export side, and I gave up somewhere in the export process. The export system has been reworked since then, though, so it's possible things are now better (would love to see a tutorial on how to do this if so).
There you go. Very little Elisp required, and maybe a little bit more if you want styles. But if you don't have the constraint of being able to browse file:// style, you can link absolutely, so you just need a template, which is doable.
Or you can use the Jekyll plugin, if you want to go that way.
I've been using this for years, and keep all my notes in a wiki[0], written in GitHub flavour mark down, with syntax highlighting etc. in the editor. I guess it's not orgmode (which sounds amazing), but it seems really really good to me.
I created the vimwiki_markdown[1] gem which allows you to convert GH style markdown to HTML using the wiki. Now I might just call out to pandoc, but I didn't know about it at the time, and my gem works fine*
I love that you can have project specific wikis etc. It's just so great. I'll also link to the relevant section in my .vimrc[2] if you are going to go down the markdown route.
[0] http://wiki.psdavey.com
[1] https://github.com/patrickdavey/vimwiki_markdown
[2] https://github.com/patrickdavey/dotfiles/blob/682e72e4b7a70e...