I'm a ml researcher (http://vmasrani.github.io/) and I've recently written a very ugly and inefficient python script based on https://www.daviddeutsch.org.uk/concordance/ that might be of interest to the Dendron ecosystem. I've looked around and I can't find a vscode extension that does anything similar - I've attached a screencast of how it works below:

I'm looking to collaborate with someone knows javascript / how to write vscode extensions to turn the hacky python script into a properly written extension. Would anyone in the channel be interested in joining forces? The logic is already written, so it's mainly just a question of converting the python to javascript (which is out of my jurisdiction :p), and writing a wrapper to make it a proper extension.

It would be interesting to have an extension that allows you to interface with a handful of NLP models for stuff like this. Natural language syntax highlighting might be interesting too.

Dendron in Sublime Test

ya thats a great idea, gonna investigate

@User @User has been doing most of the completion related improvements in Dendron the past few months and released a writeup of learnings which you can find here -> https://blog.dendron.so/notes/IThOx1Oag1r0JAglpiDLp/ Highly recommend the read if you're interested in how autocomplete in VSCode works or are curious how we do it for Dendron

@User initiated some good discussion points in one of my recent PR about coding style and testing, and I think it's worth moving those discussions here so that we can discuss further without creating noise in the actual pull request. about commenting / refactoring blocks of code: https://github.com/dendronhq/dendron/pull/1349#discussion_r713768447 about using lodash vs native js methods: https://github.com/dendronhq/dendron/pull/1349#discussion_r713777597 structuring plugin tests in bdd-light style (+ splitting plugin test utilities): https://github.com/dendronhq/dendron/pull/1349#discussion_r713757184

I always lean towards using native method when it's just 1-3 lines. The upside most people aren't aware is that native methods on V8 are heavily optimized essentially allowing you to achieve near-native speed. @hikchoi

I personally think we should focus on the readability of the code more than the performance at this point: I don't think we really have any code where the performance difference between a lodash function and a native function will make a difference. That being said, I'll also join @User to admit that I sometimes use lodash functions over native functions for no apparent reason. I actually prefer the chainability of the native functions, but it annoys me that some of the lodash functionalities (like

sortBy

) aren't available in native. In any case, I'm happy to listen to others and follow a code style we agree upon here. For BDD-light, I think we could restructure our testing code so that

runLegacyMultiWorkspaceTest

accepts

THEN

clauses that are all run within the same workspace. The test writer just needs to be careful so that the

THEN

clauses are independent of each other, and just do simple checks inside.

I think the

THEN

clauses reusing the workspace is important because I think the workspace setup takes up a significant portion of the time that it takes to run the tests. If the setup is duplicated/repeated for each

THEN

, that might lead to a massive slowdown for running tests.

Lodash was invented at a time when there was no ES6/NEXT. Javascript was this archaic behemoth. Nowaways, native language features are constantly added, optimized, improved. For Lodash. however, V8 essentially can not do optimization for package-specific methods when they are still trying to maitain compatibility that simply doesn't use ESNEXT features underneath. You'd be surprised to see how much of an improvement we are actually talking about. Especially most of those are one-liners anyway, seems like a no-brainer to just get those performance boosts for free!

One gotcha here though, most of the native equivalents of lodash are array methods, and sometimes what we are dealing with aren't just arrays. Anything iterable can be converted to arrays but it may be just better to use lodash at this point. Maybe we can start preferring native features for ones that are clearly interchangeable without doing any mental gymnastics to make it fit. and then slowly think about ways to move forward. I think the readability concern can go both ways; neither of them wins by a landslide: Some lodash methods just read better than native. (lodash wins) When we have to chain a bunch of methods, lodash starts to get confusing. (native wins) When we are dealing with iterables that aren't arrays, we need an extra step to make it into an array. (lodash wins) I agree with @User with performance not being a critical concern right now. I have no data to back this up but it might make a difference on the publishing side (and any web components we use on the plugin side) so it's good to be mindful about it at least moving forward.

coding style and testing

@User We've been making a bunch of updates to the NextJS Template. Recent highlights: - full text search - blazing fast development + build (upgrade to webpack5 and nextjs11) - updated docs on getting started with git and github actions (https://wiki.dendron.so/notes/YRsmBlShfdHEuQstRscEc.html) If you've been meaning to give publishing a try - now's the time! If you run into any hiccups, I'll be hosting a "Getting Started" tutorial this Friday at 3PM PST in the #776450886230605845 channel. You can add it to your calendar here -> https://lu.ma/8vppzo3s ☝️ @User @User @User @User

here’s an example of the new publishing experience for curious bystanders https://www.kevinslin.com/

Looks like I have some things to do this weekend on my published digital garden 🙂

looks good 👍 - although sometimes note titles can be quite long so the ability to hover over note titles in the left hand nav column and have a tooltip popup with full-title would be a nice.. (still, it looks great)

that’s coming 😅

noob question: am I supposed to run both

cd /home/j/Dendron/nextpub/.next && npm install

and then also

cd .next && yarn && cd ..

?

no, one or the other

ah! thank you!

haha its working for me now 🙂

RE the

NOTE: Pages are dynamically compiled in local preview and will take a second to load.

... is it supposed to reflect changes on the fly?

eg: if I edit some page, and then re-browse/refresh?

not yet. but when you navigate links, the pages are compiled when you click through them

does anyone know why is this yelling me about

bottom right

you’ll need to run build to get latest content

@User me?

it looks like you downloaded the nightly version. that is experimental and not guaranteed to be stable. i would uninstall and install the regular version