Custom syntax?
Hello!
I was wondering how hard it would be for me to add my own custom syntax? Such as;
?[variableToQuery](Text to display if the variable is true, or that the function that takes that string and looks it up in a dictionary of tags.)
I suspect that I would need to fork, and edit somewhere in this space? :(
# Images
var img_pattern := "\\!\\[(.*?)\\]\\((.*?)\\)"
Im just looking around for methods to create variable text without creating a parser from scratch myself 😅
Many thanks - Gene
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?
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
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) 😄