orbitalquark / textadept

Textadept is a fast, minimalist, and remarkably extensible cross-platform text editor for programmers.
https://orbitalquark.github.io/textadept
MIT License
653 stars 39 forks source link

Is it possible to show syntax highlighting in markdown's code block? #384

Closed jackusay closed 1 month ago

jackusay commented 1 year ago

run in win7

syntax highlighting in markdown's code block

current textadept: 2023-03-22 20_49_25-New chat 2023-03-14T22_13_06 291Z md _ Textadept (C__Users_eight_Downloads_New f

Is it possible like VScode? : 2023-03-22 20_49_09-● # New chat 2023-03-14T22_13_06 291Z • Untitled-1 - workspace (Workspace) - Vis

or I ask too much :/

ref: https://github.com/Edditoria/markdown-plus-plus/issues/69


I also find out find function doesn't hightlighting the keywork

2023-03-22 21_02_26-New chat 2023-03-14T22_13_06 291Z md _ Textadept (C__Users_eight_Downloads_New f

orbitalquark commented 1 year ago

It is possible to have syntax highlighting for languages inside markdown blocks, but it would require changes to the Markdown lexer to embed JavaScript.

"Find" not appearing to highlight 'var' is due to the theme: the code block background color matches the selection background color. The upcoming Textadept 12 themes do not have this issue.

rgieseke commented 1 year ago

It is possible to have syntax highlighting for languages inside markdown blocks, but it would require changes to the Markdown lexer to embed JavaScript.

Would it be possible to lex arbitrary embedded code?

The pattern can be any language (likely not mapping 100% to Textadept lexer names from GitHub flavored Markdown or whatever that is), so the language name or extension after the backticks.

orbitalquark commented 1 year ago

No, it would not be possible to do that. You'd either run out of styles or the LPeg pattern would grow too complex to create successfully.

oOosys commented 1 year ago

@rgieseke :

Would it be possible to lex arbitrary embedded code?

Sure ... in the world of programming as good as anything you can think of is possible ... but ... it would probably need another concept of a view on a buffer splitting the buffer into multiple buffers and then showing them next to each other in separate split views stick together within the host view.

Feel free to contribute a "multi-language mode" to Textadept making it possible to execute the code of the blocks having the focus (i.e. the caret in them).

If you need inspiration just start Emacs and see how it is done there ... it's a separate mode with own markup rules - from my point of view a bit complicated with reserved output area within the code - in my eyes not the best approach (just evil ...). The Visual Studio way following the overall accepted rules of stackoverflow/github markup with js ... the JavaScript code block py Python script code block, etc. seems to be a nice way to prescribe the markup rule required to accomplish this and would turn Textadept into a kind of universal multi-programming-language editor and viewer, but ... it will probably require comparable amount of code as there is already there. Look at the download sizes and compare them ... This will turn Textadept into Textadept+ and refrain from the requirement of of relatively small code base size.

The question would be: "Does it make sense?" ... I personally think it doesn't ... Just because it will start to support the already unhealthy run into higher and higher levels of abstraction trying to cover all possible options. Just take a look at Kate (have you tried to compile it from source on a non-KDE Desktop with not installed KDE-development tools? This requires appr. in first step one GigaByte of downloads ...) ... an overkill ... the same with Visual Studio. They are slower and lack immediate user input response and overwhelm with myriads of possibilities you won't need in case of having a clear concept of what is needed to achieve in first place.

orbitalquark commented 1 month ago

I'm going to close this, as the markdown lexer needs another refactor anyway, and I don't have plans to try and get arbitrary language lexing working in it for the reasons stated earlier. I will keep it in mind for the refactor though.