Suggestion to improve existing text-only highlighting features.

[Truncated]

I've been documenting the results of regular expressions in code blocks, so I've been pushing the highlighting by word feature. Overall, this works a treat, so thank you!

Three things I couldn't find but really wished I could do repeatedly. Maybe I missed them?

1. Highlight an entire line words only without the abc:xyz method.
2. Easily start the word highlight without tabs or spaces at the start. hl:1|:xyz will always highlight from the start of a line (^ in RegEx) at the word level.
3. Specify the end of the line without specific letters/word combos. No way to grab multiple lines by using :s or :en, as it only goes as far as the first match.

Without these three options, I found I needed to specify many lines of filtering to get all of the nuances at the word level.

To improve this experience, I would propose hlw: as an additional command that works exactly as hl does today but with these three key differences.

1. All highlighting is interpreted as word only; it never highlights lines as a result. hlw:1 would effectively be /^.*$/ for the 1st line in regex, for example.
2. If no value is provided to the left of a colon in abc:xyz eval,, it is interpreted as the first non-breaking space from the start of the string.
3. If no value is provided to the right of a colon in abc:xyz eval, it is interpreted as the end of the string (/$/).

Theoretically, this could also be applied to any custom alternative highlight colors by finding an extra w at the end of any custom defined names. i.e. If I added error and warn as alternative highlight colors, these rules above could be applied to those alternate highlight colors if use them as errorw:2,4-6 and warnw:2,4-6, respectively.

[mugiwara85]

1. Yeah, you can't do that currently. I haven't thought on this case.
2. and 3. I can add the cases where if nothing is specified before the : than that means it should start highlighting from where the text starts, and also when there is nothing specified after the : then it means highlighting to the end of the text.

I actually had the same thought as you (adding a w or 't' after the hl and every alternative highlight color) when I first added text highlighting, but I wasn't sure if it is a good choice. What do you think, if I change it now, would it be confusing? Theoretically the hl parameter could remain only for line highlighting, and hlw would mean text highlight. This would also mean, that I could remove the 'Highlight words instead of lines' option completely. But I am not sure if I change it now, how happy people would be about it, since it would mean then had to change it in every note where they used it :/

[Truncated]

As a user, I think the most versatile and logical approach would be to have three options for highlighting and eliminate the setting of Highlight words instead of lines completely as it's essentially manually implemented as below: hlm= (mixed - default) acts as it does today with Highlight words instead of lines enabled hll= (lines only) acts as it does today with Highlight words instead of lines disabled hlw= (words only) acts as it does today with Highlight words instead of lines enabled but with the three changes I suggested originally to aid in the finding specific characters and words .

Considerations:

• made all three commands three characters long to make the parsing simpler; no need to validate what might be 2 or 3 characters long instead.
• I'm not thrilled with two "L"s but it's too logical to ignore and no better word / letter came to mind. I then chose w instead of t because hll is bad enough without making the second option hlt... hlw is much easier to parse visually between them.
• Some way to find and replace in code block on lines that start with /(^```.* hl(:|=).*)/ based on whether the current global setting Highlight words instead of lines is enabled or disabled from /( hl)(:|=)/ to / hlm$2/ or / hll$2/ respectively would ease the change path for existing users? Make that optional, of course, so they can decide when it happens rather than just quietly doing that on first load. :)
• Depending on how hard it is to do this transition helper, it might bet better on existing users to go with hl, hll, hlwinstead of hlm, hll, hlw. That would at least limit the volume of impacted code blocks.

[mugiwara85]

I would leave the default hl parameter for line highlight, and also highlight lines if a specified word is found, so it remains compatible with the already existing documents. So for example: hl:5 -> highlights line 5 hl:5-7 -> highlights line 5 to 7 hl:test -> highlights line where the text contains test hl:5-7|test -> highlights line 5 to 7 if the line contains test

hlt would be reasonable for me (highlight text) for text highlight, and you could also define words, but if a word is defined here then it would highlight the text not the line. So: hlt:test -> highlights the word test if found hlt:5|test -> highlights the word test if found only on line 5 hlt:5-9|test -> highlights the word test if found only on lines 5 to 9 hlt:abc:xyz -> highlights text starting with abc and ending with xyz hlt:5-9|abc:xyz -> highlights text starting with abc and ending with xyz only on lines 5 to 9

I have to sleep over it. It would be really good to get other user opinions as well.

I think these two options would be enough to cover all the cases. I am not sure if three options are required.

[Truncated]

I dig it.

Additional logic for hlt? hlt:5 -> highlights all the words on line 5 (no starting spaces / tabs) hlt:abc: (space would be the gap between commands or a comma?) -> highlights all the words from abc the end of the line. hlt::xyz -> highlights all the words from the left (no starting spaces / tabs) to xyz.

One of the unique use cases for the hlt is to allow multiple lines of just text to be highlighted with partial values at the first and last lines. Especially since you can't choose which abc or xyz you match on (always the first from left to right), the level of specificity needed for some of these regex examples bloats quickly.

I think these two options would be enough to cover all the cases. I am not sure if three options are required.

I started with the three item idea just to make it 1:1 with the existing design (enabled / disabled) + what I was proposing.

Combing through the logic as you did, I think the two are pretty solid as you describe plus the details above.

[mugiwara85]

Sorry, not a native English speaker. What does "I dig it" mean?

I forgot to include these two cases, but I would include them as well of course: "hlt:abc: (space would be the gap between commands or a comma?) -> highlights all the words from abc the end of the line. hlt::xyz -> highlights all the words from the left (no starting spaces / tabs) to xyz."

And this one is really cool. I haven't thought about this, but I will do this as well: "hlt:5 -> highlights all the words on line 5 (no starting spaces / tabs)"

[Truncated]

Sorry, not a native English speaker. What does "I dig it" mean?

It means I understood, liked, and agreed with what you said.

[mugiwara85]

I thought it means something like that, but never heard it before. Thanks for the clarification!

[Truncated]

You're welcome! In American slang, it's pretty old and dated, I think. It's something my mom would say, so it stuck. :)