Using VS Code + Markdown All in One (https://marketplace.visualstudio.com/items?itemName=yzhang.m...) has honestly been the most productive blogging tool I've used in a very long time, moreso than dedicated Markdown blogging tools like iA Writer. (granted half of that is due to "Paste link on selected text" which is an embarrassingly common workflow for me)
Still amazed by the amount of external production dependencies these VSCode extensions all seem to require. I wonder how tight Microsoft's grip is on extension security and how deep any of their automated checks might go.
The extension functionality does look great though. I wrote some similar functions in my nvim which I would have really a hard time living without.
It's no different or worse than the security model of any other text editor or IDE. It runs as your user (unless you're doing something zany like running an admin account), and it can do anything your user can do like launch programs or subprocesses you have access to execute. A vs code extension isn't going to get some unexpected power like root privilege to start messing with your system, opening low ports, etc.
You're right, what I'm curious about is how difficult it'd be to sneak a malicious command into some VSCode extension update trough these production dependencies, and how far, say, an rm -rf <allthethings> could reach from the trusted project root directory from which it is executed.
I'm not a VSCode user myself, but it's pretty much the same story with nvim.
edit: I suppose what I'm really getting at, is that, depending on what their security measures look like, the VSCode extension store might be giving some false sense of security.
A lot of supply chain security relies on trusted actors doing the right thing. It’s similar to how you can trust an ingredients label.
I suppose I could mention that on a Mac, I use Objective-See’s tools to watch what programs do in the background. And also on a Mac, you have to grant access to apps first otherwise they can’t normally access files. Of course, that breaks down in reality as most apps are useless if they can’t access files.
If you really want a scare, consider that if you compromise an ecosystem package (e.g. npm), you can run on developer machines, CI systems and possibly in production, while if you compromise a VS Code extension, you only get dev machines.
If you’re looking for a bit of extra protection, you can run VS Code from a virtual machine or even run it from Docker. Though the usual docker approach, using remote containers extension, still runs on your local computer. There’s GitHub Codespaces or Google Cloud Shell that can run VS Code remotely in a VM, though.
Most projects I'm involved with require measures that go a bit further still. Got to be honest though, it can be frustrating at times.
Just sprinkling bits of awareness around by bringing some of these considerations up whenever I can. It's an uphill battle, although, the general carelessness around extension and dependency use I'm seeing - and that even after all the shit that's been going on in that space - makes it one worth to fight.
Edit: Regarding the chain of trust you mention, that one has sort of come and gone, and there is not a whole lot of trust involved in the processes I'm saddled up with.
That's an aspect from mobile OSes I miss on desktops: apps run as their own user, and have to be granted permissions to do things like read & write files outside their own "home" directory.
Programs should run as their own users. Programs should be granted access to files opened via system (desktop environment) file picker APIs or when passed in via a shell. Desktop environments & shells would need to be modified to allow this, of course.
Mobile OS permissions are way too limited. It's one of the reasons there are no good programming environments on mobile.
> Programs should be granted access to files opened via system (desktop environment) file picker APIs or when passed in via a shell.
For example, this would render the file tree of any IDE or advanced editor (like VS code) completely useless. I can count on one hand the number of times I've used the system file picker when programming.
That thread turned from a pretty straight-forward permission issue discussion to a display of some esoteric dark arts in only a few posts!
Not sure if I consider vim either simple or sane, but then again, it was first released quite a while ago, in 1991 for the Amiga, and it was based on the even older original vi from 1971 - the era of physical TTYs, no mice, and punchcard programming (ugh! glad I wasn't born yet).
Can hardly blame grandpa for forgetting and acting strange every once in a while at his age :)
I was also curious. I found an extension called Markdown Paste[0], by searching for an extension to automatically base64 encode images into markdown in VSCode, which is not how this extension works at all.
I've tried all the tools in the market for personal knowledge management/journalling/todo/whatever.
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!
The thing I keep sitting with is what one wants for personal knowledge management vs. collective knowledge management. I've been using athens research ( https://www.athensresearch.org/ ) so far after doing classnotes in roam thinking one there could be extensions in the future to make things 'feel' like navigating directories of markdown files if really needed.
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)
that's fair. the dot hierarchy has been a polarizing topic with folks falling on both sides of it.
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
For folks that already use vscode, the selling point is being able to continue to use vscode for everything, code and markdown. VSCode has an editor experience that is hard to beat
(also, disclaimer: I'm the author of the article and founder of Dendron)
> VSCode has an editor experience that is hard to beat
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.
The WYSIWYG part of obsidian can be somewhat replicated in VSCode by this obscure and community-neglected plugin [1]. Live math preview was the reason why I got this plugin, which works very unreliably, but for other markdown functions it's okay.
One missing component (last I heard) to the Obsidian story: there's no web app. With Dendron and others, you can use code-server to use VS Code in a browser. It's a better workflow for ChromeOS, iPad nomads, Wayland users.
Since your knowledge base in obsidian is simply a folder filled with markdown files, it’s quite quick and fairly painless to run say mkdocs or similar which serves up all the markdown as a nicely formatted website.
- 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
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.
> I think this is normal for most people who ever write something in markdown
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.
> But not for most markdown files, at least how I use it. I only start new line when I reach a new paragraph, and I think this is normal for most people who ever write something in markdown.
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.
> But how does someone take advantage of it without changing their current behavior: write an entire paragraph and do 2 line breaks.
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.
Hmm, interesting. I've not yet come across a situation where I'd need diffing or going back to a change or looking for one. I just use git for syncing.
Hard line wrapping is not a panacea in this regard, like when you have a words added/removed from a line and then you get a cascading series of changes for the rest of the paragraph as you rewrap it.
i think it depends on your writing style. i tend to do a lot of outlining with bullet points so it works pretty well. for longer paragraphs it can definitely be a pain
I’ve settled on similar setup. One nice thing about is there many tools that can work on this type of note setup, so you are not locked into one tool.
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.
Live View (a WYSIWYM Editor) - you type markdown, but see it rendered, comes to mind. Also some interesting extensions/add-ons centered around knowledge management are arising.
Unfortunately, Obsidian itself is not open-source though; but worth checking out.
My knowledge base is a git repository full of markdown files and vscode. I can easly goto a specific file or do text search across all files. Minimal effort and no lockin to s specific tools.
i'm currently working on shipping the publishing side of dendron in a docker (its a custom nextjs app) so that it can be easily tested locally as well as hosted remotely
I've been trying Obsidian, Foam, Dendron, etc., and most of these Zettelkasten-like editing environments have issues with relative links (i.e., they don't let you specify a base folder) and/or completely ignore front matter, which makes them hard to use when you've got 8000-odd posts across a big directory tree.
(taoofmac.com is like that, and is actually a pretty big wiki)
I've been resisting hacking my own, but I suspect I will eventually have to :)
Have you used LogSeq? Its "thing" is that it doesn't have folders, period. Your workspace is just a graph of files that reference each other. In the event that a page's name has slashes in it, the components will be treated as hierarchical pages, but that's more of an emergent folders thing than real folders (as changing the name of a page changes its own hierarchy without renaming any of its parents in the hierarchy, leaving the existing hierarchy intact)
True, Logseq is mainly an outliner. But you can enable free-form text temporarily by pressing t+d (toggle document mode). Alternatively, you can press ctrl+shift+p to open the command palette and type 'document mode'.
Since I rarely use it, I don't know. But ask on Discord. The community is very friendly and helpful there. You'll find the link to it on their website under Community.
Not the original poster, but my main problem install Dendron as a vacode plugin was sometimes my Dendron directory wasn't "Dendron", and sometimed Dendron seemed to load and do things when in directoris of unrelated markdown.
I never did figure out what was going wrong, but I moved to Obsidian mainly so I had a clear separate note keeping app.
if you have a public repo or an example note, happy to take a look at it. we've done lots of work on our markdown import and it should address a lot more cases now
> drag and drop files into the editor to create a markdown link
This is nice, but I'd really prefer being able to drag and drop and then have it uploaded to, say, OneDrive. Even better, be able to paste a URL and have it download the file and then upload it to OneDrive or Dropbox or whatever.
> find all references to header|links|files|urls inside of markdown
Sometimes this sort of thing is nice to have, but doesn't it add a lot of overhead when working with markdown files?
Atom has an "official" Markdown-enhanced plug-in that is released by atom-community. It has pretty much everything you could want. I don't understand why VS Code doesn't just have a similar official plugin and instead relies on people to go install random plugins with warnings about how they may be malicious. Shouldn't they just include a powerful markdown editor and previewer by default?
While I get their point of not enforcing hard tree hierarchies, I hate that as a consequence there is no folder structure. The integrated note explorer is quite cumbersome to use IMO, so dealing with files externally would be more convenient
Adding Prettier (https://marketplace.visualstudio.com/items?itemName=esbenp.p...) for its underdiscussed Markdown formatting keeps READMEs and blog posts clean as well.