I haven’t used Sublime Text since around 2010 but decided to install this latest version to try it out. I’m actually blown away by the speed and efficiency - beyond simply the startup speed.
Hm I think this should be pretty obvious, no? It’s pretty clear that ST is faster and more robust, but it’s also obvious that VS has more semantics-aware features. Some people value features over speed.
It’s beyond me how people can love any specific editor? Editing text sucks everywhere except in kakoune, only IntelliJ has enough polish&power to work efficiently with large projects, everyone except VS gets plugin ecosystem wrong, nothing but Emacs has efficient keyboard drive UX outside of mere editing, and only vim is installed on the server you ssh to.
Eh, close. There’s a concern I’ve seen in many devs (including, in my younger years, me) that, if you’re not using the best tooling, then you’re doing it wrong. But if you spend a lot of time trying to decide what is The Best Tool, and then really learning it, then you end up feeling a really strong need to defend whatever choice you end up making. After all, you don’t want to admit you wasted that time by making the wrong decision, do you? The more time you spend defending your choice, the more you start to identify with the choice, which in turn makes you very resistant to anything that challenges you, and very quick to overly emphasize anything positive.
Anyway, that’s a long way of saying that the mindset that results in people loving editors is less Stockholm Syndrome, more political cult, but you’re not far off.
And besides, we all know that the best editor is unconditionally and with no qualifications ed.
Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.
I find great value in rich feedback (syntax errors, typing errors etc) from an editor/IDE so bringing this to the actual text operations is very interesting.
A friend of mine told me; people use electron-based editors and then are blown away with the speed of something that isn’t electron. Like obviously with something like editors, being written in say C(++) for example, is going to be faster than something that runs off web technology.
A proper MRU ctrl-tab and a built in split terminal easily togable without lifting my hands from the keyboard did it for me.
Opening file in project using quick open and a command palete, were also requirements of mine, but other editors already had these. Sublime being one of them.
I have been wanting these simple features in an editor since before vscode existed. Vscode offers me that, I use it. I would be fine with other editor offering them too.
Their multi edit support is also ofnmy liking and I.ve been including it in my work flow more and more often.
I wonder, if there are any plans regarding first class support for LSP (or, more generally and perhaps more useful, first class support for extensions providing semantic knowledge about the code).
I know that LSP plugin exists, but, anecdotally, folks are having trouble with it. Which i think is understandable https://lsp.sublimetext.io/features/ says Show Code Actions: UNBOUND, and this is the second most useful thing in LSP (the first is extend selection), it’s not that the plugin is wrong: it’s just that you can do only so much if the editor lacks first class UI/UX concepts for features, required to expose LSP to the user.
Agree that, as a protocol, LSP is not great (it’s good enough, which means we are stuck with it now). That’s why it’s better not to support LSP per se, but to support extensions which are semantic aware.
VS Code has the right architecture there. VS Code doesn’t implement LSP protocol. Instead, it provides structured extension API to, eg, display code actions or completions. These extensions are directly reflected in the editor’s UI (the 💡) but are not directly tied into LSP. It’s up to extension to bridge editor API and LSP server.
That’s why I worry about upcoming build-in LSP in neovim: they seem to add LSP directly to the editor, which I don’t think is the best approach, given the systems effect of open source community.
I disagree with you again, which worries me because you’re clearly the expert of the two of us :-).
Maybe LSP for big languages is a whole different games than for small languages (or even for bespoke stuff). If you write the LSP implementation for Rust, you expect to be able to put significant effort into it, and to have people write decent extensions for most editors. In this case a semantic extension wrapping the LSP protocole can make sense and probably yields higher quality results.
On the other hand, if, like me, you’re more excited about LSP because it lowers the barrier to entry significantly for smaller projects (random example: Idris, but I can cite more obscure stuff), then being able to interface with it directly is very useful. The language extension might still exist to provide basic syntax coloring (easier/faster than in LSP imho), and you get basic completion, goto def, etc. This will not rival Intellij, but it’ll be orders of magnitude better than nothing. And if the editor directly supports LSP at least it’ll be reasonably fast and the UI will be ok. VSCode makes this a pain in the butt because you can’t just test your LSP server, you have to write typescript, publish the extension, etc. It removes (some of) the work-saving benefits LSP was supposed to bring.
An interesting possibility for more custom LSP servers is to have custom methods ($/<method>, iirc?) and then each editor plugin can wrap that to the tune of the editor. I wish LSP was a bit better designed, but we’re probably stuck with it indeed.
I don’t think we are disagreeing: it’s indeed true that, for smaller languages, having one thing built in is better. But I think the small here needs to be small indeed. Like, if we take idris as an example, vscode has a couple of non trivial plugins for it:
I completely agree also that plugin development workflow is absolutely bonkers for developers. Getting an access token to actually publish the extension is a real quest.
However, experience for users is really nice: they get prompted to install a plugin, and then plugin guides them through the necessary setup (or it just works).
I know that LSP plugin exists, but, anecdotally, folks are having trouble with it. Which i think is understandable https://lsp.sublimetext.io/features/ says Show Code Actions: UNBOUND, and this is the second most useful thing in LSP (the first is extend selection), it’s not that the plugin is wrong: it’s just that you can do only so much if the editor lacks first class UI/UX concepts for features, required to expose LSP to the user.
Doesn’t UNBOUND here just mean “doesn’t have a default keybinding”? Several of the other “UNBOUND” actions have recommendations for a specific key you could bind it to.
edit: yeah, I just gave this a keybinding with rust-analyzer and it works fine. I don’t really get why you think there’s missing “first class UI/UX concepts for features” here – it’s just the default preferences not setting this to anything in particular. There is a UI for presenting these actions to users.
If this is just a complaint about a lack of out-of-the-box keybindings, that’s not really a sublime-specific problem, you see the same phenomenon in a lot of emacs and atom and vscode packages too – I think that’s just down to the difficulty of avoiding clobbering something no matter what you ship with, and not everybody sharing your assessment of the criticality of “code actions” (never use the thing, myself. Nor “extend selection”. I think what most people want out of LSP is type-aware completion, personally ¯_(ツ)_/¯ ).
edit 2: and actually, it doesn’t even need a keybinding. Reverting to out-of-the-box settings (I had some other customizations running which turned this off), it defaults to showing code actions in-line with the code when your cursor is on the line – so there’s actually multiple UI/UX ways this is presented to the user and it is UX that’s surfaced out of the box. Really struggling to parse what your complaint is here, given that this is the default presentation in vscode as well
My complaint is indeed about default UX. UX matters a lot. To give a sublime related example, everything you can do with multiple cursors, you can do with Emacs/Vim macros. The functionality is the same: applying edits in lock step to many places. The difference is in the UX, and it is enourmous.
And yes, poor UX for semantic features is problem in every editor for except IntelliJ. I try to complain about everything I notice :)
Not having shortcut assigned by default is a big UX problem. As a new user, I don’t know if shortcut is need and which one is convenient. It’s developer’s job to say: “hey, we have a thousand actions, but here are the ten most important ones. Note the default shortcuts we carefully chose for them, avoiding conflicts and making combinations easy to remember”.
On a positive note, I’ve noticed that code actions UX is massively improved between 3 and 4. 4 now shows an indicator if code actions are available, and that’s the core idea of the lightbulb feature indeed. That’s exactly first-class support for semantic aware features I want to see more of.
I think what most people want out of LSP is type-aware completion
I agree here. And this is exactly the problem: people don’t know what tools are available, they can only want what they know about. So folks want code completion exactly because it just pops out there without any user interaction, so they can not not use it.
Authors of tools generally have better idea about which features are important, because they spend a lot of time thinking about and working with them. Exposing this knowledge about effective workflows via polished out of the box UX is a requirement for making the the features create value for end users.
Not having shortcut assigned by default is a big UX problem. As a new user, I don’t know if shortcut is need and which one is convenient. It’s developer’s job to say: “hey, we have a thousand actions, but here are the ten most important ones. Note the default shortcuts we carefully chose for them, avoiding conflicts and making combinations easy to remember”.
Ok. Not sure I agree that code actions needed to ship with a keybinding given that it surfaces in the UX as a prompt but that’s fine.
The thing is, though, this feels like it has nothing whatsoever to do with the original comment, which you spammed both here and at hackernews. In both places you wrote:
it’s not that the plugin is wrong: it’s just that you can do only so much if the editor lacks first class UI/UX concepts for features, required to expose LSP to the user.
The developers who decided not to ship Code Actions with a keybinding are the plugin authors, who are not the authors of the editor. And yet you wrote that the plugin wasn’t at fault and chalked it up to some implied deep failure of Sublime Text itself to provide “first class UI/UX concepts” that the plugin would have needed to expose Code Actions to the user. Again, what “concepts” are missing? The plugin could provide keybindings for it, if it so chose. It does provide a “lightbulb”-style UI for surfacing the actions by default. Nothing whatsoever appears to missing that prevents exposing Code Actions to the user.
What’s missing? Because I get the distinct impression here you misunderstood the features list to mean the actions weren’t surfacable and then spammed an identical rant to a bunch of forums about it.
Meta note: I don’t find the “spammed” wording helpful. On HN, I replied to a direct request for questions from ST developer. If I had seen the HN thread first, I wouldn’t have made a lobster comment. I put time to condense my relevant experience (like this bit of feedback) into a paragraph, it doesn’t feel great to see it dismissed as spam.
Let me try to clarify. There are two things that I don’t know. As I don’t closely follow ST development, I enquire about them, also providing my, complimentary, view of an LS developer.
On a strategic level, I wonder what is ST position for “doing semantic stuff that VS Code does”. I was surprised to read nothing about it in ST4 announcement. I would expect to hear either “we find LSP ecosystem useful, so we’ll work on integrating with it better” or “LSP is clearly popular, but it simply can not provide the latency guarantees we need, so we are building our own thing, stay tuned” (the thing they could build is something a-la https://lobste.rs/s/ujr9mg/how_do_you_index_code_your_projects#c_buj3rg they already have all the infra for it, and only need to replace approximate syntax definitions with precise parsers).
On a code architecture level, I wonder what the relation between ST and LSP plugin is. My bit of feedback here is that it’d be best if things like Code Actions are concepts of the editor itself, but their implementation is left to a plugin (where LSP is one, but not the only, possible implementation). See how they are documented in VS Code. It’s the editor that provides keybindings and UI, but it’s extension that populates this specific UI. Code Action here is just an example (which I picked because I’ve seen many people stumbling over them in ST). There’s a number of other things which are first-class in VS Code, but which I don’t see mentioned in ST LSP docs (outline, breadcrumbs, semantic highlighting, selection ranges, folding ranges).
Meta note: I don’t find the “spammed” wording helpful. On HN, I replied to a direct request for questions from ST developer. If I saw the HN thread first, I wouldn’t have made a lobster comment. I put time to condense my relevant experience (like this bit of feedback) into a paragraph, it doesn’t feel great to see it dismissed as spam.
If you don’t want to have your posts called spam, don’t copy and paste your posts between multiple forums, particularly when it’s misinformed and ended up dominating top level discussions in both places with people who didn’t understand that the assumptions underlying your post didn’t actually apply to LSP in ST4?
I don’t know what to tell you. It’s spammy behaviour.
I love Sublime Text so much. For me though, the killer app that VS code has right now is remote ssh sessions that load up a vscode server on a command-line only remote server and let me use it as though I was working natively on my code base. It might not be a situation many find themselves in, but it’s one that makes my life so simple.
If Sublime had a plugin to do the same thing with the se level of integration I’d go back in a heartbeat and never leave.
Those are unfortunately nowhere near equivalent. The way VSC is set up, the tooling runs on the remote session as well, which means things like autocomplete, debugging, Git history, project-wide go-to-symbol/find usages, etc., are all doable efficiently and cleanly. It’s honestly closer to running an IDE via X on a remote system than anything else, except that the actual UI is running locally, and so has the efficiency and integration with the local desktop that remote X cannot provide. sshfs just gets you the vanilla text editing.
Last I saw, it had an rmate-compatible plugin that let you use rmate to open remote files. I use TextMate with rmate and it’s almost seamless. It’s not perfect, but it’s good enough that it lets me use TextMate as my primary editor.
(TextMate is great, though I would like to write something with a bit fewer features. I like my text editors to edit text and not much else. If I ever start working on sam again, I’m going to remove the two-process mechanism and just have it use rmate.)
I’m an Emacs user, but I paid for a Sublime Text license nonetheless a few years ago, because it’s exactly the kind of software that I want to see: useful, fast, polished, with good defaults.
A text editor is a central tool in my workflow; almost all my work goes through it. (Same for web browsers.) I would find it completely unreasonable to use a proprietary tool for such a core tool/need, especially given the rather good quality of open source alternatives. Evidently other people disagree, and it’s completely fine, but I am constantly surprised that there is a large enough pool to make “proprietary text editor” a sustainable business.
(Maybe there is a failure among contributors to open source editors to find the right way to commercialize them and make them feel “aww” to the audience that likes to pay for slick software.)
I would consider having the right to read, modify and share the changes I make to an editor a core part of the user experience. I’ve fixed bugs both for myself and for friends in the text editor I currently use, not having the right to do that would certainly sour my experience.
That’s fine, but it’s a position that’s shared by statistically zero other people.
If your population is the entirety of people who use software, I do not doubt that. If your population is constrained to people using text editors to write programs, I’d want a link to a study before believing you :).
I would consider having the right to read, modify and share the changes I make to an editor a core part of the user experience.
I think that’s the key difference. I’ve literally never even looked at the source code for the vast majority of tools I use. They do what I need them to do, so I have no motivation to change them. I use (and pay for) JetBrains IDEs (which are proprietary) partly because I’ve never even encountered a meaningful (to me) bug or problem with any of them. That being said, FOSS editors provide competition that improves the quality of proprietary editors. So if that’s your cup of tea, then that’s great in my book!
Saying this doesn’t make it true. In practice, some open tools have better user experiences; these are not always coincidental or unrelated to the development model.
Open source GUI tools also can often have innate challenges with UX due to a “too many cooks” effect — there have been many articles written about this, with titles like “why open source usability tends to suck”. I can’t speak for all tools, but in my experience I’ve found proprietary ones to have much better UX than open source ones.
(My background is working at Apple from 1991-2007. I’ve worked with gifted UI designers who were passionate about getting things right. It could be really painful as the engineer who had to make all those changes and hone details, but I think the results were worth it. Of course sometimes this goes wrong and features get dropped or too much time gets spent on questionable eye candy, but in general I think it’s the way to go for really good UX.)
Yes, the “too many cooks” effect often happens. I see what you mean based on your experience.
I’m speaking more generally, in the hopes of highlighting some design options software developers might be less aware of. To that end, I would like to make two distinctions:
First, I want to point out that “user experience” takes many forms. In the case of a text editor, the “primary” experience is the person doing the text editing. But there are also others; e.g. the experience for the extension/plugin designer. It is often said that committees don’t design UIs well, but on the other hand, it can be very valuable to have a small army of people to listen to suggestions, triage them, document rough spots, and ease user pain.
Second, I distinguish between (a) code licensing and availability (e.g. open source code) and (b) the governance model. My hypothesis is that the governance model is a larger driving factor when it comes to user experience.
This would be an interesting area to study empirically. I personally would enjoy speaking with large numbers of open source contributors to see how they feel about their efforts and the results.
For those who don’t intend to spend cycles on editing the tool itself and just want to get the best thing and use it, their personal definition of “best” will lead them from one tool to another over the years. For such a central piece of workflow, it can be easy to justify some investment of money and/or learning time every now and then.
If I recall correctly, the first version of Sublime introduced the minimap UI feature we’ve since seen in Atom and VS Code. It was very fast for a graphical app, especially compared to its then competitor TextMate. Both TextMate and Sublime offered scripting in major languages of their day, Ruby and Python respectively.
Sitting back and observing, you can see these editors maybe trying to do too much of the job themselves, repeating work they could have shared, not standing the test of time. But to a serial app-of-the-moment user, that’s just the way it goes.
I haven’t used Sublime Text since around 2010 but decided to install this latest version to try it out. I’m actually blown away by the speed and efficiency - beyond simply the startup speed.
Yeah, how everyone got so excited by VS Code is beyond me. Sublime Text is the real deal :D
Hm I think this should be pretty obvious, no? It’s pretty clear that ST is faster and more robust, but it’s also obvious that VS has more semantics-aware features. Some people value features over speed.
It’s beyond me how people can love any specific editor? Editing text sucks everywhere except in kakoune, only IntelliJ has enough polish&power to work efficiently with large projects, everyone except VS gets plugin ecosystem wrong, nothing but Emacs has efficient keyboard drive UX outside of mere editing, and only vim is installed on the server you ssh to.
(That’s not real love, it’s mostly Stockholm syndrom).
Eh, close. There’s a concern I’ve seen in many devs (including, in my younger years, me) that, if you’re not using the best tooling, then you’re doing it wrong. But if you spend a lot of time trying to decide what is The Best Tool, and then really learning it, then you end up feeling a really strong need to defend whatever choice you end up making. After all, you don’t want to admit you wasted that time by making the wrong decision, do you? The more time you spend defending your choice, the more you start to identify with the choice, which in turn makes you very resistant to anything that challenges you, and very quick to overly emphasize anything positive.
Anyway, that’s a long way of saying that the mindset that results in people loving editors is less Stockholm Syndrome, more political cult, but you’re not far off.
And besides, we all know that the best editor is unconditionally and with no qualifications ed.
I would be very interested to hear more on this if you’re willing. For context I use (neo) Vim or Vim bindings with other editors/IDEs.
See Why Kakoune section from this document: https://kakoune.org/why-kakoune/why-kakoune.html
The TL;DR is that we write ciw in vim, but iwc in Kakoune, and this gives you immediate visual feedback about what exactly you are going to c
I find great value in rich feedback (syntax errors, typing errors etc) from an editor/IDE so bringing this to the actual text operations is very interesting.
A friend of mine told me; people use electron-based editors and then are blown away with the speed of something that isn’t electron. Like obviously with something like editors, being written in say C(++) for example, is going to be faster than something that runs off web technology.
A proper MRU ctrl-tab and a built in split terminal easily togable without lifting my hands from the keyboard did it for me.
Opening file in project using quick open and a command palete, were also requirements of mine, but other editors already had these. Sublime being one of them.
I have been wanting these simple features in an editor since before vscode existed. Vscode offers me that, I use it. I would be fine with other editor offering them too.
Their multi edit support is also ofnmy liking and I.ve been including it in my work flow more and more often.
I wonder, if there are any plans regarding first class support for LSP (or, more generally and perhaps more useful, first class support for extensions providing semantic knowledge about the code).
I know that LSP plugin exists, but, anecdotally, folks are having trouble with it. Which i think is understandable https://lsp.sublimetext.io/features/ says
Show Code Actions: UNBOUND, and this is the second most useful thing in LSP (the first is extend selection), it’s not that the plugin is wrong: it’s just that you can do only so much if the editor lacks first class UI/UX concepts for features, required to expose LSP to the user.Yeah, first class LSP support is important to me, too. But from the beta discussion a month ago, it doesn’t sound like they want to: https://news.ycombinator.com/item?id=26647731
I’m curious about your take on that response, given your expertise.
Agree that, as a protocol, LSP is not great (it’s good enough, which means we are stuck with it now). That’s why it’s better not to support LSP per se, but to support extensions which are semantic aware.
VS Code has the right architecture there. VS Code doesn’t implement LSP protocol. Instead, it provides structured extension API to, eg, display code actions or completions. These extensions are directly reflected in the editor’s UI (the 💡) but are not directly tied into LSP. It’s up to extension to bridge editor API and LSP server.
That’s why I worry about upcoming build-in LSP in neovim: they seem to add LSP directly to the editor, which I don’t think is the best approach, given the systems effect of open source community.
So far, it seems that ST does the opposite mistake: they delegate LSP support to the plugin, but they don’t provide structured plugin API on the editor side. If you look at code APIs, they have a lot of high level things like registerCallHierarchyProvider: https://code.visualstudio.com/api/references/vscode-api. ST provides mostly low-level APIs: https://www.sublimetext.com/docs/3/api_reference.html#sublime_plugin.WindowCommand.
I disagree with you again, which worries me because you’re clearly the expert of the two of us :-).
Maybe LSP for big languages is a whole different games than for small languages (or even for bespoke stuff). If you write the LSP implementation for Rust, you expect to be able to put significant effort into it, and to have people write decent extensions for most editors. In this case a semantic extension wrapping the LSP protocole can make sense and probably yields higher quality results.
On the other hand, if, like me, you’re more excited about LSP because it lowers the barrier to entry significantly for smaller projects (random example: Idris, but I can cite more obscure stuff), then being able to interface with it directly is very useful. The language extension might still exist to provide basic syntax coloring (easier/faster than in LSP imho), and you get basic completion, goto def, etc. This will not rival Intellij, but it’ll be orders of magnitude better than nothing. And if the editor directly supports LSP at least it’ll be reasonably fast and the UI will be ok. VSCode makes this a pain in the butt because you can’t just test your LSP server, you have to write typescript, publish the extension, etc. It removes (some of) the work-saving benefits LSP was supposed to bring.
An interesting possibility for more custom LSP servers is to have custom methods (
$/<method>, iirc?) and then each editor plugin can wrap that to the tune of the editor. I wish LSP was a bit better designed, but we’re probably stuck with it indeed.I don’t think we are disagreeing: it’s indeed true that, for smaller languages, having one thing built in is better. But I think the small here needs to be small indeed. Like, if we take idris as an example, vscode has a couple of non trivial plugins for it:
I completely agree also that plugin development workflow is absolutely bonkers for developers. Getting an access token to actually publish the extension is a real quest.
However, experience for users is really nice: they get prompted to install a plugin, and then plugin guides them through the necessary setup (or it just works).
Doesn’t UNBOUND here just mean “doesn’t have a default keybinding”? Several of the other “UNBOUND” actions have recommendations for a specific key you could bind it to.
edit: yeah, I just gave this a keybinding with rust-analyzer and it works fine. I don’t really get why you think there’s missing “first class UI/UX concepts for features” here – it’s just the default preferences not setting this to anything in particular. There is a UI for presenting these actions to users.
If this is just a complaint about a lack of out-of-the-box keybindings, that’s not really a sublime-specific problem, you see the same phenomenon in a lot of emacs and atom and vscode packages too – I think that’s just down to the difficulty of avoiding clobbering something no matter what you ship with, and not everybody sharing your assessment of the criticality of “code actions” (never use the thing, myself. Nor “extend selection”. I think what most people want out of LSP is type-aware completion, personally ¯_(ツ)_/¯ ).
edit 2: and actually, it doesn’t even need a keybinding. Reverting to out-of-the-box settings (I had some other customizations running which turned this off), it defaults to showing code actions in-line with the code when your cursor is on the line – so there’s actually multiple UI/UX ways this is presented to the user and it is UX that’s surfaced out of the box. Really struggling to parse what your complaint is here, given that this is the default presentation in vscode as well
My complaint is indeed about default UX. UX matters a lot. To give a sublime related example, everything you can do with multiple cursors, you can do with Emacs/Vim macros. The functionality is the same: applying edits in lock step to many places. The difference is in the UX, and it is enourmous.
And yes, poor UX for semantic features is problem in every editor for except IntelliJ. I try to complain about everything I notice :)
Not having shortcut assigned by default is a big UX problem. As a new user, I don’t know if shortcut is need and which one is convenient. It’s developer’s job to say: “hey, we have a thousand actions, but here are the ten most important ones. Note the default shortcuts we carefully chose for them, avoiding conflicts and making combinations easy to remember”.
On a positive note, I’ve noticed that code actions UX is massively improved between 3 and 4. 4 now shows an indicator if code actions are available, and that’s the core idea of the lightbulb feature indeed. That’s exactly first-class support for semantic aware features I want to see more of.
I agree here. And this is exactly the problem: people don’t know what tools are available, they can only want what they know about. So folks want code completion exactly because it just pops out there without any user interaction, so they can not not use it.
Authors of tools generally have better idea about which features are important, because they spend a lot of time thinking about and working with them. Exposing this knowledge about effective workflows via polished out of the box UX is a requirement for making the the features create value for end users.
Ok. Not sure I agree that code actions needed to ship with a keybinding given that it surfaces in the UX as a prompt but that’s fine.
The thing is, though, this feels like it has nothing whatsoever to do with the original comment, which you spammed both here and at hackernews. In both places you wrote:
The developers who decided not to ship Code Actions with a keybinding are the plugin authors, who are not the authors of the editor. And yet you wrote that the plugin wasn’t at fault and chalked it up to some implied deep failure of Sublime Text itself to provide “first class UI/UX concepts” that the plugin would have needed to expose Code Actions to the user. Again, what “concepts” are missing? The plugin could provide keybindings for it, if it so chose. It does provide a “lightbulb”-style UI for surfacing the actions by default. Nothing whatsoever appears to missing that prevents exposing Code Actions to the user.
What’s missing? Because I get the distinct impression here you misunderstood the features list to mean the actions weren’t surfacable and then spammed an identical rant to a bunch of forums about it.
Meta note: I don’t find the “spammed” wording helpful. On HN, I replied to a direct request for questions from ST developer. If I had seen the HN thread first, I wouldn’t have made a lobster comment. I put time to condense my relevant experience (like this bit of feedback) into a paragraph, it doesn’t feel great to see it dismissed as spam.
Let me try to clarify. There are two things that I don’t know. As I don’t closely follow ST development, I enquire about them, also providing my, complimentary, view of an LS developer.
If you don’t want to have your posts called spam, don’t copy and paste your posts between multiple forums, particularly when it’s misinformed and ended up dominating top level discussions in both places with people who didn’t understand that the assumptions underlying your post didn’t actually apply to LSP in ST4?
I don’t know what to tell you. It’s spammy behaviour.
I am not going to continue this conversation, but, for transparency, here’s a link to HN discussion in question: https://news.ycombinator.com/item?id=27230406.
I love Sublime Text so much. For me though, the killer app that VS code has right now is remote ssh sessions that load up a vscode server on a command-line only remote server and let me use it as though I was working natively on my code base. It might not be a situation many find themselves in, but it’s one that makes my life so simple.
If Sublime had a plugin to do the same thing with the se level of integration I’d go back in a heartbeat and never leave.
You might want to give SSHFS a try. https://linuxize.com/post/how-to-use-sshfs-to-mount-remote-directories-over-ssh/
Those are unfortunately nowhere near equivalent. The way VSC is set up, the tooling runs on the remote session as well, which means things like autocomplete, debugging, Git history, project-wide go-to-symbol/find usages, etc., are all doable efficiently and cleanly. It’s honestly closer to running an IDE via X on a remote system than anything else, except that the actual UI is running locally, and so has the efficiency and integration with the local desktop that remote X cannot provide. sshfs just gets you the vanilla text editing.
Last I saw, it had an
rmate-compatible plugin that let you usermateto open remote files. I use TextMate withrmateand it’s almost seamless. It’s not perfect, but it’s good enough that it lets me use TextMate as my primary editor.(TextMate is great, though I would like to write something with a bit fewer features. I like my text editors to edit text and not much else. If I ever start working on sam again, I’m going to remove the two-process mechanism and just have it use
rmate.)I’m an Emacs user, but I paid for a Sublime Text license nonetheless a few years ago, because it’s exactly the kind of software that I want to see: useful, fast, polished, with good defaults.
Really happy to see them still going!
A text editor is a central tool in my workflow; almost all my work goes through it. (Same for web browsers.) I would find it completely unreasonable to use a proprietary tool for such a core tool/need, especially given the rather good quality of open source alternatives. Evidently other people disagree, and it’s completely fine, but I am constantly surprised that there is a large enough pool to make “proprietary text editor” a sustainable business.
(Maybe there is a failure among contributors to open source editors to find the right way to commercialize them and make them feel “aww” to the audience that likes to pay for slick software.)
Whether a tool is proprietary or open source is an abstract property that’s totally unrelated to its user experience.
I would consider having the right to read, modify and share the changes I make to an editor a core part of the user experience. I’ve fixed bugs both for myself and for friends in the text editor I currently use, not having the right to do that would certainly sour my experience.
That’s fine, but it’s a position that’s shared by statistically zero other people.
If your population is the entirety of people who use software, I do not doubt that. If your population is constrained to people using text editors to write programs, I’d want a link to a study before believing you :).
Ehh, fair :p
I think that’s the key difference. I’ve literally never even looked at the source code for the vast majority of tools I use. They do what I need them to do, so I have no motivation to change them. I use (and pay for) JetBrains IDEs (which are proprietary) partly because I’ve never even encountered a meaningful (to me) bug or problem with any of them. That being said, FOSS editors provide competition that improves the quality of proprietary editors. So if that’s your cup of tea, then that’s great in my book!
Saying this doesn’t make it true. In practice, some open tools have better user experiences; these are not always coincidental or unrelated to the development model.
Open source GUI tools also can often have innate challenges with UX due to a “too many cooks” effect — there have been many articles written about this, with titles like “why open source usability tends to suck”. I can’t speak for all tools, but in my experience I’ve found proprietary ones to have much better UX than open source ones.
(My background is working at Apple from 1991-2007. I’ve worked with gifted UI designers who were passionate about getting things right. It could be really painful as the engineer who had to make all those changes and hone details, but I think the results were worth it. Of course sometimes this goes wrong and features get dropped or too much time gets spent on questionable eye candy, but in general I think it’s the way to go for really good UX.)
Yes, the “too many cooks” effect often happens. I see what you mean based on your experience.
I’m speaking more generally, in the hopes of highlighting some design options software developers might be less aware of. To that end, I would like to make two distinctions:
First, I want to point out that “user experience” takes many forms. In the case of a text editor, the “primary” experience is the person doing the text editing. But there are also others; e.g. the experience for the extension/plugin designer. It is often said that committees don’t design UIs well, but on the other hand, it can be very valuable to have a small army of people to listen to suggestions, triage them, document rough spots, and ease user pain.
Second, I distinguish between (a) code licensing and availability (e.g. open source code) and (b) the governance model. My hypothesis is that the governance model is a larger driving factor when it comes to user experience.
This would be an interesting area to study empirically. I personally would enjoy speaking with large numbers of open source contributors to see how they feel about their efforts and the results.
For those who don’t intend to spend cycles on editing the tool itself and just want to get the best thing and use it, their personal definition of “best” will lead them from one tool to another over the years. For such a central piece of workflow, it can be easy to justify some investment of money and/or learning time every now and then.
If I recall correctly, the first version of Sublime introduced the minimap UI feature we’ve since seen in Atom and VS Code. It was very fast for a graphical app, especially compared to its then competitor TextMate. Both TextMate and Sublime offered scripting in major languages of their day, Ruby and Python respectively.
Sitting back and observing, you can see these editors maybe trying to do too much of the job themselves, repeating work they could have shared, not standing the test of time. But to a serial app-of-the-moment user, that’s just the way it goes.
This here is why we can’t have nice things :(
I’m not familiar with any good open source text editors which weren’t formerly commercial — could you name any that I’ve been missing?
Some examples: emacs, vim, neovim, kakoune, vis, …
That’s the reply I expected, and I leave the interpretation to the reader.
Too bad then don’t support BSD OSes..
The UI looks neat ! I really wonder what GUI toolkit they are using.
They mentioned they made a custom UI framework in this article: https://www.sublimetext.com/blog/articles/hardware-accelerated-rendering
Is sublime able to live-preview markdown via pandoc? Support for math, preferably via a fast engine like katex, would be a godsend.
No, it only displays text, so no webviews for previews.
That’s false. Sublime Text has been able to show HTML snippets using the phantoms functionality for years:
https://www.sublimetext.com/docs/3/api_reference.html#sublime.Phantom
E.g. the LaTeXTools uses phantoms to preview equations and images:
https://latextools.readthedocs.io/en/latest/features/#previewing
(Not a Sublime Text user, but I did use Sublime sometimes years ago and used this functionality a bit for editing LaTeX.)