Board.KolibriOS.org

0CodErr wrote:Так что, можешь уже начинать делать какой-нибудь TinyEdit

Many versions of Emacs, including GNU, use a single contiguous character array virtually split in two sections separated by a gap. To insert the gap is first moved to the insertion point. Inserted characters fill into the gap, reducing its size. If there’s insufficient space to hold the characters the entire buffer is reallocated to a new larger size and the gaps coalesced at the previous insertion point.

The naive look at this and say the performance must be poor because of all the copying involved. Wrong. The copy operation is incredibly quick and can be optimized in a variety of ways. Gap buffers also take advantage of usage patterns. You might jump all over the window before focusing and inserting text. The gap doesn’t move for display – only for insert (or delete).

On the other hand, inserting a character block at the head of a 500MB file then inserting another at the end is the worst case for the gap approach, especially if the gap’s size is exceeded. How often does that happen?

Contiguous memory blocks are prized in virtual memory environments because less paging is involved. Moreover, reads and writes are simplfied because the the file doesn’t have to be parsed and broken up into some other data structure. Rather, the file’s internal representation in the gap buffer is identical to disk and can be read into and written out optimally. Writes themselves can be done with a single system call (on *nix).

The gap buffer is the best algorithm for editing text in a general way. It uses the least memory and has the highest aggregate performance over a variety of use cases. Translating the gap buffer to a visual window is a bit trickier as line context must be constantly maintained.

haitaka wrote:Для писателей нового редактора например

akron1 wrote:

haitaka wrote:Для писателей нового редактора например

Да, идея красивая, но при реализации оказалось, что не всё так просто. Есть проблемы, связанные с установкой курсора в произвольную строку, выводом текста и др. Лучше уж через динамические списки. Памяти хватит, у нас не 640 Кб). У меня тоже была мысль реализовать редактор для более удобного кодинга в Колибри, но сначала не хватало встроенных в систему шрифтов, опыта разработки для Колибри, потом занятость другими проектами, ну а теперь сообщество предлагает портировать редактор, так что...

- установщик драйверов