Open austincondiff opened 2 years ago
How to exactly partition the work here is a good question and to be honest, I am not entirely sure myself. Given the view in your screenshot, I would say, it ought to be two editor view, w hick get combined into the diff view (also because they will need two NSTextStorage
instances to hold the two (different) code strings). Nevertheless, these editor views surely need to be aware of the fact that they do belong together — otherwise, as you are saying, how should they properly highlight the diff'ed lines.
I also assume that there is no editing possible in this view — I am usually using Tower.app for Git, so I am not that familiar with the Xcode support for it. If there is no editing, I imagine one way to go about it would be to have a view-only mode for the code editor and in that view-only mode it accepts additional highlighting info for the diffs. Then, two such view-only editors could be combined to form this view.
Anyway, that's just a first idea. I am happy about any better suggestions.
@mchakravarty The left side (current code) is editable. The right side the original before the edits were made.
P.S. Shameless plug: The mockup above is part of this concept that turned into an open source project. CodeEdit quickly became the top trending project on Github for three days in a row with over 5k stars and got tremendous reception from the community. We'd love to get your input in our discussion to best integrate a solid editor since you have been doing this for quite some time.
@austincondiff : Isn't the right side usually the one with the current code and the left side the one with the original git code?
P. S. How do you make these mockup?
@Angelk90 Figma
Editing on the left, the left is the latest code, right is the original.
https://user-images.githubusercontent.com/806104/161122449-8ad0280c-ad86-4f34-bd4a-84e5f288cb7c.mp4
I can't type on the right. It beeps at me when I try to.
@austincondiff : I am used with webstorm that when I check the differences it is the other way around.
@austincondiff wrote,
P.S. Shameless plug: The mockup above is part of this concept that turned into an open source project. CodeEdit quickly became the top trending project on Github for three days in a row with over 5k stars and got tremendous reception from the community. We'd love to get your input in our discussion to best integrate a solid editor since you have been doing this for quite some time.
Yes, I did have a look. Very impressive project!!
As far as the integration of a code edit view is concerned, I am of course partial 😉 As I mentioned before, if you are still considering to use CodeEditorView
, I am perfectly happy to help with that. On the other hand, there seem to be other contributors who also have at least some components, such as highlighting, that they might want to use. From the issue, the overall intention wasn't quite clear to me. In any case, I can certainly add a statement of my willingness to participate on the issue.
That would be great.
Hey @austincondiff , how will CodeEdit differ from https://github.com/scade-platform/Nimble for example?
In CodeEdit, our goal is to reach editor feature parity with Xcode. We'd like to use CodeEditorView as opposed to rolling our own editor view. That considered the question arises, what is the responsibility of the editor and what is the responsibility of the application built around it?
I am thinking the Code Review might be the responsibility of the editor as it is the editor that draws the new lines, line highlights etc. What are your thoughts here? If it is not the responsibility of the editor, without looking into it too much, is CodeEditor extensible enough to build this on top of it outside the editor?