Author Topic: my suggestions for improving SlickEdit  (Read 384 times)


  • New Community Member
  • Posts: 1
  • Hero Points: 0
my suggestions for improving SlickEdit
« on: April 22, 2020, 06:05:08 pm »
I have many ideas to improve SlickEdit so I will list them all here:

1) SlickEdit needs better intellisense. Right now VS Code has the best C++ intellisense and code completion, its even much better than Visual Studio. But the intellisense is very weak on SlickEdit, hardly anything comes up when Im typing in C++ code. And for a language like C++ that makes extensive use of long library and method names, typing that out by hand instead of just tab completing everything is very annoying. Intellisense should recognize all the variable names you make in code so you can autocomplete that which saves typing and removes lots of errors of typos. What makes VS Code intellisense so good is its fuzzy search capability where you can type any of the letters in a long name instead of having to type the letters in order. This is especially great in C++ where you can have hundreds of methods that start out with the same letters but only change at the end. SlickEdit also seems to be missing a live linting feature where errors pop up as youre typing. This also is a great way to avoid bugs that could become hard to find if you wait till you do a compile.

2) I found SlickEdit to be a very bad C++ IDE for windows but very good for Linux. In windows you have to start a project with Visual Studio which I think is very bad. You should be able to access the Visual Studio C++ compiler in the Program Files directory and just use that with all the build managment done in SlickEdit. There are really no good IDE's for Linux. CLion and QtCreator are decent IDE's as far as intellisense, but they use CMake and require you to fill out a CMakeLists.txt which in my opinion is just as much a hassle as writing make files and which I think eliminates the purpose of an IDE providing a GUI menu to fill in library configurations. CodeLite is the only other IDE on Linux that I feel I could use. CodeBlocks and Netbeans have gotten really bad and are unusable now as nothing seems to work. So I think there is big opportunity to promote SlickEdit on Linux if you can ever get intellisense working on par with VS Code.

3) Code formatting is very good in SlickEdit, I like the beautify while typing feature. But it needs a format on save feature also (or a easy access formatting hotkey).

4) Get rid off the standard version of SlickEdit. The features its missing makes it unusable as an editor. Right now VS Code is setting the standard for editor features as far as intellisense and code formatting. If SlickEdit doesnt match these features then no one will use it.

5) Support Dart and Julia. The Dart community is growing fast due to Flutter. But Android Studio and VS Code are the only editors that support Dart. Also Flutter forces the dartfmt to make a unified coding standard. But some people dont like it (like myself, I am a Allman brace die hard). Julia is also a language that is growing strong in the machine learning community. But its really only supported by VS Code right now.

6) Color Schemes in SlickEdit are really bad. I need a good dark theme to work and most the built in themes in SlickEdit use a solid black background. If you want to see what I consider the best color scheme selection for any computer application, check out the color schemes for the Hyper terminal here:

7) SlickEdit is simply a corny sounding name. It might have been cool sounding back in the 90s when this editor was first developed, but its a name that would put off people as unprofessional sounding.

8 ) I like the feature where you can add things to the r-click menu when you r-click in the editor window. This kind of customization would make SlickEdit stand apart from other editors. I think this feature should be expanded to have sub menus and be able to remove features you dont want in the r-click menu.

9) One of the big advantages of SlickEdit is that its a crossplatform IDE. But you charge people separately for each OS version. So you are basically punishing people who would be your biggest customer which are programmers who use multiple operating systems, which is the future of programming as operating systems mean much less than they used to.

10) The UI for SlickEdit looks horrible in Windows, I cant see any professional who would want to use it in Windows because its too cheap looking. Part of the problem is a white window frame background looks bad. I use a dark theme in Linux so that the UI looks the same as it does in the screenshot on front page of the SlickEdit website. Another problem is that file manager panel on the left has too much indentation of file nesting. This is not so pronounced on the Linux version but on windows you lose a lot of horizontal screen space because you have to make the file manager very wide to accommodate this indentation.
« Last Edit: April 25, 2020, 06:36:59 pm by maxirater »


  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3076
  • Hero Points: 449
Re: my suggestions for improving SlickEdit
« Reply #1 on: May 05, 2020, 04:54:59 pm »
Just to let you know that we are not ignoring your suggestions.  We track all of the useful feature requests that people submit here in our defect tracking system.

I'd like to address part of #1.  We are working on adding substring searching for the next release (what you call fuzzy matching).  We do have a live-errors feature for Java, this is not something which we have been able to do for C++, however, our Symbol Coloring is a very good poor man's version of that, as it will highlight identifiers that are misspelled.  Our Context Tagging for C++ is otherwise very thorough, but only as good as the input, sometimes when your code makes extensive use of preprocessing, or other poor programming practices like side-effecting include files, the quality of the Context Tagging is compromised.  You did not give an example, so I have no idea why you did not see better results.  Frequently the problem isn't your code, but the libraries that you use, or failing to tell SlickEdit where the library source code is in the first place.

We have Dart and Julia on our future features list for language support, but no timetable yet.

With respect to #10, we have a dark theme, it is one of the first things you have a chance to select on the quick-start configuration.