Author Topic: SlickEdit versioning  (Read 9743 times)

kurtus

  • Guest
SlickEdit versioning
« on: April 02, 2008, 04:47:53 PM »
I am a long SlickEdit user and like it a lot (especially after CodeWright was discontinued). What I do not like is its versioning policy. After version 11 which was a major upgrade compared to version 10, there was very little change. I think version 12 and 13 are really only 11.1.x and 11.2.x (we never saw any update beyond xx.0.3). I understand that they want to make more money, so they call updates upgrades and automatically increment version number every year. I had very much doubts about move from version 11 to 12: so few new features for $209 they asked for upgrade of my bundle. Now I downloaded version 13 and decided that enough is enough: I will wait for real upgrade. I could understand a new version if they would added, for example, scripting language debugging, or Python macros support instead their home-made Slick-C, or improved UI...

jbhurst

  • Senior Community Member
  • Posts: 405
  • Hero Points: 33
Re: SlickEdit versioning
« Reply #1 on: April 02, 2008, 07:30:43 PM »
Depending on your usage of SlickEdit, you may or may not get benefits from the new features. These days I am mostly using it for pretty straight-up text editing, and it had most of what I need way back in version 4 or 5. (If not earlier.)

Having said that, I think SE 12 (2007) was the best release in a long time. (I'm still finding my feet with SE 13.) Some of the features I like in SE 12 are:
  - The Files tool window. This is really great. You should check it out.
  - The Find Symbol tool window. Powerful and very useful.
  - The improved Key Binding dialog.

I also thought that the stability and quality of SE 12 was better than in the previous several releases -- a very important point for me.

Finally, the documentation took a huge leap for the better in SE 12.  (Thanks Lisa!)

If you subscribe to Maintenance and Support (as I have for > 10 years) you will find that the annual cost of staying up to date is very reasonable.

BTW I used to want to use a language such as Perl or Python for scripting SE. I even once made a DLL for Windows that allowed me to execute Perl code from within SE macros. However, having worked with Slick-C quite a lot now, I find that it's actually a very good language for writing editor macros. Probably the main disadvantage of it is that the library support is rather weak compared to most languages.

Regards

John Hurst
Wellington, New Zealand

StephenW

  • Senior Community Member
  • Posts: 197
  • Hero Points: 21
Re: SlickEdit versioning
« Reply #2 on: April 02, 2008, 08:45:51 PM »
As John says, if you are paying for maintenance each year, the upgrade cost is much less, almost a manageable amount.  So that is what I do.  I really think that the SlickEdit web site should point this out better, as quite a few people seem to miss this.  Yes, the first year you take a hit as you have to pay the upgrade price, plus the maintenance cost.  But after that, each year you only pay the maintenance.  As far as I can tell, SlickEdit has a policy of adding at least one major feature each year, to help justify the upgrade.  So if you are not on maintenance, it would depend on what that feature was as to whether you consider it worth incrementing the major version number.  If it is something you are unlikely to use (eg annotations for me), then you might consider it only a "minor" feature and not worth the increment.

In any case, I am in favour of policies that keep SlickEdit (the company) profitable and in business.  I really, really want my editor, as my main tool that I spend all day with, to be properly supported and updated.

BTW SlickEdit 2008 (V13.0.0) does introduce a macro debugger, although work on it is not complete yet and it is a bit buggy.  I think they are intending to complete work on it in one of the V13 point releases (V13.0.1?).  And they have done one major UI improvement this year - the new options setup with searching, history and many other improvements is great.  I popped back into V12 the other day to try something to compare with V13, and I had to change an option.  It was horrible - I have become so used to the nice V13 options over the beta period that I really had problems finding the right place for the option.  And then I wanted to undo it, and I had to go through the menus again, instead of just going to the history list.

ehab

  • Senior Community Member
  • Posts: 285
  • Hero Points: 15
  • coding with SE is like playing music
Re: SlickEdit versioning
« Reply #3 on: April 03, 2008, 09:09:33 AM »
I didn't see what was coming on 2008 and almost purchased the maintenance support with forwarded months. Now i'm glad i didn't since the new features wont be using except for the easier options which i can live without.

Lets see what happens for 14 or 15 ... by then i would have made the money and who knows what happens : )

just sharing the same thought

kurtus

  • Guest
Re: SlickEdit versioning
« Reply #4 on: April 03, 2008, 10:48:31 AM »
Did not want to start a discussion, but cannot help it...

  - The Files tool window. This is really great. You should check it out.

What is additional 'great' functionality compared to File Tabs?

Finally, the documentation took a huge leap for the better in SE 12.  (Thanks Lisa!)

Never even suspected that improved product documentation could be a justification for version increment...

However, having worked with Slick-C quite a lot now, I find that it's actually a very good language for writing editor macros.

Why learn new (product-specific) scripting language while a number (far better) industry standard languages is simply lying around (how I miss CodeWright with his Perl macros...)

In any case, I am in favour of policies that keep SlickEdit (the company) profitable and in business.

Do you mean that there is no business model for advanced code editor beside ripping-off customers? Most efforts in version 13 release seemingly were spend on a crazy licensing implemetation (retracted fortunately, but wasted resources could not be reclaimed...)

BTW SlickEdit 2008 (V13.0.0) does introduce a macro debugger, although work on it is not complete yet and it is a bit buggy.  I think they are intending to complete work on it in one of the V13 point releases (V13.0.1?).

What I mean is not a _macro_ debugger, but a _scripting_language_ debugger (like ActiveState Komodo). By the way adding Python/Perl macros and _this_ kind of debugger would make above mentioned _macro_ debugger unnecessary...

Ding Zhaojie

  • Senior Community Member
  • Posts: 194
  • Hero Points: 37
Re: SlickEdit versioning
« Reply #5 on: April 03, 2008, 02:54:50 PM »
The files tool window is totally different with file tabs. If you have thousands of files spreading in hundreds of folders, you can not live without the files tool window ;D. It really saves my time in finding files in huge projects.

When I was using v11, I was missing SourceInsight with the Project File List and the Project Symbol List very much. But v12 gave me both, and even better!!

Did not want to start a discussion, but cannot help it...

  - The Files tool window. This is really great. You should check it out.

What is additional 'great' functionality compared to File Tabs?

Finally, the documentation took a huge leap for the better in SE 12.  (Thanks Lisa!)

Never even suspected that improved product documentation could be a justification for version increment...

However, having worked with Slick-C quite a lot now, I find that it's actually a very good language for writing editor macros.

Why learn new (product-specific) scripting language while a number (far better) industry standard languages is simply lying around (how I miss CodeWright with his Perl macros...)

In any case, I am in favour of policies that keep SlickEdit (the company) profitable and in business.

Do you mean that there is no business model for advanced code editor beside ripping-off customers? Most efforts in version 13 release seemingly were spend on a crazy licensing implemetation (retracted fortunately, but wasted resources could not be reclaimed...)

BTW SlickEdit 2008 (V13.0.0) does introduce a macro debugger, although work on it is not complete yet and it is a bit buggy.  I think they are intending to complete work on it in one of the V13 point releases (V13.0.1?).

What I mean is not a _macro_ debugger, but a _scripting_language_ debugger (like ActiveState Komodo). By the way adding Python/Perl macros and _this_ kind of debugger would make above mentioned _macro_ debugger unnecessary...

« Last Edit: April 03, 2008, 02:59:19 PM by Ding Zhaojie »

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: SlickEdit versioning
« Reply #6 on: April 03, 2008, 06:49:05 PM »
A rose by any other name...  Does it really matter what number is used to designate a release? Our goal is to have a major release each year, which is why we've gone to the "SlickEdit 2008" style naming. It is true that you may find some releases have features that you find more appealing than others. As you can see from the other posts, though, some people have found some very useful stuff.

The best way to stay current is to purchase Maintenance and Support. This is still cheaper than upgrading every other year. Even if you don't see any killer new features in a particular year, there are many bug fixes that may improve existing features.

Here is a short list of my favorite features in recent releases:
V13
   Message List - tabular list of compile errors and warnings
   Greatly improved Options dialog
   Adaptive Formatting - scans existing files and matches their formatting style
   URLs as links - really helps to tie project documentation together. Put a url to design docs in comments and open directly from SlickEdit.
   Enhaced generation of Doc Comments - uses aliases to allow you to edit comment templates.

V12
   Dynamic Surround
   Files Tool Window
   Code Annotations
   Class Tool Window
   Copy and Paste in Color

v11
   Comment Wrapping
   Code Templates
   Enhanced Search and Replace
   Vim Emulation
   Regex Evaluator
   



MartyL

  • Senior Community Member
  • Posts: 166
  • Hero Points: 29
  • Synergex
Re: SlickEdit versioning
« Reply #7 on: April 03, 2008, 07:47:50 PM »
Our goal is to have a major release each year, which is why we've gone to the "SlickEdit 2008" style naming.

I figured you just wanted to avoid lucky number 13.

kurtus: To be fair, I wasn't originally thrilled with learning Slick-C to write macros, but it was a necessity. I was pleasantly surprised when I realized how easy it was to work with and how akin it is to the language it's named after. Simplified strings, quick development times and instant results. It's a great scripting language.

If you already know C, there's no reason to want to use Perl or Python over Slick-C. The only things unfamiliar would be the builtin properties, objects and functions in SlickEdit.. which you'd have to learn anyway, to use that functionality, even if they did support some other macro language.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: SlickEdit versioning
« Reply #8 on: April 03, 2008, 11:45:40 PM »
SlickEdit scales to projects with tens of thousands of files.
Imagine trying to use File Tabs to keep track of 10,000 files -- and besides File Tabs are only useful for files that are already open.

In the Files window you can type a substring of a file name and the list filters as you type.  To open any of 10,000 files, I just press Ctrl+Shift+O (bound to activate-files-project) and then type a few characters to filter the list down to one match (or to a few and then use the arrows keys to select).

To me that is the #2 most important feature in an editor, actually.  For context, the #1 most important feature is for the editor to be written in its own macro language, and the #3 most important feature is tagging.

I am a recent convert to SlickEdit, so maybe I missed out on golden days when apparently they made 11.2 and 11.3 updates for free that had as many improvements as 12 and 13 each had.  I researched several popular editors recently (more than 10, less than 20, lost count).  SlickEdit won by miles.  I am happy to pay them $60 per year to continue providing new benefits to me.  I'm betting that at least every other year they will provide me new features that I would pay $120 for (and bug fixes, and so forth).

P.S.  Documentation costs a lot of money to produce.  I absolutely consider big improvements in documentation to be an end user feature that is worth paying for.  As since I write a lot of macros and am new to the product, improved documentation is in fact far more useful to me than for example Comment Wrapping or Dynamic Surround (both of which are features I like and use a lot).