Author Topic: Non-project tag files are broken - Huge disappointment in SlickEdit 2017…  (Read 3293 times)

olegkagan

  • New Community Member
  • Posts: 2
  • Hero Points: 0
I am using SlickEdit since boxed versions (with Alpha binaries)… My latest was SlickEdit 2014.  Just had my admin at work purchase me upgrade to SlickEdit 2017 and I am very disappointed :(… I have huge (and I mean HUGE) codebase and use tagging to navigate it, which is primary reason I use SlickEdit. 2014 works flawless with it... Now I am trying to use 2017 in the same scenario and it fails miserably... I have about 7 tag files that I generate using batch files. Now I am trying to "add" them and it works very strange...old tag files "disappearing", some files can be seen twice, there are 2 "C/C++" Tag Files subtrees... "Up/Down" are grayed... It is useless for me - I want to initiate money back procedure... I'll go back to my trusty 2014 and will upgrade when 2017 will become mature enough...
« Last Edit: June 06, 2018, 02:43:23 AM by olegkagan »

rajkej

  • Senior Community Member
  • Posts: 336
  • Hero Points: 14
I assume you applied all of the patches?

Also, it is possible that the API you were using in your batch processing has changed since 2014 so double check that. There have been many new features added to SE and those might be affecting your viewpoint.

olegkagan

  • New Community Member
  • Posts: 2
  • Hero Points: 0
Yes all patches applied... I do not use API I use command line e.g. "vs.exe +new -p make-tags -L X:\filelist.lst -C -X -O tags.vtg"... I can work with SlickEdit devs on repro, but as it stands now this version is 100% useless for me... :( I would prefer to get money back unless it can be fixed within week or two...

Dan

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2896
  • Hero Points: 153
We are looking into this.

Dennis

  • Senior Community Member
  • Posts: 3954
  • Hero Points: 515
Are you adding the tag files using the Tools > Tag Files.. GUI ?

Are your batch files building the tag file using SlickEdit 2017 or SlickEdit 2014?

Could I see a screen shot of the GUI with two instances of C/C++ tag files ?  Note (this is not new to SlickEdit 2017), there are two C/C++ Tag File categories, one for global tag files, and another one for C/C++ Compiler Configuration Tag Files.  Maybe you are looking at the wrong list?

Also, could I see a screen shot where Up/Down is disabled when you are on a C/C++ Tag File?

Also, also, if you could step through (with screen shots) how you get into the state of a tag file disappearing or a tag file being seen twice, that would be helpful.

Have you considered trying using Workspace Auto-Updated tag files instead?  There are a bit more appropriate to use for Tag files that you are rebuilding outside of the editor.

  • Tools > Tag Files...
  • Select Workspace Auto-Updated Tag Files
  • Click on "Add Tag File..."
  • Select the tag file you are trying to add (from the location where the rebuilt tag file is placed).
  • Repeat for the other tag files.

gfeiner

  • Junior Community Member
  • Posts: 3
  • Hero Points: 0
I also experienced the same tag file problems described by olegkagan when I went from SE2015 to SE2017.  I think the problem lies in the differences in tag file folder names in the tag file window in older versions of SE like 2015 when compared to SE2017.  In SE2015, I always added my C/C++ tag files in the "C/C++ Tag Files" folder in the tag file option window.  There is no such folder in SE2017 (initially) but, in SE2017 there is a very similarly name folder "C/C++ Compiler Configuration Tag Files". When I tried adding my tag files I had created in SE2015 to that "C/C++ Compiler Configuration Tag Files" folder, I experience the problems described by olegkagan.  I only did so because I had thought it was the same folder as SE2015. I initially did not notice the slight name difference, which was caused by the lack of the "C/C++ Tag Files" folder in SE2017.  I tried Dan's suggestion of adding my tag files to the "Workspace Auto-Updated Tag Files" folder and that worked fine. No more odd behavior.  After having added tag files to the "C/C++ Compiler Configuration Tag Files" folder, then the "C/C++ Tag Files" folder will appear and the tag file I added to the "C/C++ Compiler Configuration Tag Files" folder will get automatically moved to the instantly appeared  "C/C++ Tag Files" folder. However, since accidentally adding my tag file to the "C/C++ Compiler Configuration Tag Files" folder, I have found that removing the tag file from the "C/C++ Tag Files" that automatically appeared results in a tag file "ghost" always being left behind that I can't get rid of (tag file name with red dot next to it). See attached screen shot.  I hope I'm describing this in a way that makes sense. I can add more screen shots if you like.

Dennis

  • Senior Community Member
  • Posts: 3954
  • Hero Points: 515
That is a good point.  I'm going to make changes to this for the next release.  C/C++ Tag Files will be put in the tree directly after C/C++ Compiler Configuration Tag Files.  That will make them easier to find.

I will do the same for other languages that have compiler configuration tag files (currently only Java).  This will have the additional benefit of moving the two most used languages to the top of the list.  See attached image with names redacted to protect the innocent.

If the current file is C/C++, the category selected in Tools > Tag Files... will be:

1) If the file is in your workspace, the workspace tag file.
2) If you have C/C++ Compiler Configuration Tag Files, the first C/C++ Compiler Tag File
3) If you have C/C++ Tag Files, the first C/C++ Tag File
4) If you do not have C/C++ Tag Files yet, an empty category for C/C++ Tag Files.

The "ghost" tag file that you appear to have is a tag file that you have configured, but it no longer exists on disk, or can not be opened.  You should be able to select it and click on "Remove Tag File" to get rid of it.


gfeiner

  • Junior Community Member
  • Posts: 3
  • Hero Points: 0
I did select the tag file and then clicked the "remove tag file" button then clicked yes to the next prompt but the ghost still remains.  And I noticed that removing tag files from that particular folder also automatically deleted it from disk.  I thought SE would confirm in a seperate prompt if I wanted to also remove the tag file from disk.  See attached screen shot.

Dennis

  • Senior Community Member
  • Posts: 3954
  • Hero Points: 515
If the file does not exist on disk, you will not be prompted if you want to delete it.  Does this file exist on disk?

gfeiner

  • Junior Community Member
  • Posts: 3
  • Hero Points: 0
The tag file associated with that ghost entry no longer exists because the 1st time I selected the tag in the list and then clicked “remove tage file” button, it deleted the tag file from disk too and that is when the tag entry became greyed-out with a red dot and became unremoveable from the tag window list