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]
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.
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.
No, but why not? Seems like someone wanted to write some code for something they wanted and are sharing it. Can't hurt.
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?
What “market place”? How many editors are regularly sold?
Lucky for you, this project costs you nothing and takes up no space.
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.
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;
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.
(I still use VSCode myself, but I don't think your criticism was being fair to Sublime)
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.
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?
- M1 support: check
- GPU rendering: check
- LSP support: check
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:
{ "keys": ["ctrl+alt+s"], "command": "reveal_in_side_bar" }https://www.sublimetext.com/docs/gpu_rendering.html
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.
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.
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.
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.
> Pylance leverages Microsoft's open-source static type checking tool, Pyright, to provide performant language support for Python.
So that's why it's microsoft platform only...
Last I checked copilot was still a request for access.
A good example is I want to debug the value of foo and so start to type 'print..', for rust it will then offer up `println!("foo: {}", foo)`
Is it nicer to install it from the AppStore or from homebrew, I wonder?
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.
either way, congrats for the new cool project!
Slower computers can have issues running electron apps such as VSCode, which native apps (mostly) fix.
Native apps are also generally nicer to use (on mac) as they break up the flow of the way things look less.
- Kodex
- GoCoEdit
- Textastic (pair with Working Copy)
- Code Editor (unsupported, formerly Coda)
- Codea
- https://github.com/coder/code-server