7 ms·

Your position is totally reasonable, but I would argue that ST is better off with a smaller feature set and a robust plugin ecosystem. The last thing I would wa

Your position is totally reasonable, but I would argue that ST is better off with a smaller feature set and a robust plugin ecosystem. The last thing I would want to see is for ST to become the Microsoft Word of text editors, i.e. a million built-in features, of which you might only use 5%. Addendum: It dawns on me that building the Microsoft Word of anything is probably not a bad goal, considering it's the dominant word processor. It's not what I would want in a text editor, but it may very well be what most people want most of the time.

hn8788 6y ago
I think some features that are currently plugins could stand to be integrated into the main editor. For example, language server functionality is only available through a third-party plugin, and a year or two ago there was a couple month period where the plugin install was broken due to a dependency issue. Anyone who installed ST during that time would have been out of luck if they wanted to use progamming language plugins that required a language server.
- nickelcitymario 6y ago
  I'm not entirely familiar with "language server functionality", but it sounds like something that isn't needed for most text editing situations. So it's a perfect candidate for a plugin. I'm not knocking this functionality. It's probably super helpful, useful, or downright required in the work you do. It sucks that the plugin was broken. However, the fact that the plugin was broken tells me there's a problem with the plugin ecosystem, not with the editor.
  - bogwog 6y ago
    See language server protocol: https://en.wikipedia.org/wiki/Language_Server_Protocol https://en.wikipedia.org/wiki/Language_Server_Protocol If you have a programming language, you can write a "language server" for it that is compatible with the standard language server protocol. Once you have that, you can use your programming language in any text editor that implements an LSP client, and get full IDE-like features for free. Whether code intelligence/intellisense style features are important to you is another story, but it is an incredibly useful thing to have in a general purpose tool for editing code (and I believe most ST users are programmers). IMO, it makes much more sense to have that built in to ST as a first class feature, than to have it only available as a community plugin. > However, the fact that the plugin was broken tells me there's a problem with the plugin ecosystem, not with the editor. That's exactly why it should be built in to the editor. For many people, LSP support is a deal breaker.
    - nickelcitymario 6y ago
      Now that I understand this functionality better, you may be right. I'm on the fence about whether it really should be built-in, but I can appreciate why you'd want it to be. In effect, you're asking for the ability to extend the list of supported languages by specifying them on an ad hoc basis, and I can definitely see why that's an absolute must-have if you're working in a language that isn't built into the editor. (I really hope I'm capturing the functionality correctly.) That being said, I suspect most developers rarely work in languages that aren't supported, so even IF this should be built-in, it seems like something that most users would never use. While I think that's perfectly reasonable in an IDE, I think a text editor should be limited to features that are used by a majority of its users for the majority of the time. It's not that I'm saying this isn't crucial functionality. It's that if we start requiring text editors to have every bit of crucial functionality that anyone might have, you end up with an IDE. I still think the problem is the plugin ecosystem. What would stop the Sublime team from saying, in effect: "This is functionality that should always and reliably be available for those who need it, so we're going to take responsibility for maintaining this as a plugin"?
      - crooked-v 6y ago
        > I suspect most developers rarely work in languages that aren't supported Well, obviously, developers who work in language A aren't going to use an editor that doesn't support language A. They might want to use that editor, though.
        nickelcitymario 6y ago
        No argument there. But Sublime does support those languages. You just need to install the right plugin. The question is whether this should be baked in, or whether it should be managed with plugins. There are lots of features people might want. Including them all creates a bloated text editor at worse, and a mediocre (IMHO) IDE at worst. I maintain that Sublime isn't and shouldn't be an IDE. So they're better off only including the features that are very widely needed for a text editor, and then supporting the rest as plugins. After all, isn't the ability to extend Sublime with plugins one of the biggest selling points? By being lean, it wastes as little computing power as possible on stuff you don't need, while giving you the ability to include virtually any functionality you do need. I get that sometimes plugins fall out of active development or are broken for unacceptably long periods of time. But if the feature is something that the Sublime dev team wanted to support, there's no reason they couldn't support it as a plugin. Baking it in doesn't solve this problem, but it does create bloat. I guess what I'm saying is: Why does language server support deserve to be baked-in more than any other feature? I have plenty of mission-critical needs that are supported by plugins. I don't expect them to be baked in just because they're important to me. I accept that the plugin ecosystem is the solution for my needs. What makes language server support -- or any other beloved functionality -- so special?
  - Shorel 6y ago
    True, but at the same time it has evolved into something required for modern development. So: new features -> plugins. Required features -> converted from plugins to native.
    - nickelcitymario 6y ago
      > new features -> plugins. Required features -> converted from plugins to native. I like that framing. What counts as required will always be up for debate, but I like that framing. > at the same time it has evolved into something required for modern development. Has it? Is the implication that any development done without it is somehow not modern? Or that most modern development tend to eventually bump into this requirement? Assuming you mean the second one, I'm not sure that's true... it certainly hasn't been true for me, but maybe I'm in the minority and don't realize it. Edit: I'm an idiot. Leaving this comment as-is, so as to not hide my shame. I see now why this feature in particular should probably be baked in.
jpalomaki 6y ago
For more casual user (me) a large plugin ecosystem makes things complicated. It means you need to invest time to understand which ones to pick and this might be changing all the time as projects are abandoned and forked. For Eclipse there was (is?) something called MyEclipse which was paid software and contained a curated set of plugins.
- nickelcitymario 6y ago
  An excellent point. My solution to this would be (ironically) to add one feature to Sublime: Grouped Packages. Simply put, the idea would be to define a set of plugins needed (or recommended) for certain types of development. So you'd install Sublime, and then have a handy popup asking if you want to install any of the suggested Grouped Packages. There might be a dozen or so that are commonly useful for a Rails developer, another group that's useful for C, or for Wordpress, or whatever. That would allow for a minimal text editor, the infinite possibilities of plugins, and also easy onboarding for new users. It would also be useful for advanced users who are getting started in a new field.

hn8788 6y ago

I think some features that are currently plugins could stand to be integrated into the main editor. For example, language server functionality is only available through a third-party plugin, and a year or two ago there was a couple month period where the plugin install was broken due to a dependency issue. Anyone who installed ST during that time would have been out of luck if they wanted to use progamming language plugins that required a language server.

nickelcitymario 6y ago
I'm not entirely familiar with "language server functionality", but it sounds like something that isn't needed for most text editing situations. So it's a perfect candidate for a plugin. I'm not knocking this functionality. It's probably super helpful, useful, or downright required in the work you do. It sucks that the plugin was broken. However, the fact that the plugin was broken tells me there's a problem with the plugin ecosystem, not with the editor.
- bogwog 6y ago
  See language server protocol: https://en.wikipedia.org/wiki/Language_Server_Protocol https://en.wikipedia.org/wiki/Language_Server_Protocol If you have a programming language, you can write a "language server" for it that is compatible with the standard language server protocol. Once you have that, you can use your programming language in any text editor that implements an LSP client, and get full IDE-like features for free. Whether code intelligence/intellisense style features are important to you is another story, but it is an incredibly useful thing to have in a general purpose tool for editing code (and I believe most ST users are programmers). IMO, it makes much more sense to have that built in to ST as a first class feature, than to have it only available as a community plugin. > However, the fact that the plugin was broken tells me there's a problem with the plugin ecosystem, not with the editor. That's exactly why it should be built in to the editor. For many people, LSP support is a deal breaker.
  - nickelcitymario 6y ago
    Now that I understand this functionality better, you may be right. I'm on the fence about whether it really should be built-in, but I can appreciate why you'd want it to be. In effect, you're asking for the ability to extend the list of supported languages by specifying them on an ad hoc basis, and I can definitely see why that's an absolute must-have if you're working in a language that isn't built into the editor. (I really hope I'm capturing the functionality correctly.) That being said, I suspect most developers rarely work in languages that aren't supported, so even IF this should be built-in, it seems like something that most users would never use. While I think that's perfectly reasonable in an IDE, I think a text editor should be limited to features that are used by a majority of its users for the majority of the time. It's not that I'm saying this isn't crucial functionality. It's that if we start requiring text editors to have every bit of crucial functionality that anyone might have, you end up with an IDE. I still think the problem is the plugin ecosystem. What would stop the Sublime team from saying, in effect: "This is functionality that should always and reliably be available for those who need it, so we're going to take responsibility for maintaining this as a plugin"?
    - crooked-v 6y ago
      > I suspect most developers rarely work in languages that aren't supported Well, obviously, developers who work in language A aren't going to use an editor that doesn't support language A. They might want to use that editor, though.
      - nickelcitymario 6y ago
        No argument there. But Sublime does support those languages. You just need to install the right plugin. The question is whether this should be baked in, or whether it should be managed with plugins. There are lots of features people might want. Including them all creates a bloated text editor at worse, and a mediocre (IMHO) IDE at worst. I maintain that Sublime isn't and shouldn't be an IDE. So they're better off only including the features that are very widely needed for a text editor, and then supporting the rest as plugins. After all, isn't the ability to extend Sublime with plugins one of the biggest selling points? By being lean, it wastes as little computing power as possible on stuff you don't need, while giving you the ability to include virtually any functionality you do need. I get that sometimes plugins fall out of active development or are broken for unacceptably long periods of time. But if the feature is something that the Sublime dev team wanted to support, there's no reason they couldn't support it as a plugin. Baking it in doesn't solve this problem, but it does create bloat. I guess what I'm saying is: Why does language server support deserve to be baked-in more than any other feature? I have plenty of mission-critical needs that are supported by plugins. I don't expect them to be baked in just because they're important to me. I accept that the plugin ecosystem is the solution for my needs. What makes language server support -- or any other beloved functionality -- so special?
- Shorel 6y ago
  True, but at the same time it has evolved into something required for modern development. So: new features -> plugins. Required features -> converted from plugins to native.
  - nickelcitymario 6y ago
    > new features -> plugins. Required features -> converted from plugins to native. I like that framing. What counts as required will always be up for debate, but I like that framing. > at the same time it has evolved into something required for modern development. Has it? Is the implication that any development done without it is somehow not modern? Or that most modern development tend to eventually bump into this requirement? Assuming you mean the second one, I'm not sure that's true... it certainly hasn't been true for me, but maybe I'm in the minority and don't realize it. Edit: I'm an idiot. Leaving this comment as-is, so as to not hide my shame. I see now why this feature in particular should probably be baked in.

jpalomaki 6y ago

For more casual user (me) a large plugin ecosystem makes things complicated. It means you need to invest time to understand which ones to pick and this might be changing all the time as projects are abandoned and forked. For Eclipse there was (is?) something called MyEclipse which was paid software and contained a curated set of plugins.

nickelcitymario 6y ago
An excellent point. My solution to this would be (ironically) to add one feature to Sublime: Grouped Packages. Simply put, the idea would be to define a set of plugins needed (or recommended) for certain types of development. So you'd install Sublime, and then have a handy popup asking if you want to install any of the suggested Grouped Packages. There might be a dozen or so that are commonly useful for a Rails developer, another group that's useful for C, or for Wordpress, or whatever. That would allow for a minimal text editor, the infinite possibilities of plugins, and also easy onboarding for new users. It would also be useful for advanced users who are getting started in a new field.