"Display Files" option in Defs tool window

[Dennis]

This option has been turned off by default for nearly a decade now.  It is an antiquated feature dating back to before we had the Files tool window or document tabs.  Is there any reason we can't finally make the Defs tool window purely for symbols in the current file now?

[chrisant]

I didn't know it was an option.  According to source control history I've had it on for at least 5.5 years (I keep my SE install under source control).  I must have turned it on by accident somehow long ago. 

It's never been useful to me in those 5.5 years, and I didn't realize it was an option until this poll or I'd have turned it off earlier.  Thanks for asking! 

[hs2]

I agree with chrisant. Same story for me
It's fine to finally remove it.
HS2

[dholshou]

How sad. I just installed v19 and find the way I know best to navigate my tree has been removed.
<Ctrl><tab> has been hopelessly broken for many revs, going to random files, and now I don't have a way to see which files are currently open.
Gah!! Going back to v15 AGAIN.

[dholshou]

So, if it's been turned off by default for ever, why is it that it's always been on for me?

[Dennis]

I don't understand the desire to switch back to an earlier version.  I can name at least three ways to see what files you have open that are far superior to what the "Display Files" option was in the Defs tool window.

• The document tabs (you can scroll the tabs left and right using the arrows)
• Docking the Files tool window (Buffers tab)
• The list-buffers command (Ctrl+Shift+B in CUA mode, this activates the Files tool window)
• The buffer list in the document tabs.  Click on the down arrow in the upper right hand corner of the editor, or invoke it using the document-tabs-list-buffers command.

I would recommend docking the Files tool window and the Defs tool window on the left, with the Defs tool window stacked on top of the Files tool window such that you can see both at the same time.

Also, with respect to Ctrl+Tab, you may want to check how you have it configured (Tools > Options > Editing > Editor Windows > Smart next window style).  Read the docs, and choose the setting that best matches what you expect Ctrl+Tab to do.

[dholshou]

Very simply, and I've been over this before, none of the options for CTRL+TAB respond in a similar fashion to what I am familiar from MS WindowsTM tools. Smart Next Window brings up random files that I haven't accessed for a very long time.

BTW: I have read the docs many times. The description is not what I expect in any of the options.

[dholshou]

I plan to go back to a previous rev because it works the way I need it to.
Using my mouse to open the Files tab to open a file, then use my mouse to open the defs tab so I can move to the correct def within the file is much more mouse activity then being able to browse all of my open buffers and defs in the same place.

I understand it may be more complexity in your code, but this implies more mouse interaction for me and less productivity.

[Dennis]

You are not counting the time you spent scrolling the Defs tab to see other files.

Also, this is a question of how you are planning to navigate.  If ultimately, you want to go to a specific symbol, why not start with the Find Symbol dialog (or using the "f" command from the SlickEdit command line, or use push-tag (Ctrl+Dot) if you happen to already be on a reference to that symbol).  Then you don't waste your time navigating to a specific file first, in fact, you don't even have to know what file the symbol is in.

[dholshou]

1) You are not counting the time you spent scrolling the Defs tab to see other files.

2) Also, this is a question of how you are planning to navigate.  If ultimately, you want to go to a specific symbol, why not start with the Find Symbol dialog (or using the "f" command from the SlickEdit command line, or use push-tag (Ctrl+Dot) if you happen to already be on a reference to that symbol).  Then you don't waste your time navigating to a specific file first, in fact, you don't even have to know what file the symbol is in.

1) I most certainly am. My files don't have 400000 symbols and are very easy to navigate side-by-side. This is, to me, a ludicrous extreme case which does not affect me.

2) VSE does not seem to be able to differentiate between symbols between classes with inheritance. If I have a definition of class x with symbol y and class x is a top-level class inherited by every class in my entire code-base, VSE registers y for every instance and cannot differentiate to the one inherited instance my cursor is actually sitting on. When I search for a def using the symbols tool VSE just allows me to see all of the instances of y in all of the classes that inherit from x. I stopped using symbols many years ago. Maybe it has gotten better, but autocomplete certainly has gotten worse in this respect.

[dholshou]

So, by this poll, am I to assume that you have a user base of 6?
It seems strange to drop a feature based on the advice of 6 people.

[Dennis]

What language are you working in?

More significant than the six votes was the user base of 1 (out of the 408 reads this thread has had) that actually wanted to keep the feature.

[dholshou]

C++.
Nice dig. Makes me all warm and fuzzy.

[dholshou]

If my comment was taken as a dig, I'm sorry. It was not intended as such.
I don't read the forums until I need something. Just because people don't notice a discussion doesn't mean they are unaffected.
I rely on this feature. I use it all day, every day. Without it I will fall back to an older rev.

[Dennis]

OK, seriously, back to being helpful.

C++.

Code: [Select]

class B {
public:
   virtual void validate();
};

class C1: public B {
public
   virtual void validate();
};
class C2: public B {
public
   virtual void validate();
};

/* dot dot dot */

class C99: public B {
public
   virtual void validate();
};

You are sitting in a function that uses C99.

Code: [Select]

void foobar(C99 *c) {
   c->validate();
}

You hit Ctrl+Dot, cursor is on "validate".

You should expect to get the following list of items:

Code: [Select]

function:    C99::validate()             // member of expected class C99
prototype:  C99::validate()
function:    B::validate()                 // member of parent class B (also relevant)
prototype:  B::validate()

You might get different results with our code, here's just one example of how C preprocessing can completely screw things up.

Code: [Select]

void doobar( MYPOINTER_TO(C99) c ) {
   MYFUNCTION_ENTRY
   c->validate();
   MYFUNCTION_EXIT
}

In this case, for numerous reasons, SlickEdit can't evaluate the type of "c", so it falls back on finding anything that is named "validate", thus you get:

Code: [Select]

function:    C1::validate()
prototype:  C1::validate()
function:    C2::validate()
prototype:  C2::validate()
...
function:    C99::validate()             // member of expected class C99
prototype:  C99::validate()
function:    B::validate()                 // member of parent class B
prototype:  B::validate()

If SlickEdit doesn't navigate correctly, it isn't always a shortcoming of SlickEdit, it is frequently, especially for a good, strongly typed language like C++, a shortcoming of how you have your projects set up, or most often, how you have C/C++ Preprocessing configured for your code base.

Document > C/C++ Options... > C/C++ Preprocessing.

There are limits, of course, maybe you are using some obscure template meta-programming trick that is tripping up our context tagging.  Who knows.  I'd like to see a real example, because what you are describing appears to be a case that we handle robustly.