Make CrLf invisible
dertuxmalwieder opened this issue · 7 comments
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 oftype 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.
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!
That other cue should be optional though.
@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 aCrLf
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 asCrLf
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.