A propos better SyncTeX'ing...
Backwards search in TeX is inherently a badly posed problem. For example, if you ctrl-click on a word in the output title of a latex document,
should you be backwarded to the line containing the \maketitle command (the one that created the title) or the line containing the \title command (the one that defined the title). Both solutions are acceptable, none is universally better than the other.
That being said we must accept that backwards synchronization will only be satisfying as long as tex macros are not involved too deeply. In that case, here is what can be done
- À la TeXShop : when the user ctrl+clicks somewhere on the output, take ten characters to the left and ten to the right, then try to match this sequence of 21 characters in the source. Coupling with SyncTeX will solve ambiguities
- À la iTeXMac2: when the user ctrl+clicks somewhere on the output, take the word where the click occurred, take the two words before and the two words after. Then find those 5 words in the source, in that order. Of course there are in general many occurrences, you just state that the better ones are found when the words found in the source file span over the shortest interval. Coupling with SyncTeX will solve ambiguities too.
In fact, I used only words with 3+ letters in order to be significant and avoid the high frequency of shorter words. Sometimes we do not find the whole five words, but only 4 or 3. The important thing is that ambiguities are rare. In theory, we can show all the occurences found in the backwards search, but in practice this is sometimes unreadable and a bad UI design.
Whereas iTeXMac2 works far better than TeXShop, this technology won't work with foreign language due to accented letters, except when used with utf8 encoding and the proper font. However, you can circumvent this limitation by using the Levenshtein distance or some weak variant, at a possibly significant computing price.
Anyway, all this assumes that the output is somehow readable, which means that the output viewer must be sufficiently clever. The pdf reader on OS X is really cool since a long time for that purpose, and readers on other OS's start to implement more advanced stuff little by little.
On a completely different approach, SyncTeX ing would be improved if not only line numbers but column numbers were also recorded. Unfortunately, the TeX engine only uses line numbers. I have no precise idea of the amount of work necessary to implement column numbering in TeX, but my feeling is that it is beyond my possibilities (at least in time...). But SyncTeX is already supporting column numbering, that is a first step.