The current best option for a native editor on macOS is still Sublime Text (now 4). It's not purely native as not using all the core Apple frameworks, but it still does the job and finally has support for LSP which is the major feature you would expect from a code editor today.
Congrats for providing another option: If well done and providing a user experience which is close enough (including visually) to vscode, that could be a compelling option. Don't forget LSP and just provide a native implementation of something that looks like vscode (which was designed after Sublime), not a different UI altogether.
I bought Sublime Text through v3 but didn't really use it anymore, so declined to buy v4 (so far).
It's interesting you mention LSP support, because that is basically why I stopped using it — the as-you-type auto-completion, error/warning highlighting, and doc/reminder/hint functionality was sorely lacking (compared to leading non-native editors like VS Code / Jetbrains).
I just fired up Sublime Text 4 and opened a vanilla Angular project to try the TypeScript support.
const foo = new Hoge();
foo.titleId = 69;
Unfortunately, while it did offer to autocomplete the titleId property, that property is from a completely unrelated class to Hoge that isn't imported in the current file (but I can see in the hover popup where it Sublime is getting the definition), and also that property is a string, but Sublime lets me go ahead and assign a number to the property without flagging it as an error.
To me, these basic features are table stakes for an editor in 2022, and should hopefully "just work" if you open a TypeScript file. But are you saying these features can now be made to work in Sublime (perhaps with some configuration, or something)?
There was a lot I liked about Sublime back in the day, but I felt like it just failed to keep up with the basic-level state of the art for a code editor. I'd be happy to find that I'm wrong about that, though.
You need to install a couple extensions and then it works well enough. It could be a slightly smoother process, but I think it's reasonable. Even in VSCode you have to install and configure plugins for all non-TypeScript languages; TS gets special support because Microsoft wants it to. Sublime is unopinionated.
(I still use VSCode myself, but I don't think your criticism was being fair to Sublime)
Cool. Not really trying to criticize it; just noticing that it doesn't work out of the box, and I personally have never had the time to fiddle with it to see if it can be made to work.
However, since we are in the thread I googled it with duckduckgo.com, and then followed the top blog post results, which involved:
- install "Package Control"
- use that to install Package → LSP-typescript
- restarted Sublime Text 4 (just in case)
But it still didn't work.
(For any reasonable value of "work"... I mean it didn't highlight errors in TypeScript as a typed them, and "go to definition" didn't jump to the correct definition, but rather offered me a list of every place in the project where a symbol with that name was defined (including the correct one, but also several incorrect ones).)
So, maybe I'm doing it wrong, or maybe it doesn't work.
I'd love to be wrong, though, and see an example (blog post, youtube, whatever) of Sublime working for TypeScript development with all/most of what VS Code offers out of the box (even if it involves some configuration steps).
Thanks! Indeed the blog post omitted that step, probably since they already had it installed or something.
Once I installed the base LSP package, and restarted Sublime, then it gave me an error[1] at startup, explaining that it couldn't initialize the LSP for TypeScript. The error message included a button to fix it.
After that, yeah, it works a lot better! Jump to definition works, and the as-you-type errors I mentioned before now do appear. Also, the auto-complete list looks fairly sane, without all the "random guesses from all the text in this project" entries it had before.
So... not bad! At a glance I think it is still probably not as good a VS Code, but it might be usable. I will give it a closer look later.
[1] The error was: "Could not start LSP-typescript due to not being able to find Node.js runtime on the PATH. Press the "Install Node.js" button to install Node.js automatically (note that it will be installed locally for LSP and will not affect your system otherwise)."
What are your thoughts on as-you-type errors? I personally don't like seeing errors on every keystroke, so in sublime, I set the lint mode to "background" and set the "delay" [0] to 2 or 3 seconds. Do you know if such a thing is possible in vscode?
My own thoughts on it are that yes, that is definitely something that should be user-controllable, but as far as I know it's not possible in VS Code. I remember the old issue below, which was closed without actually fixing that.
Personally, though, I've learned to live with it, so it no longer bothers me, except in principle. ;-)
I'd much rather have annoyingly-instant error highlighting than missing or incomplete error highlighting. It will look good once I've finished the code.
For purely native options we have TextMate 2 and Nova (more of an IDE).
I've personally used TextMate for many years, only switching to Nova more recently. The community for both is not as comprehensive as VS Code or Sublime but they're still both solid options.
Sublime is great, but I switched to VScode for the built in terminal.
I know there is terminus in Sublime, but I can't send commands to it like I can in VCode. My use case being:
- I open up a spec file and I am on line 123
- I press CMD+Shift+R and it will open a terminal tab, if it isn't there already
- It runs: `bin/rspec path_to_file:123`
I can't do that with Sublime.
What I CAN do with sublime is run the command as a build, which is almost perfect, but it hangs when I add a `binding.pry` because it isn't interactive. Hence making it unusable in this way.
Maybe there is something else I can do like running an iTerm tab or something I don't know of?
The main problem (for me) is the use of their external app Sublime Merge to manage git sync: This breaks the work flow, and is an inferior experience compared to vscode.
Also, there are slight differences in the way tabs are managed which make it cumbersome to switch between Sublime and vscode (which has won muscle memory lately).
Edit: for instance the current file is not highlighted by default in sidebar, I resort to a custom keybinding:
Wasn’t there an issue with that plugin getting bought out and then used for really intrusive analytics? I could definitely be wrong. It might have been a different plugin.
Also it doesn't really have a user interface outside the text editor. For example, it doesn't use native dialog boxes. It does use native menus though.
These days not having Copilot is a pretty big productivity hit to me. The other day Copilot somehow stopped offering completions for maybe an hour, and I was pretty shocked to realize how much I've grown to rely on just hitting tab to complete the whole line. (I was writing Go at the time which is on the boilerplatey side among the mainstream languages, so Copilot is particularly effective there. Auto-completion from gopls — the language server — is no match.) I'm officially spoiled.
I'm afraid small independent code editors are increasingly fighting uphill battles as the big ones roll out support for more and more productivity boosts like LSP and Copilot integration.
Are there any projects to bring Copilot to other unsupported editors such as my favorite, Emacs? I noticed there's a new trend of only releasing important extensions to blessed products and barring their implementation in others such as the new Python LSP, Pylance and now Copilot.
Forgive my ignorance, but what's the difference between this and VS code? Other than look, feel, and architecture. or is it merely a for fun project?
I'm using vs code or vim and tmux as daily editor (except for java which i use IntelliJ) and have been very comfortable with it. I used to try different editors back in the days just to explore for fun, but now when you want to get the work done, it'll be very time consuming to switch editors, map keys, themes, setup, etc.
CotEditor (https://coteditor.com) is a well written, open-source (https://github.com/coteditor/CotEditor), lightweight, native (Swift), lightweight plain-text editor that many Chinese, Japanese, and Korean developers love to use. I highly recommend it.
I use MacPorts anyway, and for software like this I use App Store since it’s not like I can avoid using my Apple ID these days anyway… (Which is slightly bothering, but off topic.)
The auto compete in xcode has to be the worst I've ever used. Hitting tab autocompletes just one word. Even if it's the only option! It's infuriatingly bad. It's like no one at Apple uses it.
Related question: What's people's preferred diff tool for code and directories of code on macOS? I haven't found one I liked since the Catalina update killed 32-bit apps.
Kaleidoscope. File/directory diffing and three way merging, everything can be done with key combinations. Nice interface, can be invoked from command line.
This is probably the best on macOS but as the app is being bounced between different companies (probably 3rd now), now they charge some crazy $165 for the license. At least it's not subscription but feels a bit too much for a diff app.
I've used Beyond Compare for many years. Interface is not super polished, but it gets the job done for me. For both Mac & Windows (https://www.scootersoftware.com)
For me it’s the one that’s built into JetBrains IDEs.
Although for directories I believe it only works when combined with Git. I’ve never tried to compare 2 directories of code in a situation that wasn’t a Git changeset.
I dunno about directories, I only use the diff from within `git difftool`, and to keep things simple I only use what I find in the default brew repo.
Tkdiff: instant startup, stopped working on latest update so had to junk it. Was not thoroughly happy with it because it never remembered the monitor and position from instantiation to instantiation.
Meld: Very slow startup. Takes 3s or so. Unusable from within `git difftool` due to the insane lag.
Kdiff3: Fast startup, not as quick as Tkdiff, but around 200ms or so. Currently using it happily.
At some point, the question has to be asked (and this is not directed at CodeEdit, but this prompted my question)... do we need another editor?
We have a very crowded editor market place. There seems(?) to be enough competition to drive innovation, and most(?) support plugins/extensions for devs to tailor to their needs (as opposed to swapping editors for a killer feature).
I also think there is a benefit to a team using the same editor for a project. This allows checking in of editor-specific files that increase productivity (We check in our .vscode folder with recommended extensions, on save actions, launch configs etc)
What do you think? Am I missing something here?
[Edit: To be clear, I'm personally not in the camp of "no more editors pleases", just was interested in seeing others thoughts here]
"Ed is the standard text editor." and maybe we didn't "need" anything else, but comfort and ease of use are good incentives to create better tools, and tools more adequate with our work environment.
"I've seen [visual] editors like that, but I don't feel a need for them. I don't want to see the state of the file when I'm editing."
- Ken Thompson on the superiority of ed to editors such as today's vi or emacs, as summarized by Peter Salus in A Quarter Century of UNIX (Addison-Wesley, 1994)
> I also think there is a benefit to a team using the same editor for a project. This allows checking in of editor-specific files that increase productivity
This is an interesting thought. Off the top of my head, I don't think I agree -- I'd consider mandating that everyone use an editor that supports EditorConfig and check in an .editorconfig file to enforce basic style standards, but beyond that, I'd be inclined to think that you're going to get more productivity by letting people use editors that they're familiar -- and fast -- with.
On topic to your first question: at this point I don't know if we "need" CodeEdit, and of course CodeEdit has to have more to it than a nice README document and a cool icon before we can really make even educated guesses about where it might go in a few years. But you never know. While I don't use Panic Nova (I tried for a bit, but BBEdit 14 has just been better for me as far as aggressively Mac native editors go), I find it really interesting, and v9 suggests they may go after JetBrains more than after VS Code. And I just don't buy the "we need to put all our resources behind Glorious Editor X and embrace a monoculture" argument I've seen in some quarters (particularly a few folks who insist that Nova needs to adopt Code's extension API). I think Code really is shaping up to be the next generation Emacs, but as many, many people might point out, the original generation Emacs is still doing pretty well.
I very briefly trialled it out of curiosity, as I was just finishing the job where I was using Go daily. It wasn't as full-featured as GoLand, but the UI and performance was a fair bit nicer. The only major drawback though, for me, was the language server/ auto-completes and all that. JetBrains does a phenomenal job in Go especially, where even the official language server is pretty meh.
There have been a few releases since then, and if I were using Go again I would try it out for sure. There's a free trial, so nothing to lose!
Who's we? The great thing about text files is that they're editor agnostic. If there already exists 1000 editors that work, should that really be stopping me from making the 1001st that works for me better?
Also I disagree with the idea that teams should use the same editor. I, for example, hate vscode, so if I join your team, I'm stuck either using a less productive editor, or re-creating the launch configs and save actions in my editor. To me it seems like a failure on the editor's part to separate concerns---a code editor should edit code. If it compiles or launches the code, it should do so using an external program, e.g. make, where all the launch configs can go in the Makefile, and not in some editor specific file.
> I also think there is a benefit to a team using the same editor for a project. This allows checking in of editor-specific files that increase productivity (We check in our .vscode folder with recommended extensions, on save actions, launch configs etc)
There's a benefit to having a well-trodden path for the team. But that's about where it stops. If I put up quality PRs that meet the standards for the codebase and my productivity is high, who the hell cares which tool(s) I use? Should I be forced to use a certain text macro program? A particular terminal? What purpose does it serve other than to micromanage?
> We check in our .vscode folder with recommended extensions, on save actions, launch configs etc
That has the side effect of silently overwriting your local .vscode config when you check out a branch. If you have custom settings they get destroyed.
Congrats for providing another option: If well done and providing a user experience which is close enough (including visually) to vscode, that could be a compelling option. Don't forget LSP and just provide a native implementation of something that looks like vscode (which was designed after Sublime), not a different UI altogether.