Author Topic: Improved Context Tagging  (Read 908 times)

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Improved Context Tagging
« on: December 07, 2011, 10:02:37 am »
See this topic.  When using Ctrl+/ on a symbol name that's relatively unique, it seems like SE typically filters the "select symbol" list to relevant ones I might be interested in.  But when the symbol name is widely defined (e.g. AddRef or Release in Windows programming) then the "select symbol" list is enormous, gets truncated, and is basically useless.

It makes sense to not force the user to wait while SE analyzes all of the symbols to figure out which ones really make sense to show in the list.  But sometimes (actually often, I think) we users are willing to wait for that analysis.

Request:  Please add a cancellable progress dialog while SE analyzes all of the symbols to figure out which ones really make sense to show in the list.  For example, when the cursor is on "MyClass::Release" and I hit Ctrl+/, I want to see the list filtered to instances of "Release" that are in some way related to "MyClass" -- I don't want to see every single COM interface from every header under the sun listed.  :)
« Last Edit: December 07, 2011, 10:04:56 am by chrisant »

Shelku

  • Community Member
  • Posts: 45
  • Hero Points: 0
Re: Improved Context Tagging
« Reply #1 on: December 09, 2011, 07:27:04 pm »
When programming in C, I might have code like:

Code: [Select]
typedef enum
{
ENUM0,
ENUM1,
ENUM2,
}MY_ENUM;

Then when I type code to use that enum, I would like to type something like:
Code: [Select]
void voo(MY_ENUM e)
{
if (e == {TYPING_HERE})
{

}
}
Note the {TYPING_HERE}. After I hit == I don't know of any way to get the list of enumerator options (even hitting ALT-. doesn't). However, if I type "e." or "MY_ENUM." (C++ style), then I get the list of enumerator options. I've learned to generally use the "e." style to get my list, then I go back and change my '.' to a comparison operator so it compiles in C.

Similarly, if I do a switch-statement on that enumerator variable, then I would expect to get an auto-complete list of enumerators for each case-statement as I'm typing.

So my feature request is to have the enumerator list pop-up on comparisons and available on ALT-.
« Last Edit: December 10, 2011, 03:22:33 am by Shelku »

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: Improved Context Tagging
« Reply #2 on: December 09, 2011, 08:01:10 pm »
And building on Shelku's request, I'd like to see more contextual awareness in the list completion logic.  For example, when I'm editing in Foo::Method() and I type a few characters and hit Ctrl+Space it seems like the completion list should be prioritized by "relationship distance" and also proximity.

If there's a local variable that matches, then it should be prioritized early in the list -- it's likely I'm trying to complete and match the local variable.  The local variable is a more likely match than a CRT function or other random symbol (#define, enum, function, struct, etc) from a random header from an unused/unlinked component that only happens to be in the workspace tag file because it's included in the 1000-file set of standard OS headers.

Or if there's a member function/variable that matches, then it should be prioritized early in the list as well.

Functions in the same file might come next.
Then maybe symbols from the same directory.
Next maybe symbols from the same project.
Then general symbols from the workspace tag file.
Finally symbols from the compiler tag file.

The prioritization described above is only meant for illustration purposes, to clarify what I mean by "relationship distance or proximity".  There's probably a smarter way to prioritize.  My request is that some kind of smart prioritization be introduced.  Because right now I have to try to make the first few characters of anything be relatively unique across the workspace + compiler tag file, otherwise the completion list isn't very useful if there isn't an explicit scope provided.

For example:
var.xx    <-- completion list is already useful, because it's restricted by "var."
xx    <-- completion list not very useful right now