On Fri, 19 Aug 2011 18:10:42 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
I'm trying to address bug 3386129 [1], and I'd like comments & reviews about my fix, because the whole thing don't look obvious at all...
We already have 2 ways of determining what a "word" is: a manual one using GEANY_WORDCHARS or a caller-given list of wordchars, and one that uses Scintilla's word boundaries.
3? Shoudn't we have symbolchars for the current programming language ([A-Za-z_] if unknown), and wordchars that match the current locale? They don't have much in common.
The former seems to make more sense when the caller code knows the kind of characters it wants (e.g. tags lookups), but the latter is better when getting the word to search for.
Looks like symbolchars and wordchars to me; when writing 3rd party software for a specific country, or using Geany as a text editor, it's common to search for locale words.
Actually if we do a whole word search we *need* to get what Scintilla sees as a "word" since we leave the search to it (see bug report for a example of what's going wrong otherwise).
There is always a SCI_SETWORDCHARS... Hmmm, we even use it to set the sci wordchars to the filetype wordchars if we don't know the exact lexer or something? Well, I guess it's really non-trivial.
So in the attached patch, I added a alternative way to get the the current word (that uses the same algorithm as the word selection) and tries to use it whenever the word was fetched for a search.
Makes sense to me. Though I'm not sure about that SCI_SETWORDCHARS we use in highlighting:styleset_common().
I'd appreciate reviews & comments :)
+ guint start; + guint end;
We always use gint for positions. Nothing else suspicious, at least from a first sight.