Hacker News Reader

Comment by _samjarman | Hacker News Reader

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]

View on HN

Yeah, you're right! We should have stopped with Emacs in 1976. After all, everything after that point has been pointless and derivative.

I agree with your point, even though emacs is still my favorite editor

"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)

https://en.wikiquote.org/wiki/Ken_Thompson

It’s very weird how I can’t imagine editing text without seeing the state

> 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.

The market can't be that crowded if a native open source editor that tries to be as close to MacOS as possible doesn't exist.

Would Chime count? Seems to be Go specific, for now at least.

https://www.chimehq.com

Native MacOS aside, how does it compare to GoLand?

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.

Since I still want Jetbrains, but fast, and I don’t have it yet? Yes, we do need a new editor.

> do we need another editor?

No, but why not? Seems like someone wanted to write some code for something they wanted and are sharing it. Can't hurt.

> 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?

This is how new ideas evolve.

What “market place”? How many editors are regularly sold?

Lucky for you, this project costs you nothing and takes up no space.

> 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.

Reply on news.ycombinator.com