You are propably able to get by creating a walk-token. They basically act as an intermediate processing step before the data is handed to the renderer. Their ability is somewhat limited, but it should be plenty for things like this.

I tried the following but it doesn't work. Does tokenizer only substitute existing tokens? Can you not add your own custom ones?

const tokenizer = {
	tipNotice(src) {
		const match = src.match(/\nnotice: (.*)\n/);
		if (match) {
			return {
				type:'tipNotice',
				raw:match[0],
				text:match[1].trim()
			};
		}
		return false;
	}
};
const renderer = {
	tipNotice(text) {
		return `<div class="tip notice">${text}</div>`;
	}
};
marked.use({ tokenizer, renderer });
marked(content,{ headerIds:true });

@alystair Both the Parser and the Lexer implementation currently have their structure hardcoded. So you can so there currently is no straight way of altering what they hand to the Tokenizer and Renderer, as those are "stupid" as they are build tor speedy processing.

And as it turnes out, it is pretty much impossible to make invasive modifications short of altering the source-code or meta programming a weil.

Whoever wrote the core of this package can really pad himself on the back, it is as solid as granit.

#1695 i filed an issue about that yesterday

Argh... in that case I'll have to replace several built-ins like paragraph, and review the source code to expand on the current functionality. Fun.

A little hint: copy the repo and directly modify the sourcecode i spent a full day trying to alter the parser and lexer from inside my module and i have nothing to show for it, as marked is stable as hell.

But the code is modern and well formatted. Navigating it is a breze

This is something that could be useful. If someone wants to create a PR I would be happy to review it.

@UziTech the PR is to add "token" param to renderer methods, right? So for example the "paragraph" one will receive "token" in addition to "text"?

No the issue is for the ability to add additional tokenizers/renderers. For example adding an "underline" tokenizers and renderer to extend markdown.

Moving to the renderer taking tokens instead of certain parameters is something that will have to be done on a major version bump but I think it would help with this issue.