Closed Hi-Angel closed 1 year ago
yes, I know
next-property-change
is called inscan-identifiers
too, but only ifre-search-forward
fails, which I don't think happens too often
Oh, btw, it may not be obvious from the code, so to make it clear: when scan-identifiers
checks a face at point and get nil
because face isn't set, it checks if identifier-faces
has nil
. And it does! As result, face-property check succeeds very often, so the execution skips a call to next-property-change
and goes further where a call to re-search-forward
resides.
This is mostly a refactoring task.
There are multiple bugs about wrong text being colorized, such as #40 or #62. Both #40 and #62 can be solved by making "scan-fn"
color-identifiers:cc-mode-get-declarations
(like in #93).cc-mode-get-declarations
andscan-identifiers
are similar in what they do, but the main difference is thatscan-identifiers
is called against almost every word, whereascc-mode-get-declarations
is only called on words that have properties set. In terms of code the difference is that the former mostly usesre-search-forward
to move through buffer, whereas the latter does that only withnext-property-change
. (yes, I knownext-property-change
is called inscan-identifiers
too, but only ifre-search-forward
fails, which I don't think happens too often).What I can gather from this difference is that these two functions have different usecases:
cc-mode-get-declarations
is used to find out declarations of identifiers, but not their usages in the textscan-identifiers
is used to find and highlight usages of identifiers in the text.With that said, I don't think using
scan-identifiers
as the defaultscan-fn
function is correct. More likely, thecc-mode-get-declarations
should be renamed to sound more generic, and be the defaultscan-fn
.