search

rjkroege / edwood

Go version of Plan9 Acme Editor
Other
387 stars 34 forks source link

Windows filename handling is utterly broken. #472

Closed paul-lalonde closed 1 year ago

paul-lalonde commented 1 year ago

Edwood (nor acme) cannot handle driver letters and backwards slashes in path names. I believe we use Path internally in some places to handle paths, but not everywhere. We should probably use package path everywhere we parse paths/guess at filenames. Button 3/Look would benefit greatly. This would almost make edwood usable on Windows.

rjkroege commented 1 year ago

That code needs some more attention. More refactoring. Maybe I'll have time soon.

rjkroege commented 1 year ago

Meta comment: the tag contents are both editable text and "structured" in that Edwood parses the tag. This is special cased throughout the code in convoluted ways. My design intuition is that the "right way" to address this is to provide some kind of parse tree layer adjacent to a file.Buffer.

I can't yet decide if I want to make fixing this contingent on refactoring the handling of "structured" text in Edwood.

@paul-lalonde given that I don't have a windows device conveniently at hand, are there some low-road concrete fixes that might be the 20% that addresses 80% of your unhappiness?

rjkroege commented 1 year ago

Probably helped with #483.

paul-lalonde commented 1 year ago

Yes, I think handling spaces is the 80% fix that makes it usable. Handling drive prefixes and backslashes would finish it. Drive prefix handling is ugly because of single character filenames followed by an address, so I suspect windows edwood will need knowledge of currently mounted drive letters. And to do that right you need notifications of mount/unmount events, or a test for a letter being a drive. The latter is simpler, but I don't know if it will be fast enough. Paul

On Fri, Mar 10, 2023, 9:58 a.m. Robert Kroeger @.***> wrote:

Meta comment: the tag contents are both editable text and "structured" in that Edwood parses the tag. This is special cased throughout the code in convoluted ways. My design intuition is that the "right way" to address this is to provide some kind of parse tree layer adjacent to a file.Buffer .

I can't yet decide if I want to make fixing this contingent on refactoring the handling of "structured" text in Edwood.

@paul-lalonde https://github.com/paul-lalonde given that I don't have a windows device conveniently at hand, are there some low-road concrete fixes that might be the 20% that addresses 80% of your unhappiness?

— Reply to this email directly, view it on GitHub https://github.com/rjkroege/edwood/issues/472#issuecomment-1463925494, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ6RUDIPKJYKG2Z47E7NPTW3M6RVANCNFSM6AAAAAAUASB6MM . You are receiving this because you were mentioned.Message ID: @.***>

paul-lalonde commented 1 year ago

Fixed in #485