>>> From my POV, this would be required in some form or another before such >>> a scheme could actually work. Without it we end up with an improved >>> win32text (good!) >> >> I still think this would be actually bad. >> >> Instead, a new extension should be written, with a name that does not >> have "win32" as a substring, and that has no provision for guessing >> line breaks by inspecting files. > > To be clear, you are suggesting: > > * Having hg enforce an extension as required is good. I have no opinion on that. > * Python adopting win32text as that extension would be bad - instead > another extension with different semantics (ie, no guessing based on > file content) should be used, and enforced, instead. Yes. The functionality being discussed should not be added to win32text. > Assuming I am correct, I am inclined to agree - win32text may be "good > enough" in the short term, but it is far from ideal. I also feel that an extension that is inherently platform independent and has a clear specification has much higher chances of becoming a standard feature of Mercurial one day. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4