And I've finally found my comfort in a folder with a certain directory structure containing all markdown files. I use VSCode for this (as it's already my daily driver) and GitJournal in Android to manage sync via git.
These features are a huge value addition to my workflow!
After reading more about dendron which states on https://github.com/dendronhq/dendron "It's a personal knowledge management solution (PKM) built specifically for developers and integrates natively with IDEs like VS Code and VSCodium." , the question is how these tools could serve a wider audience if they were packaged more as standalone app (using something like Eclipse Theia).
This makes it easy to publish your notes as a static site. The plan is to add optional server side capabilities here so that it becomes possible to read *and* write notes, at which point it becomes a web interface for note taking. It also helps with the distribution problem (Dendron is used by teams to publish documentation to non-technical folks so it helps that they can access it as a regular webpage)
the reason we went with it is because: - it allows a file to be both a note and a parent of notes - it makes hierarchy an explicit part of note creation - it greatly simplified operations like refactoring (regex over filename, no need to create scaffolding with empty folders or removing folders if they no longer had children) - it makes it easy to work with using cli tools
More discussion on this here: - https://wiki.dendron.so/notes/683740e3-70ce-4a47-a1f4-1f140e... - https://wiki.dendron.so/notes/683740e3-70ce-4a47-a1f4-1f140e...
- Advanced Tables: for automatic formatting and table operations of markdown tables
- Dynamic Table of Contents: allows you to include a codeblock that automatically renders a table of contents from headers of some level
- Natural language dates: insert dates in your preferred format using language like 'next Friday' or 'first Monday of June'
- Quick latex for Obsidian: autoformat and autocomplete common latex commands (e.g. 'a/b' becomes '\frac{b}{a}'
- Tag Wrangler: rename, merge, toggle and search tags easily
- Sliding Panes: changes notes to panes that can be stacked similar to the ui of Andy Matushchak's notes [0] (check it out, it's rather neat)
- Zoom: Work on part of a bullet list structure in isolation, with a breadcrumb line at the top to jump to a different parent level
- Copy button for code blocks
- Auto backup with Git
- Outliner: Vertical indentation lines for bullet lists, and hotkeys to move list items about in the structure
- Recent files: List of files, ordered by most recently opened
- Vimrc support
Not a plugin, but I tried to make a cheatsheet of the supported Prism language types that I'm likely to use. They can be specified in the code fences (```) so that the code and config blocks in my markdown notes look prettier : https://prismjs.com/#supported-languages
- Convert to iframe (transform a pasted URL into a iframe)
- Custom attachment location (so pasting a screenshot automatically stores it in a dedicated subfolder)
- Core search assistant (to preview search results)
- Reveal Active File (to find the current note in the LHS tree)
- Mind map (show the outline of a note as a mind map)
- Excalidraw (draw things in notes)
- Outline (adds a Outline side panel)
And I plan to investigate:
- obsidian-annotator
[0]: https://obsidian.md/
(also, disclaimer: I'm the author of the article and founder of Dendron)
VS Code is a text-editor focused on coding. Obsidian is a markdown-editor focused on knowledge- and self-management. They are each hard to beat in their own specialty. For example, the WYSIWYG-Editor of obsidian is not something that VS Codes raw text-view can beat, especially if you combine it with add-ons for code-blocks.
I found out that I end up doing a lot of editing + file organisation tricks native to my VSCode setup. So +1 to kevinslin's sibling comment.
But not for most markdown files, at least how I use it. I only start new line (actually, 2 new lines) when I reach a new paragraph, and I think this is normal for most people who ever write something in markdown.
So now I get a huge 2000 character line with a few small edits, and I can hardly see where the changes are.
Nice heads-up to look out for.
I wish github would also implement word-diff option.
Edit: Github actually does some form of word-diff! See example here: https://github.com/chaoxu/chaoxu.github.io/commit/6d9ab6eefc...
I also looked up how word-diff work with Chinese language. Found a useful stackoverflow link with other suggestions.
https://stackoverflow.com/questions/26135133/git-word-diff-o...
Markdown treats lines separated with a single line break as a continuous line/the same paragraph, and you need to add two or more newlines for Markdown to interpret it as a new paragraph.
Git works just fine with Markdown.
But how does someone take advantage of it without changing their current behavior: write an entire paragraph and do 2 line breaks.
Always end a sentence with '.\n'? Manually format lines so no line have more than 80 characters?
Prettier options to extensions like Rewrap, one of those might fit your use case.
I don't understand your question. Markdown's syntax already requires 2+ newlines to define a paragraph. There should be no change in a workflow if you're already using Markdown.
The only nuance is that if you want git to track changes in each sentence that forms a paragraph, just add a single line break after the punctuation mark. Markdown still interprets that as the same text block, but git is able to handle changes per line.
I recognize that I am not normal and this doesn't contradict your assumption, but I use Emacs' fill command to hard-wrap long lines at ~80 characters when I'm writing Markdown. In fact, it's so habitual for me that it causes me problems when writing Gemtext. I keep meaning to disable filling in gemini-mode.
Working Copy works decently well on iOS. Gollum [1] on desktop operating systems provides a web interface to the notes. For some shameless self-promotion, I’ve been hacking on a clone of Gollum called Smeagol [2]. It is written in Rust so it is quite a bit faster to install and run on some of my low powered systems than installing Gollum.
[1]: https://github.com/gollum/gollum [2]: https://smeagol.dev/