Author Topic: Slickedit roadmap?  (Read 5497 times)

DavidA

  • Community Member
  • Posts: 29
  • Hero Points: 0
Slickedit roadmap?
« on: February 25, 2014, 01:33:01 PM »
Hi
Our seats of SlickEdit are up for maintenance renewal next month, so we are considering whether to renew.  Please will you give me an idea of the SlickEdit roadmap to entice us to renew?
Best regards
David

Matthew

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 990
  • Hero Points: 44
Re: Slickedit roadmap?
« Reply #1 on: February 25, 2014, 07:28:35 PM »
I can't speak to everything that we have planned, but here are a couple things coming up for SE2014 and later.
- Overhauled support for SQL languages. The first step is a greatly improved parser and tagging infrastructure for SQL, which you'll see in SE2014. And we have more ideas for adding additional SQL features as customer requests warrant.
- More beautifiers. We've pretty much knocked out all the C-like languages in the past 2 releases, and the HTML/XML variants are up next. Beyond that we'll start developing new beautifiers for dynamic languages.
- UI enhancements. In the past two releases we've redone the entire GUI subsystem, and last year added support for a very flexible docking/floating architecture for editor control windows. In SE2014 we're working on support for placing tool windows in floated tab groups. Once that's in place, in future releases we're eyeing adding support for multi-instance tool windows to go along with the multiple floating tab groups.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6881
  • Hero Points: 530
Re: Slickedit roadmap?
« Reply #2 on: February 27, 2014, 02:30:12 AM »
Next release will have some additional ant-like file matching support. For example, from the command line you will be able to type "e **\*.html" to recursively search and open all HTML files. You can get much more sophisticated than this example (i.e.  "e backup\*\a*b\**\*.html"). This new ant-like file matching will also be supported by multi-file diff, multi-file search and replace, the file manager, and invocation (i.e. "vs **\*.html").

Here's something cool the new 2014 file listing engine will support. Let's say you have a .zip/.jar file with source code. You can type "e file.jar\**.cpp" to view all the C++ files in the jar file. Save isn't supported but the ability to recursively search .zip and .jar files is very handy.

There is more planned than what Matthew and I have mentioned.

rowbearto

  • Senior Community Member
  • Posts: 2335
  • Hero Points: 132
Re: Slickedit roadmap?
« Reply #3 on: February 27, 2014, 02:54:40 AM »
Hi Clark and Matthew:

Some features that I would like that I think could have good benefit for many are mentioned in the new features thread.  Here's my 2cents:

Support equivalent of eclipse's "Open Call Hierarchy".

Speed up searching by using multiple threads - allow user to specify how many threads to use (like -j option to make).

Allow to user to set a limit as to how many active editor windows there can be, and SE can automatically shuffle out the last recently used file out when a new file needs an editor window.

"Unify/Combine" the way search-results and references results are shown.  Examples: add tabs to the References tool window, allow search results to be displayed in the way that cross-reference results are shown, so that context can be seen - also vice-versa, allow references to be seen in the way search results are shown - both "perspectives" are useful for different reasons.  Allow user to choose the "perspective" that the search results or references are shown in.

Column sort in "Smart Open" tool window, to sort by last modified time, or by directory.

Combo box in the "Smart Open" window to keep history of most recent files opened.

Don't lock large files if they are open in an editor window.  I often have the .map file from my linker open in the editor.  But if I try a new link of my object files, it fails because slickedit has the very large .map file open.  This slows me down when I am trying to rebuild, as link can take a long time before outputting that error, and it is wasted time.  Even with the current option telling SE to not lock files, it is still locking large files.

Specify tagfile path to allow it to be placed on local hard disk instead of in same path as workspace, and to use %variables to describe its location, such as env vars, portions of a path, and username.

Thanks for listening!

Rob

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6881
  • Hero Points: 530
Re: Slickedit roadmap?
« Reply #4 on: February 27, 2014, 03:52:06 AM »
Thanks for the ideas.

Locking of large files is configurable. Keep in mind that SlickEdit can edit files up to 2TB. You will probably just want to up the size.

2014 will allow you specify where your workspace tag files are stored!

rowbearto

  • Senior Community Member
  • Posts: 2335
  • Hero Points: 132
Re: Slickedit roadmap?
« Reply #5 on: February 27, 2014, 04:05:33 AM »
Thanks Clark!

One more idea, already mentioned in the new features thread:

A way to keep all tool windows locked in their current positions - with no way to inadvertently move them around.  When I try to introduce some new colleagues to SE, they sometimes inadvertently move their tool windows around and have a hard time moving them back.  I've seen them end up with some crazy layouts so I taught them the 'tbResetAll'.  But some people don't even ask me how to fix it and just give up on SE.  Even I sometimes end up getting a tool window undocked when I don't want it to be.

Also, is large file locking already configurable in SE 18?  I tried looking in the File Options->Load, and I only see "File Locking".  I already have that set to off, but large files still get locked.

You mentioned there is a way to modify the size at which files are locked?  I am having trouble finding that option, can you point me to it?

Thanks again!
Rob

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: Slickedit roadmap?
« Reply #6 on: February 27, 2014, 07:43:42 AM »
Also, is large file locking already configurable in SE 18?  I tried looking in the File Options->Load, and I only see "File Locking".  I already have that set to off, but large files still get locked.

You mentioned there is a way to modify the size at which files are locked?  I am having trouble finding that option, can you point me to it?
I can't find anything in the options or in macros\*.e that looks directly related.  However, there's also a "Load entire file" + "Load partially for large files" set of options.  Maybe they implicitly lock large files?

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6881
  • Hero Points: 530
Re: Slickedit roadmap?
« Reply #7 on: February 27, 2014, 02:00:36 PM »
Tools>Options>File Options>Load

You can turn off "Load partially for large files". There appears to be a bug with the enable/disable for the size field ("Load partially when files are larger than"). The default is 8 megabytes. We will look into this.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6881
  • Hero Points: 530
Re: Slickedit roadmap?
« Reply #8 on: February 27, 2014, 04:46:13 PM »
Also, is large file locking already configurable in SE 18?  I tried looking in the File Options->Load, and I only see "File Locking".  I already have that set to off, but large files still get locked.

You mentioned there is a way to modify the size at which files are locked?  I am having trouble finding that option, can you point me to it?
I can't find anything in the options or in macros\*.e that looks directly related.  However, there's also a "Load entire file" + "Load partially for large files" set of options.  Maybe they implicitly lock large files?

I took a quick look and it looks like the macro variable "def_max_loadall" has these options. You can manually change the 8000 to something larger.

rowbearto

  • Senior Community Member
  • Posts: 2335
  • Hero Points: 132
Re: Slickedit roadmap?
« Reply #9 on: February 27, 2014, 05:32:00 PM »
Thanks Clark!  That fixed my issue!

When I first looked at the value of def_max_loadall, it was set to '1 8000'.

I am not sure what the first "1" means, but I changed it to '1 40000', and my .map file no longer gets locked, and the linker can overwrite it when the file is open in SE!  Yahoo!

A small suggestion for SE2014 - in the Tools->Options->File Options->Load->File locking, when I click on it once, I see the help at the bottom of the dialog, which currently says this:

'When set to On, a file handle is kept open to the file for locking purposes. This detects when another user is editing the same file.'

You may want to add a note in there about large files, and how to turn off locking for them and how to adjust the threshold.  Because it was not obvious how to do this.

Thanks again!  And thanks chrisant for looking!