allow customisation of underlying NS/UI TextView

[ConfusedVorlon]

This adds an optional param to the initialiser so that you can customise the underlying TextView.
In my case, I wanted to make it non-editable (It's just for previewing code)

    CodeEditor(text: .constant(file.objCBody),
               position: $position,
               messages: $messages,
               language: .swift,
               layout: .standard) {
        textView in
        textView.isEditable = false
    }

I forked from the current release as main doesn't build for me - but if you're open to this then I can redo against the head.

[mchakravarty]

Thanks, that is an interesting extension and I'd be happy to include it. I would suggest one change. Currently, the file OSDefinitions.swift includes aliases for types where AppKit and UIKit use different names. Hence, CETextView should go there and be named OSTextView to be in line with the other names.

What are the specific problems with building main for you? (A while a go, there was a missing dependency, maybe you tried to build then. In case that was the problem, it should be fixed now.)

[lgreydev]

Thank you @ConfusedVorlon

[srazzell]

I would love this feature too.

[rrichc]

I'd also love a way to access the underlying TextView. My use case would be to support a custom keyboard accessory view

[mchakravarty]

@rrichc

I'd also love a way to access the underlying TextView. My use case would be to support a custom keyboard accessory view

I assume that merely accessing the text view is not sufficient for that, but that you also need to hook into the layout of the various views making up the code view. There are four: (1) the text view, (2) the gutter view, (3) the minimap (itself a text view with custom rendering), and (4) a divider line on the left-hand side of the minimap.

Views (2) - (3) are subviews of the text view and I use a custom tiling procedure to position and size them. (See the tile() function in CodeView.swift.)

I assume that you want to put a custom view at the lower end of the text view (above the system keyboard), which means that all the other views need to get shorter.

Anyway, I'm keen to hear your thoughts on this.

[rrichc]

Hi @mchakravarty, thanks for the reply!

I assume that you want to put a custom view at the lower end of the text view (above the system keyboard), which means that all the other views need to get shorter.

Correct, I took a similar approach to the original post and exposed the text view to attach some custom keys to enable tab, shift+tab, move lines, and undo features using the inputAccessoryView property of the text view. It does squish the editor a bit while the system keyboard is active, but with the code editor contained within a scroll view it's sufficient for my use case on iOS.

[mchakravarty]

Correct, I took a similar approach to the original post and exposed the text view to attach some custom keys to enable tab, shift+tab, move lines, and undo features using the inputAccessoryView property of the text view.

Ok, good to know that this is sufficient here.

I am still wondering whether we shouldn't have a bit more general customisation if we add such a feature. With the suggestion in the original post, you only get to manipulate the text view on set up of the code view. (I.e., what corresponds to the makeUIView(context:) function of UIRepresentable). It seems to me that for slightly more elaborate customisation, you likely would also want to hook into updateUIView(_:context:), so that you can update the text view on every SwiftUI view update of the code editor.

What do you think, does that sound reasonable?

[ConfusedVorlon]

I'm some way past using this - so take with a pinch of salt.

broadly though - if you can offer more customisation with a reasonable API - that seems like a good thing to me.