Using nedit-ng to read .md files

[ericxuo]

Hi,

Does anybody have the .config/nedit-ng/config.ini contents for nedit-ng to interpret markdown (.md) files ?

Regards.

Xuo.

[eteran]

I assume you are looking for syntax highlighting rules?

[anjohnson]

I have a set of recognition patterns that I developed for highlighting GitHub Flavored Markdown. They work for me and I'm happy to share them (and accept improvements), but I don't claim they're complete or even fully correct.

@eteran What's the easiest/recommended way to export and import a set of syntax highlighting patterns? It looks like there's a short entry in the languages.yaml file, with most of the details in patterns.yaml file. Is it just manually copy & paste from/to those files?

[ericxuo]

Hello,

Yes, I am looking for syntax highlighting. And if you can copy/paste something, it would be great.
I greped for "verilog" in my .config/.nedit-ng directory and the following files have this pattern :

• languages.yaml
• macros.yaml
• patterns.yaml

I guess the same would have the 'markdown" keyword.

Thank you.

Xuo.

[eteran]

@anjohnson so the current answer is just copy and paste from those two files and manually copy them.

I do have a plan to improve this going forward, but just haven't gotten around to it. Basically I plan to have a new .config/nedit-ng/languages directory where each language and its associated syntax would be its own file. Something like:

01-Markdown.yaml

(The number is so we can control load ordering).

The plan is that it'll load the directory on start and when you save, it will literally replace the entire language directory with what it knows. (Which is functionally similar to how config files just get replaced on write).

So that's the plan, I just need to get around to actually implementing it :-).

Once we have that, it'll just be a matter of copying the file from one machine to another.

[ericxuo]

Hi,

Any file to share with me ?

Regards.

Xuo.

[anjohnson]

Sorry, I got busy. This is the languages.yaml section:

name: Markdown - github
extensions:
  - .md
wrap: Continuous
indent: Auto
---

This is from patterns.yaml:

Markdown - github:
  line_context: 1
  char_context: 0
  patterns:
    - name: Ruler
      style: Flag
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: ^-{4,}$
    - name: Heading
      style: Keyword
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: ^#+(.*)$
    - name: "**Bold**"
      style: Bold
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: \*\*[^*]+\*\*
    - name: __Bold__
      style: Bold
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: __[^_]+__
    - name: Bullet
      style: Keyword
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: ^\s*[-+*]\s
    - name: Numbered List
      style: Keyword
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: ^\s*\d+\.
    - name: Fenced Code
      style: Character Const
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: ^```.*$
      regex_end: ^```$
    - name: Indented Code
      style: Character Const
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: ^\n\s{4,}
      regex_end: \n$
    - name: Inline Code
      style: Character Const
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: "`[^`]+`"
    - name: Blockquote
      style: Preprocessor1
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: ^\> .*$
    - name: Link
      style: Preprocessor1
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: \[[^]]+\]\([^)]+\)
    - name: Link in **Bold**
      style: Text Arg
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      parent: "**Bold**"
      regex_start: \[[^]]+\]\([^)]+\)
    - name: Inline Code in **Bold**
      style: Identifier
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      parent: "**Bold**"
      regex_start: "`[^`]+`"
    - name: Italic
      style: Italic
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: (<_(?!_).*?(?<!_)_>)|((?<!\*)\*<.*?>\*(?!\*))
    - name: Bold in Italic
      style: Bold Italic
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      parent: Italic
      regex_start: (<__.*?__>)|(\*\*<.*?>\*\*)
    - name: Italic in **Bold**
      style: Bold Italic
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      parent: "**Bold**"
      regex_start: (<_(?!_).*?(?<!_)_>)|((?<!\*)\*<.*?>\*(?!\*))
    - name: HTML Comment
      style: String1
      defer_parsing: false
      color_only: false
      parse_subpatterns_from_start: false
      regex_start: \<!--
      regex_end: --\>

I didn't write any macros for this.

[ericxuo]

Hello,

Thank you for the files. It is working fine now. I just had to define the "italic" and "Bold italic" styles.
Now, my .md files are easier to read.

Thanks again.

Xuo.

[anjohnson]

@eteran That's an interesting issue that @ericxuo hit, I forgot that I had added some extra text styles for my Markdown language definition. Relying on a common set of visual styles that all rules have to pick from seems rather clunky and brittle, IMHO that's an area that could be improved while you're working on exportability — language patterns may need to be associated with the visual styles they use.

The names for some of the existing styles are language-specific, but they are probably used for other things in other languages. Also finding a style that looks appropriate for a new pattern is usually trial-and-error, which is less that optimal.

[eteran]

Yeah, the common styles thing is interesting for sure.

I think it's pretty common though...

If we look at QT creator, it also has a concept of shared styles that syntax highlighters reference.

Now, what those styles are called and what they refer to... Maybe that should be refactored a lot. I'll think on it.