OberonCore

есть у BBCB весьма нервирующий меня недочёт.

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

проблема в том, что `StdSequencer.modLevel` жёстко заточен только на положительные значения: любое undo после его скидывания не отметит документ как грязный. но ведь это неверно! технически, если мы скинули флажок грязности, а потом отменили какое-то действие — то документ стал опять грязным.

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

p.s.: маленькая проблема будет с `SetDirty()` тогда: оно просто инрементирует счётчик. это получается неправильно. можно сделать хак: принудительно ставить флажок в `MAX(INTEGER)`. тогда за счёт переполнения у нас будет два миллиарда (ну, сколько там в signed int влазит) операций до того, как флажок станет нулём. считаем, что такая ситуация нереальна, и плюём на неё.

я себе в LC сделал такое изменение, посмотрим что сломается.

Если откатили изменения до исходного состояния, то - чистый. И Bred, и Geany IDE, и IAR Workbench - все гасят кнопку "Сохранить", когда документ вернулся в исходный вид. А вот в сохранённом изменённом доке уже ничего не откатишь - нет ничего.

меня это везде бесит. ну какой же он чистый, если там явный десинк с диском?

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

в итоге постоянно влетаю на чудесное: повставлял фигни для отладки, автоматом схоронил. отладил, откатил всё до самого начала — а вот тут рефлекс схоронить не работает: я ж ничего не печатал! ;-) документ закрываю — среда молчит, ничего не спрашивает. потому что он «чистый». а потом открываю — а в документе ни разу не чисто, там нагажено.

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

p.s.: самое забавное то, что в BBCB именно такая механика и реализована… почти. вот нафиг не нужен аж целый счётчик изменений, если «чистый» = «больше нет undo-записей». там обычного була достаточно. но BBCB бережно всё считает в инте. но не позволяет инт откручивать ниже нуля почему-то.

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

а, и справедливости ради: у BBCB этого бага не было, пока мы не убрали очистку undo после сохранения. оригинал же ундошки после сохранения чистит, поэтому там всё работает логично. а как только мы чистить перестали — вылезла вот такая фиговина.