More collaboration possible? about codeeditsourceeditor

[mattmassicotte]

Originally, when I opened this issue, I was really focusing in on the specific things I noticed within this repository. I see stuff from other libraries I've made, and it would help me make better things if I could understand why that's happened. I cannot help but feel like that's a high-pressure ask, even though I really do not intend to be! The code is out there to be used, it would just be cool to understand if/how it could be more useful.

We also got into much deeper territory pretty quick too!

I like collaboration a lot. It's one of the most important things to me about open source work. It's really fun to work with others on common problems.

I think that levels 1 and 2 here, generalized, are really baseline norms for being part of the open source world. I will definitely do better here. It should not have taken me so long to reach out.

Getting to level 3-type collaboration is an entirely different thing though. I don't even know where to begin. Regardless of how things evolve, collaborating on shared libraries is what we're currently doing! That's my favorite part, and let's definitely do more!

[thecoolwinter]

I'd love to collaborate more, is there anything specific we could contribute back to your packages? We make heavy use of TextFormation as we've talked about before, and we use your tree-sitter package for CodeEditTextVIew's tree sitter implementation.

You're right that we have some code that was inspired by Neon and Rearrange. We opted not to include Rearrange because it felt like we were using such a small subset of the features it provided, but I'd be happy to contribute back to Neon some of the things we've developed in CodeEditTextView. I think the only feature that's missing between them is async editing, which I'd be happy to work with you on implementing in Neon. We did have different methods for implementing async editing before (we opted to use the timeout feature, Neon attempted to guess what would be long work).

I think then if we got that feature in Neon we could consider replacing our tree sitter implementation with Neon (might as well reduce the number of swift tree-sitter options in the world). But that might be dependent on how well it works with our languages package. Although to be honest, that package could maybe use a rework as we've hit git's package limit so I'd be willing to talk about building that out to help fit your needs if that's something you're looking to do.

We've also talked a bit about improvements to TextFormation and I left some thoughts on the issue there, I'd love to contribute to the v1.2 of that package if you have a vision for it, or help create that vision.

[matthijseikelenboom]

What a coincidence! We actually had a discussion about this in our meeting yesterday haha.

We would very much like to setup a call to discuss collaboration! Personally I'm also curious what your future plans are regarding Chime, now that you're planning to make it free and open source as well.

[mattmassicotte]

I'd love to discuss more! If you feel a live discussion is needed, we can definitely do that. I'm also totally ok with written communication.

[Wouter01]

I think it might be beneficial to do written for now so more people can follow. That said, more collaboration between both projects is great! I was wondering what "kind" of collaboration we're referring too? Is it sharing packages between both editors, or more of global merge of both projects?

[matthijseikelenboom]

I'd love to discuss more! If you feel a live discussion is needed, we can definitely do that. I'm also totally ok with written communication.

Needed is big word, but I do think it's more effective and efficient 🙂. We can always write a summary of the discussed things to post to the community.

I was wondering what "kind" of collaboration we're referring too?

That is something we could discuss/explore in a call imo.

[bombardier200]

Yes I would love to discuss collaboration as I think that will help out both tremendously!

[austincondiff]

@mattmassicotte, thanks for reaching out, and it's great to hear that you consider CodeEdit an important client. We are all very impressed with the work you continue to do in the open-source community. We value your interest in collaboration and improving TextFormation and beyond.

Regarding your proposal for collaboration, I think it's a fantastic idea. Rather than stepping on each others toes, we should be reducing duplicated effort and work together. Collaborative efforts can often lead to stronger and more efficient projects. Let's explore the various levels of collaboration and how we can align our goals:

Level 1: Feedback - At the foundational level, we are more than willing to provide feedback on TextFormation and share our goals and requirements. This can help us understand each other's needs better. @thecoolwinter might be able to share more insight here as he primarily implemented TextFormation.

Level 2: Contribution - If you're open to it, we can actively contribute to the TextFormation project while maintaining its ownership under your leadership. This way, we can work closely on specific improvements.

Level 3: Deeper Collaboration - If our projects have substantial overlap or a shared vision, we could consider the possibility of merging efforts. This could entail combining our projects into a single, more comprehensive solution or collaborating on a collection of shared libraries. We are open to exploring this option.

We are committed to maintaining CodeEdit as a free and open-source product, however we are willing to adapt and evolve to align better with your vision within reasonable boundaries as necessary.

We'd love to hear your thoughts and preferences on these three levels of collaboration. I look forward to how we can work together to take our projects to new levels. We look forward to furthering our relationship and making native text editing tools even more powerful for the community!

[matthijseikelenboom]

I see stuff from other libraries I've made, and it would help me make better things if I could understand why that's happened. I cannot help but feel like that's a high-pressure ask, even though I really do not intend to be! The code is out there to be used, it would just be cool to understand if/how it could be more useful.

I'd say let's setup a call to discuss this. Are you in our Discord? Or do you have any other ideas on how to set it up?

[mattmassicotte]

I'd say let's setup a call to discuss this. Are you in our Discord? Or do you have any other ideas on how to set it up?

I completely understand that a project of your size has organizational requirements. But, this strikes me as something that is both well-suited for written communication, and also discussion that others could benefit from reading externally.

I'm not on the Discord, but I can join!

Edit: I joined the server, but I do not have sufficient permissions to make my server user name the same as my GitHub name. This makes me unable accept the rules, so I currently cannot post.

Edit 2: Here's an issue for some specific TextFormation-related work that was discussed independently between myself and @thecoolwinter ChimeHQ/TextFormation#5

[austincondiff]

I cannot help but feel like that's a high-pressure ask, even though I really do not intend to be! The code is out there to be used, it would just be cool to understand if/how it could be more useful. We also got into much deeper territory pretty quick too!

I assume you are referring to my mentioning level 3? My apologize, I was only intending to lay out different methods of collaboration, that being one of them. I was only trying to see what you wanted to see come from this. I appreciate your clarification. I'd be remiss if I did not mention that there was chatter within our community amongst some members around the possibility of combining projects and that it might improve the probability of success. I personally just want to move forward and make progress in whichever way we can. I'd suggest we start small and take it one step at a time.

I like collaboration a lot. It's one of the most important things to me about open source work. It's really fun to work with others on common problems.

I couldn't agree with you more!

I think that levels 1 and 2 here, generalized, are really baseline norms for being part of the open source world. I will definitely do better here. It should not have taken me so long to reach out.

Getting to level 3-type collaboration is an entirely different thing though. I don't even know where to begin. Regardless of how things evolve, collaborating on shared libraries is what we're currently doing! That's my favorite part, and let's definitely do more!

Again, I really appreciate that. Let's move forward in that direction and see where that leads us! 🚀

I completely understand that a project of your size has organizational requirements. But, this strikes me as something that is both well-suited for written communication, and also discussion that others could benefit from reading externally.

I agree with you. Let's continue talking here and on Discord. If a call is necessary later, we can certainly set something up. You are also welcome to join our meetups held weekly on Saturday at 3pm UTC on Discord.

Edit: I joined the server, but I do not have sufficient permissions to make my server user name the same as my GitHub name. This makes me unable accept the rules, so I currently cannot post.

It looks like everyone can change their own nickname when lookin at the default permissions. You may need to accept in order to make the change.

[mattmassicotte]

Hmm unsure what's wrong with my Discord set up. I still cannot change my nickname. No worries though!

You have absolutely nothing to apologize about! I wasn't clear enough when I first wrote this up. I really just want to get a better handle on what things I've made that aren't working, and if there are ways I can help. Sometimes, you also just wanna make your own thing, and that's ok.

How about this. If anyone has an interest in providing some feedback in these areas, let me know via an issue in one of the repos. And it's also helpful if the goal is just "less package dependencies". I've already been doing work in that area to reduce transitive dependencies myself.

[matthijseikelenboom]

The goal isn't really less packages I think. It's more about preventing a dependency hell/technical debt. But, I think this is automatically reduced when we collaborate more on common cases, because then we're both familiar with the same pieces of code, that can then be improved more easily.

The other thing is, is that when packages are build upon another, a situation could occur that you pull in stuff that you don't need.

I haven't read you post in detail yet, but from a quick overview I agree with your piece. (Also yes, documentation is very important in packages, I haven't looked at your packages enough to say it's good or bad 😅)

Lastly about Discord. It could be that you just need to join the server and accept the terms. Then you maybe able to change you nickname

[mattmassicotte]

Lastly about Discord. It could be that you just need to join the server and accept the terms. Then you maybe able to change you nickname

You were correct! You must accept the terms before you can comply with them it turns out. I should have tried that.

I cannot think of any other way to collaborate across projects without using Swift packages. But, I'm always open to suggestions!

As for transitive dependencies (packages that depend on other packages), I've been doing a lot of work to minimize that as much as possible. And I like to think I'm succeeding, somewhat. Of course, it is a trade-off, and there are times when it just doesn't make sense. But, hearing about cases where you have run into problems would be really helpful!

[matthijseikelenboom]

Great that you where able to join the Discord!

I ask some of my more experienced colleagues what opinion of dependencies/packages are. (Sidenote: They are all Java devs) Their points where mainly:

• It's expected that you need to have some dependencies, unless you really want to do everything yourself.
• Transitive dependencies are not really a problem, it's part of software development
• They do prevent usage of dependencies that aren't backed by (big/strong/active) organizations. Simply because they're more prone to being stale and not being updated. (Note: They talked about this in context in using dependencies a client/customer)

For the last point, it could be an issue in your case...? I believe, and correct me if I'm wrong, that you're the only developer developing Chime, so that could be a reason. Emphasis on COULD 😄

So, personally I think that Swift tends to suffer from the same community "problem(s)" that Golang has and that is that it is obsessed with optimization at all costs.
"Every KB that is added to the final app is a KB too much." And, in this case Apples "default SDKs are the best so adding external libraries and frameworks is dumb and unnecessary."

Lastly, in our case I think we where looking at the complexity of the dependency and how much of it is used. If it's not that complex, one could argue you best can make it yourself, or copy it over, so you have full ownership of the code (That argument changes somewhat in context with open source though in my opinion). In terms of how much a dependency is used, I mean what percentage of the imported functionality is used, not how many times the functionality is called in the code. So for example if we import a dependency where we only use 15% of it's functionality, it's something to look at.

[mattmassicotte]

This all sounds reasonable! So, given this, let's circle back to the original question:

While poking around, I found code that seems like it came from Rearrange and Neon.

This is fine!

But I think it would be a lot cooler if we could find ways to collaborate better. What do you think? I haven't heard from you, so my assumption is the main driving factor here was different functionality requirements and/or a desire to reduce imported packages.

[matthijseikelenboom]

I don't think I can answer that question, as I haven't really been in involved developing this. So perhaps @thecoolwinter can clear that up better.

[austincondiff]

@mattmassicotte I don't think anyone was trying to hijack your work. We really do appreciate all of your effort.

I am curious what the motivation was in doing that instead of pulling in the package. What code specifically are you referring to just so we have a reference point? Perhaps the intent in doing this was because only a small piece was being used and the call was made not to bring in the package in it's entirety. A comment should have been added to indicate the code was originally in your package though. Let us know what you'd like to see here and we'd be happy to cooperate.

We certainly want to minimize imported packages, however I personally do not mind bringing them in as long as it makes sense to do so. We are using TextFormation as it aligns with our goals. We are also considering LanguageServerProtocol as we will be working to integrate LSP relatively soon.

That said, are you looking for more contribution to those libraries? I certainly like the idea of pooling our resources to move forward in this area.

[mattmassicotte]

Thanks all!

I think I can summarize all my thoughts here pretty simply. My number one goal with open source work is to build stuff that works for more than one client. I really enjoy collaboration, and am particularly interested in avoiding overlapping work. This is basically impossible at the app level of course, but working out super-well with libraries.

Philosophically, I have no problem with copy/pasting code (unless you are a commercial entity, and then I have a huge problem with it). I think it is a suboptimal solution in many technical dimensions. But, you can and should do it if that's your preference!

So, if you are interested in trying to collaborate more, get in touch with me via those repos! The ball is now rolling for TextFormation, and I'm pumped. Maybe we can do the same for Neon. That's be cool, as it is used in a number of other projects and could stand a lot of improvement.

I helped Luke set up that languages package. We spoke at the time about the potential limitations. Tree-sitter has some fundamental problems here unfortunately. But I'm always up for working on a solution!

We are using TextFormation as it aligns with our goals.

I'd actually really like to understand those goals. Can you elaborate?

We are also considering LanguageServerProtocol as we will be working to integrate LSP relatively soon.

I'm very curious about the alternatives you are looking at!