Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom markup symbols (bold/italic) instead of the defaults #122

Closed
eugenesvk opened this issue Aug 1, 2024 · 8 comments
Closed

Custom markup symbols (bold/italic) instead of the defaults #122

eugenesvk opened this issue Aug 1, 2024 · 8 comments

Comments

@eugenesvk
Copy link

Is Scroll flexible enough to allow Parsers to be extended to replace the default markup symbols?

For example, I'd like the asterisk to just be an actual asterisk and use something else for bold

Or make the underline used for underlining text and something else for italics?

@breck7
Copy link
Owner

breck7 commented Aug 1, 2024

I'd like the asterisk to just be an actual asterisk

Yes, but the documentation for that is not good yet.

Demo:

http://hub.scroll.pub/edit.html?folderName=asteriskdemo&fileName=index.scroll&password=homeamsomefindnewsnew

use something else for bold...Or make the underline used for underlining text and something else for italics?

Yes, the aftertext directives can be added/expanded easily. In theory. In practice that code is a bit messy and it's on my todo list to clean it up. But you can absolutely bank on it that this is not only possible but is possible and will be very easy in later versions.

@eugenesvk
Copy link
Author

The demo is for overriding asterisks as a prefix, but I only meant asterisks as used in the *bold* paired markup

will be very easy in later versions.

So that could be a "global" override instead of being used for every piece of text (as far as I understand from https://breckyunits.com/aftertext.html)?

Similarly to how your demo allows a global override of the asterisk as a prefix

@breck7
Copy link
Owner

breck7 commented Aug 1, 2024

but I only meant asterisks as used in the bold paired markup

Oh that makes sense. Sorry I read it wrong.

The relevant line of source code is

const wraps = [{delimiter: "`", tag: "code", exclusive: true, name: "code"},{delimiter: "*", tag: "strong", name: "bold"}, {delimiter: "_", tag: "em", name: "italics"}]

I can clean this code up soon to make it easier to accomplish what you want. Good idea!

@eugenesvk
Copy link
Author

Would be nice indeed if all one had to do was something like "substitute wrapsOnParser" and just change this one const wraps with custom delimiters, while leaving all existing rules as is (and when you update the inner rules this custom substitution would benefit from that as well), and it would work everywhere wrapsOnParser is used in the current parsers

For example, I see that here is wrapParser that extends wrapsOnParser, guess it should continue to work? Or maybe this could lead to issues with priorities? For example, this wrapParser as far as I understand defines _ as an italic marker, but in my example I've replaced wrapsOnParser to use _ as an underline marker, so which parser would win?

breck7 added a commit that referenced this issue Aug 1, 2024
@eugenesvk
Copy link
Author

eugenesvk commented Aug 2, 2024

Looks great, and even nested markup works, playground example! Though for some reason /a//b/ instead of 2 italicized letters prints a/<>b, couldn't find the reason and how escaping works

(triple symbol works, but isn't a proper escape since

`a```b`

while printing

a`b

doesn't surround the actual backtick in "code" highlight?
So how would you escape the default or custom marker?

@breck7
Copy link
Owner

breck7 commented Aug 2, 2024

Looks great, and even nested markup works

Great to hear!

(triple symbol works, but isn't a proper escape since
So how would you escape the default or custom marker?

I've found I rarely need escapes, and in those cases I just use a code parser or disable the conflicting markups, or use a raw html div <div>. Seems to work great, and keeps things simple for most cases.

If one needed escapes a lot, I'd probably suggest building one's own paragraph parser perhaps.

@breck7 breck7 closed this as completed Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants