It feels like the promise of neovim is finally being realized. So much good stuff in 0.5, and now we're seeing cool things being made with the lua integration. It's gone beyond just being a more maintainable fork. It's starting to really feel like the next generation of vim. Very exciting.
> The pain... it won't stop. After so much oppression from other text editors, it's time we fight back.
> Woah, keybinds that actually make sense. Some text editors should take notes.
Am I being overly sensitive tonight, or is it a bit out of taste for a landing page? It's great that they are re-implementing org-mode and I'm all for a bit of friendly banter, but that sounds surprisingly bitter to me.
A shame because I personally found it funny and completely non-offensive as an Emacs user. This weird fake editor war is part of the culture of both editors and I'd prefer this kind of banter to the boring and tired jokes of "it's a great operating system that just lacks a decent text editor".
I have no doubt that this is a useful project, but I sure wish this webpage used words instead of animated images to explain things, especially because the images are taller than the browser size on my laptop (unless I shrink to the point where the letters are too small to read.
The setup steps are also really quite unclear. What content do we insert, and in what file? Just a few more words of clarification on this would be appreciated.
PS. I agree with the contention that neorg, when more completely coded and described, could encourage users to switch from vim to neovim. Another contender (which, for me, is more convincing) is telescope.
The true power of orgmode lies in its embedded source blocks. I have dozens of little codeblocks inside my orgmode files that aggregate data for me.
I also have a a collection of scripts inside org for various tasks, neatly sitting in a todo tree.Babel src blocks are a true game-changer.
What language does neovim/neorg use for scripting? As much as i like orgmode, i'm still not very fond on scripting LISP.
Hm looks like an interesting approach, to let the user configure what symbols to use for what kind of markup. However, using a bunch of regexes reminds me of painful regex writing for Atom, Sublime and GEdit (or was it Geany?) syntax highlighting. It was never really easy to make it work correctly, without disregarding some edge cases. For most users it will probably mean to use a popular config and that's it.
EDIT: From the readme:
> Let's be real here, org and markdown have several flaws - ambiguity (tons of it), ugly syntax and the requirement for complex parsers.
Aside from the fact, that I do not think org has ugly syntax, I think an actual parser is way better than having to rely on putting everything into regexes. It makes the code easier to maintain.
Cool! The reason I sticked with org-mode was org-roam which changed my usage from a single document to a whole zettelkasten system and I love it. Any plans on linked documents?
This seems promising. Some things I would like to see:
1. Deft-like interface for viewing and searching norg files.
2. Perhaps as part of the above, a way to create a new note which is automatically saved with a file name or prefix (i.e. The current date or timestamp).
3. Project-wide todos / agenda view. Perhaps this could be based around dirman's workspace concept.
It seems the author has gone through some trouble to make the project easy to extend, and the documentation looks quite good for such a young project, however from the commit history and PRs it looks like it's maintained largely by a single developer so far. I don't see any links in the README to modules that have been built by the community yet.
I will be keeping an eye on this one. I'm really excited about NeoVIM's future and all of the interesting projects that could be built using LuaJIT.
I'm interested to check this out but for me simplicity is more important than features when it comes to note taking software in general. I've tried apps like Notion, Evernote, etc. but I always find myself going back to Simplenote; it doesn't have all of the bells and whistles of those other apps but it works well for my use case of quickly writing some text and having access to it across all platforms. When it comes to Vim, I get a ton of use out of vimwiki [0] with Markdown syntax. It may not be as powerful as Org-mode (or Neorg in this case) but it's had the most "stickiness" out of any comparable plugin I've tried.
Vimwiki has some basic keyboard shortcuts for editing and navigating between pages in your wiki. It also has a couple of neat features, like the ability to export your entire wiki as HTML documents using a single command. But you could accomplish all of this with some basic configuration changes so I wouldn't call any of those "advantages". To be honest, I don't remember why I started using vimwiki as it was years ago but for whatever reason it has stuck with me.
I have been using vim (and recently - nvim) daily for almost 15 years for development and general text editing.
I'm certainly a big fan.
However, I couldn't really find any set of configurations that surpasses simple todolist applications like todoist/etc.
Sure, If you want to spend your days tinkering and hacking the app that's super cool. But most of us want a todo-list app that just works.
Ability to send notifications to the OS/phone would be nice
Calendar sync would also be nice
Per-project tasks is cool too
But that's mostly it. I couldn't understand from the wiki of that project how can I do those things. Those are the most important issues to address, way before an elaborate discussion on modularity and customization.
I wish installation instructions were more clear. Neorg depends on plenary and packer, and they also don't have clear installation instructions.
I followed steps as well as I could, :CheckHealth doesn't show any plugin problems, but .norg files don't show syntax or any advertised features. Being complete Neovim noob, I don't know how much time I'd have to spend in Neovim ecosystem to understand how to make it work?
How is this different from vim + vimwiki which exists for ages and is very stable and mature?
I don't like this "must rewrite everything in Lua" obsession that neovim has started. The neovim plugin landscape is now riddled with rewrites of vim plugins, often multiple attempts of the same thing, but usually with half the features and more bugs.
Can't say I'm happy with the split that neovim has brought in the vim community, the incompatibly between the two is increasing sharply.
Seems good, but I think Neovim as a platform lacks a couple of features to make this competitive against Emacs org-mode, in particular inline images and proportional fonts.
vim is the "VIsual editor iMproved", which is an upgrade to the "VIsual editor". It works by having a text entry "mode" and a separate text manipulation mode. This is very powerful, but does take some getting used to.
For example, let's say you want to delete 5 lines: In visual studio code, you'd either select all the text and hit backspace, or maybe hold ctrl+backspace to delete whole words at a time. In vim, you'd hit escape to exit "insert" mode, then position your cursor at the beginning of the 5 lines to be deleted, and type "5dd" which means "delete a whole line, 5 times".
In the hands of an experienced vim user, it can make amazing edits to text in fractions of a second. It's really cool! It also works in a terminal, so it's available to you when you SSH to a remote server, for instance.
Org-mode is kind of like Markdown, in that it's a way for plain text to have structure. Something like this:
* Birthday Party Plan
** INPROGRESS [#A] Buy cake
Ask Jen about her baker friend's availability
** TODO [#B] Buy beverages
Talk to Mike about his party and what people drank
** INPROGRESS [#A] Send invitations
<DEADLINE 2021-08-10>
*** DONE Design invites
*** TODO Get Addresses
*** TODO Mail merge
*** TODO Print invites
Lots of stuff going on there! I'm tracking the state of each made up todo item. I've got a priority on the main todo items, and a deadline for one of them.
Org is note taking, scheduling, structured text, even running programs and scripts inside your notes and saving the results in the note itself. From orgmode.org: "Org mode is for keeping notes, maintaining to-do lists, planning projects, authoring documents, computational notebooks, literate programming and more — in a fast and effective plain text system."
So, all of that is being supported by NeoVIM now :)
I hope that helped, let me know if there's anything you want clarified or expanded.
To remove 5 lines in VSCode I would just type cmd-backspace 5 times. Don’t even have to count the number of lines beforehand. Just delete lines until it looks as you wanted. Much simpler than the complex process you describe, that involves counting lines and moving the cursor to the exact correct position.
As always, I am unimpressed by “vim tricks” that vim people always boast about. And I am yet to see a single real use case where vim is faster than good old basic keyboard shortcuts (that includes cmd-d)
Absolutely not. My problem with Vim is I pair program with Vim experts on a daily basis and am annoyed at their slowness while they are proudly using their gimmicks. (Also the length and complexity of the answer you linked makes me laugh, and proves that a category of programmers is more interested in defending Vim than about making things people want)
They have been using its daily at work for many years. And they are very competent and productive programmers.
It’s just that it’s tempting to find the “perfect” combo when performing complex tasks, and that takes time and mental energy even if you don’t realize this. Small time admittedly, but still present and cumulative.
I can't see how someone can use vi for more than a couple of years without doing most everything from muscle-memory. That's the dominant value-proposition, in my view.
That said, your attitude toward use of an editor is bizarre. If you want to use vscode, use it. If not, don't.
If you are trying to convince the world that your choice is the best, and anyone who disagrees is wrong, well, good luck with that.
Delete until next matching parenthesis 3000-ish lines further down is a neat one. Or hex-edit a 5 GB binary. Or doing columnar editing with visual block mode.
These do indeed sound cool. Too bad that most vim users I know face these use cases rarely enough that it takes longer to remember how to do these tricks rather than just do it in a normal IDE.
Dunno. I'm about average and I use 'di(' or 'di{' like all the time. Not rocket science. One nice thing about vim is you basically don't need to remember 'tricks'. They're structured, so you can pretty much guess at a new trick if you want. For instance, d2w. Never used it before. Just used it. It deletes two words. Pretty useless, but the point is, it's not a trick - it's just an application of stuff you use all the time (delete, a count, a word object). Or like, dF. It deletes everything until the last dot. This is also obvious, because you use F all the time to jump to the last occurrence of a character. So 'delete till last dot' is just something you can make up or use without even noticing you're using it. I certainly don't know if I've used it before.
I haven't seen anyone identify themselves as vim user and don't know how to change text inside parenthesis or quotes with ci( or ci" or ci'. How is that rare in everyday programming?
Or delete the entire function/scope with di{.
The limitation of non-modal editing is that you only have arrows and modifiers whereas you can have a whole vocabulary /language for yourself with modal.
You could also hit dd several times or dd followed by a dot to repeat as needed. I wouldn't call them tricks. These are normal actions done in "normal" mode. You don't generally need key chords, which improves ergonomics, and many keys are mnemonics (like d for delete, c for change, etc.)
It's not like finding out about a secret shortcut. You're using a ton of these in a smooth flow to do what you want at the speed of thought and with less finger contortion. If you wanted to be convinced, run `vimtutor` and complete the tutorial. It'll show you a variety of common actions.
You mean “esc, d, d, ., ., ., ., esc” which is two mode changes, eight key strokes of three different types. Versus five identical key strokes with VSCode. Next.
Also define “smooth flow”. I my experience pair programming, by the time you are starting you command after choosing among all possibilities, I have already performed the change with VSCode.
No. First, you don't hit esc at the end to get back into insert mode, assuming that's what you mean - you'd hit "i". Also, it doesn't make sense to include mode changes since you don't know what mode you are in to begin with or what mode you want to be in when you are done. Lastly, this is all you need:
5dd
But as long as you are including preparation keystrokes, how may keystrokes would it be to get to a particular line in vscode? I guarantee it will be a lot more than vim. There are countless ways to navigate to a position in a buffer.
I cmd-arrow + click on it on my MacBook trackpad if needed. Believe it or not, it’s actually really really fast, and in my experience faster than any vim trick.
The reason why it’s faster is that it’s a lower level task: I can just visually go where I want without even having to read contents or even line numbers, just based on text shape, don’t even have to think about it, it’s just muscle reflex.
I don’t have to (consciously or not) plan a strategy choosing the best way among 5 different ways each time I want to select text. And no, this never becomes a true reflex. If it does then it’s just because you always choose the same strategy. You always have this part of your brain that has to think about vim tricks, and believe me, we can see that from the outside.
If you really use vim, you typically are "always" in normal mode. When you want to type text, you go into insert mode, and you leave it when you're done. If you sit around in insert mode, you miss out on a lot of utility.
>Also define “smooth flow”. I my experience pair programming, by the time you are starting you command after choosing among all possibilities, I have already performed the change with VSCode.
There's really not much thought involved. If you can imagine yourself using keyboard shortcuts, it's probably pretty similar. In a simple example, you don't think "I gotta hold ctrl, press c, release c, and then release ctrl", you just think "I'm going to copy this". I think you have the idea that vim is really complicated and its users must be bogged down and thinking more. At worst I would say it's probably the same as what you have now, unless you count very early stages where you actually just don't know your way around too well. When you're situated and experienced, it's not ever slower in my experience. On the contrary I feel a bit disabled when I have to edit in something without vim keys. It's not like I can't jump around with home/end and select text with ctrl-shift-arrows and whatnot, but it doesn't feel as fast or comfortable or natural to me.
> And I am yet to see a single real use case where vim is faster than good old basic keyboard shortcuts (that includes cmd-d)
I feel like I’m far from a vim “power user”, but people regularly comment on how quickly I edit text and code when I’m doing a screenshare. It becomes second nature in short order, so I’m never thinking about some multi-step process to before an edit; I just “do it”.
As for the “5dd” example… there are multiple ways to do things. For me, that would likely be:
In vim you would actually just do 5dk to delete 5 previous lines. Or just do dk to delete one line, then . to repeat until satisfied.
So you get an easy way to repeat actions. You can make this into a macro easily if needed.
Then, most importantly in my opinion, you keep your hands in the normal typing position. The command key is awkward for me to reach and hurts my hands.
Even with the example you mentioned - cmd+backspace 5 times vs. "5dd" - I'm surprised that you can't see why some people would prefer the latter. (Also, if you're on the last line, I think "4dk" works.)
I agree, the "5dd" example is super contrived, though not as much as you think. In vim, you can have the line numbers on the left show you numbers relative to your current line, so you never really have to count, you can just look at the number on the line you want to go to.
But outside of that, the problem with standard editors is that none of your keyboard shortcuts compose together. You have special shortcuts for deleting lines vs deleting individual words. No shortcut for copying objects to your clipboard. No shortcuts for "get me what's within these parens". You can't move between panes with consistent keybindings, because most editors represent code panes vs directory panes differently.
Vim lets you think of editing and navigating your code in terms of verbs and objects, and treats everything consistently. Take the "w" object, that's "word". Now I can move around by word by mashing "w", I can delete with "dw", change with "cw", yank to clipboard with "yw". The "." command lets me repeat, so I can do things like "dw..." and delete more easily. Some plugins add more objects, like being able to refer to surrounded text (e.g., in parentheses.) They compose with all the verbs you already know, so now I can delete inside parens, surround with parens, replace text within parens, copy in parens, etc.
Vim compared to standard text editors is like functional vs imperative programming. It works best for code, because editing code is not like writing prose. You're manipulating a syntax tree.
Thank you for this explanation. It makes sense. But still, I find that vim is overcomplicating things for no good reason. What happened to KISS? Like every time I make this sort of remark, the thread becomes a thread about vim people debating that actually typing dd multiple time is better, or that dk could do the trick, or that select text followed by d is better, or that d% does the trick, or soon someone will share their custom shortcut that address this particular case, etc. Vim people have to think about Vim way too much.
Meanwhile, keyboard shortcuts on a Mac do compose: arrow=Move, shift-arrow=Select, arrow=a character at a time (or vertically, a line), shift-arrow=a word at a time (or vertically a paragraph) cmd-arrow=the whole line (or vertically the whole file).
Also cmd-d has immense powers when you know how to use it.
And finally let me mention that syntax-aware editing is overrated when you use a linter/formatter because regular indentation and normal shortcuts work flawlessly already.
Last but not least: these shortcuts work system wide! So we don’t have to reimplement every possible software within my text editor so I can use these shortcuts.
It's not like you _need_ vim to edit code. If those are the only shortcuts you need, then you don't need vim! It's just very useful for power users, especially with the huge plugin ecosystem. Instead of each plugin adding its own shortcuts, they often compose together with what you already know to make editing even easier.
> syntax-aware editing is overrated when you use a linter/formatter
Not quite what I'm talking about actually. Going back to the theme of "code as syntax tree", when editing code you'll often find yourself needing to do things like "ah I should hoist the code in this paren block into its own variable." Vim lets me operate on that syntax level, which feels more reliable to me than using the mouse to carefully select text. I just tell it to delete in parens (which automatically pulls it into a register that I can paste from), move to a new line, paste with "p". When I edit code it's less about individual characters and more about moving blocks of logic around, which is super important for refactoring safely. I end up making fewer mistakes with vim.
There are many ways to skin a cat. Personally, in vim, I would do "dj" or "dk" twice, (deletes two lines up or down respectively) and then dd for the 5th one. Where vim shines is where you can just naturally start stringing together "sentences" of vim vocabulary and you can do what you mean. The macro system allows you to store these commands on the fly and replay them too.
It looks like your comment spawned a lot of discussion!
I chose the "delete 5 lines" example because it was simple; the person I replied to said they weren't familiar with vim, and I didn't know how familiar they were with editors and code in general.
I think that perhaps you jumped to the incorrect conclusion about that part of my comment. I didn't impugn or insult visual studio code, nor try to insinuate that vim is better. In fact, I use vscode every work day for my devops day job, alongside Emacs for my org-mode documents, and vim for remote editing.
For counting lines, in vim I generally don't do that. If I have, say, a couple hundred lines to delete then I use something like 50dd a couple of times. Once I'm close to the end of what I wanted to delete, I just use dd followed by . to repeat that dd.
There's more than enough space in the world for multiple text editors! It doesn't really have to be a competition.
There are loads of other tricks. For example, say you have discovered that you need to delete an entire block of code. You could position your cursor on the opening or closing brace and type d$. This sounds arcane when you hear it (and to be fair it is to a degree), but once you realize that it's just a combination of navigation and action most of it becomes obvious.
Quite the converse, in fact I use vim mode whenever I can; I would struggle to think of a better way of editing text. (My current editor is Emacs+evil and I don’t anticipate changing it any time soon.) I strongly suspect GGP’s post was simply a typo, as ‘%’ and ‘$’ are right next to each other on the keyboard. And if I were to make that typo while editing a real document, I would need only the three keystrokes ‘ud%’ to undo it and then do the editing action I originally meant.
Looks like another iteration of someones personal markup-flavor, aimed at task-managment for self-organization. Basically, a todo-list in text-form.
But I don't see anything worthful yet which makes this flavor preferable over org-mode or markdown. Seems to be also still very in progress. So give it some more years to grow I would say.
Markdown and Org are not in the same league. However, the goal is to have something like Org in (Neo)Vim. It will take a while, if it ever happens to get to feature parity with Org though.
Edit: I would welcome though, if Org was supported well in (Neo)Vim. Then there would be one less excuse not to use it.
I don't think so. Their focus and culture is different and so each has different tools available, but syntax-wise they are pretty much the same and you can overall build the same tools for both.
Org comes more like an interconnected ecosystem, while in Markdown, you will have to choose your tooling wisely and will still not be able to do all the things you can do in Org. A few examples:
Export to many formats. Emacs ox-... packages. Hit C-c C-e there you go. In Markdown there is no integrated tool for that, there is only the rather excellent Pandoc, but Pandoc itself suggests its own Markdown dialect (! not what we are talking about here) for things like footnotes and quotes and such things, which are required for technical writing.
Running code from Org files in Emacs is, thanks to the Emacs integration of Org, a simple thing to do, once you got an interpreter / compiler installed and configured appropriately. This in conjunction with noweb (oh, did I mention that one?) enables literate programming. Yet another case of needing a specialized markdown dialect.
LaTeX in Org mode documents is possible and the format takes precautions to enable you to do anything you want using LaTeX in an Org file. In Markdown it depends again on your Markdown processing tool. Again Pandoc to the rescue, mostly.
Things like the already mentioned footnotes and citations and quotes. Some of that stuff is not available in Markdown. You can merely patch something up using HTML or, if you use Pandoc, perhaps you can add LaTeX to your document. This becomes a necessity, rather than a choice like in Org, because Org supports these things.
Document internal linking. In Markdown you can again only patch it to full capability by using HTML. In Org it is included in the format.
Tables and spreadsheets. You need special markdown dialects for that, which have special processing tools, which can then do half the things you can do in Org using spreadsheets.
You can probably somehow shoehorn all of that into some kind of markdown dialect or multiple ones and process it using multiple external tools. It is just not there in normal Markdown and you will have to build the whole chain yourself or use some obscure tool, that has already showhorned it all. So Org and Markdown are really 2 different kinds of beasts. For more details you could join the Emacs-org-mode mailing list, where people all the time come with tricky questions and use-cases they are using Org for. Quite an active mailing list.
You're missing a bit the point. Markdown is today a family of flavors and tools, not just the original format made 2 decades ago. Yes, not all flavors have the same syntax, not all tools have the same abilities. Markdown-family today is quite chaotic, but also moving and consolidating. It's constantly evolving and moving forward. And while org-mode in it's single-app-cage provides a better offer in it's specific focus of abilities, markdown is not worse in general and also beats org-mode in other aspects.
And in the meanwhile we also have tools emerging which start to beat org-mode&emacs even in their own strong points. One crucial apsect here is that markdown never had the strong focus on task-managment that org-mode had. This changed in the last years.
Hmmm. You are not really bringing any examples and we have moved the goalpost to all markdown dialects in existence and call it "markdown family" now. I think you will have to be more specific there to convince me.
Looks interesting, but I'm a bit sceptical - feel a bit likes it's features before use-cases - ie: many features, that may or may not be useful, but mmaybe not a few good use-cases?
I've simply changed my notes.txt to notes.md - and that handles most of what I need for ideas, To-do lists and such.
Yes, I agree. The command vocabulary needs to come first for it to make sense and be a sensible application which is different from just a text editor.
I have recently developed my own terminal-based UI for day journalling and todo/task tracking [1] in markdown files because I was sick of rearranging todos in other tools and just needed something which provides a standard template for each day (journal, high priority, todos of the day).
The main advantage is that you can "migrate" all unfinished todos to a new page/day and thus get a clean start each day. This idea comes from bullet journalling.
Long term I would like to add generated views (for instance: last year this time one of your highlights was...) and support recurring tasks to be inserted into the daily log.
