👍

I would model this (the naming and impl) off of Roslyn's GetTouchingToken and GetTouchingWord functions:

http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis.Workspaces/Shared/Extensions/CommonSyntaxTreeExtensions.cs,cc1428a84e6b2e48
http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis.Workspaces/Shared/Extensions/CommonSyntaxTreeExtensions.cs,ceb10becddb03c3f

THe difference is that features then use helpers like GetTouchingWord, and that function passes in the appropriate predicate to GetTouchingToken. That way you don't need every feature to have to define an entire set of tokens it cares about.

1. I'm ok with renaming getTokenAtPosition to getTouchingToken (though personally I found former option more intuitive).
2. I don't see why it is bad if feature defines its specific set of tokens given that now this set is feature specific and mostly don't intersect. Since we don't have established definition of word - name getTouchingWord does not tell us what exactly should be returned and people still need to peek to the implementation to discover what was meant by word. One exclusion when predicate is undefined - and we can introduce helper getTouchingTokenExcludingEndPosition for this case (name is can definitely be changed)

'Word' is the union of 'Identifier' and 'Keyword'. i.e. all the things that are words in a language like english. This is a distinct concept from things like 'string' or 'number' or 'punctuation' or 'operator'. Effectively 'words' are the alphanumeric string sequences.

It's not bad per-se for features to identify the list of tokesn they care about. However, i am concerned about things like brittleness, as well as the fact that many features will end up using the same set.

For example, goto-def and quick-info will need the same set. So will highlight-references. This means maintaining several duplicate lists.

"One exclusion when predicate is undefined - and we can introduce helper getTouchingTokenExcludingEndPosition for this case (name is can definitely be changed)"

Isn't this just FindToken ?

AFAIR we do support gotoDef on numeric\string literals used in indexers and those ones are not words. Instead of "word" we can use "name" but getTouchingName does not sound like a very descriptive function name (but maybe for a native speaker it makes more sense than getTokenAtPosition)

THe right term to use in that case is 'PropertyName'. That matches the name the specs use for Identifiers/NumericLiterals/StringLiterals. So, there would be:

getTouchingToken (most flexible, but reqiures the most work to consume)
getTouchignWord (keywords/identifiers)
getTouchingPropertyName(identifiers/string/numeric-literals).

Thanks!

👍