Not spell-checking org's CAPTION

[DamienCassou]

Given the following org content:

#+CAPTION: This should be spell-checked
#+RESULTS:
[[file:./some-picture.png]]

which shows a picture and a caption, I would expect the caption to be spell-checked. Unfortunately, the face used by org-mode is org-block (this doesn't make sense to me) which is ignored by jinx.

Could jinx include a workaround? Maybe through a new jinx-include-regexps?

[minad]

Thanks for the report.

Unfortunately, the face used by org-mode is org-block (this doesn't make sense to me) which is ignored by jinx.

I don't have a simple solution for this problem honestly. One can maybe remove the org-block face from the exclusion list and instead use a separate predicate function to detect Org blocks. Quite heavy machinery for such a small issue if you ask me.

However I think Org should not use the org-block face for the caption. I guess we agree that this face seems quite out of place? Would you like to create an Org bug report?

Could jinx include a workaround? Maybe through a new jinx-include-regexps?

No, I usually don't include workarounds in my packages as long as a better fix can be applied upstream, such that the overall package ecosystem gets better. FWIW I also consider this a minor issue and the workaround would be way more heavy than an upstream fix.

[DamienCassou]

I guess we agree that this face seems quite out of place? Would you like to create an Org bug report?

Done, with a patch: https://list.orgmode.org/87le6q5ip9.fsf@cassou.me/T/#u.

No, I usually don't include workarounds in my packages as long as a better fix can be applied upstream

I understand your position. My point about jinx-include-regexps would not be a workaround but would make jinx customization options more "symmetrical" because of the already existing jinx-exlude-regexps, jinx-include-faces and jinx-exclude-faces. I guess this can wait until you see more use cases for this new option.

[minad]

Done, with a patch: https://list.orgmode.org/87le6q5ip9.fsf@cassou.me/T/#u.

Thanks. This looks good.

My point about jinx-include-regexps would not be a workaround but would make jinx customization options more "symmetrical" because of the already existing jinx-exlude-regexps, jinx-include-faces and jinx-exclude-faces. I guess this can wait until you see more use cases for this new option.

I see.

I don't think your symmetry argument would hold though, since jinx-(ex|in)clude-faces would be symmetric to jinx-(ex|in)clude-regexps. What you are asking here is different. You want the include regexps to override the face exclusion mechanism, in other words, a coupling of the regexp and face exclusion mechanism, something which does not exist yet.

In any case before we add something, we would need more use cases.