<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8"> </head> <body> <div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">On 8 Oct 2019, at 20:55, Rob Brackett wrote:</p> <blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">P.S. Allan, I think a while back, you or some other major contributor mentioned it might be better to try and integrate EditorConfig support directly into TextMate, since plugins like this can be a bit fiddly and it’s hard for third party compiled code to get at the non-dynamic C++ bits like the actual settings struct attached to an OakDocument. I was thinking the right place to start for that would be to add support for the two EditorConfig settings that don’t have an equivalent in TextMate (trim_trailing_whitespace and insert_final_newline) to the settings struct and to OakDocument. Does that seem like a good idea? Should I just submit a pull request to <a href="https://github.com/textmate/textmate" style="color:#777">https://github.com/textmate/textmate</a> <<a href="https://github.com/textmate/textmate" style="color:#777">https://github.com/textmate/textmate</a>>?</p> </blockquote><p dir="auto">I am definitely open for native EditorConfig support, but with 2.0 now “final”, I’m expecting some refactoring with one of the goals being to have more of the C++ interfaces moved to Objective-C classes and “inline” the load/save process (it’s currently way to complicated), so if the plug-in currently works, I’d not recommend investing too much time on a PR based on the current code base, as at least I don’t see an obvious place where these features should be added to the current code, but I’ll keep them in mind when I get around to refactoring.</p> </div> </div> </body> </html>