Tinderbox Forum

Highlighters: a practical guide to using the new capabilities in "Hints" please

Hi folks, is there a good video that gives a practical explanation of how to use highlighters in the “hints” template please? If possible, I’m looking for a step by step guide that takes nothing for granted and gives plenty of examples designed to guide non coders. Best wishes and thanks.

To answer that what exactly are you trying to do with highlighters (so nothing is taken for granted in the answer)? As most users use the same tools in the overall app toolbox differently, there isn’t a one-size-fits-all solution. But, have you read these notes on the highlighter feature? It includes code examples of all the features you can set. Obviously as we don’t know your usage, it is difficult, in advance to write an individually tailored example.

So, what did you try? Why not post a document showing what you tried and explaining what you thought would happen vs. what happened. That would be a faster.

Note that whilst the system highlights—according to the syntax you set—any matching terms, altering such text to no longer match doesn’t remove the RHF ‘highlight’ formatting. IOW, this methods adds RTF styling to a note but doesn’t remove it. It is not a dynamic highlight depending on a match or not.

The a highlighter can remove highlights, too. For example, consider this simplified version of the syntax highlighter:

pattern: :.+
    color: black

pattern: yes|no|bold|italic|strike|underline
    case-sensitive: NO
    color: bright red
   

This makes everything black, but then makes some keywords bright red.

I stand corrected! Up to a point though, because…

Can the ‘default’ color use $TextColor? Otherwise, if I set the $TextColor to a dark blue, highlight resetting will fail as non-matched items will be the wrong colour in the note, i.e. black as opposed to dark blue. Indeed if another note used green text…

This isn’t to quibble. For 99% I’m sure the method posted will work just fine, as it will if all notes use the same non-default text colour (remembering to set the ‘reset’ highlight to the desired colour instead of black.

I assume the pattern: :.+ must come first in the list of highlight rules otherwise it will reset everything as .+ matches _all $Text`.

I’ve made a note to document this as I don’t think this aspect is explained anywhere in detail.

I don’t think this case is accounted for. Yes, rules are interpreted sequentially.

In the default Syntax highlighter in hints I see this:

pattern: :.+

That second colon looks superfluous and makes no regex sense in terms of the task of this highlight rule. This seems to work as well:

pattern: .+

Interestingly, if the rules do run sequentially, e.g.:

Then anything coloured bright blue by the first pattern should immediately be reset to black by the second pattern. However, in a note using this built-in highlighter the word ‘strike’ is coloured bright blue and not black. Odd. As the OP wanted an ambiguity-free description I’m struggling. The highlighting seems to work as described.

Several other oddities:

  • It seems like you need to de-/re-select a note in order for changes to the highlighter code note to be reflected by the highlighting
  • I think re-setting is built-in but not via the pattern: :.+ & color: black pattern. I removed the latter from the built-in ‘syntax’ highlighter file. Un-highlighting of word that were changed still worked, resetting black (current $TextColor)
  • I turned off highlighting, set a notes $TextColor to red and reset the text (i.e. $Text is now ‘red’). I turned highlighting back on and items highlighted or re-coloured to red (i.e. $TextColor not black) when a word no longer matched a pattern. Adding back the removed pattern did no cause anything to turn black.

So, de-highlighting seems to be baked in (using $TextColor as base colour). Could be that the pattern:

pattern: :.+
    color: black

Is an artefact from early design that got left in the built-in file but actually has no purpose?

The second rule says, "Turn everything black except text before the colon. That preserves the coloring of pattern in rule 1.

Yes, all this is an artifact of earlier designs, but it may be useful.

1 Like

I’m storing my action code into external notes and use a rule to copy the $Text attribute into the $Edict of a target note. No problem with this setup.
Next thing: I created a highlighter for my action code notes:

pattern: var\s([^\s]+)
    color: yellow

pattern: $1
    color: poppy

pattern: abs|action|any|atan|attribute|attributeEncode|avg_if|avg|between|capitalize|ceil|collect_if|collect|Color|compositeFor|compositeWithName|contains|cos|count_if|count|covid|create|createAgent|Date|date|day|days|degrees|delete|descendedFrom|dictionary|Dictionary|distance|distanceTo|do|document|drivingTimeTo|else|escapeHTML|eval|every|exp|exportedString|find|first|firstWord|floor|format|hasLocalValue|hour|hours|idEncode|if|indented|inheritsFrom|inside|Interval|interval|isbn10|isbn13|isDuplicateName|jsonEncode|last|lastWord|linkedFrom|linkedTo|linkFrom|linkFromOriginal|linkPath |links|linkTo|linkToOriginal|List|locale|log|lowercase|max|min|minute|minutes|mod|month|months|neighbors|neighbors2|neighbors2Within|neighborsWithin|notify|Number|originalLinkedFrom|originalLinkedTo|play|pow|radians|rand|replace|rgb|round|runCommand|seconds|similarTo|sin|sort|sqrt|stamp|String|StyledString|substr|sum_if|sum|tan|time|time|twitter|type|unlinkFrom|unlinkFromOriginal|unlinkTo|unlinkToOriginal|uppercase|urlEncode|values|var|version|weeks|word|wordsRelatedTo|year|years
    color: bright blue
 
pattern: all|ancestors|children|descendants|siblings
    color: bright green
    
pattern: \"[^\"]*\"
    color: violet
    italic:  yes

pattern: \$[^\s^\n^\=^\(^\);\"]+
    color: bright red
    bold: yes

pattern: [\(\){}]
    color: dark red

Found my error - the indent before “color” is important. Missed that.
So only one question remains: can I use the back reference $1 to select the local variables after the declaration?

I have started to play around with the Highlighters feature to use it when writing notes in Markdown format.

To get the RegEx which is necessary right, I used the excellent “Pattern Playground” feature in BBEdit to construct two Highlighters for the moment, namely one highlighting Markdown citations and one for Markdown inline footnotes.

Since @Jasonromney asked for practical examples, I share them here. The code needs to go into an appropriately named note in the /Hints/Highlighters folder:

Citations:

pattern: \@(\w+)(\d{4})[a-z]?
    background: #fff2cc

Inline Footnotes:

pattern: \^\[(.+)\]
    background: #cfe2f3

If you are looking for the right hex code for colours, check out https://www.color-hex.com

Sadly, only one Highlighter can be used per note. Any way to change that, @eastgate, to allow several being used at the same time?

Interesting. Why are several needed?

To highlight e.g. both citations and inline footnotes?

But a highlight file can include multiple definitions. To use both in a single highlighter note, code like so:

pattern: \@(\w+)(\d{4})[a-z]?
    background: #fff2cc

pattern: \^\[(.+)\]
    background: #cfe2f3

More on highlighter syntax. In deed if you look at the highlighter notes in the default built-in /Hints/Highlighters/ container you will see both use multiple definitions.

Also, where does it say only one rule is allowed per highlighter as that source needs correcting.

In case aTbRef was in some way ambiguous I’ve just added this explicit description to the article on highlighter notes:

A highlighter note may contain multiple style declarations reflecting the fact that any given note can only apply a single highlighter.

1 Like

Good point, thank you, Mark! I was lacking precision in thought and writing (as so often :wink: )

So I should probably create a single Highlighter and name it something like “Markdown Text Elements” or some such like.

Sounds good. The longer the name, however human readable, the longer the name you need to remember and type correctly. I don’t think there are name limitations for the note but I’d avoid using any of the usual problematic characters: semi-colon, forward slash, parentheses, etc.

If experimenting, it might be useful to name something like “MD Text Elements 1”, so if you end up with variants, e.g. “MD Text Elements 2”, “MD Text Elements 3”, etc., you can easily change the highlighter by editing a single character.

Once in use, the value pop-up list (at right of selected row in Displayed Attributes or Get Info/attributes tables) can be used for selection. But, that only shows values in use. So whilst testing and likely only using a highlighter once in the doc the above idea may help.

1 Like