View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003205 | Wishes | Plugins API.Editor | public | 2016-03-30 07:47 | 2016-07-17 19:49 |
Reporter | AleXH | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | reopened | ||
Summary | 0003205: Добавить возможность указания цвета пробельных символов, включаемых в настройках редактора | ||||
Description | [x] Show white space Editor.Set(20,1) а также добавить в АПИ возможность указания/изменения этого цвета. Хотелось бы сократить время на раскраску окна редактора и избавиться от необходимости перекрашивать пробельные символы в более тёмный цвет - используемый сейчас единый с текстом цвет приводит к дискомфорту восприятия. | ||||
Tags | No tags attached. | ||||
Build | 0 | ||||
|
ECTL_ADDCOLOR. |
|
ECTL_ADDCOLOR задаёт цвет части строки. В то время как речь идёт о задании цвета для всего класса пробельных символов одновременно. Если мы можем включить/отключить одномоментно их отображение командой editor.set, то почему также не сделать с их цветом? - Повторюсь, процедура раскраски пробельных построчно требует времени, и если есть возможность этого избежать, то прошу сделать. Тем более, что схожее желание уже озвучивали ранее на форуме. Если же это невозможно по техническим, либо каким другим причинам, то просьба пояснить это. |
|
> Повторюсь, процедура раскраски пробельных построчно требует времени Как я понимаю, вы уже написали плагин, делающий ECTL_ADDCOLOR, провели измерения и результат явно неудовлетворителен. Можно увидеть конкретные цифры? |
|
Имеется функция отображения пробельных знаков - это замечательно. Но для того, чтобы она была юзабельной, к ней в догонку требуется плагин, который превратит фарш из одноцветных символов на экране в удобочтимый вариант. - Разве не разумно было бы одновременно добавить возможность указания цвета для отображаемых пробельных символов, чтобы этой возможностью было просто и удобно пользоваться? Если же принятое половинчатое решение связано с техническими ограничениями, тогда перекладывание раскраски на сторонний плагин, либо скрипт понятно, в противном же случае это не доведённое до логического конца решение. Раскраска с помощью скрипта справляется с задачей, но если пользователю требуется подсветить не только пробельные символы, но и другие его классы (наборы), то производительности скрипта становится уже недостаточно - ощущаются лаги при скроллировании текста, особенно в горизонтальном направлении. Отсюда и выплывает желание довести начатое с подсветкой пробельных символов в FAR до логического конца - добавить возможность указания цвета, избавившись от их раскраски в скрипте. |
|
> особенно в горизонтальном направлении длинные строки? тогда может быть дело в скорости нахождения мест, где надо красить, а не собственно в раскраске? вообще, если это делать внутри фара, никакого принципиального ускорения не будет. |
|
В 3204 приведена ссылка на сам скрипт, базирующийся на вашем, в нём использован нежадный захват множеств символов, поэтому ему длинные строки не столь страшны, тем более они ограничены шириной окна. Основной тормоз от лишних EE_REDRAW обходится срабатыванием на первый, а последующие, пришедшие чаще, чем 8мс - игнорируются. Хоть из-за этого появляется иногда проскакиваемое мерцание, тем не менее их игнор позволяет частично решить проблему тормозов скролинга. Но есть сильная зависимость производительности от контента, находящегося внутри окна. А поскольку используется раскраска 3-х множеств, одно из которых пробельные символы, то появился этот виш. С одной стороны я вас (разработчиков фара) понимаю - вынести за пределы фара то, что можно вынести. Отображение пробельных символов добавили - хотите плагин их раскрашивающий - делайте, не хотите - не делайте, справедливо, нет вопросов. С другой стороны городить плагин для этого такой "мега" задачи никто не будет - и задача не столь велика для целого плагинаа и желающих нет. И получается, возможность отображения есть, а пользоваться - глаза ломать, остаётся скрипт. Ну а про него уже написано выше. Если принципиального ускорения не будет, то делать, безусловно, не нужно - покрасим пробельные, как и ранее, скриптом. Но для скрипта это одно лишнее множество, символы которого щедро рассыпаны по строке, поэтому избавиться от него было бы неплохо. Но лишние EE_REDRAW надо бы пофиксить в любом случае. Ну и событие исключительно при изменении контента внутри окна добавить, по возможности, конечно. Перекрашивать при сдвиге курсора внутри окна смысла нет, по крайней мере в моём случае. |
|
> В 3204 приведена ссылка на сам скрипт TabToReal, если не стоит преобразовывать табы в пробелы, не сказать, что дешёвая функция. регэкспами искать пробелы тоже не думаю, что самый быстрый вариант. > Но лишние EE_REDRAW надо бы пофиксить кто ж спорит, надо. но всё не так просто, да. раньше было ещё хуже. > Ну и событие исключительно при изменении контента внутри окна добавить, по возможности, конечно. EE_CHANGE. |
|
TabToReal нужен - на входе tsv, табы разделители полей и нужно чётко видеть что за символы перед глазами. Если бы не табы, то да, можно пробелы и по коду искать, а так регэксп \s выявляет любые пробельные, которые могут затесаться в текст. EE_CHANGE, как я понял, не приходит во время сдвига экрана, что приводит к необходимости красить всю строку целиком, а не видимую её часть - активация раскраски и вертикальный скроллинг будут ещё больнее. |
|
TabToReal используется, чтобы определить видимый текст, на не очень длинных строках такая оптимизация может привести к потери производительности. зачем красить длинные строки — мне не очень понятно. |
|
Последовательности табов могут быть длинными - колонок много. > зачем красить длинные строки — мне не очень понятно чуть выше же сказал. |
|
длинными — это в абсолютных цифрах сколько? |
|
до 40 колонок, а сами строки до 2000 символов |
Date Modified | Username | Field | Change |
---|---|---|---|
2016-03-30 07:47 | AleXH | New Issue | |
2016-03-30 11:02 | zg | Note Added: 0014412 | |
2016-03-30 11:03 | zg | Build | => 0 |
2016-03-30 11:03 | zg | Status | new => closed |
2016-03-30 11:03 | zg | Resolution | open => no change required |
2016-03-30 12:49 | AleXH | Note Added: 0014414 | |
2016-03-30 12:49 | AleXH | Status | closed => feedback |
2016-03-30 12:49 | AleXH | Resolution | no change required => reopened |
2016-03-30 12:50 | AleXH | Note Edited: 0014414 | |
2016-03-30 12:51 | AleXH | Note Edited: 0014414 | |
2016-03-30 17:20 | DrKnS | Note Added: 0014418 | |
2016-03-31 07:57 | AleXH | Note Added: 0014421 | |
2016-03-31 07:57 | AleXH | Status | feedback => new |
2016-03-31 07:57 | AleXH | Note Edited: 0014421 | |
2016-03-31 14:06 | zg | Note Added: 0014422 | |
2016-03-31 16:42 | AleXH | Note Added: 0014423 | |
2016-03-31 16:52 | AleXH | Note Edited: 0014423 | |
2016-03-31 19:57 | zg | Note Added: 0014424 | |
2016-04-01 09:10 | AleXH | Note Added: 0014425 | |
2016-04-01 09:11 | AleXH | Note Edited: 0014425 | |
2016-04-01 09:24 | AleXH | Note Edited: 0014425 | |
2016-04-01 09:30 | AleXH | Note Edited: 0014425 | |
2016-04-01 10:45 | AleXH | Note Edited: 0014425 | |
2016-04-01 10:50 | zg | Note Added: 0014426 | |
2016-04-01 11:17 | AleXH | Note Added: 0014427 | |
2016-04-01 11:30 | zg | Note Added: 0014428 | |
2016-04-01 11:35 | AleXH | Note Added: 0014429 |