This is for adding the plumbing necessary to support multiple syntax highlighters in the (plain text) editor, if that support doesn't already exist (I don't see any evidence of it).
-1 It is NOT the scope of writer! there are already a few extensions that provide syntax highlighting, so we don’t need a builtin feature! There are enough Tools which provides proper Syntaxhightlighting… so why reinventing the wheel?
(In reply to Werner Tietz from comment #2) > -1 > > It is NOT the scope of writer! > there are already a few extensions that provide syntax highlighting, so we > don’t need a builtin feature! > > There are enough Tools which provides proper Syntaxhightlighting… so why > reinventing the wheel? Provide an example. I was of the impression, per https://ask.libreoffice.org/t/does-syntax-highlighting-exist-as-a-feature/103940/4, that such extensions' scopes were limited to advanced file formats (like DOCX and ODT, etcetera) and in limited fashions (custom text boxes) rather than for all text, especially plain text.
-1 from my side. I used this extension https://extensions.libreoffice.org/en/extensions/show/5814 when I have formatted my latest book about programming
The function should be covered with the macro. You can also use the code editors. On Linux/KDE the text editor is Kate, having a powerful highlighting features. Use "Copy as HTML" and paste the snippet into Writer. Or just copy/paste from Visual Studio.
(In reply to Heiko Tietze from comment #5) Do you all agree consequently that we should resolve the linked issues as WONTFIX too? 1. https://bugs.documentfoundation.org/show_bug.cgi?id=43089#c0 2. https://bugs.documentfoundation.org/show_bug.cgi?id=97638#c0 3. https://bugs.documentfoundation.org/show_bug.cgi?id=160360#c0 Without a shared codebase for syntax highlighting support between them, they seem like they would become disparate nightmares for any maintainer, and be unnecessarily difficult to implement.
(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #6) > Do you all agree consequently... > Bug 43089 - Syntax highlighting for Math I don't see highlighting of a particular bracket as syntax. => WF > Bug 97638 - Beanshell Editor: Add syntax highlighting Sure, Beanshell is a macro language with a strong syntax, http://www.beanshell.org/manual/syntax.html > Bug 160360 - Syntax Highlighting for Markdown I don't fully understand this idea but if you expect a Writer text to be saved as or loaded from md my take here is also WF.
(In reply to Heiko Tietze from comment #7) > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #6) > > Do you all agree consequently... > > > Bug 43089 - Syntax highlighting for Math > I don't see highlighting of a particular bracket as syntax. => WF What else do you suppose it is? To my knowledge, punctuation is syntax, and colouration of punctuation is the purview of a syntax highlighter consequently. > > Bug 97638 - Beanshell Editor: Add syntax highlighting > Sure, Beanshell is a macro language with a strong syntax, > http://www.beanshell.org/manual/syntax.html In which case, because this issue is WF, why is that not marked so? > > Bug 160360 - Syntax Highlighting for Markdown > I don't fully understand this idea but if you expect a Writer text to be > saved as or loaded from md my take here is also WF. That's not what it requests, although in this case, it's actually somewhat subjective: Because text/markdown is text/, it means that it's - for LO's purposes, except this request - equivalent to /plain. Consequently, if *this* issue had not been resolved as WF, extending the syntax highlighter to /markdown would have been feasible and desired due to significant community interest.
(In reply to `{3rd: "Beedell", 1st: "Roke"}`{.JSON5} from comment #8) > Consequently, if *this* issue had not been resolved as WF... No need to be the wisenheimer ;-). The request is clear and desirable: You want to prepare a publication that contains code snippets, for example. Your proposal is to enhance the office suite by syntax highlighting capabilities, while I believe this is better done per macro or copy/paste. Applying a bunch of PS/CS to a section is like <PS1<CS1>void</CS1> main<CS2>(</CS2><CS2>)</CS2> <CS3>{</CS3></PS1> <PS2>printf(<CS4>"LibreOffice rocks"</CS4>);</PS2> <PS1><CS3>}</CS3></PS1> comes on top of plain text editing (see also comment 1 and comment 4). And I'm not against a macro / wizard as build-in solution. And I could imagine to have another OLE object "LibreOffice Basic" (with a way more flexible syntax). If you still think this is needed, feel free to reopen the ticket. Your opinion is as relevant as anyone else's.
(In reply to Heiko Tietze from comment #9) > The request is clear and desirable: You want to prepare a publication that > contains code snippets, for example. Your proposal is to enhance the office > suite by syntax highlighting capabilities, while I believe this is better > done per macro or copy/paste. Applying a bunch of PS/CS to a section is like > > <PS1<CS1>void</CS1> main<CS2>(</CS2><CS2>)</CS2> <CS3>{</CS3></PS1> > <PS2>printf(<CS4>"LibreOffice rocks"</CS4>);</PS2> > <PS1><CS3>}</CS3></PS1> > > comes on top of plain text editing (see also comment 1 and comment 4). > > And I'm not against a macro / wizard as build-in solution. And I could > imagine to have another OLE object "LibreOffice Basic" (with a way more > flexible syntax). I believe that I see why your opinion differs now - it appears that you expect this feature to be a formatting aid for a potential *reader*, whereas I desire it so that life might be easier for myself when *writing* such markup. Am I correct? Note that I'm unfamiliar with that specific syntax - I've never seen XML-style markup being rendered inside LO. > If you still think this is needed, feel free to reopen the ticket. Your > opinion is as relevant as anyone else's. Thank you. I would rather it be open because it would simplify architecturally the implementation of quite a few FRs, but I don't believe I can implement it myself. Is it still acceptable to reopen it in that case?
(In reply to `{3rd: "Beedell", 1st: "Roke"}`{.JSON5} from comment #10) > Is it still acceptable to reopen it in that case? You don't need to be a developer to request features. Yes, reopen and find support for the idea. And vice versa ;-)
Still clearly wontfix material. Putting to unconfirmed.
(In reply to Buovjaga from comment #12) > Still clearly wontfix material. Putting to unconfirmed. Apologies. Meant to set it as that.
Syntax highlight is not core to ODF and ODT Text document (nor any other ODF module). The "Code Highlighter 2" extension [1] noted in comment 4 seems rather functional to this workflow, yet OP has not commented on its utility. -1 and => WF as enhancement to core, defer to extension.
(In reply to V Stuart Foote from comment #14) > Syntax highlight is not core to ODF and ODT Text document (nor any other ODF > module). > > The "Code Highlighter 2" extension [1] noted in comment 4 seems rather > functional to this workflow, yet OP has not commented on its utility. > > -1 and => WF as enhancement to core, defer to extension. I created this issue expecting that it would be able to provide syntax highlighting to plain-text areas (like the toolbar in Calc) and plain text files in LO. I didn't even consider that use case - colourising snippets in abstracted document formats (ODT and DOCX) - although in retrospect, it's not a bad use case either.
(In reply to `{3rd: "Beedell", 1st: "Roke"}`{.JSON5} from comment #15) > (In reply to V Stuart Foote from comment #14) > > Syntax highlight is not core to ODF and ODT Text document (nor any other ODF > > module). > > > > The "Code Highlighter 2" extension [1] noted in comment 4 seems rather > > functional to this workflow, yet OP has not commented on its utility. > > > > -1 and => WF as enhancement to core, defer to extension. > > I created this issue expecting that it would be able to provide syntax > highlighting to plain-text areas (like the toolbar in Calc) and plain text > files in LO. I didn't even consider that use case - colourising snippets in > abstracted document formats (ODT and DOCX) - although in retrospect, it's > not a bad use case either. Plain text files in Writer do not exist. Imported text files are converted into the internal document model of Writer just like everything else.
(In reply to Buovjaga from comment #16) > (In reply to `{3rd: "Beedell", 1st: "Roke"}`{.JSON5} from comment #15) > > (In reply to V Stuart Foote from comment #14) > > > Syntax highlight is not core to ODF and ODT Text document (nor any other ODF > > > module). > > > > > > The "Code Highlighter 2" extension [1] noted in comment 4 seems rather > > > functional to this workflow, yet OP has not commented on its utility. > > > > > > -1 and => WF as enhancement to core, defer to extension. > > > > I created this issue expecting that it would be able to provide syntax > > highlighting to plain-text areas (like the toolbar in Calc) and plain text > > files in LO. I didn't even consider that use case - colourising snippets in > > abstracted document formats (ODT and DOCX) - although in retrospect, it's > > not a bad use case either. > > Plain text files in Writer do not exist. Imported text files are converted > into the internal document model of Writer just like everything else. I wasn't aware. In that case, I suppose it doesn't have much worth. I've posted at https://ask.libreoffice.org/t/does-lo-restrict-what-it-does-to-non-odt-docx-files-until-the-user-is-warned/108592?u=rokejulianlockhart about this - thanks for informing me.
(In reply to Buovjaga from comment #12) > Still clearly wontfix material. Putting to unconfirmed. (In reply to V Stuart Foote from comment #14) > -1 and => WF as enhancement to core, defer to extension. Let's keep it as "honey pot" for similar requests. I mean the use case is not too far fetched and I can imagine to ship a macro/wizard (and make this one shiny).
As there is already an extension for this niche need, why should it be implemented in core?
This request, asking to make a dynamic syntax highlight (presuming that Writer is a proper plain text / code editor), is a wontfix. No need for honeypots (or rather, any other duplicates are welcome to be closed as dupes of this closed one), until we decide to change Writer to an IDE. An idea to syntax-highlight parts of text statically, for presentation as part of a normal text document, is not what this request was, and is irrelevant here.
Note that bug 43089 "Syntax highlighting for Math" and bug 97638 "Beanshell Editor: Add syntax highlighting" are completely different, and are valid requests: for Math, the user actually enters codes, and gets the representation in a different window (there is a way to work right there in the graphic area, but that request is about text of the formula markup). For Beanshell, there is a dedicated editor, like Basic IDE (just much worse), and in a code editor, it's OK. Both are unrelated to Writer.
(In reply to Mike Kaganski from comment #21) > Note that bug 43089 "Syntax highlighting for Math" and bug 97638 "Beanshell > Editor: Add syntax highlighting" are completely different, and are valid > requests: for Math, the user actually enters codes, and gets the > representation in a different window (there is a way to work right there in > the graphic area, but that request is about text of the formula markup). For > Beanshell, there is a dedicated editor, like Basic IDE (just much worse), > and in a code editor, it's OK. Both are unrelated to Writer. This FR wasn't solely related to Writer. I should have scoped it better, but I only thought it would have worth if there were also a desire to implement generic syntax highlighting in Writer. If, in the future, there become enough niche use cases for a more comprehensive implementation (like the dedicated Beanshell and Math editors, thus far) don't hesitate to utilize this issue to track that, if it has worth in that case.