ecc-comp

Hey, I hope there is a BackBlaze person lurking the comments. I use BackBlaze to make sporadic, one time backups. I then disconnect everything - which is just 2 mirrored drives. These drives only contain important documents. Can BackBlaze please not delete my backups if my drives are not connected for X days, even though I pay for the backups? It is very confusing to me, and actually pretty damn frustrating. To be more clear, my backup solution is detailed here, where I recommend BackBlaze even: https://ecc-comp.blogspot.com/2020/07/backing-up-for-mortals.html Thanks!

> I wonder what data structure the Atom text editor uses --- it's famously slow on large files, but I doubt that's where the bottleneck is; it's more like an IDE so parsing and rendering are taking the bulk of the time. It is written in JavaScript and browser-based, but having seen JS run a PC emulator and boot a usable Linux kernel, I don't think that is the bottleneck either. There was quite nice post [1] commented here [2] lately on text management of web text editors. Quote: > Every time text is inserted, it's inserted as one "chunk", then split up by its line endings. This is done by invoking a regular expression engine. Personally I think this is overkill, but it certainly lets Atom continue to be easily modifiable. I can imagine the same thought is running through a few people reading this. It pushes all the new lines to a stack (or more technically: a regular JavaScript array). Already I don't want to find myself opening a large file. It then uses "spliceArray" to replace a range of lines. > So what is the actual data structure of the great Atom text buffer?... > @lines = ['']; > A regular JavaScript array. Ooof. I think that in JS simple operations on arrays of strings have much more impact than in C. Few things from the top of my mind: additional metadata that has to be managed behind the scenes and garbage collection. But I don't really know how it would add up to overall performance. Certainly performance would look different if text would be rendered by…

Yeah, reminds me of this post: https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-5-text-edi… There's a simple array of lines, a gap buffer, a BTree... No DOM, though. I wonder why... :)

This is a much interesting link: http://ecc-comp.blogspot.com/2016/03/reverse-engineering-kirbys-dreaml… Has some screenshots too.

https://news.ycombinator.com/item?id=20603567, discussing https://viewsourcecode.org/snaptoken/kilo/index.html probably will give you some hints. Architecture-wise, you can start with an ordered list of lines, with each line stored as a string. Features that complicate things are: - supporting large documents and staying speedy (“replace all” is a good test case) - supporting line wrapping or proportional fonts (makes it harder to translate between screen locations and (line, character) offsets) - supporting Unicode (makes it harder to translate between screen locations and (line, byte position) offsets) - syntax-colouring - plug-ins - regular expression based search (fairly simple for single-line search _if_ you store each line as a string; harder for custom data structures, as you can’t just use a regexp library) - supporting larger-than-memory files (especially on systems without virtual memory, but I think that’s somewhat of a lost art) - safely saving documents even if the disk doesn’t have space for two files (a lost art. Might not even have been fully solved, ever) Edit: you also want to look at https://news.ycombinator.com/item?id=11244103, discussing https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-5-text-edi…