Sublime Forum

The missing basic functionality thread

#1

I love Sublime. I do. I have paid the license and is my weapon of choice on OSX while hacking and working.

It might be just my opinion, but I feel that dev build after dev build we, the users, keep getting updates that don’t show a coherent priority order. In all seriousness, how many times have we read “Various syntax highlighting improvements” on the changelog over the past updates, instead of things like “SCM sidebar integration”? Wouldn’t it be great if we knew this is a thing that’s even being considered as a future feature?

This is not meant to be a rant. I’d like to compile a list of basic stuff that Sublime 3 does not support yet and turn this into hints to @jps or whoever moves the project forward. Things that most text editors/IDEs out there already have or feature one way or another and are part of a developer’s daily work. I expect that stuff on this list shouldn’t be considered part of “user land” or relegated to a plugin. They ought to be supported out of the box without the need of extending the editor or paying for additional software.

Things like the following (no particular order):

  • First class git integration.
  • Filename coloring based on SCM status.
  • Clear customizable file icons on sidebar, tabs and quick search menu.
  • Moving files around on the sidebar.
  • Renaming sidebar highlighted file with a shortcut (like the renowned F2).
  • Uncompressing .zip and .rar files to reveal actual content.
  • Notifications/popups/inline tooltips API to allow plugins to show relevant, elegant errors/warnings to users.
  • Allow file grouping on sidebar (show multiple files as being one, such as what Webstorm does with .ts and transpiled .js).
  • (S)FTP support.

This is, by no means, a comprehensive, complete list. What else can you think of?

2 Likes
#2

That’s the question, “What is basic editor functionality for an editor that specializes in being easily customizable?”

I’ve been a Sublime User for the better part of a year now, and it is my tool of choice for nearly any project I do these days. I love the addon community and activity. That’s what sold me on purchasing a license. That said, the first thing I had to do was to find and eventually buy addons for FTP functionality, SVN integration, and using my choice of diff tool. Since then, I’ve added and coded some new features that fit my particular workflow. I love how easy it is to extend this editor.

It would of been nice if the editor would of had those features directly out of the box, but for it to match what my workflow is while still being generic enough for all the other ways of doing Version Control is (as an example) would be onerous for the developer. Simply write a good API into the file handling and let addon authors do the rest. That way the users can pick and choose.

I feel that way for notifications. Good API for that should suffice. That may already exist for all I know.

The rest of the list I am ambivalent about because I have already found a good addon solution or I don’t use. From what little I know about the developer of Sublime Text (I’ve heard it is just one guy) I rather that he work on the things that inspires him to further development on this project.

I never would of thought I would of paid good money for an editor with all the good free ones out there. But it turns out that I like how he has designed Sublime and what it doesn’t have I can addon or program in. The rest of them that I’ve looked at/used are way too bulky for my tastes.

1 Like
#3

That’s the question, “What is basic editor functionality for an editor that specializes in being easily customizable?”

Well, this is exactly what I’m trying to answer here. And the point of the thread.

Simply write a good API into the file handling and let addon authors do the rest. That way the users can pick and choose.

I agree. Currently, no such API exists and there’s no way of knowing if one is even being considered.

I feel that way for notifications. Good API for that should suffice. That may already exist for all I know.

Again, agreed. So, you are with me in saying that this is a basic feature that’s lacking?

The rest of the list I am ambivalent about because I have already found a good addon solution or I don’t use.

Please, feel free to add more items into that list that you do use. Surely there’s something you’d like to have and that you consider basic stuff that could be thrown in or enhanced.

From what little I know about the developer of Sublime Text (I’ve heard it is just one guy) I rather that he work on the things that inspires him to further development on this project.

I found it very difficult to believe that “what inspires him” is “syntax highlighting improvements”. Call me apathetic, but I feel that those kind of “updates” are just there to justify buying a license. And it’s not just lately. It’s been years now.

0 Likes
#4

I think ExoticGel’s point was that most things you consider basic functionality should just be done using packages/plugins, created by whomever wants to implement them. That API obviously already exists, since there are thousands of sublime packages using it today. The question is if the existing API provides sufficient flexibility to achieve the things you’d like to do, and if not, what needs to be added to it to do so.

As for truly basic built-in functionality, the biggest thing I think is missing is the Package Control plugin itself - currently all first-time users have to (1) know about it, and (2) go copy-paste the install-string from the web to get it into Sublime. I think it should be built into Sublime itself, so you don’t have to install it separately.

3 Likes
#5

I find myself agreeing with some of your suggestions as being appropriate to work out of the box (such as moving files around in the sidebar, file icons, notifications etc).
However keep in mind that editors like Webstorm are code editors, and Sublime doesn’t pretend to be one.
Some of your features only make sense if you’re editing code. As such, they aren’t relevant to the entirety of use cases of a text editor and so (I think) belong in the plugin territory.

0 Likes
#6

That API obviously already exists, since there are thousands of sublime packages using it today.

If you’re calling “that API” to the python extensions, then yes, of course there is one. But that API splits into different tighter APIs (such as “sidebar API”, for example). And some of those APIs are close to non existent or very poorly implemented.

The question is if the existing API provides sufficient flexibility to achieve the things you’d like to do, and if not, what needs to be added to it to do so.

Exactly this ^.

As for truly basic built-in functionality, the biggest thing I think is missing is the Package Control plugin itself - currently all first-time users have to (1) know about it, and (2) go copy-paste the install-string from the web to get it into Sublime.

Thanks for adding that stuff to the list! While it doesn’t annoy me, I believe that to be true, as well.

0 Likes
#7

 
I agree with you in most cases of core feature requests, but a majority of the functionality mentioned in the OP is not available to developers via the API.
 

 
Out of the initial recommendations, I’d say these are already pretty well handled:

See: Git, SideBarGit, GitGutter, SublimeLinter, SFTP, etc.
 

 
However, it is not currently possible to implement the rest of the recommended improvements via the API:

All of these suggestions would be beneficial to workflow efficiency, and are common in other editors.
 

 
It’s nice to see that the ST development team is growing & focusing on improving existing functionality, but I also feel that ST should be more competitive in terms of innovation.

Editors like Atom & LightTable are quickly setting new standards for what an editor should be capable of, and as a result people are going to expect more from other editors ( including Sublime Text ).

IMO both of those editors are unusably slow compared to SublimeText, but to be fair, they’re both pretty new & are still under heavy development.  If they happen to match or surpass SublimeText ( performance-wise ), and ST hasn’t managed to keep up ( with overall features & API capabilities ) I wouldn’t hesitate to make the switch.

 

Additionally; from my experience, ST’s development hasn’t been the most transparent process.

This is apparent on the forum, and also in the real world ( Not too long ago, I gave a lightning talk to 100+ people on SublimeText package development and at the end got hit with something along the lines of “I heard Sublime Text isn’t even being developed anymore, do you know anything about this?”.  This was during one of ST development’s radio silence phases, so needless to say - I did not have a great answer.  As an active advocate of this software, it doesn’t feel so great to be left in the dark at times. ).

I think, in addition to the current improvements being made in ST, a clear ( official ) development road-map would inspire confidence in those of us who actively develop packages.

Trello has a great example of such a road-map.  It documents upcoming features, those in progess, and those which have been pushed to releases.

1 Like
#8

I find myself agreeing with some of your suggestions as being appropriate to work out of the box (such as moving files around in the sidebar, file icons, notifications etc).

Great. Thanks.

However keep in mind that editors like Webstorm are code editors, and Sublime doesn’t pretend to be one.

Oh, but it does. Again: just take a peek at the changelog. For a text editor “not pretending to be a code editor” I read the word “javascript” an awful lot.

Of course, I don’t have precise statistics, but I’d like to gamble on this and say that the vast majority of paid Sublime users came here looking for an alternative to “bulky IDEs”.

Some of your features only make sense if you’re editing code.

Some. But things like “moving files around the sidebar”, we could agree it does not.

As such, they aren’t relevant to the entirety of use cases of a text editor and so (I think) belong in the plugin territory.

No feature (ever) is relevant to the “entirety of use cases”. Some features appeal to some crowds and some to others. But I’m trying to generate consensus of what the “general crowd” wants included in the editor.

0 Likes
#9

@fico Thanks for the response!

I am with you in almost every point you make. The only exception would be your opinion on how well features like git integration and such are handled.

Let’s see:

First class git integration. I wrote first class there for a reason. Git + GitGutter are not bad, mind you. But it could be way better. Not having files colored depending on whether they are dirty or not and a lack of general visual grepping of SCM status (heck, it’s even hard to see which branch you are currently working on because the same status bar is used by so many other plugins for their own messages!) are a must.

Show relevant, elegant errors/warnings to users. Which plugin does this? This is certainly not “pushing a string warning to the status bar”. The only one that comes to my mind is TypeScript-Sublime and, TBH, errors on that look horrible in Sublime compared to what the same package does on other editors.

SFTP. You got to pay for this. Won’t even comment on that.

1 Like
#10

 
I’d argue that if the API allowed for it, those features could easily be implemented into the existing plugins.

I don’t think we need an entire rewrite, just a more flexible sidebar API and maybe a GUI API that allows extension of elements like status bar, sidebar, view, etc. ( example 1, example 2 )

 

 
SublimeLinter & it’s plugins do a decent job of linting.  Although, as you mentioned, the display of lint results could be greatly improved.

Visual improvement is available via the newer popup feature, but it hasn’t yet been implemented.  IMO, this is kind of a grey area since the raw functionality already exists and the plugin just needs some improvement on it’s implementation.  Maybe submit a feature request ( and/or pull request ) to plugins where you’d like to see improved notifications.  mdpopups provides a great, easy to implement solution.

1 Like
#11

There’s a popup feature? How come we haven’t seen that around? I’ll give it a try and see if this could serve the linters in any way.

1 Like
#12

if you want to see a very basic popup, type view.run_command('show_scope_name') in the ST3 console :slightly_smiling:

it is much more powerful than that shows, however :wink:

2 Likes
#13

Well, that kind-of is where the line gets fuzzy. I’d still argue syntax highlighting alone an IDE does not make. I think you’d be hard pressed to find other features like this aimed at code writers that come out of the box.

I respect that. What I meant by “relevant to the entirety of use cases” is that features that come out of the box could be relevant to any use case, while others strictly aren’t (like file grouping by extension for example, if you don’t use file extensions this could never be relevant for you).
I feel like I’m failing at explaining myself here so if you remain unconvinced perhaps we should let it go.

I suspect that the Sublime devs see things this way as well and would be very wary of feature bloat.
For that reason I don’t believe you’ll see out-of-the-box file grouping or git integration. The other features you had stated are inherently different and arguably appropriate.

Edit: Also integrated package manager - extremely appropriate.

0 Likes
#14

Broadly agree with @fico ie. missing functionality for me is everything that is about core and API, and nothing that could be implemented with plugins were Sublime’s API sufficiently flexible. So the focus should be on the core engine, functionality, API and and UI access via APIs. With sufficient flexibility in these areas, there’s little to nothing that can’t be done with plugins. Given that Sublime’s Python plugins run with a nice turn of performance, compute intensive processing could be performed for implementing complex, language appropriate IDE-style capabilities.

With all that said, here’s some major missing stuff from my perspective, in my priority order:

  1. Macros which can record and automate every aspect of Sublime. Notably missing is find and replace functions, a major weakness of Sublime for sophisticated text manipulation.
  2. Sidebar APIs for allowing the sidebar to be populated and controlled by plugins.
  3. Sort out command line behaviour, messy at present.
  4. Improve code-folding to make it language aware and sticky for workspaces. At the moment block folding is dumb ie. based purely on indent level.
  5. Performance of editing engine for large file and long line handling. Editing massive SQL dumps is a no-go in Sublime presently, especially if they’re on one line.
  6. Greater abilities to interact with UI elements, both within the text and outside (ie. status bar)
  7. Find/replace in files that doesn’t open up all the files.
  8. More API flexibility generally, eg. ability to define text zones based on scopes which could support change events, cursor/mouse events etc.
  9. Oh, and bugfixing. There’s shedloads of little bugs (too many to mention here) which have been around since ST2. It’d be lovely to have a sustained bug-squashing effort to tidy them up.

You get the idea. Some of the above are simple, some complex, but most are about unlocking the ability for plugins to rock, while making the core editor functions fast and flexible. With that in mind, plugins could be written to do almost anything, and given the performance of Sublime’s plugins, sophisticated text processing could be automated along the lines of products like PHPstorm with comparable performance.

6 Likes
#15

Totally on board here.

This is key. I wonder what’s preventing @jps to deliver that. Time? Maybe the refactoring implications to get this working?

If that’s a “no-go” in Sublime, I wonder what would it be in other text editors/IDEs such as Eclipse.

+1

Didn’t think of that one before, but now that you’re bringing it to the table I think this needs to be on my list too.

For me, ST has the potential to become the text editor of choice for coders. The foundations are there. But for some incomprehensible reason, it has taken a turn for the worse, clearly falling behind the troupe of newcomers.

1 Like
#16

more, more API… if API will be extended, the rest of the job / missing functionality will be doing by people ( plugins etc. )

0 Likes
#17

 
That’s pretty much the entire reason ST is such a great editor.

Would you rather wait for a handful of people ( the ST dev team ) to fix all of the bugs, implement & improve basic functionality, and then get around to feature requests ( based on their personal priorities & preferences ), or just have a more powerful API so that 2k+ plugin authors can create an exponentially larger feature set at an exponentially faster rate?

0 Likes
#18

Someone could probably just write a plugin to run the find replace and then save and close the file. Would hate it if this was default functionality. I want to know every file that has changed when doing this kind of thing.

1 Like
#19

Most of the time (for me, at least), the default, mechanic chain of command is: find/replace, save all, close all tabs. That’s roughly 90% of the time. Maybe change default behaviour and make the current one opt-in?

1 Like
#20

I did pay, both for ST and plugin.
Must say working with ftp files is a pain - at best.
Stopped using it after a day.
It is sad that developer is working on thing that amuses him, and not on real user needs. (here I trust there are more users that like ST and need proper ftp functionality)

2 Likes