Ah ha! I see it updates when at Joplin's sync interval. (I installed the extension today, so ... it is the most current).
No, I mean, at the top of some of my markdown documents, there is an @import. Sometimes that import will reference a CSS file from some server "https://example.com/css/cool.css"; , but more often than not, it will reference a file from my filesystem. Joplin is 100% fine with this. vscode, alas, is not.
<style>
@import "/path/to/a/stylesheet.css";
</style>
# A bunch of Markdown
...
No, I mean, at the top of some of my markdown documents, there is an @import. Sometimes that import will reference a CSS file from some server "https://example.com/css/cool.css"; , but more often than not, it will reference a file from my filesystem. Joplin is 100% fine with this. vscode, alas, is not.
... if I set it to, for example /home/todd/path-to-stylesheet/stylesheet.css (Which is not ideal anyway because the style sheets I use change per file, but whatever.)
I think the "open folder" that serves as the working directory is some virtual thing that can't be routed around, relative path or not. That, or I am just not figuring it out.
I checked and it does not work, kind of magical, the official maintainer's statement is that referencing local absolute paths is not supported for security reasons. Is there anyway you can create a simple extension to do it? Although this is indeed very strange. . .
I wasn't sure if you were quoting the maintainer here, or asking me this question. Regardless, my coding days are largely over. Heh.
But this hard line by the maintainers is ... naive, IMHO. There are tons of scenarios where a robust editor is not used for production development (this whole thread is an example of that). And hell, just wrapping the option in tons of warnings and caveats should be sufficient. (Putting on my ex-product-manager hat for a moment.)
Oh well. The work-around is for me to push the CSS to a website. Not a huge deal for me (though if you are troubling-shooting CSS through rapid cycles of trial-and-error this is a major PITA) but often folks don't maintain a website. Or they don't have an easy way of deploying arbitrary CSS somewhere.
Anyway. I said my piece. Thanks for looking into it.
OK, I got it to start after realizing that the bit about copying tokens and such was setting up in vsc, rather than joplin.
I now find that while I can create a new note in vsc, and some number of edits will be reflected in joplin, if I then go and edit that same note in joplin, vsc never sees the update, unless I exit and restart.
Is this expected???
(If I open a note with joplin's external edit button syncs seem to work fine.)
Yes, this is expected, since the vscode plugin is intended to replace the joplin client, you should only use one of the editors at a time in most cases.
By the way, how does joplin's own multi-language search be implemented? It seems that each language uses different methods for word segmentation, so I currently just use spaces to do simple word segmentation processing. @laurent
I never realized this problem, which is strange, maybe it has something to do with the fact that I have never used this feature of joplin. Now the vscode plugin can indeed only display the todo, but not create it.
If possible, we hope to integrate support for CJK (Chinese, Japanese, Korean) word segmentation search directly into Joplin. This would eliminate the need to implement it in external applications that call the Joplin REST API. We expect to achieve this through WebAssembly (WASM), which offers natural cross-platform compatibility and relatively high performance. For Chinese word segmentation, this would add approximately 2.7MB to the WASM file. If we integrate it into Joplin, would this be acceptable? @laurent