Custom syntax? about markdownlabel HOT 3 OPEN

Hi, sorry for the delay! I don't have a moment right now to check how I would do this, but my guess is that you were in the right track. Add a regex pattern for your custom syntax somewhere along the others and put your logic in there.

Alternatively, I guess you could just create a new node that inherits from this one, and use a regex pattern to find your syntax and replace it with the appropriate text. Maybe that would be easier?

from markdownlabel.

That makes sense.

I'm not in any rush :) I'm interested where your thoughts go.

I don't see an easy way to inherit without duplicating the whole '_convert_markdown' function.

I might insert a function call near table, and override that function. Then I'm editing least of your code if you update your code later 🤣

		# Breakout to process custom processing
		_processed_line = _process_custom_syntax(_processed_line)
		
		# Tables:
		_processed_line = _process_table_syntax(_processed_line)

		# Lists:
		_processed_line = _process_list_syntax(_processed_line,indent_spaces,indent_types)
...
		func _custom_table_syntax(line: String) -> String:
			# inherit and replace this function with custom regex and  _convert_markdown code
			return line 

from markdownlabel.

Well, inheriting would have its restrictions, but it would be the most robust if the parent class' node is updated at some point.

Something like:

class_name MyMarkdownLabel extends MarkdownLabel

func _convert_markdown(source_text = "") -> String:
    # Custom syntax here #
    super(source_text)

If I'm thinking about this correctly, this would work with simple syntax like what you shown on the first post. The cons would be that it would have slightly lower efficiency, since it would be checking the whole text twice (one for your syntax and another one for markdown), and your syntax would always be parsed even if it's inside code blocks or escaped somehow (unless you also implement checks for that) (but that could be a non-issue depending on your use case).

Then, this would always work regardless of if MarkdownLabel is updated or not, since you are basically just pre-parsing the text with your syntax.

Now, for more integrated syntax, I think your approach in the latest comment is best. The only con is that you would need to manually update the code if you want to update MarkdownLabel at some point, as you say.

I could in principle add a function inside the parser that can be overridden to implement custom syntax, which is basically what you are doing manually there. I think I'll consider it for the next version (whenever that is) 😄

from markdownlabel.