Make CrLf invisible

[dertuxmalwieder]

On Windows, the standard line ending is CrLf. Although edwood is a solid Windows application, I think it should handle native Windows line endings more gracefully than by showing them as "unknown character".

[rjkroege]

The implementation seems not too difficult. Something like this:

• file/observable_editable_buffer.go:267 Load()needs to determine if a given file contains \r\n pairs.
• strip the \r
• and mark the file as being \r\n mode. Seems like an attribute of type ObservableEditableBuffer?
• On save, put put it back in the original format

But: is this the Acme way? Should we do it this way? The "better" way maybe:

• Edwood loses the ability to load files (or directories)
• There is only the filesystem interface
• Edwood can be taught (via plumb?) to find the appropriate loader-storer for a file. Loader-storer are simple single function commands that connect the Edwood filesystem to a physical filesystem?

Maybe this is too precious? @dertuxmalwieder do you prefer option (1)? Assuming option (1), how should the format of new files be controlled? And conceivably, I'd have to serialize the \r\n mode into the dump file.

[dertuxmalwieder]

I would prefer the "better" way if there was a native plumber for Windows (= native paths, no /mnt/c/whatever), but there isn't as far as I could see...?

I guess that the "Acme way" for option 1 would be an independent tool for controlling the file format - Acme itself does not have much functionality built-in either (which is good!). The more interesting problem is that files could have mixed Lf and CrLf line endings. Git has a built-in detector/converter for that, but edwood users do not necessarily have Git. Hmm!

[paul-lalonde]

I want to edit files with both kinds of line endings and have them preserved? Maybe? That means coloring or some other cue.

…

On Thu., Aug. 25, 2022, 6:38 p.m. Cthulhux, ***@***.***> wrote: I would prefer the "better" way *if* there was a native plumber for Windows (= native paths, no /mnt/c/whatever), but there isn't as far as I could see...? I *guess* that the "Acme way" for option 1 would be an independent tool for controlling the file format - Acme itself does not have much functionality built-in either (which is good!). — Reply to this email directly, view it on GitHub <#461 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ6RUDP3FBFQC3MT2I4J7TV3ANYRANCNFSM57SS6LNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dertuxmalwieder]

That other cue should be optional though.

[paul-lalonde]

I'd be happy with a one-pixel glyph. But yes.

…

On Thu., Aug. 25, 2022, 7:09 p.m. Cthulhux, ***@***.***> wrote: That *other cue* should be optional though. — Reply to this email directly, view it on GitHub <#461 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ6RUEOUTYNFZQCJINLOTDV3ARLZANCNFSM57SS6LNA> . You are receiving this because you commented.Message ID: ***@***.***>

[rjkroege]

@paul-lalonde I don't understand "colouring or other cue". Would something like this be satisfactory:

• open file through any of the existing actions
• Logic determines that file has CrLf line endings or regular endings.
• Tag contains the cue (e.g. CrLf before the |.) that this is a CrLf file
• Adding CrLf to the tag of an empty file makes it into one operating in this mode
• CrLf files are saved back to storage as CrLf

Filesystem access sees the CrLf or not? Or not would be way easier to implement and presumably very few existing tools written to the Acme filesystem interface assume Windows line-ending conventions.

[paul-lalonde]

Which now reminds me of the plan9 solution to this: use a synthetic file system to do the CrLf translation. I used to do this with acme-SAC. Which on windows is so much of a pain to do that it's maybe worth doing in the editor. I like the tag suggestion. Paul

…

On Wed., Aug. 31, 2022, 4:20 a.m. Robert Kroeger, ***@***.***> wrote: @paul-lalonde <https://github.com/paul-lalonde> I don't understand "colouring or other cue". Would something like this be satisfactory: - open *file* through any of the existing actions - Logic determines that *file* has CrLf line endings or regular endings. - Tag contains the cue (e.g. CrLf before the |.) that this is a CrLf file - Adding CrLf to the tag of an empty file makes it into one operating in this mode - CrLf files are saved back to storage as CrLf Filesystem access sees the CrLf or not? *Or not* would be way easier to implement and presumably very few existing tools written to the Acme filesystem interface assume Windows line-ending conventions. — Reply to this email directly, view it on GitHub <#461 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ6RUDMA2U7UUMKLBXPZC3V345XFANCNFSM57SS6LNA> . You are receiving this because you were mentioned.Message ID: ***@***.***>