The last issue listed is the killer. If you rename or move a file, you need to update all the links. It's not terribly hard to solve with a quick script as he showed, but that is the part which has always felt very hacky to me when I've done this.
Reconstructing Obsidian Features in Vim and Bash
21–30 of 47 posts
Re: Reconstructing Obsidian Features in Vim and Bash
#22The obsidian vim bindings can also be modified with the vimrc plugin. It lets you hook into obsidian’s native features with normal mode maps e.g. for pane splitting and navigation.
Re: Reconstructing Obsidian Features in Vim and Bash
#23The last issue listed is the killer. If you rename or move a file, you need to update all the links. It's not terribly hard to solve with a quick script as he showed, but that is the part which has always felt very hacky to me when I've done this.
I’m thinking an inotify hook could be created to run the script.
Re: Reconstructing Obsidian Features in Vim and Bash
#24Since the page doesn't seem to load: https://archive.is/oRhu0
Re: Reconstructing Obsidian Features in Vim and Bash
#25Again, I'll put up another vote for http://zim-wiki.org which I've been using for now almost decades. I've begun to experiment more with Obsidian as well, a killer thing for me would be for e.g. Zim to support standard Markdown and just make the two fully cross-compatible...
Does zim support markdown? (no there is a fork but not merged yet) and no mobile app...
Re: Reconstructing Obsidian Features in Vim and Bash
#26The one killer feature that I wish Obsidian had is CRDT support, Apple Notes-style. I realize it's a huge engineering lift and they are (appropriately) focused on making the UX perfect, but it would be really great for collaboration. I can't really recommend it to my team without better collaboration.
I still use it every day though.
Re: Reconstructing Obsidian Features in Vim and Bash
#27Earlier quoted context omitted.
> Obsidians live rendering has shown me that plaintext sucks I don't understand. I currently use obsidian and the live rendering is great, not exactly sure what you mean.
That live rendering exists is in itself a sign that we want more than plaintext. On its own, plaintext is simple, which is why we like it. And it shoves everything directly in your face, which is also why we like it. But many of us also want more than just plaintext, so we invented markup, to add some levels of richness. But this makes it complicated again, and the more we want, the harder it gets, the less support f…
> That live rendering exists is in itself a sign that we want more than plaintext.
If people would just finally realize that this especially applies to code!
It's imho a complete joke that we're still using plain text for source code, and convert it back and forth between it's actual structure (an AST) and some limited and quirky textual representation.
The text representation of code should be just that: A visual representation. Not "the real thing".
Having proper rich data structures for code instead of plain text would make so much more possible given some proper editors…
Re: Reconstructing Obsidian Features in Vim and Bash
#28Earlier quoted context omitted.
That live rendering exists is in itself a sign that we want more than plaintext. On its own, plaintext is simple, which is why we like it. And it shoves everything directly in your face, which is also why we like it. But many of us also want more than just plaintext, so we invented markup, to add some levels of richness. But this makes it complicated again, and the more we want, the harder it gets, the less support f…
Everyone is re-inventing "show codes" from Wordperfect 5 and other similar platforms because no one who is inventing these things has ever used Wordperfect 5. That said, re-solving this problem is turning up some nice new U/X patterns that (as far as I know) weren't around in the older platforms ("show codes on cursor", "local modal editing for format", etc.)
What editors have those two new ux's? I'd like to try them out ("show codes on cursor", "local modal editing for format", etc.)
Re: Reconstructing Obsidian Features in Vim and Bash
#29For me the main benefit of Obsidian is live-rendering editor + other handy features. Not having to look at two panes side-by-side (or having to parse the markdown format in my head) is such a QOL improvement. Neovim might never be able to provide complete live-rendering. I don't blame it though, I wouldn't want terminals to become a rendering engine. Edit: Grammar
Funny enough, Obsidians live rendering has shown me that plaintext sucks, and that I want richtext and data structures for my stuff. Just that there is no good tool for this. Notion and its clones are the best in that regard, but they suck in their own regard, mainly because they are online-only. And considering how many tried to replicate Notion in obsidian-extensions (and failed), I'm not the only one I guess. Ther…
I've become a big fan of LogSeq for these reasons. In LogSeq, you have pages and trees of data (aka blocks[1]. All can be cross-referenced or embeded between each context. It's quite nice.
1: https://docs.logseq.com/#/page/the%20basics%20of%20block%20r...
Re: Reconstructing Obsidian Features in Vim and Bash
#30What, we're talking about wikis and vim, and not mentioning vimwiki?
https://github.com/vimwiki/vimwiki
I tried a whole bunch of personal wikis over the years (I see Zim has been mentioned, that's one of the ones I remember trying) and this is the only one that stuck.
The github page shows some basic markdown, but it also handles nested checklists (parent nodes can be partially checked off) and understands tables (automatically fixing spacing so columns stay aligned). It can also render to HTML (though I don't use that feature) and has a whole bunch of other stuff too.