Open dertuxmalwieder opened 2 years ago
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.\r
\r\n
mode. Seems like an attribute of type ObservableEditableBuffer
?But: is this the Acme way? Should we do it this way? The "better" way maybe:
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!
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 https://github.com/rjkroege/edwood/issues/461#issuecomment-1227919697, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ6RUDP3FBFQC3MT2I4J7TV3ANYRANCNFSM57SS6LNA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
That other cue should be optional though.
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 https://github.com/rjkroege/edwood/issues/461#issuecomment-1227963766, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ6RUEOUTYNFZQCJINLOTDV3ARLZANCNFSM57SS6LNA . You are receiving this because you commented.Message ID: @.***>
@paul-lalonde I don't understand "colouring or other cue". Would something like this be satisfactory:
CrLf
before the |
.) that this is a CrLf
fileCrLf
to the tag of an empty file makes it into one operating in this modeCrLf
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.
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 https://github.com/rjkroege/edwood/issues/461#issuecomment-1232805670, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ6RUDMA2U7UUMKLBXPZC3V345XFANCNFSM57SS6LNA . You are receiving this because you were mentioned.Message ID: @.***>
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".