What is the ETA for v17 beta and what are expected new features?

[asandler]

Got curious :-)
Alex.

[Matthew]

Standard upfront disclaimer that states:
1. Timeframes are estimates, not promises
2. Feature list is far from set in stone

We usually target late March or April for our spring beta cycle. We've had a lot of changes to our UI framework, and it'll take us some time to iron out all the quirks. That means the beta may be a little later than usual this year. So call it early-to-mid April as a guesstimate.

When we get closer to the beta, we'll be able to share our feature plans in-depth. But here are a couple things we're working on.

• Enhanced C/C++ beautifier framework
  This is the start of a multi-release effort to provide better support for beautifying and auto-formatting your code, including the ability to define and switch between multiple "profile styles". We'll start with the C-like languages, with the goal of incorporating more languages in future releases.
• Android development
  For those not in love with Eclipse, we aim to provide an end-to-end environment for Android projects. Right now integrating with the emulator debugging is giving us heartburn, but we're working on it.
• Objective-C support
  Now that we've got a real Mac version, we're going to give Objective-C some much-needed attention. Major improvements in framework tagging, auto-completion, dynamic surround, etc.
• Alias Overhaul
  Our aliases are a really powerful feature, and one we think is largely under-utilizied. So we are aiming to make defining and accessing available aliases much more obvious and user-friendly.
  

[asandler]

Cool. Thanks.

[jaymmartin]

One vote for doing a C++ tagging performance overhaul first.  Weird stuff (random slowdowns and stalls) is occuring in there.

[ehab]

now the Android development part got me excited, i look forward for it and wish you all the best results.

[Jeremy]

It would be great if the actual filenames created by templates could be variable-driven....i.e. having variables in the filename such that inputs could change what was created.  Not the path, but the actual filename.

[jwiede]

Personally, the Obj-C improvements sound quite nice!  No more excuse for it being treated as the red-headed stepchild of the application programming languages.

[anic]

2nd vote for C++ tagging performance improvements. I have used every version of SlickEdit since about V9. V16 when used with large projects has me constantly trying to tweek and tune the settings to make projects not pause, freeze (the entire slickedit app until I need to kill it) or fail to find symbols. I used to like having colleagues in my office while I showed them some piece of code using slickedit -- now I usually cringe at the thought of navigating through my projects using slickedit for fear that it will lockup somehow while trying to find something.

I still really like slickedit because, when it works, I'm able to figure out how some code is called/structured way faster than my colleagues.

[Gered]

3rd vote for C++ tagging performance improvements.

The tagging support in SlickEdit is excellent, but having random pauses and slowdowns gets a bit annoying. Tweaking the tagging settings definitely can reduce the frequency/length of any pauses and slowdowns, but I'm unable to remove them completely. And I'm running an i7 2600K, so not really convinced that it's a lack of horsepower.

[rgloden]

4th vote for eliminating the tagging pauses/slowdowns.

I also see the random but painful pauses / slowdowns in V16 which wasn't there in V15 ... but I'm mostly Ada and Perl ... so I'm not sure its not limited to C++.

[aziwoqpd]

5th vote for fixing the tagging pauses!

I've tweaked as many of the tagging settings as I can find, but SlickEdit still randomly freezes up for 1-10 seconds pretty often.

[scm6079]

6th-33rd vote for fixing the tagging pauses!

My whole team (27 SlickEdit installations on Linux, Windows & Mac) complains about this one - and we experience the "spinning beach ball" on the mac version / freezes on windows all the time.  With network drives the problem is much worse.  Having a config option to set the base directory for project/workspace tag files would be **HUGE** for us - which would let my team specify their home folders for tag files when using the required network drives for projects.

I love the addition of iPhone (Objective-C) and Android Development as well. 

[Phil Barila]

With network drives the problem is much worse.  Having a config option to set the base directory for project/workspace tag files would be **HUGE** for us - which would let my team specify their home folders for tag files when using the required network drives for projects.

I'd really like SE to allow me to specify a location for the workspace tagfile in the workspace, with full support for environment variables.  Until that happens, however, there is a workaround.  Since the workspace tagfile is located in the same directory as the workspace file, if you locate your workspace file (not the project files it references) in the desired location, your workspace tagfile will be there, too.  Makes it a bit difficult to have your workspace under source control, though, which is why the assignable tagfile location would be preferred.