Skip to content

Plugins: Support shorthand syntax processing - #495

Merged
yamgent merged 1 commit into
MarkBind:masterfrom
jamos-tay:preprocess-syntax
Apr 13, 2019
Merged

Plugins: Support shorthand syntax processing#495
yamgent merged 1 commit into
MarkBind:masterfrom
jamos-tay:preprocess-syntax

Conversation

@jamos-tay

@jamos-tayjamos-tay commented Dec 24, 2018

Copy link
Copy Markdown
Contributor

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] New feature

Fixes#492

What is the rationale for this request?

We want to be able to support shorthand syntax for certain elements.

What changes did you make? (Give an overview)

Have a feature that transpiles shorthand syntax into proper Markbind syntax before processing.

The current implementation is just a proof of concept. Better to migrate this function to external plugin once #474 is merged.

We can generalize this plugin so other shorthands can be added easily as well. I'm thinking we can handle these all together since they are too small to warrant their own functions/plugins.

Something like this perhaps?

{
'panel>span[heading]' : (ele) => // modify ... ,
}

@jamos-tayjamos-tay changed the title [WIP] Syntax preprocessing[WIP] Shorthand syntax preprocessingDec 24, 2018
@yamgent

Copy link
Copy Markdown
Member

{ 'panel>span[heading]' : (ele) => // modify ... , }

So this is going to be specified by the user in the site configuration file? If code is involved, seems better to have it in a .js file.

@jamos-tay

Copy link
Copy Markdown
ContributorAuthor

Oh yeah, js plugin definitely. I'm just suggesting we have some kind of framework that can be generalized to different syntax transformations.

@yamgent

Copy link
Copy Markdown
Member

I'm just suggesting we have some kind of framework that can be generalized to different syntax transformations.

Understand the point, my question originated because you mentioned the following:

We can generalize this plugin so other shorthands can be added easily as well. I'm thinking we can handle these all together since they are too small to warrant their own functions/plugins.

Will look forward to your actual implementation.

@jamos-tay
jamos-tayforce-pushed the preprocess-syntax branch 2 times, most recently from 9de6a39 to fb32bccCompareFebruary 11, 2019 13:18
@jamos-tay

jamos-tay commented Feb 11, 2019

Copy link
Copy Markdown
ContributorAuthor

Reviving this PR now that #474 is merged.

Moved to shorthandSyntax plugin.


This plugin is kind of empty right now. I'm not sure if it's worth exposing to public (documenting as a plugin) at the moment. How about:

Add a mechanism for 'always-run' plugins i.e. without having to include it in plugins. The way I see it plugins are good for two things:

  • Allowing users to enable/disable features
  • Keeping the code base clean

This was made as a plugin more for the sake of keeping the code base clean, users are unlikely to need to disable it. Having it always on saves the user from having to add it in every time.

This can also be applied to other features that should be always enabled, such as

@jamos-tayjamos-tay changed the title [WIP] Shorthand syntax preprocessingShorthand syntax preprocessingFeb 11, 2019
@acjhacjh mentioned this pull request Feb 11, 2019
yamgent
yamgent previously approved these changes Feb 17, 2019

@yamgentyamgent left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a mechanism for 'always-run' plugins i.e. without having to include it in plugins.

As mentioned by Prof in #474 (comment) perhaps this can be enabled by default and allow the user to disable it if necessary.

We can then adjust the documentation as necessary then.

But for now the PR is sound and can actually be incorporated into the codebase. 👍

@jamos-tayjamos-tay changed the title Shorthand syntax preprocessing[WIP] Shorthand syntax preprocessingMar 1, 2019
@jamos-tay

Copy link
Copy Markdown
ContributorAuthor

Waiting on #702 so this can be converted to always-on

@jamos-tay

Copy link
Copy Markdown
ContributorAuthor

Sorry for late update. Plugin has been converted to default (always on) and rebased.

@jamos-tayjamos-tay changed the title [WIP] Shorthand syntax preprocessingShorthand syntax preprocessingApr 13, 2019
@yamgentyamgent added this to the v2.1.2 milestone Apr 13, 2019
@yamgent

Copy link
Copy Markdown
Member

Propose a merge commit message.

@jamos-tay

Copy link
Copy Markdown
ContributorAuthor

How's this?

Plugins: Shorthand syntax processing
Certain MarkBind elements such as panels require a lot of boilerplate HTML to be written in the .md file, which is tedious. We would like to have syntax shorthands for such element to make it easier for the site author.
Let's create a plugin that can convert shorthand syntaxes into proper MarkBind syntax simply, which serves as a framework for more of these
to be added.

@yamgentyamgent changed the title Shorthand syntax preprocessingPlugins: Support shorthand syntax processingApr 13, 2019
@yamgent

yamgent commented Apr 13, 2019

Copy link
Copy Markdown
Member

Revised your commit message to use <span heading> as an example:

Plugins: Support shorthand syntax processing (#495)
Certain MarkBind elements such as panels require a lot of boilerplate HTML to be written in the .md file, which is tedious. We would like to have syntax shorthands for such element to make it easier for the site author, so that, for example, instead of writing:
<panel>
<span slot="header" class="card-title">
Heading
</span>
</panel>
Authors can write this instead to achieve the same effect:
<panel>
<span heading>
Heading
</span>
</panel>
Let's create a plugin that can convert shorthand syntaxes into proper MarkBind syntax simply, which serves as a framework for more of these
to be added.

@yamgent
yamgent merged commit 5f0b46e into MarkBind:masterApr 13, 2019
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Provide a shorter syntax for specifying complicated panel headings

2 participants

@jamos-tay@yamgent