View Issue Details

IDProjectCategoryView StatusLast Update
0003205WishesPlugins API.Editorpublic2016-07-17 22:49
ReporterAleXHAssigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionreopened 
Product Version 
Target VersionFixed in Version 
Summary0003205: Добавить возможность указания цвета пробельных символов, включаемых в настройках редактора
Description[x] Show white space Editor.Set(20,1)

а также добавить в АПИ возможность указания/изменения этого цвета. Хотелось бы сократить время на раскраску окна редактора и избавиться от необходимости перекрашивать пробельные символы в более тёмный цвет - используемый сейчас единый с текстом цвет приводит к дискомфорту восприятия.
TagsNo tags attached.
Build0

Activities

zg

2016-03-30 14:02

developer   bugnote:0014412

ECTL_ADDCOLOR.

AleXH

2016-03-30 15:49

reporter   bugnote:0014414

Last edited: 2016-03-30 15:51

View 3 revisions

ECTL_ADDCOLOR задаёт цвет части строки. В то время как речь идёт о задании цвета для всего класса пробельных символов одновременно. Если мы можем включить/отключить одномоментно их отображение командой editor.set, то почему также не сделать с их цветом? - Повторюсь, процедура раскраски пробельных построчно требует времени, и если есть возможность этого избежать, то прошу сделать. Тем более, что схожее желание уже озвучивали ранее на форуме. Если же это невозможно по техническим, либо каким другим причинам, то просьба пояснить это.

DrKnS

2016-03-30 20:20

administrator   bugnote:0014418

> Повторюсь, процедура раскраски пробельных построчно требует времени

Как я понимаю, вы уже написали плагин, делающий ECTL_ADDCOLOR, провели измерения и результат явно неудовлетворителен. Можно увидеть конкретные цифры?

AleXH

2016-03-31 10:57

reporter   bugnote:0014421

Last edited: 2016-03-31 10:57

View 2 revisions

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

Раскраска с помощью скрипта справляется с задачей, но если пользователю требуется подсветить не только пробельные символы, но и другие его классы (наборы), то производительности скрипта становится уже недостаточно - ощущаются лаги при скроллировании текста, особенно в горизонтальном направлении. Отсюда и выплывает желание довести начатое с подсветкой пробельных символов в FAR до логического конца - добавить возможность указания цвета, избавившись от их раскраски в скрипте.

zg

2016-03-31 17:06

developer   bugnote:0014422

> особенно в горизонтальном направлении
длинные строки? тогда может быть дело в скорости нахождения мест, где надо красить, а не собственно в раскраске?

вообще, если это делать внутри фара, никакого принципиального ускорения не будет.

AleXH

2016-03-31 19:42

reporter   bugnote:0014423

Last edited: 2016-03-31 19:52

View 2 revisions

В 3204 приведена ссылка на сам скрипт, базирующийся на вашем, в нём использован нежадный захват множеств символов, поэтому ему длинные строки не столь страшны, тем более они ограничены шириной окна. Основной тормоз от лишних EE_REDRAW обходится срабатыванием на первый, а последующие, пришедшие чаще, чем 8мс - игнорируются. Хоть из-за этого появляется иногда проскакиваемое мерцание, тем не менее их игнор позволяет частично решить проблему тормозов скролинга. Но есть сильная зависимость производительности от контента, находящегося внутри окна. А поскольку используется раскраска 3-х множеств, одно из которых пробельные символы, то появился этот виш.

С одной стороны я вас (разработчиков фара) понимаю - вынести за пределы фара то, что можно вынести. Отображение пробельных символов добавили - хотите плагин их раскрашивающий - делайте, не хотите - не делайте, справедливо, нет вопросов. С другой стороны городить плагин для этого такой "мега" задачи никто не будет - и задача не столь велика для целого плагинаа и желающих нет. И получается, возможность отображения есть, а пользоваться - глаза ломать, остаётся скрипт. Ну а про него уже написано выше.

Если принципиального ускорения не будет, то делать, безусловно, не нужно - покрасим пробельные, как и ранее, скриптом. Но для скрипта это одно лишнее множество, символы которого щедро рассыпаны по строке, поэтому избавиться от него было бы неплохо.

Но лишние EE_REDRAW надо бы пофиксить в любом случае. Ну и событие исключительно при изменении контента внутри окна добавить, по возможности, конечно. Перекрашивать при сдвиге курсора внутри окна смысла нет, по крайней мере в моём случае.

zg

2016-03-31 22:57

developer   bugnote:0014424

> В 3204 приведена ссылка на сам скрипт
TabToReal, если не стоит преобразовывать табы в пробелы, не сказать, что дешёвая функция. регэкспами искать пробелы тоже не думаю, что самый быстрый вариант.
> Но лишние EE_REDRAW надо бы пофиксить
кто ж спорит, надо. но всё не так просто, да. раньше было ещё хуже.
> Ну и событие исключительно при изменении контента внутри окна добавить, по возможности, конечно.
EE_CHANGE.

AleXH

2016-04-01 12:10

reporter   bugnote:0014425

Last edited: 2016-04-01 13:45

View 5 revisions

TabToReal нужен - на входе tsv, табы разделители полей и нужно чётко видеть что за символы перед глазами. Если бы не табы, то да, можно пробелы и по коду искать, а так регэксп \s выявляет любые пробельные, которые могут затесаться в текст.

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

zg

2016-04-01 13:50

developer   bugnote:0014426

TabToReal используется, чтобы определить видимый текст, на не очень длинных строках такая оптимизация может привести к потери производительности. зачем красить длинные строки — мне не очень понятно.

AleXH

2016-04-01 14:17

reporter   bugnote:0014427

Последовательности табов могут быть длинными - колонок много.

> зачем красить длинные строки — мне не очень понятно
чуть выше же сказал.

zg

2016-04-01 14:30

developer   bugnote:0014428

длинными — это в абсолютных цифрах сколько?

AleXH

2016-04-01 14:35

reporter   bugnote:0014429

до 40 колонок, а сами строки до 2000 символов

Issue History

Date Modified Username Field Change
2016-03-30 10:47 AleXH New Issue
2016-03-30 14:02 zg Note Added: 0014412
2016-03-30 14:03 zg Build => 0
2016-03-30 14:03 zg Status new => closed
2016-03-30 14:03 zg Resolution open => no change required
2016-03-30 15:49 AleXH Note Added: 0014414
2016-03-30 15:49 AleXH Status closed => feedback
2016-03-30 15:49 AleXH Resolution no change required => reopened
2016-03-30 15:50 AleXH Note Edited: 0014414 View Revisions
2016-03-30 15:51 AleXH Note Edited: 0014414 View Revisions
2016-03-30 20:20 DrKnS Note Added: 0014418
2016-03-31 10:57 AleXH Note Added: 0014421
2016-03-31 10:57 AleXH Status feedback => new
2016-03-31 10:57 AleXH Note Edited: 0014421 View Revisions
2016-03-31 17:06 zg Note Added: 0014422
2016-03-31 19:42 AleXH Note Added: 0014423
2016-03-31 19:52 AleXH Note Edited: 0014423 View Revisions
2016-03-31 22:57 zg Note Added: 0014424
2016-04-01 12:10 AleXH Note Added: 0014425
2016-04-01 12:11 AleXH Note Edited: 0014425 View Revisions
2016-04-01 12:24 AleXH Note Edited: 0014425 View Revisions
2016-04-01 12:30 AleXH Note Edited: 0014425 View Revisions
2016-04-01 13:45 AleXH Note Edited: 0014425 View Revisions
2016-04-01 13:50 zg Note Added: 0014426
2016-04-01 14:17 AleXH Note Added: 0014427
2016-04-01 14:30 zg Note Added: 0014428
2016-04-01 14:35 AleXH Note Added: 0014429