I'd love to mount a top-down webcam above me when I work on electronics and have a real time feed into ChatGPT or similar for Q&A, for a real time coach that can see. One day... :)
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.
