3 ms·
I've mostly built Amp to fit into my workflow, which is unix line-endings & ASCII/UTF-8 at the moment. Not opposed to alternative encodings, but I think that's
by wasted_intel 8y ago
I've mostly built Amp to fit into my workflow, which is unix line-endings & ASCII/UTF-8 at the moment. Not opposed to alternative encodings, but I think that's a non-trivial addition. Amp uses a gap buffer under the hood and avoiding segmenting multi-byte UTF-8 graphemes/grapheme clusters was tricky. It's definitely possible, it just hasn't been a priority, yet.
- jimsmart 8y agoArguably this is somewhat of a kludge(?), but one option (which would involve less coding than making the engine work with different encodings) would be to use readers/writers to support other formats, and keep using UTF-8 internally. UTF-16BE/LE and UTF-32, plus Windows CPs, are all really easy to do like this — probably others too. (Note that depending on the range of codepoints used in files using these encodings, they may take more memory in UTF-8 form. This usually isn't an issue unless one is handling large files of Kanji)
- carlmr 8y agoI agree, especially as UTF-8 is standard inside Rust. Also the encoding library would make it easy enough to support other formats. I'm not sure if the editor streams or loads into RAM right now. If it already loads into RAM this is a tiny change. https://crates.io/crates/encoding https://crates.io/crates/encoding Line endings should also be unproblematic.