These are chat archives for wooorm/remark

30th
Sep 2016
Titus
@wooorm
Sep 30 2016 07:13
What’s the rest of the code?
I’m guessing you don’t have remark2rehype in there, and no rehype-stringify
Jesse
@motleydev
Sep 30 2016 08:36

Here's the plugin I based it on:
https://github.com/wooorm/remark-slug

and here's a gist with the two files in question, the markdown processor script (I'm using Phenomic static engine) and my plugin:

https://gist.github.com/motleydev/2b529463c9371bb7adb16b9fa9d0e7a5

Titus
@wooorm
Sep 30 2016 10:28
@motleydev You’re mixing mdast with hast: the different syntax trees
You can interact with how remark-html compiles, but in that case remark-autolink-headings is a much better example
Ben Briggs
@ben-eb
Sep 30 2016 10:32
@wooorm remark-autolink-headings is probably better as a rehype plugin eventually though?
Jesse
@motleydev
Sep 30 2016 10:34
@wooorm so should I do the mdast stuff first (remark-html) and then do a hast plugin second?
Titus
@wooorm
Sep 30 2016 11:08
@ben-eb Yeah, we should start doing that. Wanna give it a try? Or prefer me to take a stab?
@motleydev remark-html is kinda funky: it handles transforming the syntax tree to string, so it always runs at the end
Ben Briggs
@ben-eb
Sep 30 2016 11:09
What's the plan of action? Rename the module and update to rehype?
Titus
@wooorm
Sep 30 2016 11:09
@motleydev What you probably want, is do markdown stuff first, then transform to HAST (with remark-rehype), then do HTML stuff, then compile to string
@ben-eb Maybe a new plugin? rehype-autolink-headings? Deprecate the original?
...which is kinda the same as a name-change
Ben Briggs
@ben-eb
Sep 30 2016 11:10
Yeah. :)
I'm probably not going to get to this quickly so if you want to do this then go for it
Titus
@wooorm
Sep 30 2016 11:11
:+1:
BTW, could you add me as a collab to your remark repo’s?
Makes it easier to work together on it
Ben Briggs
@ben-eb
Sep 30 2016 11:12
Sure thing
Titus
@wooorm
Sep 30 2016 11:12
:ok_hand:
Ben Briggs
@ben-eb
Sep 30 2016 11:12
Likewise, could you add me as a collaborator on remark etc? :D
https://github.com/ben-eb/remark is not really necessary as a fork ;)
Titus
@wooorm
Sep 30 2016 11:13
Sure!
Anything in specific you’d like access to?
Ben Briggs
@ben-eb
Sep 30 2016 11:15
Not in particular :) Just nice to be able to send pull requests directly
Titus
@wooorm
Sep 30 2016 11:18
OK, you’re on everything I believe
Ben Briggs
@ben-eb
Sep 30 2016 11:18
Thanks!
I did the same. But a lot less repos. :D
Titus
@wooorm
Sep 30 2016 11:19
;)
Thanks man!
Ben Briggs
@ben-eb
Sep 30 2016 11:19
No probs :) I might not have much time to contribute at the moment but we'll see how we go
@wooorm By the way are you familiar at all with Babel's approach to AST transforms?
Instead of giving you access to the full AST, they break it down into a path abstraction. Then, the AST is walked by Babel itself. Plugins then act on the paths that they are interested in. I was thinking of using Unist with this abstraction but I'm not sure how amenable the code would be to this
Ben Briggs
@ben-eb
Sep 30 2016 11:27
Well, Unist the node tree would work as a storage for the full AST. I meant things like Unified :)
Ben Briggs
@ben-eb
Sep 30 2016 12:31
So at the moment the current setup is that you walk the AST inside a Unified plugin, using something like unist-util-visit. That means that every plugin is walking the AST once, when more complex transforms might require two plugins to riff off of each other. Babel's system allows you to do this by returning an object of visitors, that are basically functions that are called when that node type is encountered by the walker. Then, if any nodes are changed, they are requeued into the walker so that other plugins can perform transforms if they should need to
Jesse
@motleydev
Sep 30 2016 14:25
so if I understand hast then, every visitor to unist-util-visit is an element with a type, as opposed to mdast where elements were one of heading, paragraph, etc ?
Titus
@wooorm
Sep 30 2016 14:30
@motleydev Very close, maybe reading up on https://github.com/wooorm/unist and https://github.com/wooorm/hast would help?
MDAST and HAST are both Unist nodes, which can be visited by unist-util-visit
MDAST is for markdown, HAST is for HTML
So in MDAST you have code, paragraph, link, etc.
And in HAST you have element, comment, doctype, etc
@ben-eb I’m not toooo familiar, but I do know some of the essence of it
I’m wondering if it would be possible for a plugin to pool these together, or if it must happen in unified itself
Ben Briggs
@ben-eb
Sep 30 2016 14:33
The thing is a plugin shouldn't have to know about other plugins, so if anything I think this happens at the Unified level
Titus
@wooorm
Sep 30 2016 14:34
So instead of a transformeryou’d return an object with type-paths to visitors?
Ben Briggs
@ben-eb
Sep 30 2016 14:34
I guess in theory you could have one plugin that provides the path abstraction and then you have plugins designed for that plugin, not unified
But that seems like a mess :)
Yeah, essentially
Titus
@wooorm
Sep 30 2016 14:35
I’m more talking of a utility rather though, kinda
Something like:
var pool = require('unist-pool');

function attacher() {
  return pool({
    'element:exit': console.log
  })
}
I suppose you could have something that added up all of those calls and then performed the transformation at the end
That's kind of weird when you have plugins that don't use this system though, is my concern
Titus
@wooorm
Sep 30 2016 14:38
Yeah! Attachers happen immediately, right? So pool could return one function (it needs to know the processor too though, hmm)
Why is it weird?
Ben Briggs
@ben-eb
Sep 30 2016 14:39
unified().use(poolPlugin).use(poolPlugin2).use(nonPoolPlugin).use(poolToAst)
Like in what order does all of that happen :)
Titus
@wooorm
Sep 30 2016 14:40
Ok, hold on, I’ll write that down
Ben Briggs
@ben-eb
Sep 30 2016 14:41
In this example we're mixing together two types of plugin, one that affects the AST immediately as it is run, and two where they can perform multiple AST passes (as they don't hit the AST directly through unist-util-visit)
So in theory the multi-pass plugins can be specified in any order, whereas the single-pass plugins have to be run in a certain order
My gut feeling is that these approaches shouldn't be mixed together. So maybe there could be a new unified-pool or something
Titus
@wooorm
Sep 30 2016 14:47
unified()
  .use(poolPlugin)
  .use(poolPlugin2)
  .use(nonPoolPlugin)
  .process('foo()', console.log);
//=> 'a'
//=> 'b'
//=> 'c'

unified()
  .use(poolPlugin)
  .use(nonPoolPlugin)
  .use(poolPlugin2)
  .process('foo()', console.log);
//=> 'a'
//=> 'b'
//=> 'c'

unified()
  .use(nonPoolPlugin)
  .use(poolPlugin)
  .use(poolPlugin2)
  .process('foo()', console.log);
//=> 'c'
//=> 'a'
//=> 'b'

function poolPlugin(processor) {
  return pool(processor, {
    'element:exit': function (node) {
      console.log('a');
    }
  })
}

function poolPlugin2(processor) {
  return pool(processor, {
    'element:enter': function (node) {
      console.log('b');
    }
  })
}

function nonPoolPlugin(processor) {
  return function () {
    console.log('c');
  };
}

function pool(proc, fn) {
  proc.queue = proc.queue || [];
  proc.queue.push(fn);
  return function (tree) {
    doFunkyStuff(proc.queue, tree);
  }
}
Ben Briggs
@ben-eb
Sep 30 2016 14:50
Yeah, the single passes are easy, it runs in the same order as they were injected into the processor :) But this pooling technique means that we can make multiple passes as the pool host controls when the AST will be traversed
So whereas a single-pass plugin will work once, a multi-pass plugin might run a few more times depending on what nodes were inserted or updated in the AST
So you call a method like replace(node, otherNode) and the AST gets traversed again, right, with all of the pool clients
Titus
@wooorm
Sep 30 2016 14:53
Yeah, but the effect of that would be same if it’d be implemented in unified or in a utility, right?
Ben Briggs
@ben-eb
Sep 30 2016 14:56
Possibly?
I'm not really sure. But I think what you are saying is this is possible already
It's not the default way that Unified works but I don't have to reinvent the wheel with regards to plugin creation/hosting etc
Jesse
@motleydev
Sep 30 2016 16:02
Ok, so that plugin… is working. :) Thanks for the help!
Ben Briggs
@ben-eb
Sep 30 2016 16:02
Awesome! :)