Лучше расскажи, как ты word wrap делаешь.

(Reply to this) (Thread)

и скобачки

(Reply to this) (Parent)

а тут-то чего интересного? хардврап тривиален, а софтврап делает фрэйм-рисовалка. массив строк и их длин — отдельный для каждой рисовалки, он не привязан к буферу текста вообще. на стадии скана строк и бьём, где удобно. а при редактировании проверяем, надо ли переразбивать, и если да — переразбиваем «физическую» строку заново на логические. определить границы «физической» строки тривиально.

(Reply to this) (Parent)

Котики, бобики... Развели зверинец.
Мне интересно как они китайцев теснить будут. Мс ведь и в мобиллы даже метит, но там уже занято.

(Reply to this) (Thread)

анон, ну ёлы-палы же, у тебя прицел сбился!

(Reply to this) (Parent)

неизящно...
Мы в 10-м, примерно, классе всем кагалом писали текстовый редактор. Строки там хранились в списке. Односвязном. Мне ещё досталась обработка Enter'а.
Вот это неизящно, а не то, что у тебя.

upd, кстати, правильный, лучше идти от результата, чем гадать на кофейной гуще.

(Reply to this) (Thread)

да все, наверное, писали редактор, где строки в списках. ничего, у меня тоже список строк есть (массив, точнее; ну, aa-массив), наследственность соблюдена. и тоже надо этот массив рихтовать при каждом обновлении текста. проклятие какое-то: куда ни ткнись — везде каким-то образом для скорости можно заюзать аа-дерево.

и, кстати, чего такого неизящного в списке строк? нормальная идея же. основной недостаток — нужно делать compacting GC, чтобы фрагментацию забарывать, поэтому памяти надо 2*n. ну и чо, egedit (мой «сейчасный» редактор) вообще 3*n требует, и фрагментирует её адово; ничо, пользуюсь.

(Reply to this) (Parent)

p.s.: ты вот не поверишь — но в том же far редатор список строк использует. посмотри исходник (там он не лучший, но). а сколько кода в фаровом редакторе написано, тем не менее…

(Reply to this) (Parent) (Thread)

Не, вот фаре всё по уму сделано. Во-первых, там никто не пишет велосипед, и пользуют стандартный контейнер. Во-вторых, стандартный контейнер это всё же двусвязный список, поэтому идиотских пробежек от начала там нет. И, в-третьих, там список не строк, а объектов управления строками. В общем, достаточно прилично сделано.

(Reply to this) (Parent) (Thread)

>это всё же двусвязный список, поэтому идиотских пробежек от начала там нет
ойхаха. смотрим код перехода на строку номер n. умиляемся. оно в принципе нормально не работает нигде кроме как рядом с текущим регионом редактирования.

там неприлично и уёбищно абсолютно всё. ну, то есть, вообще, полностью, абсолютно всё — от структур данных до лапши вместо кода.

(Reply to this) (Parent) (Thread)

Посмотрел.
Неужели ты не заметил, как красиво там оптимизирован переход?
if (Line > m_it_CurLine.uNumber() / 2)
{
bReverse = true;
}

Ну а так-то да, типичное рагу болоньезе из 90-х. Зато кондово и понятно.

(Reply to this) (Parent) (Thread)

если это — «понтяно»… а я-то, блядь, стараюсь… ты просто мне убил всё. как жить, если это вот — «понтяно», как, я тебя спрашиваю?!

(Reply to this) (Parent) (Thread)

Ну блин, ты ж не маленький, должен осознавать, что наивная реализация всегда будет более понятной, чем оптимальная. Она как песня акына, что вижу, то пою.

(Reply to this) (Parent) (Thread)

да там понятно только то, что кого-то сильно тошнило. прямо в код.

(Reply to this) (Parent)

кстати, не, не осознаю. чего в SXED непонятно-то? кроме системы undo/redo, которая уёбищная, и мне самому не нравится.

(Reply to this) (Parent)

вопрос, кстати, не праздный: мне действительно было бы интересно, если бы ты — когда дойдут руки (я оптимист!), — сказал, что в SXED неясно хотя бы по API.

(Reply to this) (Parent) (Thread)

Неясно #1: а где, собственно, сам API?

Ну то есть в фаре понятно, речь про него не идёт, но как я и говорил, наивная реализация, чо куда смотреть практически сразу понятно.

В коде вима (ну да, я туда для сравнения заглянул) разобраться сложнее, но в общем минут за пять я нашёл команды командного режима и как там переход по номеру строки работает.

У тебя что-то есть в buffer.h, но как-то оно слишком низкоуровнево для API.

Впрочем, я тупой и испорчен шарпожабой, это тоже нельзя забывать.

(Reply to this) (Parent) (Thread)

потому что дизайндокумент читать надо! ;-)

текстовый буфер и есть низкоуровневый текстовый буфер. вид на этот буфер делает фрэйм, который в "backx11/sxed_frame.h" (пока там). оно, конечно, ещё не полное — дополняется по мере дописывания фич в уй. а в libsynt/ лежит движок стилей и хайлайтер синтаксиса.

а интересны мне все уровни, конечно. и апи деревов, и птаблов, и буфера, и фрэйма. мне, в общем, интересно, достаточно ли комментариев к апи и структурам, чтобы понять, что делает тот или иной вызов без заглядывания в его полные исходники.

(Reply to this) (Parent) (Thread)

>backx11
Really?

Я, собственно, ожидал, что у тебя будет абстрактный буфер, который будет дёргаться из бэкэндов, потому в папку для иксов и не заглядывал.

>и апи деревов,
Ну вот сразу пара блошек:

Пометь sxed_aatree_init_ex как служебную функцию. А то смотрю раздел "Создание и удаление деревьев", сначала идёт функция создания без пояснений и с нихуя не очевидными аргументами, затем удаление. Я сразу подвисаю на вопросе "а как создавать-то". И только потом замечаю отдельные функции для создания каждого вида. То есть не принциально, но слегка мешает.
То же верно для sxed_aatree_insert_ex. Коммент создаёт впечатление, что относится к ней, а на самом деле надо использовать sxed_aatree_insert

Вот эту конструкцию я не пони:
// you can walk the tree starting from any node, in any direction.
// returns `nullptr` when complete (or on error)
//
sxed_aatree_node *sxed_aatree_first_node (sxed_aatree *tree);

Как мне кажется, "when complete" это "по завершению". Но как мне кажется, по завершению она должна выдавать указатель на ноду, или нульптр, если что-то пошло не так. Или в данном случае complete имеет иной контекст, который я не схватываю.

// remove given range from the tree
What's range? Usually, a range is something between two arbitrary marks. And the function got only one static mark. So some clarification is needed I believe.


// _join_ the given node at the given offset
....
sxed_aatree_node *sxed_aatree_split_at

Copypaste is baaaaad ^)

// lineinfo tree API
// WARNING! calling this (and any other API) on invalid tree type is UB!
Then I would be good to add _line_ as a separate noun in function name to clearly distinguish LI-tree API and other functions

// returns line offset in the node in `lineofs` (if `lineofs` is not `nullptr`)
.....
sxed_aatree_node *sxed_aatree_findudata (sxed_aatree *tree, uint32_t index);

Copypaste is baaaaad ^)

(Reply to this) (Parent) (Thread)

>Пометь sxed_aatree_init_ex как служебную функцию
почему служебную? она не служебная. добавил туда камент, спасибо.

>Вот эту конструкцию я не пони:
это пояснение ко всей секции. "when complete" — это "when the walking is complete". спасибо, докинул каментов.

>// remove given range from the tree
>What's range?
ahem…
`sxed_aatree_delete (sxed_aatree *tree, uint32_t index, uint32_t size)`
там вот `size` не на что не намекает разве? ;-)

>Copypaste is baaaaad
ага. она вдобавок ещё и не используется нигде. надо бы удалить нахрен потом.

>Then I would be good to add _line_ as a separate noun in function name to clearly
>distinguish LI-tree API and other functions
неудобно печатать. и так имена неебической длины. но в принципе ты прав, конечно. ;-)

>Copypaste is baaaaad
ага, спасибо, убрал к хуям тоже. ;-)

(Reply to this) (Parent) (Thread)

>`sxed_aatree_delete (sxed_aatree *tree, uint32_t index, uint32_t size)`
>там вот `size` не на что не намекает разве? ;-)

Не-а, не намекает. Ну размер это чего-то. Тем более, судя по комментарию (// for non-pt tree types, `size` doesn't matter), этот размер относится к внутренностям ноды, а не к дереву.

(Reply to this) (Parent) (Thread)

и что он может значить кроме длины спана? я честно не в состоянии представить ни одного логического выверта, который позволит при виде слова «range» и аргументов «позиция, длина» — проинтерпретировать это как-то иначе, нежели «начало и длина оного range». а если кто-то таки да — то ему лучше никогда не пытаться использовать libsxed, там дальше всё ещё хуже. ;-)

(Reply to this) (Parent) (Thread)

Так я же тебе и продемострировал этот выверт: из коммента делается вывод, что к range относится только индекс, а size это только для специфичных внутренних данных. Вот и остаётся из аргументов только "позиция".

(Reply to this) (Parent) (Thread)

ну, вот в этом случае я не согласен, что это нормальный вывод. есть граница между «понятно» и «для не умеющих думать идиотов».

а вот про «size doesn't matter» — это баг документации. про который я уже протупил. убрал, спасибо. он везде матерс.

(Reply to this) (Parent)

p.s.: ты просто не совсем понял, видимо, что дерево может быть как массивом в виде «каждый индекс соответствует одной ноде», так и хранилищем спанов произвольной длины, где нода может покрывать некую длину. соответственно, там везде почти указывается размер, и функция «выкусывает» из дерева спан — вне зависимости от типа хранилища. вставлялки делают то же самое.

(Reply to this) (Parent) (Thread)

у вставлялок офсет есть. Вот есть у тебя нода, в которой лежит 'abcd'. Как ты 'bc' выкусишь?

(Reply to this) (Parent) (Thread)

да элементарно — сплитим ноду на три, внутреннюю удаляем. что, собственно, код и делает.

(Reply to this) (Parent)

ну, то есть, движку-то похуй, один там спан, три, или охулиард. офсет — внутри ptable. индекс — индекс в буфере, виртуальный.

(Reply to this) (Parent)

то есть, индексируются НЕ НОДЫ. индексы — для массива. без дырок. а сколько именно нод этот массив представляет — неважно, это забота дерева. оно лучше знает. захочет — смержит, понадобится — сплитнет.

(Reply to this) (Parent)

ну, и переименовал некоторые функции, спасибо тоже. пусть уж будет красившее.

(Reply to this) (Parent)

Продолжаем потихоньку

sxed_buffer.h

// called on successfull attach, "pre"
Add the word 'callback' to clarify the meaning, pls

// callback type, for `type`
for `type` what? Argument? Field? RetVal? I'd like it to be a little more eloquent.

// this blocks buffer changing via the API
#define SXED_BUFFER_FLAG_READONLY (0x01u)
Как-то смысл коммента и флага не бьются. Получается, что флаг выставляется, когда идёт изменение содержимого буфера что-ли? Но тогда BUSY or LOCKED было бы понятнее

// this clears the buffer, frees all buffer internal structs, and reinits everything
// doesn't remove any callbacks, only text and undo
// resets "modified" flag
sxed_status sxed_buffer_wipe (sxed_buffer *buf);

1-е противоречие:reinits everything vs only text and undo
2-e противоречие: У флага в комментах:
// will NOT be reset on clearing/disabling undo
#define SXED_BUFFER_FLAG_MODIFIED (0x02u)

// passing zero will reset all flags
void sxed_buffer_reset_flag (sxed_buffer *buf, uint32_t flagmask);
All _public_ flags, I believe. Or do UNDOING/REDOING flags get cleared too with zero?

// if `slen` is negative, use `strlen()`
What does it mean? It's an input parameter, there is no ifs. Or does it means that the function will call strlen to get slen on itself?


// ////////////////////////////////////////////////////////////////////////// //
// callback attaching and detaching
//
// it is guaranteed that you can attach at least 64 callbacks to the buffer
// it is possible to add/remove callback from inside the callback code

Ранее в той же серии:
// WARNING! adding/removing callbacks from callback code is NOT SUPPORTED. this is not checked, and is UB.

// returns `false` if there is no callback with the given id
А в других комметах в этом случае говорилось, что возвращается zero для false и non-zero для true
Не принципиально, конечно.

//it is called "clip object" because i couldn't invent a better name
The name is.... Clippy! ;)

// out-of-bounds length will be truncated
What are the bounds of Clippy? At this point I couldn't remember any corresponding defines

(Reply to this) (Parent) (Thread)

>Add the word 'callback' to clarify the meaning, pls
придира! ;-)

>for `type` what? Argument? Field? RetVal? I'd like it to be a little more eloquent.
совершенно очевидно, что это тип события. ладно, тоже убедил.

>Как-то смысл коммента и флага не бьются.
по-моему, довольно очевидно, что если установить этот флаг, то буфер превратится в r/o, и любые попытки его модифицировать провалятся.

>2-e противоречие: У флага в комментах:
потому что для запрещения унды надо снять флаг `SXED_BUFFER_FLAG_UNDO_ENABLED`. или почистить унду отдельным апи. а вот вайп его чистит, о чём и написано явно в докукаменте.

>1-е противоречие:reinits everything vs only text and undo
я не знаю, как короче и понятней написать. тем более, что в буфере кроме унды и текста больше ничего и не бывает. ;-)
переписал ваще заново. ;-)

>All _public_ flags, I believe.
да, ты прав, уточнил.

>// if `slen` is negative, use `strlen()`
>What does it mean?
а вот здесь я считаю, что всё очевидно, и если надо пояснять — то не надо пояснять. везде, где есть параметр «длина», и он знаковый, при отрицательной длине на входной буфер натравят `strlen()`.

>Ранее в той же серии:
спасибо, остаток старого апи. уточнил.

>А в других комметах в этом случае говорилось, что возвращается zero для false и
>non-zero для true
да, исправил на «ноль».

>// out-of-bounds length will be truncated
>What are the bounds of Clippy?
ну, довольно очевидно, что длина здесь относится к буферу, потому что клип ещё не существует. там даже параметр называется `length`. добавил бэктики. ;-)

спасибо!

(Reply to this) (Parent) (Thread)

>везде, где есть параметр «длина», и он знаковый, при отрицательной длине на
входной буфер натравят `strlen()`

Ну да, я до этого додумался. Но конструкция if `slen` is negative, use `strlen()` переводится как "Если slen отрицательна, используй strlen"
А то, что ты хотел сказать, это When `slen` is negative, `strlen()` will be used.

(Reply to this) (Parent) (Thread)

а, ты в этом плане. да, ты прав, докинул везде «will».

(Reply to this) (Parent)

тут проблема в том, что я иногда сбиваюсь с «фокала читателя» на «фокал кода». и сам этого не вижу. поэтому и нужны «другие глаза». спасибо большое.

(Reply to this) (Parent)

В критах только одна очепятка
this code is inspired by Dan Bernstein's "qhasm" and implements a binary
* crit-bit (also known as PATRICA) tree for byte keys.

It's PATRICIA

(Reply to this) (Parent) (Thread)

спасибо, все опечатки пофиксил.

(Reply to this) (Parent)

sxed_encode.h

// minimum utf valud for the given

valuE
и ниже

// ////////////////////////////////////////////////////////////////////////// //
// if `ssize` is negative, use `strlen()` to calculate `s` size
// assumes valid utf-8 sequence
uint32_t sxed_utf8_slen (const void *s, int ssize);

will use
и в следующих то же самое.

(Reply to this) (Parent)

sxed_memman.h

* internally it asks OS to mmap some area, splits it to by 4KB chunks,

to явно лишняя

(Reply to this) (Parent)

p.s.: фрэйм и буфер разделены потому что это удобно. а ещё можно открыть несколько фрэймов для одного и того же буфера (да, это уже есть, и уже работает; они все обновляются, когда в буфере что-то поменялось).

(Reply to this) (Parent) (Thread)

Дык я же и не спорю, что это удобно, иногда реально очень полезный функционал.

Просто не ожидал, что ты фрейм к бэкенду прицепишь.

(Reply to this) (Parent) (Thread)

а мне так девелопить удобней. так-то он рендерит в «абстрактный символьный буфер», а уже этот буфер бэкэнд рендерит себе куда интересно.

(Reply to this) (Parent)

собственно, оно потом уедет оттуда — поэтому и название "sxed_*". а пока нестабильное — живёт рядом с икс-рендерилкой. они так-то вместе росли из «просто нарисую сраную букву в иксах», поэтому и живут пока вместе. ;-)

(Reply to this) (Parent)

sxed_ptable.h

Коммент 1: note that there is no way to "shrink" the buffer.
Коммент 2: // shrink buffer to the given size

Кто прав?

(Reply to this) (Parent) (Thread)

оба. ;-) буфер нельзя шринкать, но если очень хочется и точно-точно знаешь, что делаешь — то можно. я хуй знает, как это понятней написать без кучи слов. убрал к херам.

(Reply to this) (Parent)

интересно, (Win)RAR такой же жопой написан?
а то от 7-Zip психическая травма у меня уже случилась, я его с компа тупо снёс нахуй (но на ноуте стоит ещё).

/ЧД/

(Reply to this) (Parent) (Thread)

>интересно, (Win)RAR такой же жопой написан?
а ты думаешь нет? вот фар криво, а рар вдруг чудом прямо. ;-)

(Reply to this) (Parent)