mattiemass

I have found myself, many times, in exactly the same situation. I think a concurrency-compatible queue is basically essential for many kinds of pretty boring situations. I made one here, and it look a lot like an OperationQueue. But it also points to another implementation I found recently that is certainly different, but also might be interesting.

https://github.com/mattmassicotte/Queue

These tests are being extracted from an editor project I work on. The tests themselves use the OSSignpost API for high-precision measurements combined with the XCText infrastructure for driving the UI and capturing the measurements. I've been using this combination for performance testing for a while now. It can be flakey a bit, but that's kind of the nature of UI testing sometimes. Still really great when it works.

The only truly interesting test is one that creates a 1 million line document, measures the loading time (extremely fast) and then measures the time it takes to navigate to the final line in the document. This exercises the layout system. It's really fast. On my machine TextKit 1 can do it in about 70 ms, and TextKit 2 in around 10. This isn't quite good enough for 120 fps UI on macOS machines that support it, but it's really close.

Live scrolling and window resize are both things I'm really interested in testing. But, the UI automation framework doesn't, as far as I know, have good ways of driving those interactions. But I may be able to cook something up. Ideas welcome!

Author here. I'm not entirely sure why this project would be of interest, but I noticed it here so figured I'd provide a little more context.

The test suite is small, and there are no concrete results. This is because the very first truly stressful test I got to produced terrible results. Instead of continuing, I began investigating that more closely. I also opened up a developer support ticket (distinct from a Feedback) with Apple. Apple got back to me about 3 day later, pointing out a bug in my use of TextKit 2. I'm a long-time TextKit 1 user, and this stuff is new to me. I also write a lot of bugs.

TextKit 1 is a very fast system. But with this problem addressed, TextKit 2 now outperforms it by quite a bit. From a performance perspective, it seems really good so far.

If you have any other questions, let me know!

I'm truly sorry to hear that you are disappointed. And I really do get it! The full story is long, but I can sum it up with: our number one request, by far, is support for more languages. Even since this release, we've still gotten requests for yet more not yet available.

The hope is that an open source extension system will make it much easier to add new languages and improve support for existing ones.

But, I also want to be really clear: if you aren't happy, contact us and we'll try to make it right. If you are willing, I'd also love to hear from you about problems and/or missing features. We prioritize requests from license holders over all others.

Same thing on macOS. The containing app does not need to be running for the extensions to be active. You are right that the extension bundle can only be used by this mechanism, but interestingly the containing app can use its own extensions (though this may not make sense in many cases).

The only reason I was able to figure out how to use ExtensionKit at all was because of a chance encounter with an Apple engineer during WWDC that provided some needed information.

I'm sorry to disappoint, but ExtensionKit/Foundation do not make use of any Swift features in the way you describe. It's all just IPC (via XPC), so much of it is useable from ObjC, or even C!

Also, this does not provide a direct app-to-app communication channel. The extensions themselves must be separate executables and run within their own sandbox. I think the extension could communication with its containing app, but the system is not set up to do that. All your scheduling questions are really around how XPC works. The view itself is basically an image within your hosting app, so communication is entirely async to the other process.

Practically speaking, that's still basically an SDK. It's all over XPC, but the interface still needs to be defined.

(author of that quoted blog post here). You are correct, there's nothing new about apps offering plugins/extension systems. What's new here is: this works across sandboxed apps, support for remote (out-of-process) views, and the extension permission and discovery system is entirely managed by Apple.

I'm sorry it's working so poorly for you. 2.0 has some performance issues that do make it seem more like slow-open in a number of situations. We're working on it.

Honestly, dropping v11 for 2.0 was a really tough call. Adopting ExtensionKit, and getting that out the door right when v13 shipped was difficult, but that was the goal we set out for. Supporting v11 made a number of things more difficult, and SwiftUI was some of it. It was not strictly technically necessary, but it made it easier.

That's more or less exactly what we've done. Our SDK does have support for LSP. But, unfortunately those extensions still need to be made. Or are you talking about a generic LSP extension that is server-agnostic? That is definitely buildable, but my experience has been that the experience tends to be a lot better when customized for a particular server.

We did start off with just Go. After doing a bunch of infrastructural work, we added another, Ruby. We've just finished generalizing this, in a way that both more 1st- and 3rd-party extensions can be created. To date though, we've only gotten to Rust and Swift.

You did not. Aside from Rust and Swift, all the added languages are preliminary. A minimal extension is required to, for example, connect Chime up to an LSP server to get semantic features going like completions and diagnostics. We do not have a 1st-party extension built for C# yet.

Thank you so much! The limited language selection was definitely a problem. Go, Ruby, Swift, and Rust extensions are all available today. Go and Ruby aren't open-sourced yet, but will be soon.

thank you so much!

I sincerely appreciate you saying this!

The open source work we've done is something I particularly enjoy. Our work with LSP has been a blast, and I know that there are actually other projects that use it! Really looking forward to doing more here.

Thanks so much! Very appreciated.

Navigation by typing was planned, but ultimately pulled from our 1.0. It's in the works. As is errors and warnings.

Debugging is a very common request, but its a large feature. We'd like to do it well, and there are other things we have to get to first.

Good feedback, and I agree. We just have the one, but it's not enough.

Thanks so much for trying. These two issues are both fairly related, and an area of active work.

That string termination thing in particular is killing me as well. Going to be addressed in the next release or so, but thank you for reporting.

The experiences around autocomplete interactions are noted and, with the exception of the very last bit, understood. Very much appreciate you reporting what happened.

Wow that does look very cool! Development on the iPad is going to be something that seems to be in very high demand.

First, thank you for taking the time to take a look and write some feedback. It's very helpful.

You aren't the first person to have difficultly understanding now to get your bearings. We hear you (and others) loud and clear about an FAQ/feature list.

An actual voting system is an interesting idea. But we prioritize feature work 100% base on feedback. I think we'll probably end up favoring requests from license holders, but we're going to attempt to satisfy as many users as we can. Within the constraints of our desire to build out features carefully.

Navigation by name (to open a file for example) is in the works, but was cut from the 1.0. Errors and warning are also being worked on. Running/testing is highly requested, but we're focusing on those for now.

Extremely kind of you to support the work like that. We will try our best make it something you do want to use for day to day coding.

That's very kind of you. I'm afraid a bunch of things don't work without a working local Go install, but would still love to hear your thoughts. Get in touch if there's anything else you'd like to share.

We're so glad that you're interested in what we're up to!

We do have plans to offer build/run/debug/test, as that's something everyone is after. But, right now, we're very focused on the core editing experience.

Well I guess that remains to be seen :)

There are lots of excellent cross-platform editors out there. We're macOS users, and we just wanted to build something that catered specifically to that crowd. iPad is close in some respects, but would really need a totally different interaction model.

Many parts of the system are open, and more are coming. We're just not savvy enough to be able to open source the whole thing and also continue to afford to work on it.

Sounds like you work on exclusively open source software. You're lucky!

Both :) We'll be using a "Sketch-style" pricing model, licenses work forever, but updates are only for a year.

I'd say that most developers are like you, invested in one editor. It's hard to change, especially given how much customization is possible. Chime's really tailored to people looking for a dialled-in macOS experience. Usually, the people that want that kind of thing are out looking for it. It's pretty niche.

Oh wow this is fascinating! It would have been pretty crazy to not use LSP, so that's good to see. Looks incredibly customizable, with a JS API. Definitely going to be popular!

Many people feel this way. This is why there are so many incredibly high-quality open source tools today. Chime is definitely not made for people that want to tinker. Some major components of the app are open source, though, and more are coming.

But, there's no spyware in the app and there absolutely will never be in the future. Of course, if you don't want to take my word on that (and also do not trust Little Snitch), open source is the best option. There are tons of good things out there, even specifically for the Mac.

Oh man I'm an idiot. Yes. You've all figured it out. Cursor there would indeed make sense. Will fix!

Final price is TBD. We've got a lot of beta testers now, so unsure how an open beta will go. It's quite possible we go right from closed beta to general availability.