Latest post of the previous page:
а кто сказал, что они ненужные?NightRoman wrote:но хорошо ли, что ненужные данные хранятся?
Latest post of the previous page:
а кто сказал, что они ненужные?NightRoman wrote:но хорошо ли, что ненужные данные хранятся?
колорер — не единственный красящий плагин. плагин вообще может открыть свой файл в редакторе, заблокировать его от изменений и раскрасить его один раз. как можно не хранить, то что за экраном? т.е. фар вообще не в курсе, нужна раскраска, не нужна. хранится всё, что сказали.NightRoman wrote:Если нужные, значит, хорошо.
в тройке — нет.NightRoman wrote:Например, с колорером не будет работать, он все затрет (даже на файлах, которые не знает).
я не пользуюсь.А поскольку колорер пользуют почти все
в 3-ке это уже не нужно.Пришлось разработать 2 сценария раскраски
в тройке цвета персональные. только кто добавил, тот и может удалить.Либо ядро освобождается от цветов за экраном, либо никто.
да.NightRoman wrote:Об удалении своих цветов все равно каждый плагин должен заботиться?
т.е. возьмём файл в 200000 строк. вы считаете, что сканированиие всех 200000 строк при каждой перерисовке на предмет, а не надо ли удалить чего из раскраски, это будет эффективнее по скорости?При такой схеме Фар мог бы сам невидимые цвета за экраном просто освобождать. Такая схема не будет ли проще для разработки и эффективнее по скорости (очистку только ядро делает, а не каждый плагин всяк по-своему, в том числе и неоптимально)?
Я бы делал по другому. Очищал бы то, что _становится невидимым_, а не сканировал 200000.т.е. возьмём файл в 200000 строк. вы считаете, что сканированиие всех 200000 строк при каждой перерисовке на предмет, а не надо ли удалить чего из раскраски, это будет оптимальние?
Согласен. Но я не об этом. Я о том, что можно просто не дать плагинам возможность делать что-либо тут неоптимально. Определенным дизайном ядра и АПИ.борьба с неоптимальными плагинами средствами фара, это вообще что-то странное.
Вот еще мнение коллеги, который в теме.sonar wrote:разве фар хранит раскраску для всего файла, а не для только области экрана/окна ? даже если ты туда ходил . что то мне не верится, ибо эту жуткий перерасход памяти, а экран и так перерисовывается при его листании по событиям.NightRoman wrote:Но только у меня не граббер все-таки. Текст за пределами экрана тоже копируется, если надо (правда, для этого хотя бы раз туда надо сходить, чтоб Colorer покрасил, например, просто глянуть в конец файла сначала).
сделайте патч, проверьте выигрыш в памяти и проигрыш в скорости расскажите нам.NightRoman wrote:Я бы делал по другому. Очищал бы то, что _становится невидимым_, а не сканировал 200000.
я так понимаю — это очень плохо, и все должны испугаться?NightRoman wrote:А сейчас если юзер пролистал 200000 строк, то они все будут в памяти покрашены колорером. И в тройке тоже будет так.
вот в том-то и дело. в теории я тоже возможно не против такого поведения. но на практике, это пол редактора перелопачивать и потом ещё пол года глюки вылавливать. а так — всё работает. ну ест памяти слегка побольше, чем надо в синтетических случаях. но на практике если 12 лет назад никто не парился, то теперь-то чего уж.NightRoman wrote:Патч делать не возьмусь. Сапоги - сапожнику, пироги - пирожнику.
фар хранит не для всего файла, а то что покрасили и не стёрли.sonar wrote:то, что фар хранит раскраску текста для всего файла
Ребята, а вообще что вы собрались делать с таким раскрашенным текстом после вставки его в Word? Весь мой опыт показывает, что, как только в документе появляется прямое форматирование на уровне символов, всей поддерживаемости документа моментально приходит мрачный капец и медный таз. Чтобы сохранить поддерживаемость, нужно использовать только форматирование стилями (которым потом можно назначать различное, но всегда консистентное оформление).WARP ItSelf wrote:Тут подумалось, был бы полезен плагин, который в буфер обмена текст из редактора помещает в RTF, вместе с цветами. Сильно полезная вещь при вставке в Word.