I’m working on a project in which I store emails from people who suffering from tinnitus to get more insight in the problems they are dealing with.
The mails are copied into tinderbox and processed. One process is searching the text for specific keywords, Extract them to an attribute called ‘$Trefwoord’ and then make them bold text in the note.
The variable “vTrefwoorden” is the content of the note with the Name “Trefwoorden”
This code worked well until begin April and the extracting part still does. But the part where the text in the note is replaced with bold text stopped working and I can’t figure out why.
When I change the ‘making bold’ part into: $Text=$Text.replace(trefwoord,uppercase(trefwoord)) it works like a charm but I prefer the bold text because its stands out more.
Confirmed. This won’t work at present, because the replacement string in .replace takes the characteristics of the text it replaces. The old behavior was bad in some other contexts, but the change is unfortunate here.
Have you considered using a highlighter for this task? Paging @satikusala , the number one highlighter fan!
The fix isn’t trivial, alas; I’m pondering ways and means.
I’ve never used the .bold operator, which is interesting. I prefer to use syntax highlighting, markdown, or HTML to manage appearances, as I find this method easier to unwind later.
As @eastgate notes, I prefer using the highlighting syntax in cases like this because 1) I can match on more patterns than just words, e.g,., I can use regex to help with the matching, and 2) I can have the pattern match do multiple things, e.g., bold, color change, highlights, etc.
@satikusala: Indeed, your solution works like a charm and there are more possibilities now.
A few questions if i may…
I’ve noticed that the words in ‘pattern’ are case sensitive. Is there a way to bypass that? If not is there a limit on the keywords used in a pattern?
Also, I use a large amount of keywords which I have written in a note. The $Text of that note is used in a variable: (var:set vTrefwoorden = $Text("Trefwoorden");). Is this possible with SyntaxHighlighting? Otherwise i have to maintain 2 lists of keywords. Not a big problem but I’d rather use one list.
I’ve noticed that the color of the highlighted word turns black when exported to html. For now I don’t need the color in the exported file but 'm just curious. if is possible to keep the color
Thanks again for your help.
Jan
Edit: Already found the solution for 1. Case sensitivity
‘Bypass’ is perhaps the wrong concept. as there ‘pattern’ is a regular expression. However, as far as I know, the pattern syntax doesn’t have a case-insensitive per-pattern qualifier.
Good, I was travelling when I wrote the above. Of the two specimen highlighter notes added as part of the default /Hints container, the ‘Syntax’ example does use the case-sensitive syntax—as you quote above.
I do document all the known ‘rule’ codes at Highlighters in aTbRef.
For the highlighter rules themselves (and for boolean, i.e. yes/no values) it is not recorded if these are case sensitive. In such circumstances, I follow the examples and follow their use of case (i.e. rules and boolean values are lowercase). IOW assume all are lowercase and case-sensitive. For string values (for pattern), obviously varying case may be needed and thus the case-sensitive rule. If anyone has tested more deeply re case of the rule codes, do let me know and i’ll add any necessary notes to my article.
In checking this I’ve noted an ambiguity in this description:
The first line of a highlighting rule must not be indented; additional lines for each rule must be indented. Empty lines may be added between rules for clarity.
Essentially, each discrete ‘patten’ within the highlighter note starts with the word pattern—as such notes can contain one or more patterns. Any modifying rules for a pattern , e.g. case=sensitive, follow their patter on a new line immediately after the pattern line and the modifier rules are indented. This can be one (or more) spaces or tabes. The built-in examples use 4 spaces, but I’ve just tasted and a single space or a single tab works to correctly mark such lines as pattern modifiers for the preceding rule.
There is no requirement to place blank lines between discrete patterns within a single note as the presence of a rule starting a new line, indicates a new rule. However, I think it makes sense to place a blank line between rules, if only to help your future self when trying to understand your own rules at a later date! I’ll update aTbRef with this in due course.
I’m not quite clear. As far as I know, the user can’t modify the syntax highlighting using in action code boxes in the Inspector (e.g. rules, edicts, etc.) or in notes using the builtin-in ‘Action’ prototype such as stamp or library notes.
It is undocumented if you can use custom highlighting in an ‘Action’-prototyped note, but my experiments just now suggest not. Here, an ordinary note capturing ‘vTerfworden’ with/without the ‘v’ and case-insensitive:
I think both highlighters are run but the built-in one wins out so the custom one has no effect. FWIW, the action code syntax checker does not colour variable names. this makes sense as it is doing a regex check, not parsing the code to find things like variable names (like their name—variable!) and then re-check for those names.
I’m unclear however, why two lists of keywords are needed.
HTML export has never exported $Text colour, so i’d not expect it export dynamically-set syntax-colouring either. So I guess your use case would be a feature request at this point.
Thank you very much for your extensive explanation!
I need one list for autoselecting the keywords from text to a attribute ($Trefwoorden). Now that the action code for bolding the selected text does not work anymore I need to maintain a second list in the Highlight syntax.
Not a big deal but preferably not.
Nice and very helpful. I was not familiar with this feature so I missed it when developing my first code.
Reflecting this thread and some recent tests I’ve re-written/updated my aTbRef article on Highlighters to clarify some of the points.
@jmesenig’s question #3 above is answered, in that rule-based styling, such as a text colour, is applied to the applied to the styled text (RTFD) stored data for a note’s text, but HTML export only exports the ^text^ render of the plain text note—that essentially supports only bold/italic/underline styling of $Text content. To export coloured text, the differently coloured text would need an inline <span> tag enclosing said text and use a class attribute to set a text colour via CSS.
A highlighter couldn’t insert such inline mark-up but .replace() could. This offers an ugly kludge for export. In the export template, replace ^text^ by:
adding an ^action()^ code at the very start of the template. Inside this section:
Create a string variable to hold some output, e.g. var:string vText;
Set the vText variable to call the current note using exportedString() and using a template whose only code is ^text^. The value of vText is now the normal ^text^ (HTML) export data for this note, stored so we can now add extra HTML code for coloured text.
Now iterate through your text colouring rules (bold/italic are already in the HTML), and set the <span> tags accordingly. So, if the word ‘tinnitus’ is to be in bright red, you can use vText.replace() to replace occurrences of tinnitus with <span class="brightred">tinnitus</span>.
N.B. for each CSS class you define, e.g. CSS class .brightred above, ensure your overall export defines the class .brightred with/including a color:#FF0000; value in the template—or in a CSS file referenced by the exported page.
in the main template, were you normally insert ^text^ you must now insert the value of your variable, e.g. ^value(vText)^, thus getting the default HTML export with the additional text-colouring HTML <span>s.
To be clear, I’m not advocating the above as it is an ugly workaround (and not fully tested!). But it is possible if you really need exported text colouring. Indeed, by colouring, you could also capture RTF text (background) highlighting. However, do not try this where different text colour/background effects overlap as you have to consider how the HTML rendering of the <span> elements works.
