CodeEdit: Building a free, open-source code editor for macOS

by readbeard • 4 years ago

172 84 4 years ago

_samjarman• 4 years ago

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]

jjice• 4 years ago

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.

jspaetzel• 4 years ago

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

ziftface• 4 years ago

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

hyakosm• 4 years ago

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

david38• 4 years ago

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.

Narretz• 4 years ago

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.

sk0g2• 4 years ago

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

https://www.chimehq.com

Aeolun• 4 years ago

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

chipotle_coyote• 4 years ago

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.

nmilo• 4 years ago

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.

bastawhiz• 4 years ago

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?

visarga• 4 years ago

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.

hbbio2• 4 years ago

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.

eek2121• 4 years ago

What? It is back from the dead?!? YESSS!!! :D

hbbio2• 4 years ago

Indeed!

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

nicoburns2• 4 years ago

They’re just really bad at publicising their beta builds.

eatonphil• 4 years ago

What are the non-native parts?

madeofpalk3• 4 years ago

Now we’ve got to get into what "native" even means, defining it in a way that include Sublime Text but excludes VS Code

dkjaudyeqooe• 4 years ago

It renders text using OpenGL instead of using the various Mac text rendering APIs.

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.

veidr4• 4 years ago

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.

brundolf2• 4 years ago

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)

chewmieser• 4 years ago

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.

mosselman• 4 years ago

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?

sigzero• 4 years ago

If you have a programming itch...scratch it. Good job and keep going.

seumars• 4 years ago

Really excited for this. Looks like what I wanted/expected Nova to be. Still sticking to Sublime for now though.

radiKal07• 4 years ago

Where does Nova fall short to you?

itslennysfault• 4 years ago

Today I learned some people actually like xCode. I despise it and typically do swift in VS Code and do everything I can to avoid launching xCode.

cellularmitosis2• 4 years ago

If you have a setup which replicates the autocomplete from Xcode, I'd love to hear the details :)

boxed• 4 years ago

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.

robertwt7• 4 years ago

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.

either way, congrats for the new cool project!

eezing• 4 years ago

I think they’re saying vscode is slow. I agree, it’s molasses.

8n4vidtmkvmk• 4 years ago

it's gotten bad enough that I've reinstalled sublime

gaetgu• 4 years ago

I think the biggest issues are slow computers and non-native apps (which intersect in a lot of places)

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.

jpurnell• 4 years ago

I just wish someone would do this for iPad. I know the market is small, but there's nothing even attempting this for iPad.

oatmeal_croc2• 4 years ago

You'd have to build and execute the code on a different machine remotely, I guess. Seems like a pain for most people.

DHPersonal• 4 years ago

What about Kodex? https://apps.apple.com/us/app/kodex/id1038574481

Terretta• 4 years ago

Some things to look at:

    - Kodex
    - GoCoEdit
    - Textastic (pair with Working Copy)
    - Code Editor (unsupported, formerly Coda)
    - Codea

And if you’re online:

    - https://github.com/coder/code-server

(see: https://coder.com/docs/coder/latest/comparison )

HWR_14• 4 years ago

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.

sgjohnson• 4 years ago

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.

joerobot• 4 years ago

I think Meld is a great tool. I haven't found another free tool that works as well. https://meldmerge.org/

eludwig• 4 years ago

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)

readbeard• 4 years ago

For git repositories in particular, I find Fork's [0] built-in diff tool to be pretty useful.

[0] https://git-fork.com

sixstringtheory• 4 years ago

Kaleidoscope. File/directory diffing and three way merging, everything can be done with key combinations. Nice interface, can be invoked from command line.

guessmyname2• 4 years ago

Here is a link for commodity: https://kaleidoscope.app

grishka• 4 years ago

As I mostly work on Java projects, the one built into Idea/Android Studio is a good one for merge conflicts.

xenonite• 4 years ago

kdiff3 is my preferred tool, although homebrew doesn't offer M1 compiled binaries yet.

raju• 4 years ago

There was a discussion around Meld and other tools just yesterday here at HN: https://news.ycombinator.com/item?id=30741123

lelanthran• 4 years ago

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.

philistine• 4 years ago

Is no one going to mention the grandfather in the corner, BBedit?

oefrha• 4 years ago

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.

emptysongglass2• 4 years ago

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.

wiz21c• 4 years ago

From pylance web page :

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

lvncelot• 4 years ago

For neovim, there's copilot.nvim[1], and for emacs there's flight-attendant[2], which is very much a work in progress, though.

[1] https://github.com/github/copilot.vim

[2] https://github.com/cryptobadger/flight-attendant.el

ge96• 4 years ago

Curious to what extent do you use it? I saw some demos (JS) side was like "create an http server" and it would pull in/setup express.

Last I checked copilot was still a request for access.

jossclimb• 4 years ago

I use it as a glorified auto completion tool, but very rarey for any programming logic, I just ignore it then.

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

strogonoff3• 4 years ago

If anyone is looking for a simple macOS-native anti-IDE source editor, check out Coteditor (available in App Store). Been using it for a while.

guessmyname2• 4 years ago

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.

strogonoff3• 4 years ago

Yeah, I believe it is made by Japanese devs.

biehl• 4 years ago

Looks very nice.

Is it nicer to install it from the AppStore or from homebrew, I wonder?

strogonoff3• 4 years ago

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

cormullion• 4 years ago

CotEditor has excellent typography support. Invaluable for testing fonts.

amitprayal• 4 years ago

use jEdit its the best

CodeEdit: Building a free, open-source code editor for macOS

Related Stories