SlickEdit Community

SlickEdit Product Discussion => SlickEdit® => Topic started by: Dennis on October 16, 2013, 03:32:55 pm

Title: "Display Files" option in Defs tool window
Post by: Dennis on October 16, 2013, 03:32:55 pm
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?
Title: Re: "Display Files" option in Defs tool window
Post by: chrisant on October 17, 2013, 08:32:38 am
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!  :)
Title: Re: "Display Files" option in Defs tool window
Post by: hs2 on October 17, 2013, 09:21:45 am
I agree with chrisant. Same story for me :-[
It's fine to finally remove it.
HS2
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 11, 2015, 03:50:50 pm
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.
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 11, 2015, 03:55:02 pm
So, if it's been turned off by default for ever, why is it that it's always been on for me?
Title: Re: "Display Files" option in Defs tool window
Post by: Dennis on February 11, 2015, 04:26:29 pm
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.


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.
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 11, 2015, 04:41:39 pm
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.
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 11, 2015, 04:44:10 pm
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.
Title: Re: "Display Files" option in Defs tool window
Post by: Dennis on February 11, 2015, 04:56:27 pm
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.
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 11, 2015, 05:05:06 pm
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.
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 11, 2015, 05:07:26 pm
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.
Title: Re: "Display Files" option in Defs tool window
Post by: Dennis on February 11, 2015, 05:11:27 pm
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.
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 11, 2015, 05:14:32 pm
C++.
Nice dig. Makes me all warm and fuzzy.
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 11, 2015, 05:18:25 pm
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.
Title: Re: "Display Files" option in Defs tool window
Post by: Dennis on February 11, 2015, 05:45:11 pm
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.
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 11, 2015, 06:02:07 pm
Of course. VSE's powerful tagging and referencing are what I love.

I'm just upset about losing a feature I depend on.
I don't understand the symbols tab. It doesn't make sense to me, so I've lost the ability to get around and now I have to learn a new way.
My expectation of <ctrl><tab> is obviously very different than yours, so I find it very frustrating and my only recourse is to have files displayed in my defs tab.
Now I have double the mouse clicks to get where I could get yesterday with a minimum of expense.
Title: Re: "Display Files" option in Defs tool window
Post by: Dennis on February 11, 2015, 06:11:34 pm
Personally, I don't use Ctrl+Tab to navigate files, so my expectations are not really an issue. 
I do make a lot of use out of Ctrl+' (edit-associated-file).

What specifically do you not understand about the Symbols tool window ?  (BTW, I was suggesting you try the "Find Symbol" tool window earlier, not Symbols).
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 11, 2015, 06:15:55 pm
So, "Find Symbol" would mean typing out the symbol name when I want to move to a file/symbol area within my code in a file I already have open. Hmmmm. We'll see.
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 19, 2015, 04:48:24 pm
Ok, so I've narrowed down a bit on this concept.
You say <ctrl>+. "Go to definition" and that does work for inherited classes (actually sometimes it only goes to the symbol in the current file and ignores the other [declaration or definition] even if I don't have "Do not show these options again" checked. but it works most of the time.)
But if I "Go to references" <ctrl>+/, a dialog pops up with the super and the sub class Symbols listed for choice, and then when I select the sub class, all possible symbols, from the entire code base are shown.

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();
};

The References tab always shows all references to all B::validate() if the cursor is sitting on C99::validate() select "Go to Reference for validate()" and then select C99::validate() from the selection dialog.
There are no preprocessor weirdities (or any other oddities.) This code base is very simple and straightforward. We don't have strange constructs. It's simply not allowed.

See attachment ScreenClip.png
I seem to remember VSE being smarter in the past about only showing references that match.
Title: Re: "Display Files" option in Defs tool window
Post by: Dennis on February 19, 2015, 05:57:44 pm
Testing with 19.0.1, when I do Ctrl+/ on validate, I'm prompted whether I want C99::validate() or B::validate().

If I choose C99::validate(), I only see B::validate(), which is a reference by virtue of being the declaration in a parent class, and C99::validate(), which is the item I selected.

If I choose B::validate(), I see all four references, which is correct, because they are all related by inheritence to the parent class B.

In your screen shot, it's hard to tell if what I happening is correct or not because I don't know your class hierarchy.  Which of the following classes inherit from SspInterface?  Which of the following classes use SspInterface or a class that derives from SspInterface, or call the Initialize() method from an abstract class that SspInterface derives from.


I notice that the reference in IrAlgorithms.cpp is in an unrecognized code region, so there must be some preprocessing going on there, or some very unusual code construct that the parser did not recognize.  Maybe it's incomplete code.

Polymorphism can be great, but it does create situations where code navigation gets more difficult.  Every time you have some thing like the following example, there is no guessing what sub-class is being called, except at run-time, of course.  An overuse of this construct can decompose a strongly typed language down to being as hard to statically analyze (ie, read the code) as an run-time typed scripting language.

Code: [Select]
   CommonInterface *pci = something;
   pci->Initialize();
   // 200 classes derive from "CommonInterface" and redefine Initialize()
   // This call could be to ANY one of them.
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 19, 2015, 06:04:54 pm
None of these classes inherit from SspInterface. That's the point.
They ALL inherit from a super class LPSW.
I have selected the symbol Initialize(SspInterface:func), but it's showing me every possible version including the super class and all inheriters.

There is no preprocessing allowed. IrAlgs is not showing because it's unimplemented and in a half-baked state. I don't know what's up with it, it's just empty right now.

I've seen this on several code-bases. All of those codebases use different structures but follow the same rules, no weird preprocessing. Don't blame it on that. That's not it.

VSE didn't used to do this, in the last few rev's things have gotten so complicated that it seems to be missing the simple stuff now.
Title: Re: "Display Files" option in Defs tool window
Post by: Dennis on February 19, 2015, 06:29:32 pm
OK, here's a made-up example.  Do you think this is a possible reference to SspInterface?  [hint, I do].  If you are looking for references to SspInterface::Initialize(), then I presume you want to see all possible places where it could theoretically be called from.

Code: [Select]
void CameraManager::Initialize()
{
    for (size_t i=0; i<m_cams.length(); i++) {
       LPSW *child = m_cams[i];
       child->Initialize();   // could be any class that ultimately derives from LPSW
    }
}
Title: Re: "Display Files" option in Defs tool window
Post by: dholshou on February 19, 2015, 06:47:58 pm
I'm trying to figure out the implications of that. There is nothing that does that exactly, ie: pointer/polymorphic use of the super to change a "shape" into a "circle" or a "square".

All applications follow exactly the same construct in this respect.
All sub classes explicitly call super::Initialize() as the first line of sub::Initialize() to setup interprocess communication.
There are no pointers to possible polymorphic subclasses. This is direct and simple in every sense I can think of.
Code: [Select]
lpsw_err SspInterface::Initialize(CmdRouter *pCmdRouter, TlmCollect *pTlmCollect, FaultManager* pFaultManager)
{
   lpsw_err locRetVal = LpswApp::Initialize(pCmdRouter, pTlmCollect, FaultManager);

But this is digging too deep into detail. I've seen this behavior on multiple code bases with different structures. This isn't about polymorphism or ruby-like run-time type-morphic madness. I'm not sure how I can describe it better or differently. Every reference, to every possible name that's spelled the same (even if it's in a different class) isn't the correct match but that's what I'm getting.
Title: Re: "Display Files" option in Defs tool window
Post by: Dennis on February 19, 2015, 07:14:30 pm
OK.  I think that may have finally helped me narrow it down.  I can fix this.

Code: [Select]
class B {
public:
   virtual void validatex();
};

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

/* dot dot dot */

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

void C99::validatex()
{
   B::validatex();   // only a reference to B::validatex(), not classes derived from B
}