Keeping up with other Editors (Slickedit still rocks)

[greggman]

This is going to be just some random thoughts/requests/wishes....

I've been a slickedit user since 1993. Recently though I've been getting jealous of other editors. Specifically SublimeText and Visual Studio Code. I have no idea why they have such large followings compared to Slickedit. I suppose VSCode partly because it's free and partly because it's JavaScript making writing plugins accessible to more programmers. Sublime I have less of an idea. I think it uses python as its scripting language so maybe that helps? It's also only $80 per use for all platforms. Not that I personally think price should matter (I've been paying for Slickedit for 25 years!) but it could be one reason. Basically Sublime is on-your-honor shareware.

Anyway, every year or so I try to switch for various reasons (I always fail to switch so far 😉)

The biggest reason is to take advantage of some of the newer features that are becoming available for VSCode. Microsoft announced their language server standard

https://github.com/Microsoft/language-server-protocol

The idea is that an external process can do all the language processing and ANY editor can talk to that process to get language info. This makes it easier to take advantage of tools in any language to write the context help.

Has Slickedit considered supporting that?

Having tried VSCode for a while a few things I REALLY enjoyed

1.  At least for JavaScript/node.js projects VSCode is project aware

In a node.js project you declare your dependencies in a package.json file. VSCode looks at that file and can tell you if you're missing dependencies. For example you might type `somelib.someFunc` and it will warn you you don't have `somelib` listed as a dependency.

2. VSCode is external lint aware

In JavaScript land it's common to use ESLint. ESLint has 100s of options and they are different for each project. There are various ways to specify the options including putting .eslintrc files in any folder. VSCode reads these and can highlight lines not matching that project's style guide. It can also auto fix individual or in bulk many of the issues

3. VSCode (vs ESLint?) is library aware.

#2 above has a huge added benefit. People like Facebook have added library specific lint rules so you'll get warnings about usage, deprecations, etc directly in VSCode on the correct lines with options to auto correct

4. They've got a built in marketplace for plugins

I don't know if Slickedit's userbase is big enough to support a plugin market but it's arguable that the fact that it's so easy to browse and add plugins directly from the editor encourages people to write them. In fact the first time you run VSCode it shows the top recommended plugins.

Sure editors since vi and emacs have allowed customization as does slickedit (and in the past I've written a bunch) but AFAIK there has not been the community for them like there is for VSCode. I'm sure the marketplace is only part of it though.

I could list many other minor issues but those are probably the major things making me want to switch. Basically the ability to benefit from community contributions.  Any way Slickedit could become a part of that community and/or have more of one would be great.

[mjdl]

 Good points, but I'm wary of a couple of them (and will inadvisedly put my head above the parapet with obvious and uninformed remarks):

1) Disproportion of corporate manpower resources available. There's no way SlickEdit can match the number of people Microsoft must have on the VSCode team. The effort needed to define & implement the language server protocol (in addition to the editor itself) is an example.

2) Product strategy: I don't use VSCode, but one way it functions is like a gateway drug for the other development tools/cloud/services of Microsoft, particularly Visual Studio. It's a canny strategy for MS, since it is freeing them from the enclave and reputation of just Windows developers, they now get to a huge base of e.g. Javascript-savvy people. At the same time, a product like VSCode is very narrowly defined in terms of coding and tool targeting compared to SlickEdit: VSCode just covers technologies the MS ecology/platforms needs, SE is more open (and sometimes it's hard to remember or find that it actually already has a particular feature). In particular, MS will want people using VSCode to be reminded that by moving "up" to some version of Visual Studio, they will get a development platform highly tuned for precisely the technologies already supported by VSCode.

3) Product evolution: MS's Visual Studio has become more and more "componentized" in recent versions, so they're able to extend support with relatively less effort to all kinds of development technologies that weren't invented at MS (e.g. the PHP. mobile, and other stuff). I get the impression that SE is still in the process of chopping up its monolithic structure (both binaries and the macro code) inherited from a (by now) very long history, into something more suited to desired "plugin" extensibility (e.g. the SE hot fix feature might evolve into something like a plugin or modules facility, but it would probably have to carry a lot more metadata about the editor configuration than at present, and the editor itself would have to produce/consume that metadata). As you say, that kind of thing would perhaps open the way to more community contributions to deepening the editor's support for particular technologies/tools.

4) Editor extensibility language(s): being able to extend SE in a more widely known language such as JavaScript sounds great, but I wonder if the effort is worth-while, given that practically all the API and the extensibility features like dialog inheritance would have to be shoe-horned into the particular semantics of the other language. Much better, I think, to put time into the existing extensibility tools & features so that they are more attractive and easily managed in a plugin-like fashion.

[Clark]

Keep the comments coming. Everybody has different opinions about things.

There does seem to be some misconceptions about plugins being the answer for everything. Adding a full featured language plugin (with context tagging) for any product is more work than any customer would be willing to do for free. SlickEdit can easily be enhanced with macros but DLLs are only supported on Windows right now. DLLs are typically only needed when implementing high performance features like context tagging which like I already said, no customer would be willing to implement for free.

Another misconception is that using a non-proprietary language (like JavaScript, Python, Java, C#) would be a better way to go than Slick-C. If this were the case, we would have already done this. I would have to write too much here to convince everyone that it would be a disaster. If we started over today, we would design a proprietary language that was C# like because it comes closest to giving us the power and language design we need. Notice that I've said that it would have to be proprietary (not exactly like C#- no signature overloading, very different APIs -- we need really good Utf-8 support and killer dynamic linking). I'd have fun implementing it but because it would also be proprietary, it wouldn't be exactly what people want.

We had planned for a new plugin architecture (without DLL support) for v22 but it didn't make it (website portion not finished). If you look, v22 ships with a macro file called plgman.e. It's not loaded (don't use the plugin_manager command). This stuff is totally undocumented but I'm using it to package the macro files I used into a plugin which gets loaded at start up. At the moment, this plugin stuff would be considered experimental. In some cases, users will be able to create a plugin WITHOUT writing any code at all. For example, you can create a plugin for a color profile and have that color profile configured as the default edit window color profile when the plugin is loaded.

[jporkkahtc]

I've not used vscode much, but right away I found it won't even try to load large files. I don't know exactly the limit, but it is pretty small. Maybe OK for small projects, but it fails at scale.

That seems true of other editors I've tried on -- try editing some really big file. Either they refuse, or performance is unbearable. (or editing some large number of files, or having 50,000 files in your workspace, etc...)

There are certainly a lot of features I'd like in Slickedit, but I'd hate to lose the performance.

Hard to say what prevents Slick from being more popular. I've found that coworkers are very reluctant to try to just because it isn't free and they don't want to bother asking the company to buy it.

A free version would really help, but then, how does Slickedit Inc. make money?

[joecar]

Free...!?  You get what you pay for 

I do linux kernel code... I know how to use vi/vim (free)... but I prefer SlickEdit (paid).

What I really don't understand is:
my peers insist on Codewright    even tho I clearly run rings around them with SlickEdit 

[guth]

I bought Slick 12 years ago just because it can do very long lines without performance degradation. If you, like me, write some LaTeX and want to keep a paragraph as a line for easier searching, then you really like Slick. At the time, Vim was really slow on long lines. TextMate was slow, and Emacs strength is not long lines. But BBEdit was really fast, though.

After some years I began doing programming full time, and then Slick is your friend. I'm very accustomed to doing Diffzilla on files in version control systems. The check out from within Slick is also helpful.

I try to setup Emacs every now and then, but most often fail. Is is possible, though, to use spacemacs, which is a good example of a plugin system, but I still can't get an environment where I feel comfortable. Most probably I'm too accustomed to Slick...

[greggman]

A little bit frustrated that most of the comments here seem to be defensive. The point of the thread is to consider ways to make Slickedit even better. Not to bash it.

One of the things VSCode has going for it is community contributions. Slickedit doesn't really have that. People are writing tons of plugins and some of them are extremely useful. Is there a way to bring that to Slickedit?

Microsoft's Language Server Protocol is available to be used by any editor that bothers to support the protocol.  That would be one way to take advantage of community support. Could Slickedit piggyback off that support by adding support for the protocol? Would it be a plus?

ESLint integration is amazing for JavaScript, especially that it has library specific rules which are a huge performance boost and it's per project configured help me to match each projects' coding style. How can Slickedit do something similar?

I agree 100% that Slickedit has its strengths. Like I said in the original post I'm still using it. That said it feels like it's losing ground. Already if I'm doing JS/Node/React etc the benefits if using VSCode *mostly* outweigh the pluses I get from Slickedit. I'm not yet a fan of the current VSCode for various reasons where slickedit is better. But I can't deny that for JS dev VSCode's pluses are indispensable.  I don't like being torn between the two so just here to mention some of the features I found useful that I wish slickedit could maybe provide.

[tealduck9]

I have to say that the line "DLLs are typically only needed when implementing high performance features like context tagging which like I already said, no customer would be willing to implement for free." is totally NOT true. There have been many times where I have considered doing just that to get this editor to work with a particular language. I would also be willing to bet that I'm not alone and could find help for such a thing through the forums.

[Clark]

I'm referring to the non-toy situations where implementing context tagging even would take us at least a month which means it would take a customer longer. Context tagging is only part of the work. Then there are other features to be implemented which can also be difficult (maybe a beautifier, smart editing, debugging, Project support etc.).

Over the years, no one has implemented any parsing with DLLs (who wasn't being paid for it). The APIs have been there for Windows. Many have implemented a simple proc_search function for various languages in Slick-C because it doesn't require anywhere near the effort.

[greggman]

They may not have written them for Slickedit. They are writing them for the Language Server Protocol

See list here including languages, who's maintaing them, and which editors have integrated support

https://langserver.org/

[jporkkahtc]

I have tried my hand at it (tagging/symbol support) for Slickedit -- there is (or was?) no clear documentation, nor clear examples, nor a reasonable API for implementing these. (Just from Slick-C).
Slick could make it a lot easier for people to implement this stuff.
The code in macros\* has definitely been improving over the years, but there is a lot more that could be done to make it more user friendly.
Making it easier for users makes it a lot more likely that users will actually do some of the work.

[Clark]

They may not have written them for Slickedit. They are writing them for the Language Server Protocol

See list here including languages, who's maintaing them, and which editors have integrated support

https://langserver.org/

We will have to check this out

[mjdl]

Re,. adding language support: Is it time to update the 2008 blog posting Tutorial: Adding Language Support to SlickEdit to take account of the changes that may have occurred since then? I tried finding a similar tutorial in the 2017 Manual & Help files, but I must have missed it: something like it it would be an excellent addition to the existing help documents.

Also just take a look at results of a forum search "adding language". Some interesting results.

And maybe as an intermediate step to improved documentation (or even a replacement for it), the SE developers could take one of the simpler shipped language definitions and extensively annotate the what/why/how of the various macro and other files involved in it with detailed comments in the files themselves.

[Dennis]

This is on my to-do list.  But, I have a very long to-do list.  I am currently working on a Rust parser that uses our parser generator, slicklex.  What I want to do is add a copy of that to the sample projects we ship with SlickEdit, and document slicklex thoroughly.  We're using slicklex for several languages now, including Fortran and all the variations of SQL (Few people know that SlickEdit has one of the few complete PL/SQL parsers not written by Oracle, as well as Transact/SQL and DB2).  Slicklex is currently an internal tool, but I'd like to make it available to power users in a future release.

I agree with Clark that we will have to look into LSP.  So far, the docs I'm seeing are pretty sketchy and unclear about what dependencies it has with respect to tools and the environment necessary to run these various language plugins.  I hope this isn't another GDB/MI protocol type of thing that changes every time we blink our eyes, and doesn't actually match the specification.  Nevertheless, what it promises sounds good on paper.

[mjdl]

I agree with Clark that we will have to look into LSP.  So far, the docs I'm seeing are pretty sketchy and unclear about what dependencies it has with respect to tools and the environment necessary to run these various language plugins.  I hope this isn't another GDB/MI protocol type of thing that changes every time we blink our eyes, and doesn't actually match the specification.  Nevertheless, what it promises sounds good on paper.

Well, I'd concentrate on making internal tools fit for end-user use (insofar as they are genuinely useful for advanced extensibility, such as the lexer generator might be for dealing with variants of a language already supported by SE), rather than chasing after external tooling specification/software dependencies: I mean that there are already enough just in tracking essential external dependencies such as changing language specifications and tools like GDB!