I started using wiki.vim a few weeks ago, and it's already becoming a mess. Using a good tool is not foolproof if you don't know how to use it correctly. Merely studying the wiki.vim help pages and learning the commands isn't enough. I would like to gather the experience of veteran wiki.vim users and try to extract the best practices that new users could learn and apply right off the bat. I'm not sure what would be a good way to attract veteran users to answer this thread.

I believe that there exists a core of principles that all experienced users can agree upon, no matter how different their methodology is. For example, nobody will recommend copy-pasting wikipedia articles' entire content to wiki notes, but writing a summary of it using our own words is probably a great thing to do.

This is different from sharing tips on how to vim-golf our way through wiki.vim, that could go in the wiki.

What structure to follow ?

From my understanding of wiki.vim, it appears that it follows 2 patterns:

Filename-based (write good names and you can quickly find your notes with :WikiFzfPages.
- Shouldn't we use a convention to write clean names? Right now, visual selection will create a filename with all the selection characters, including spaces and special chars.
  - How can we find related existing notes when creating a new one ? To make sure we don't recreate a note that could have been merged with another one. And also to make wiki-graph-find-backlinks more useful. A linting warning suggesting to link to similar notes sounds awesome.
  - Similarly, when creating a link to another file, autocompletion of existing files would be lovely (eg after typing wiki:).
  - It'd be great to see an overview of the note content while in the WikiPages and WikiTags windows (the fzf.vim plugin offers that for :GFiles, (example)
tags (several tags can be set on one filename)
- Wouldn't it be great to search for several tags at once ? If I have a note with tags :mission: :mogs: :triathlon:, searching mission mogs in WikiTags won't return anything.
- How do we avoid typos or synonyms when writing tags? They'll make finding the right note more and more difficult over time.
- It would be great to get a completion window opening when typing : with all existing tags (results from wiki-tag-list)
- The WikiTags window is quite verbose, showing tags and files multiple times. Wondering how to make this more readable. Ideally, I'd like to see the result of wiki-tag-list together with the WikiTags result.
- Could the wiki-tag-list's readability be improved with alphabetical sorting ? Not the case currently (example)
- What is the reason behind parsing only the top 15 lines for tags? Is that related to some best practice? If we can eventually preview the top of the file content while searching notes, the top of the file might be more valuable for knowledge and key insights, and placing tags at the bottom of the file could be a better option.

That said, I wonder why is there even an index.wiki file. What do you use it for? Wouldn't it be best used as an automatically-formatted index list of top pages (pages that have no links to them)? If adding such feature, it could open the door to another structure methodology: Folder/Category/Project/Mission -oriented. Create folders in the wiki, each with their index.wiki file indexing their folder's files, and the top wiki index.wiki file could index the folders. Yet another way to group information in addition to tags, with the advantage of having an autogenerated ToC of the folder.

How to write good notes ?

I like the progressive summarization methodology. Leave details at the bottom of the file, but only keep the insightful knowledge at the top of the file. But right now, I have a lot of FAQ-like files with lots of Questions and Answers. I suppose I should write a note of each Q/A, and link them with the same tag (currently the FAQ note's filename) ?

How to handle archives / immature / stale cards?

Let's say I finished a project. Then I want to search for knowledge that has hundred of matches. I wouldn't want my finished project's matches to come of top, since that's quite specific information that I probably won't need. How can I have "archived" notes showing up at the bottom of my search results to reduce scrolling?

Let's say I find a way to connect my phone to wiki.vim and use a speech-to-text software to jot down notes while on a walk. This is immature data that I'd need to review and curate once I'm home. Another example would be time-bound knowledge, let's say the name of my children's school teachers every year. I'd want to be prompt for a review of staled notes at the beginning of the new school year, so that I can update the note with new relevant knowledge (this feature connected to Anki notes would be a life-saver).

Is there a way to handle the current state of a note? Or is that a feature you'd consider adding to wiki.vim?

How to visualize / analyse data ?

When writing regular entries like weight, sport performances, sicknesses/injuries, etc, what would be a good way to visualize the aggregated data? If I want to share a subset of my wiki with external people, what would be a good way to do so?

It feels like a dashboard could be a valuable addition to wiki.vim's ecosystem. A terminal based dashboard or vim plugin would be one idea, but a web application with API that can be synced from wiki.vim would be even more powerful. Are people already using some solution?

How to connect with other tools?

wiki.vim looks like a great base to start off building a PKB (Personal Knowledge Base). This means connecting all the tools that I'm using together, to have a single entrypoint to search for knowledge.

I'd like to keep using jrnl instead of wiki-journal. Could wiki-journal be exported to its own vim plugin, and wiki.vim updated to allow configuration with journaling tools using a text-based format?

Same thing with using TaskWarrior instead of wiki.vim checklists for task management.

I'd like to connect wiki.vim with my browser's bookmarks, is that possible?

Another important component for me would be a mind-mapping tool. Currently using the slow and proprietary Milanote tool, and could never figure out a good way to do that with vim or terminal-based software. But since we can already navigate easily from vim to a pdf reading, an image viewer or the browser, adding a mind-map viewer doesn't sound impossible.

I also wonder how people are using their knowledge base outside their computer. If I'm outside with my phone, I'd love to be able to query my knowledge base for info. It'd also be great to jot down thoughts, that I could later on review and clean from vim.

Write a configurable linting tool?

A linting tool would go a long way towards improving consistency. Like any linting tool, each rule can be enabled/disabled for each user to customize his own experience.

Verify date stamping of notes (is that even needed? shouldn't wiki.vim get this info from the file itself and make it visible in the buffer?)
Verifying tags (are they in the right position to be recognized by wiki.vim?). Suggest tags.
Are they linked to a parent note ? Is the link broken or not? Suggest links
Is the line content very similar to another note's line ?
Number of lines in the note
Number of sub-headers in the note

Following the discussion, I can create dedicated issues for feature requests. Didn't want to spam the repo with a large number of issues at once.

I started using wiki.vim a few weeks ago, and it's already becoming a mess.

Ah, yes. The tool is not itself the solution, it is only there to help. So, you are raising a very important issue with regards to how to actually get a value from writing a personal wiki!

I believe that there exists a core of principles that all experienced users can agree upon, no matter how different their methodology is. For example, nobody will recommend copy-pasting wikipedia articles' entire content to wiki notes, but writing a summary of it using our own words is probably a great thing to do.

Yes, I agree.

I will pitch in my own workflow and use pattern, which may or may not be helpful to others. I don't know how many "veteran" users will end up sharing their thoughts, but I do think there is a vast amount of relevant info on the web in forms of blog posts and similar. That is, the problems you are mentioning do not really concern wiki.vim, but instead the more general topic of how to properly make notes and a knowledge base in such a way that it becomes useful to someone.

But first, I'll reply inline to some of your following comments/questions/thoughts. Note, you are raising a lot of ideas and possible feature requests, and I will not be able to follow up on them from this single thread. In the following, I will suggest whenever I feel that you could open a specific feature request.

Shouldn't we use a convention to write clean names? Right now, visual selection will create a filename with all the selection characters, including spaces and special chars.

In my opinion, it is not a problem that files contain special characters, including whitespace. And with time, I've grown less interested in conventions other than that whatever I think is a sensible name for something should be the name of the page. If I later realize that I think something should be renamed, I either rename it or I add a new page with a link to the old one.

How can we find related existing notes when creating a new one ? To make sure we don't recreate a note that could have been merged with another one. And also to make wiki-graph-find-backlinks more useful. A linting warning suggesting to link to similar notes sounds awesome.

Yes, perhaps, but how would it work? One idea could be to search the wiki for all pages that contain the current new page title. I do agree that there may be some possibilities here, and I would not mind a new issue specifically about this.

Similarly, when creating a link to another file, autocompletion of existing files would be lovely (eg after typing wiki:).

This should already work... when I create link I often do [[PartOfName<c-x><c-o> to start omnicompletion, and it will complete the relevant page names. You can also complete anchors, i.e. [[wiki.vim#anchor<c-x><c-o>.

It'd be great to see an overview of the note content while in the WikiPages and WikiTags windows (the fzf.vim plugin offers that for :GFiles, (example)

I don't like the preview function myself, so this is clearly opinionated. However, it could be possible to make options for this. Feel free to open a specific feature request.

Wouldn't it be great to search for several tags at once ? If I have a note with tags :mission: :mogs: :triathlon:, searching mission mogs in WikiTags won't return anything.

Yes, that sounds useful. Again, feel free to open a new feature request!

How do we avoid typos or synonyms when writing tags? They'll make finding the right note more and more difficult over time.

Good question, I don't have an answer. I personally don't use tags.

It would be great to get a completion window opening when typing : with all existing tags (results from wiki-tag-list)

Again, feel free to open a feature request.

The WikiTags window is quite verbose, showing tags and files multiple times. Wondering how to make this more readable. Ideally, I'd like to see the result of wiki-tag-list together with the WikiTags result.

As mentioned, I don't really use tags, so I don't have an opinion on this. Everything is possible, so feel free to write a feature request. If so, it will be useful with some examples.

Could the wiki-tag-list's readability be improved with alphabetical sorting ? Not the case currently (example)

Feel free to open a feature request.

What is the reason behind parsing only the top 15 lines for tags? Is that related to some best practice? If we can eventually preview the top of the file content while searching notes, the top of the file might be more valuable for knowledge and key insights, and placing tags at the bottom of the file could be a better option.

The reason is that I believe parsing the entire files is going to be way too slow. But I don't use tags, and I don't really know. There is no best practice involved, only relatively arbitrary restrictions.

That said, I wonder why is there even an index.wiki file. What do you use it for?

I use my index.wiki as a "scratch buffer". I'll comment more on it later.

Wouldn't it be best used as an automatically-formatted index list of top pages (pages that have no links to them)?

What is the point of such an automatically formatted index list? For which purpose?

If adding such feature, it could open the door to another structure methodology: Folder/Category/Project/Mission -oriented. Create folders in the wiki, each with their index.wiki file indexing their folder's files, and the top wiki index.wiki file could index the folders. Yet another way to group information in addition to tags, with the advantage of having an autogenerated ToC of the folder.

This type of organization might work for some people. However, I believe it is difficult to do, because it implies that you always know how information should be categorized. I've realized I generally don't know that, and so I've found that it is better to have a flat structure. Again, I'll write more about it later.

How to write good notes?

This is a million dollar question!

Let's say I finished a project. Then I want to search for knowledge that has hundred of matches. I wouldn't want my finished project's matches to come of top, since that's quite specific information that I probably won't need. How can I have "archived" notes showing up at the bottom of my search results to reduce scrolling?

I don't know, but I've never really had this problem.

Let's say I find a way to connect my phone to wiki.vim and use a speech-to-text software to jot down notes while on a walk. This is immature data that I'd need to review and curate once I'm home.

Interesting idea! This is typically a case where I would start a scratch note based on some type of filename practise that I later remember to parse. It could also just be appended to the index.wiki.

Another example would be time-bound knowledge, let's say the name of my children's school teachers every year. I'd want to be prompt for a review of staled notes at the beginning of the new school year, so that I can update the note with new relevant knowledge (this feature connected to Anki notes would be a life-saver).

Perhaps put your wiki in Git? I do that, and I don't really worry about deleting and changing the contents.

Is there a way to handle the current state of a note? Or is that a feature you'd consider adding to wiki.vim?

It feels wrong to me to think that a note/page has a state other than being some text that at some time is relevant. I often add a timestamp when I write notes to add some context. That might work?

When writing regular entries like weight, sport performances, sicknesses/injuries, etc, what would be a good way to visualize the aggregated data?

Wow, you really are thinking this along all edges! Ok, so: I don't think this should be something inherent in the wiki plugin itself. I think emacs org-mode might have some relevant features in this direction. I don't have the capacity to make this type of system. Instead, I would make pages with information in some form that is easily parseable and write a simple python script (or LaTeX with pgfplots) for doing the visualization. Perhaps I would write a wiki page with information about something and links to a csv-file in which I add the data.

If I want to share a subset of my wiki with external people, what would be a good way to do so?

Good question. Right now, I don't really have a good way except exporting to PDF and sending it. I can see the usefulness of combining a personal wiki with a way to share individual pages "on demand".

I currently have my wiki on dropbox, so I could share via dropbox, but I plan to move onto syncthing later on. That would make this type of sharing less easy, I think.

It feels like a dashboard could be a valuable addition to wiki.vim's ecosystem. A terminal based dashboard or vim plugin would be one idea, but a web application with API that can be synced from wiki.vim would be even more powerful.

Yes, perhaps. I think we need a stronger community of developers for things like this. I would not mind collaborating.

Are people already using some solution?

I don't know.

I'd like to keep using jrnl instead of wiki-journal. Could wiki-journal be exported to its own vim plugin, and wiki.vim updated to allow configuration with journaling tools using a text-based format?

Perhaps. Separate feature request? I don't see exactly how this should work. I mean, can't you just not use the wiki journal? What does it mean for wiki.vim to allow configuration with other tools/formats?

Same thing with using TaskWarrior instead of wiki.vim checklists for task management.

I think this could/should work already. Not sure.

I'd like to connect wiki.vim with my browser's bookmarks, is that possible?

Not sure, never tried it.

Another important component for me would be a mind-mapping tool. Currently using the slow and proprietary Milanote tool, and could never figure out a good way to do that with vim or terminal-based software. But since we can already navigate easily from vim to a pdf reading, an image viewer or the browser, adding a mind-map viewer doesn't sound impossible.

Again, interesting idea. Perhaps a new feature request?

I also wonder how people are using their knowledge base outside their computer. If I'm outside with my phone, I'd love to be able to query my knowledge base for info. It'd also be great to jot down thoughts, that I could later on review and clean from vim.

Right now I use Vim on a phone (Vimdroid) with Dropbox + my wiki content. It does not work well, but it works.

Write a configurable linting tool?

Perhaps, but I personally would not need this.

Ok, so, you raise a LOT of different ideas and issues. I don't mind that, but it makes it a little bit difficult to respond, because there are like 10-20 different threas. I've asked you to open specific feature requests for some of these, and you should of course feel free to do so. Note, I have other projects (e.g. vimtex) and my time is not so abundant of late. So I would appreciate help from more people (e.g. you) to develop the solutions.

I'll finish with the promised overview of my own workflow. I've spent perhaps 10 years developing it, and the last couple of years I think it has shaped into something that works very well for me. I'll write this as a second comment.

I currently have 1361 pages in my personal wiki with a total of 61745 lines. This excludes my journal, which has 2782 pages with 130837 lines.

How did I get there, and how do I use this in my day-to-day business? Here are some thoughts, partly unstructured and not very well written. But I hope it can be useful.

Well, I started off with taking some notes in a simple notes.txt file. This was back in 2007, and it quickly became messy. After some time, I started using Vimwiki, and the idea of linking notes was a revolution to me. I also started making daily journal entries, and things started to grow from there.

In the early years, I often tried to apply structure to my notes. E.g., I would name my pages stuff like "Linux_Ubuntu.wiki" and "Linux_Arch.wiki", or "Linux_Tools.wiki", or similar. But with time, I started to realize that this was working against me. E.g., if I am writing a note and want a link to Ubuntu, it is much easier if I simply have a page that is named Ubuntu. Today, I generally try to keep the names as close to the one I would write in text as possible. This makes it easy to convert text to a link, and it makes it easy to "remember" the page name. I use :WikiFzfPages to search for a page, and it is usually a matter of a couple of seconds from I think of something until I can be in the relevant note.

However, sometimes I write stuff that I don't know what I should call/how to categorize. This is where I use my index.wiki. I have a global keyboard shortcut on all my computers to open Vim with the index (<alt-n>). Here I either add this loose content, or I make a link to some new scratch buffer with the new content. With time, I work through this index (often slowly) and move content into more dedicated pages. For this workflow to work well, it is crucial that my index.wiki is extremely accessible. That is, it takes less than a second from I have a thought until I can add it to my index.wiki for later processing. This is what makes it important.

Note, I also use my index.wiki as a simple list of stuff that I want to read or look into, and I use it as a place where I add questions I want to add to Anki. I try to keep it from growing too large, which requires me to spend some time every week to process it.

I do add a lot of data to my wiki, but I've also realized that I should not add all data there. For instance, I've come to use Zotero for managing my literature database. This is why there is now some simple support for Zotero in wiki.vim.

For some topics, I may write a wiki page about stuff where I have links to data files in which I can append new data and to scripts I can run to visualize. the data. Thus, I don't keep everything in the wiki, instead, I may write the "metadata" and general overview in the wiki, and then keep the real data and relevant tools as a "third party".

As I said, I don't use tags. Instead, I rely heavily on searching. I use rg and fd, as well as :WikiFzfPages. From the Vim perspective, I use the ctrlsf.vim plugin (which uses rg or fd as a backend). This makes it easy to search the wiki. And if my search has too many hits, I can either narrow it down by changing the search pattern, or I can search within the result buffer of ctrlsf. This has generally not failed me in finding information I'm looking for. I generally don't spend a lot of time searching for things. If I know I've written about something, I find it with :WikiFzfPages and/or :CtrlSF, and it typically goes very fast (both of the commands are properly mapped).

So, how do we write good notes? I don't know. I just make sure to write down what I feel like at the moment, then clean it up and rince/repeat as something is developing. I add links to relevant external and internal pages/resources. I often add examples (e.g. for tools I discover or libraries I learn about). I've stopped caring so much about structure. However, in some cases I end up writing very large pages, and I realize I need to e.g. move some old content to archives. For now, I've often added a duplicate page where I append archive to the page name, e.g. Linux Tools Archive.wiki (bad example, because it does not exist). But I've found this does work well for me.

I don't worry about having many pages. I don't worry about almost empty pages. I don't worry about keeping my pages in a hierarchy. I've found it can be useful to split information into separate pages, as it makes it easier to link things. I sometimes find the graph features useful, but I don't use them much. Regarding categorisation: I've found that if I spend a lot of energy on categorising my notes, I also spend a lot of time recategorising them. It seems that categories change, especially when I am learning new stuff. Thus, I've realised that it is better to just "keep things simple".

What do I find lacking in my own workflow? There are a couple of minor (IMHO) things:

I don't have a good way of sharing my knowledge, except copy-pasting things in chats or emails. Thus, a "mirror" of sorts of my wiki on a web server where I could easily share separate pages could be very useful. Still, it has not been worth the effort to develop this.
I don't have a good workflow for working with my notes on my phone. It is not very important, because I generally don't spend much time with my phone writing notes and stuff, but sometimes I do think it would be useful with a better integration of my wiki with my phone.

Finally, I stress that these are my personal experiences/opinions, and I very much acknowledge that what works for me probably does not work for everyone else.

I think that the most important thing is to not overthink things and just keep writing stuff down. I invented the most complicated systems to manage my 3 notes. Now I just throw files in a flat structure to a single directory. I even dropped tagging them as tags never worked for me (typical problems: typos & naming things). The only reliable way to search through my notes is grep (rg to be specific). The only categories which I accept are personal notes and work-related notes, and this is only because my work notes might contain classified information which I want to keep in a separate git repo on my company servers.

Recently I also decided to write a book so I added a new "notebook" for these, but it's also quite straightforward to decide if a note is related to that book. :)

I agree that having a scratchpad notebook ready in less than a second after pressing a key is one of the most important things to configure. Almost all of my notes land in it. I move some of them to separate notes later, others are either removed or left. I have no problem with that.

I prefer small, Zettelkasten-style notes to the big ones. I created a function which more-less ensures their unique names by adding part of random UUID to their names. This way I can have meaningful and unique file names and don't have to worry too much when learning new things. For example, if I learned rust, I could write Note rust twice and it'd create 2 different notes. I can also write Note work/blah and create this note inn a different "notebook".

func! s:shortuuid()
    let l:uuid = ""
    if executable('uuidgen')
        let l:uuid=system('uuidgen')[:-2]
    else
python << ENDPY
import vim
from uuid import uuid4
vim.command("let l:uuid = '%s'"% str(uuid4()))
ENDPY
    endif

    let l:spl = split(l:uuid, '-')
    return tolower(l:spl[0])
endfunction

func! custom#99notes#edit(name)
    let l:uuid = s:shortuuid()

    " assign note to a default notebook
    let l:default_notebook = "0/"
    let l:name = a:name =~ '.\+\/.\+' ? a:name : l:default_notebook . a:name
    let l:fname = expand("~/docs/content/") . l:name . "-" . l:uuid . ".adoc"
    exec "e " . l:fname
    exec "keepalt r " . expand("~/docs/archetypes/default.adoc")
    exec "normal ggdd"
endfunc

command! -nargs=1 Note call custom#99notes#edit(<q-args>)

Overall, I feel that lowering the friction of entering notes is more important than anything else. What's good with even the best process and notes structure if there are no notes?

I don't have a good workflow for working with my notes on my phone

I abandoned the idea of writing notes on the phone. Waste of time if you ask me. For occasional readings I use Termux and Vim, which is configured exactly the same way as on PC.

I thought about recording my thoughts to myself e.g. on Signal and processing them later, but I'm not comfortable to speak to the phone.

I almost always have a small A6 notebook with myself which holds a TODO list though (yes, old and boring paper works best for me). In rare times when I don't have it I use Orgzly, which synchronizes with my computer via Syncthing. I don't use Emacs though and just read org files in Vim with a syntax plugin for org files. It's very basic and I like it. I tried org-mode in the past but it overwhelmed me.

@mgoral Thank you for your insightful post. I find we have reached some similar conclusions at the higher level. I do have some quite large notes, and I've also realized that I should not be afraid of putting things in small, more isolated notes. E.g., when writing about Python, it is much better to write about a specific package in a separate note linked to the main Python note.

I'm not sure if I fully understand your use of UUIDs. Do you mean you can have two separate notes with the same "title"?

I abandoned the idea of writing notes on the phone. Waste of time if you ask me.

I mostly agree for the same reasons you list. The important thing is to be able to take note of things when I'm not on a computer. Pen and paper is perfect for that, of course.

I have to admit I quite believe org-mode would really be a perfect solution for me if I just had the time to invest to learn it properly. However, for now, I really don't. I'm very invested in Vim and it works very well, so I don't think the benefits of emacs and org-mode are large enough for it to really be worth spending that time. I think the important ideas are more about the workflows and concepts, not really that much about the tools (even though the tools clearly add some value).

I'm not sure if I fully understand your use of UUIDs. Do you mean you can have two separate notes with the same "title"?

I borowed the idea from Zettelkasten methodology of notetaking and modified it to my personal preferences :). With Zettelkasten file names usually don't matter because their content constantly changes as they are being reworked. Zettelkasten people often don't give any meaningful names to their notes and use timestamps instead.

It doesn't suit me because sometimes I navigate notes by their names. So I am naming them with 2 parts: their rough name/category, and random one, which more-less ensures that any new note is unique.

For example, suppose that I'm learning a new book about Rust. Each time I learn something new, I just have to type :Note rust<cr> and each time my function will create unique note (e.g. rust-abcdefg.adoc and rust-12ab346f.adoc). I like it because:

I don't spend much time on thinking how to name the file. Is it about Python? :Note python. Is it a list of colors which we'll use to paint our house? :Note home. Is it anything remotely related to my server? :Note server.
If note contents change 2 days later, I don't have to rename it, because usually their name still matches: notes about Python usually don't miraculously change their topic to Chinese Cultural Revolution (:Note china).
"shortuuid" it is short enough to not clutter filenames in a file browser. Because it usually contains letters and numbers it looks better in my opinion. But in fact I barely notice it now.
"shortuuid" is unique enough to prevent most file conflicts, even between several computers. (I make notes on 2 laptops and was making them on the phone in the past, when I was trying things). Conflicts between files were especially painful when I used syncthing for synchronization. Today I use git-sync, so this isn't that big deal, but still.
sometimes I don't know what to search, so neither grep, nor tags (which I don't use anyway) will help me. This is when I have to just open the first file on the topic and iterate from it. To ease jumping between files, there's one of Tim Pope's plugins which has a handy mapping for opening the next file in the filesystem, but today I use vim-dirvish for navigation inside Vim, which makes it easy as well.

Thanks @mgoral; I'm curious, how does this work if you want to find some info? E.g., you know you've written something about Rust, but you've made 50 different notes. How do you find the one you're looking for?

I'm personally not this "minimal", I typically combine things in one note. E.g. one page on Python with sublinks to specific package related topics. One page for Rust. And so on. If I want to find something I know I've written about Rust, it's immediately available, and if it is in a sub page, I'll find the link immediately. If I know it's related to Rust, I will also probably have a link from Rust to the correct page.

I'm curious, how does this work if you want to find some info?

A lot of grep. :D Ripgrep is great and near-instant in returning results.

I also have some "index" pages for some topics, but I don't use them very often. Sometimes I navigate links, sometimes I iterate and quickly scan all notes on the subject. Sometimes I create links to specific pages in my main index file, which is in fact a journal (1 section per day) and has ~1k lines, but I can navigate it quickly and easily. I use folding (:map <tab> za) to hide uninteresting sections. Sometimes I completely forget that I have notes about something and search that thing on the web.

Journal is the most useful part of my whole "notebook". It's easy to find notes from 3-4 days ago and they enable me to quickly get back to work.

And as to the other notes... I usually don't need to find them. They're there, just in case, bitrotting. My brain does miracles and simple fact of writing something down makes it remember that thing. And if there are some notes with things which I use daily, then I usually jump directly to them somehow.

I think that notes are not that important as making things done so I don't stress myself too much about them. If they help - that's great, if they don't - too bad. I keep them mostly for the peace of mind that my thoughts are safely stored and accessible somehow.

I planned to create a script which would open one random note daily, which I could read several times and improve somehow, but I never wrote it. Maybe I'll return to this idea one day. :)

I have also had issues with my wiki growing too large to navigate, and requiring too much maintenance work to "fix it"... In general, I believe the key should be to make wiki maintenance as simple as possible so that I actually do it.

Recently, I've been trying out the following system to lower the maintenance problems:

No tags. They don't add much value over just full-text search, but I waste lots of time thinking about what tags to use globally and trying to ensure that I actually tag my notes properly.
No names. Thinking about good filenames is another thing that increases maintenance work when I start getting many notes on the same topic; this way you don't have to think about renaming notes. Instead, I use auto-inserted unique ID (here: HEX UNIX timestamp) for the filename, and try to focus on the note contents and links.
No long notes. I'm now trying to follow the Zettelkasten idea of "one thought per note", where you rather create a link to a new note when you make a digression from the main topic of a note.
No Git. I used to think that having my notes in Git was the right thing to do; but I rarely actually used version diffs, merging, etc., find that cloud sync + daily backup is sufficient safety for my needs, so it was simpler to just avoid Git for notes.
"Boy scout rule": Try to leave each note better than you found it :).

With this system, I don't actually use that many features of wiki.vim, but the ones I use are very useful. My config is simple:

let g:wiki_filetypes = ['md']
let g:wiki_link_target_type = 'md'
let g:wiki_map_link_create = 'ZettelLink'

function ZettelLink(text) abort
  return printf("0x%08x.md", str2nr(strftime('%s')))
endfunction

I use MarkDown links to keep it more readable in other apps (e.g. on mobile), and use the wiki_map_link_create to insert random identifiers. When writing, I can then highlight text in visual mode like this is a *test* (asterisk for selection) and press enter to convert to this is a [test](0x5fa40535.md), referring to a new note. (Not the best example, since the link should ideally have a longer description than "test" to explain how it is relevant to this context ;).)This note then doesn't have a "name" that I'm supposed to manage; it has a permanent location given by the HEX timestamp, and is otherwise just defined by its contents and links. After writing it, backspace to jump back and continue to write from there.

To find the note again later, I would then either recursively follow links from an "entry node" in my index file, or search for it via CtrlSF. For the index file, the idea is described e.g. in this recent article; it is not a complete index, but contains a list of the most important nodes of your wiki where you can start browsing links from.

I'm still new to Zettelkasten, so it remains to see how well this scales over time. But based on the problems I've experienced with other systems, I'm at least optimistic :). Referring to the original post: I do not use filenames or tags for organization; I use recursive linking from index.md for "navigating the graph" or CtrlSF full-text search for "jumping to a node".

@mgoral @jabirali It seems you are thinking in a similar fashion. I'm wondering: how does the linking between note works when the filenames are "random"? Do you need to manually link to the "random" filename?

For me, the linking concept is crucial. If I create links from different pages at different times to some word/topic/person/something, then I want to be sure that the links point to the same page. That's sort of the point, at least for me. I do agree on the concept of avoiding huge pages, but I've found it is often easy to reduce a page size by "refactoring" it into multiple pages.

Except for this particular part, it seems we have landed on a quite similar workflow/philosophy. I find that in itself quite interesting :)

I usually split-open a note to which I'm going to link. I'd probably do that even without randomness because I simply don't trust myself that much. :)

Since I discovered omni function from wiki.vim few days ago, I started using it to complete links. Then I follow these links to check if everything works, and then to jump back.

Yesterday, inspired by @jabirali comment I added custom g:wiki_map_link_create which now creates these short uuids of mine. It's a relief! Before I used a script to regularly batch-rename notes which didn't have that "random" part.

Regarding preview... When showing file lists, fzf.vim shows a split floating window which displays that list on the left and preview on the right. Feature like this would work great with omni function provided by wiki.vim, but I'm not sure if this should be a feature of wiki.vim or some other completion plugin. And it might be hard to find a note if you have 1000-2000 completely random names (I don't have that many).

Except for this particular part, it seems we have landed on a quite similar workflow/philosophy. I find that in itself quite interesting :)

As a part of my daily procrastination, I've been searching for a long time for a tool which would fit my needs, even outside of Vim. I tried org-mode, vimwiki, some other wiki plugin, Zettlr, Joplin, Zim, 2 or 3 outlining plugins. wiki.vim feels like the closest to the ideal, so it's no surprise that we all share with author some views on note taking. :)

@mgoral @jabirali It seems you are thinking in a similar fashion. I'm wondering: how does the linking between note works when the filenames are "random"? Do you need to manually link to the "random" filename?

I still haven't completely converged on a solution for linking. My newest experiment is:

nnoremap <silent> <leader>wi <c-w>p:let @" = expand("%")<cr><c-w>pi[]()<esc>Pl%hi

I would edit notes in a two-pane (vsplit) or three-pane (vsplit then split) layout, where I use the main pane for writing, and CtrlSF or link navigation to find references in the other panes. When I type \wi (assuming default leader key, short for "wiki insert link") in the main note, this automatically inserts [](0x5fa16bd5.md) where 0x5fa16bd5.md is the name of "the other" note, and puts me in insert mode within [] to name the link. I like that it remains flexible with respect to how you find the object you want to link to (CtrlSF, browsing links, etc.).

I think a more elegant/vimmish solution, in that it doesn't require using windows (e.g. buffers work just as fine), would be to set a global mark (e.g. mA) on the file you want to link to, and take this as an argument to a function like this (so <leader>wiA links to the file where A is set). But I don't know enough Vimscript to do that right 😄

[Edit: Removed some irrelevant discussion]

Reasons for rejecting the "Finding a note by its content" feature are explained in #102.

While I'm at it, thank you all for sharing your experience. It was really worth it opening this thread, I'm learning a lot :heart:

I agree this is an interesting discussion, which makes it valuable in itself. I'll leave it open for some more time.

Interesting reading other people's journeys with some issues I've had myself. Nowadays I've simplified my workflow to the point of barely needing a plugin, and the cornerstone of my personal workflow is searchability.

I don't have a system for naming, categorizing, tags, etc. I just try to title notes in a way that I think I'll remember later. If I'm looking for a note I'm sure I made but I can't find it by the title, instead of fzfing filenames I'll fzf the entire contents of my vimwiki. If this happens repeatedly I just rename the note to what my instinct told me to search for.

To me any manual organizing and categorizing is friction. It's more a vault for data than I would like to have available than it is a wiki, cause I feel a neatly organized wiki is mainly a thing for other people to navigate, where the structure has to be clear and visible. But for personal stuff, the structure is basically in my own head, if I think I need to access something I look for it with a simple keybind.

I don't have a rule for note length, because again it comes down to how I want to search and find things. When I'm making a note about a subject and it becomes fragmented into multiple sub titles that might be a time to make separate shorter notes instead. On the other hand, I have files that are thousands of lines long because they're just a log of the same thing over and over with different dates: I have no reason to search for individual dates, I rarely even have a reason to search old instances of the log, so I keep it all in one file. If I want to find my workout session of 2019-09-12 then it's gonna be in the file workout.md (or if it gets too long, I'll archive it as 2019-workout.md and keep workout.md as the current version).

That said the only plugin feature I miss from vimwiki is [[markdown links]]. I found this plugin with the hopes of implementing that without all the overhead of vimwiki.

... the cornerstone of my personal workflow is searchability.

Same here! I use FZF, but also ripgrep and CtrlSF.

I don't have a system for naming, categorizing, tags, etc. I just try to title notes in a way that I think I'll remember later. If I'm looking for a note I'm sure I made but I can't find it by the title, instead of fzfing filenames I'll fzf the entire contents of my vimwiki. If this happens repeatedly I just rename the note to what my instinct told me to search for.

This is very similar to how my own workflow is today.

To me any manual organizing and categorizing is friction. It's more a vault for data than I would like to have available than it is a wiki, cause I feel a neatly organized wiki is mainly a thing for other people to navigate, where the structure has to be clear and visible. But for personal stuff, the structure is basically in my own head, if I think I need to access something I look for it with a simple keybind.

This diverges from my workflow. Or; I don't spend very much time organizing and categorizing. But I do use links a lot. The point of it is to "remind" me about related content that I may forget. E.g., let's say I need a tool for working with CSV files - I know I have a page about data analysis, so I'll open it. From there, I'll find links to other pages on specific topics like VisiData, Miller, and so on. But sometimes I may first remember e.g. Miller - having the links from Miller back to my topic page or to related pages is often very useful to me. (This is not the best example, but it was the one I came up with now.)

That said the only plugin feature I miss from vimwiki is [[markdown links]]. I found this plugin with the hopes of implementing that without all the overhead of vimwiki.

I don't mind considering new features - could you open a new issue to describe this in more detail?

 Same here! I use FZF, but also ripgrep and CtrlSF.
I'm curious about this. I just have a binding to use fzf in the vimwiki dir, what do you use CtrlSF for?

I don't mind considering new features - could you open a new issue to describe this in more detail?

I wasn't clear enough, it's not a new feature, I meant the wiki links by surrounding a title [[like this]].

From what I'm reading it's already a feature, however I'm just testing it and it's not working. Do i need any additional setup? The plugin is installed, however when I autocomplete Wiki in the command line from nvim, I only get these available commands 1641655200

I can edit the comment and ask this in a separate issue if you want, just let me know.

I'm curious about this. I just have a binding to use fzf in the vimwiki dir, what do you use CtrlSF for?

I use Fzf with the :WikiFzfPages command to find a particular page, and I use CtrlSF (with ripgrep as a backend) for free text search within my wiki.

I wasn't clear enough, it's not a new feature, I meant the wiki links by surrounding a title [[like this]].

Ah!

From what I'm reading it's already a feature, however I'm just testing it and it's not working.

It seems you've not configured wiki.vim properly yet. I believe you are using markdown files with .md extensions. Please read :help wiki-intro.

I can edit the comment and ask this in a separate issue if you want, just let me know.

Let me know if it is still unclear after my above suggestions. If so, open a new issue.

thanks, i read the guide part but not the intro part, it's working now

Fascinating discussion. In regards to naming conventions, my approach differs from what has been discussed here. I use very broad categories, typically only seven, that have evolved over the years, and I am content with them. It likes having different notebooks in a single directories. I prefix my naming with these categories, and some of my naming conventions come naturally to me. For instance, I use U_vim to denote Unix stuff/Vim, and when I write about Vim, this naming convention is intuitive and doesn't require much cognitive effort. The subsequent keywords that follow are usually only one, but sometimes three. So I ends up some name like U_vim_wiki. I also use ranger or other terminal file manager which sometimes filter just to have a list of sub-topics within the directory and because of this naming, I can link much faster than relying solely on content rg.

Although I have considered using time-stamps or UUIDs, I don't believe it would be beneficial since relying on grep/rg would be only option. It's a personal trade-off I think. If you go completely random, the creation will be easy but later retrieving/link would be at least a bit slower.

I have a flat structure, and I place almost everything except my diary in it. Maintaining it hasn't been a significant issue for me, and while there may be broken links here and there bcz of rare but some re-naming, I only fix them when I come across them again. Since the naming conventions I use provide enough context, fixing the links is almost always straightforward, akin to making another :Fzf-like link. I think some plugin like wiki.vim can help by graph view, backlink, searching, creating link, navigation etc and this make everything much smoother (I've previously done this with no plugin - used to :q , fall back to ranger, do rg/fzf and continue!).

Linking is the most critical part of my system, and I used to add links at the bottom of the page before my personal use of Vimwiki and later Wiki.vim. Nowadays, thanks to the utilities these programs provide, I can link within the context, which has been a significant improvement for me.

Thanks for sharing your thoughts on the matter! It is interesting to hear about other peoples workflows!

lervag / wiki.vim

Define opinionated best practices #101

What structure to follow ?

How to write good notes ?

How to handle archives / immature / stale cards?

How to visualize / analyse data ?

How to connect with other tools?

Write a configurable linting tool?

How to write good notes?