Highlighting a fragment

[jyhelle]

While I was re-reading something I wrote yesterday, I spotted some parts of the text that didn't please me while I couldn't yet find a better formulation.
In paper form I would have used my yellow highlighter to mark these parts for later correction. So I used the emphasis/italics, but I bet you'll guess my enhancement proposal : highlighting the text background to spot a given fragment.

Of course that brings other questions : one color or choice of several ? what to do at export time ?

It certainly isn't an urgent thing, more a wish than a request.

[vkbo]

Yes, I agree this would be useful. There is already a suggestion for something similar #352. This one proposes to use the html tag <mark> for this.

[vkbo]

I was playing around with some new code yesterday on this, and it got me thinking.

I don't think I will implement the equivalent of html's <mark> as proposed in #352. Partially because it isn't really standard anywhere other than in html, and I want novelWriter to primarily focus on Open Document as the export format now that I've written the odt generator code. Meaning that I want to tailor text features for odt files, not html.

In addition, highlighting text isn't really a core formatting feature for writing fiction. That said, highlighting can be a useful tool of the writing process as you say. It is in the spirit of allowing comments in the text as well.

In-line Annotations

The feature could be added as an in-line syntax. Say, just as a first idea, to allow comments at the end of a paragraph. Since the % symbol is the comment symbol, perhaps by use of a double percentage %%. Any text following the %% would be an in-line comment, and the affected paragraph could be highlighted, say with yellow. This would also be possible to include in the document viewer, and quite possibly in the Open Document export as comments as well using the commenting feature of the standard.

If I add a context menu entry that allows for selecting text and clicking "Add Comment" or something, I could also capture the location of the highlight and auto-generate a %% [5:10] Comment text here entry at the end of the same line, say if the user wanted to add a comment from character 5 to 10. This may be a bit clunky. I would have to implement it to get a real feel for it.

The benefit of this approach is that it makes it extremely easy and light-weight to handle by the syntax highlighter because it doesn't involve heavy regex parsing. I only need to check for the existence of the %% in the paragraph and only parse it if it exists. I would then add a background colour up to the %% mark and change text colour to the comment colour for the rest.

Annotations as Meta Data

The other alternative is to not have such annotations being part of the novel text at all, but meta data associated with the document. A sort of editor tool for your own review process. I could add it to the context menu, with a keyboard shortcut, and allow the user to annotate any piece of text. The data would be saved in an adjacent file with each document, or in a central annotations file. In either case, the address of the comment, in terms of start and end position in the editor, would be harder to tokenize and export since the tokenizer doesn't preserve character location within a document. It would need some location accounting or mapping feature, which could be prone to mistakes.

In general, the in-line approach is more fitting with the rest of the philosophy. But the latter is more sophisticated I guess.

What do you think @johnblommers?

[jyhelle]

I would definitely favor the inline model
And some day - far away in a remote galaxy - the %% flag might be augmented by a %%# or whatever to indicate this comment to be included in the final text as a footnote (or %%## for chapter notes, %%### for end notes ?), so that might link to #342

%%#[label] This one with a label ?

[vkbo]

For footnotes, I think it would be better to go with the kramdown syntax, which also allows for footnotes in the middle of a paragraph.

The limitation of the proposed in-line syntax here is that each paragraph or line would only allow for one comment.

[jyhelle]

a single comment per paragraph would be no problem for me as I merely see it as a reviewing tool, but it is important that we can decide to transfer them into the odt output file

if the footnotes have a different syntax, it will mainly be a cut and paste operation to eventually transform a comment into a note

[vkbo]

Ah, I see. You wanted to be able to convert a comment to a note. Hence the expanded syntax.

The benefit of the kramdown syntax for footnotes is that they can be collected in whatever file you want, if you want them out of the main text docs. They would work pretty much like the current tags do, just that you can insert them into the middle of the text.

[jyhelle]

most of the comments I add when reviewing have to do with my writing, and they simply disappear after the text has been amended or clarified, but those that eventually remain most often become notes for the reader.
so that would not be a problem to pick them and store them somewhere else, especially since they often have to be reworded to become an actual note

[vkbo]

While I haven't set these ideas aside, I am starting to think I may want to take the editor in a more rich text direction and away from Markdown. There are numerous limitations to keeping it as it is when people seem to want a different experience. This also includes myself.

I have been experimenting with ways to make the editor handle a limited set of rich text formatting while still being able to save the content of the editor to a plain text file. The obvious solution is to use HTML, but HTML gets really verbose so I've actually worked on a simplified format that is more like the one Open Document uses, just with plain text codes instead of XML. The format I'm working on saves a paragraph as a single line with a set of paragraph formatting tags in square brackets ahead of the text, and any bold/italic/etc formatting in span tags around the relevant regions. This makes it possible to extend the format to allow for nearly any feature that the editor itself can handle.

I'm working on all of this in a different repository, using C++ and Qt6. I may just make this an entirely different editor, or I may incorporate some of the features in novelWriter. The other project is named Collett. I'm experimenting with it as a way to test out some of the suggestions that have come up during the lifetime of novelWriter, for instance feature suggestion #102 by @johnblommers.

[marek-lach]

Markdown-inspired syntax doesn't need to be abandoned for this, see these syntax possibilities, for example. Thus, wrapping a passage of text in square brackets [], like [this entire text is highlighted in yellow] while what is outside of the square brackets uses the normal black, or white font color could render the wrapped text to be specifically colored/highlighted. For example in yellow, or something like that... as one possibility.

Update: Upon yet further research, some claim that two equal signs from each side, like ==some highlighted text== are used for highlighting a text in between by certain extended Markdown preprocessors. As such, this may thus be the most widely adopted Markdown syntax specifically for the purpose of a highlight, that exists in practice. Such syntax is for example recognized by iA Writer, as well as Zettlr and others.

[vkbo]

I'm making this a part of the Editor Shortcodes feature in #1541.

[vkbo]

With the shortcodes feature in place, I think it's time to propose a syntax for using them. Here's my current thinking, but feel free to add ideas.

For default highlighting, I was thinking something like.

Some text with [h]a part of it highlighted[/h] in the middle.

For alternative colours, I propose the option to define a standard set of named highlight colours in the different syntax themes. I definitely don't want to pull all the 140 named colours in browser, but perhaps the base colours at least. Then we could use the following syntax:

Some text with [h:green]a part of it highlighted in green[/h] in the middle.

I can also allow a HTML/CSS colour code in there.

I don't want to go completely overboard with options, so I propose to pick a set of sensible named colours. As mentioned, in the editor the syntax theme decides what they look like, and in the outputs, like HTML and ODT, I will define a standard set that works on white backgrounds based on the official CSS colours mentioned above.