Т9 подбор по буквам

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

Потом начнется, как раньше было с умным фильтром в навигаторе. "Зачем подсказка мне выводит эти значения, по какому принципу???!!!"

Пока не отключил умный фильтр в навигаторе, все никак не успокаивались ))

(1) tormozit, Это нормально что в комментарии подсказка срабатывает?

(5) amiralnar, оффтоп! да

(1) tormozit, Сделал такую фильтрацию в ИР https://www.hostedredmine.com/issues/998755. Потестировал. Теперь уверен, что она для меня оптимальна. Вроде бы ее единственное отличие от актуальной фильтрации Турбоконфа в том, что в моей допускаются пропуск слов.

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

ОбщегоНазначения.УдалМасс

Нужно четко понимать как он должен работать в разных случаях. Я изучил работу фильтров в разных IDE, все они работают по разному.

Также есть разные варианты набора слова.

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

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

3. Пропуски внутри частей слова.

"клчство" - должно вывести Количество

4. Если применять все эти фильтры одновременно, нужно понимать какие у них приоритеты при сортировке.
   bolsun изменил статус на Открыто

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

1. Нахождение полной введенной строки в начале строки с учетом регистра букв, кроме первого символа ("удалитьЭ" находит "УдалитьЭлементМассива")
2. Нахождение всех слов фильтра в началах слов строки в оригинальном порядке с разрешением пропусков (УдалМас находит "УдалитьЭлементМассива")
3. Нахождение всех слов фильтра в началах слов строки в произвольном порядке (УдалМас находит "МассивДляУдаления")
4. Нахождение всех слов фильтра в любых местах строки с учетом порядка (УдалМас находит "УдалитьЗамасленныйРадиатор")
5. Нахождение всех слов фильтра в любых местах строки без учета порядка (УдалМас находит "ЗамасленныйРадиаторУдалить")

Если такая реализация будет слишком долго работать, то можно п.3 и п.5 не применять. Разрешение пропусков уже даст заметный выигрыш в удобстве.

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

Тут предлагаю применять аналогичный сокращенный вариант анализа (10), т.е. без п.3 и п.5 и проверять наиболее быстрые варианты разбивки на слова:

1. Нахождение полной строки фильтра в начале строки без учета регистра букв
2. Нахождение всех слов фильтра в началах слов строки в оригинальном порядке с разрешением пропусков ("удалмас" находит "УдалитьЭлементМассива")
3. Нахождение всех слов фильтра в любых местах строки с учетом порядка (удалмас находит "УдалитьЗамасленныйРадиатор")
4. Нахождение полной строки фильтра в любом месте строки без учета регистра букв без пересечения границы слов
5. Нахождение полной строки фильтра в любом месте строки без учета регистра букв с пересечением границы слов

Если п. 3 будет тяжелым, то его можно не делать.

Пропуски фрагментов внутри одного слова, чтобы например "клчство" находило "Количество", укладываются в п.3 из (11)

(11) Я сам редко заглавные буквы ввожу, т.к. лень. Поэтому думаю все же надо опираться на случай без заглавных букв как на основной. В ИР я этот алгоритм уже реализовал, кроме п.3

Да. Алгоритм Турбоконфа в этих сценариях сильно проигрывает большинству конкурентов. И я с ними сталкиваюсь регулярно.
Вот очередной тестовый пример.
Я забыл имя метода (ТаблицаЗначенийИзКоллекцииЛкс), но помню что там было слово "таблиц" и "коллекц" и в данном случае даже помню их порядок. Пишу "такол" (ТАблиц+КОЛлекц).

Процедура ТаблицаЗначенийИзКоллекцииЛкс()
КонецПроцедуры

Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
	такол	
КонецПроцедуры

Турбоконф выдает пусто

ИР выдает нужное слово

VSCode выдает нужное слово, но правда еще много мусора

EDT выдает нужное слово, но правда еще много мусора

Могу сам дописать нужный алгоритм C#, если дашь мне этот кусок исходников.

Напоминаю

Новая реализация гибкого фильтра подсказки T9
6.4.9228.27042
https://disk.yandex.ru/d/nrcRx8lTUr_ccQ

Добавлена возможность пропуска букв и фрагментов слова.

Работа фильтра похожа на VS Code, но чуть более строгая (порядок символов обязателен) В VS из-за возможности несоблюдения порядка в результаты попадает намного больше мусора.

Подсветка пока работает только для старой реализации фильтра и нужно подумать нужна ли для расширенных совпадений, т.к. сразу видно что что-то не так с вводимым словом. Возможно стоит подсвечивать только вхождения по фрагментам.

Filter() System.MissingFieldException: Поле не найдено: "TurboConf.Shared.DisplayedItem.FlexibleFilter".
в TurboConf.Service.FlexibleFilter1.Filter(List1 items, String searchString, Func`2 GetValueForFilter)
в TurboConf.Service.NewT9Form.Filter()

Ссылка скрыта

(18) tormozit, замени файл

TurboConf.Shared.dll

Вроде работает, но без подсветки фрагментов недостаточно удобно.

(17) bolsun, слишком много мусора выдает. Вот результат теста из (14), где алгоритм фильтра ИР выдает один результат:

Из-за отсутствия подсветки трудно понимать результат. Но похоже ты каждую часть фильтра ищещь в любом месте слов. Это на мой вкус редко полезно и чаще вредно. Поэтому я ищу не с начала слова только полный введенный фрагмент. А части фильтра ищу только по началам слов с пропусками.

(21) tormozit, я же написал принцип такой же как в VS Code, только не допускается перестановка букв.
Вот пример

Видно, что ищет не только по началам строк.

Одно из пожеланий было разрешить пропуски букв (опечатки).

Еще пример

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

колие
Количество - попадет

КоличествоТоваров - уже не попадет

олие

Количество - не попадет

Тогда можно и допустить перестановку на случай опечаток.

Зачем делать так же плохо как в VSCode? Мне кажется очевидным, что его алгоритм выдает массу бесполезных результатов, которые намного чаще крадут внимание чем приносят пользу.
В (11) я описал хорошо продуманный алгоритм.
Но да, я там не учел пропуски букв при быстрой печати, описанные в (0).
Поэтому предлагаю аккуратно дополнить его возможностью пропускать один символ в каждом слове в любом месте кроме его первой буквы. Например целевое слово ТаблицаЗначенийИзКоллекцииЛкс будет найдено запросами

• тблкл
• талко

Еще похоже ты заехал в очень большие значения свойства "Приоритет", т.к. мой порядок сломался.
А мои значения начинаются от 100. Вот картинка из старого Турбоконфа

В новом Турбоконфе выше этого самого приоритетного для меня слова находятся как минимум десятки других слов.

(26) tormozit, приоритет еще не поддерживается.

(25) tormozit, лучше разрешить пропуски и даже перестановки букв, но только в первом подходящем фрагменте. Как по мне работает очень хорошо. Мусора в этом случае вообще не будет.

Но попробую разрешить пропуск по одной букве (без перестановок) тоже, возможно это не приведет к мусору.

Вроде бы разрешение на пропуск одного символа во фрагменте не приводит к появлению мусора

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

Процедура ТаблицаЗначенийИзКоллекцииЛкс()
КонецПроцедуры
	такол	

(30) tormozit,

Новая версия алгоритма, мусора не наблюдаю совсем.

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

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

6.4.9228.42969
https://disk.yandex.ru/d/a0LPXDXi9s-beA

(32) bolsun, перестановка - слишком сильное отклонение. Опиши подробнее, какого вида перестановки учитываешь.

(33) tormozit, любые. Первая буква должна совпадать обязательно.
На практике ищет отлично при опечатках.

Вот пример, все значение подходящие. Мусора нет

Просто случайный набор букв набрал, но значения тоже все подходят

Дополнил описание алгоритма, что перестановка допустима только в первом найденном фрагменте. Если там она есть, то в следующих уже не допускаются пропуски.

(35) bolsun, в чем практический смысл разрешать пропуски в 2 символа? Кажется это буде крайне редко приносить пользу. Один символ пропустить - да, иногда случается. Но более чем 1 - это уже мусорные захваты.
Пример: слка - Ссылка - тут пропущено 2 подряд символа "сы"

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

В снегопате, если нужен был фильтр по подстрокам, то я нажимал между словами shift+пробел.
Мне кажется, что при текущем варианте, когда нет разделения на слова, которые точно помнишь, в подсказке будет очень много лишнего. А так ты сам контролируешь какие части должен подхватывать поиск.

(39) Евгений М., предлагаю скачать и попробовать будет мусор или нет. Если будет - привести пример.

(38) tormozit, ты можешь хотя бы оценить релевантность выдачи, зачем прямо видеть какой символ входит? Если выдает правильные значения - значит алгоритм работает хорошо.
Если выдал ерунду - можно разобрать почему.

(40) bolsun, да, конечно попробую завтра на работе. Как раз вроде бы кодинг наконец-то намечается )

(38) tormozit, и в примере видно, что "склад" идет первым.
А если бы еще были значения, которые подходят без учета опечаток, они бы встали еще выше.
Ия не проверяю перестановки в первом слове, я проверяю наличие символов.

(41) bolsun, Ну тогда еще нужны замеры скорости. Слишком сложный фильтр кроме мусора еще будет дольше реагировать. Хочу понимать, что лишние захваты не несут ощутимого замедления. Прошу добавить также аналогичный замер в старый алгоритм.

(41) bolsun, я не очень понял какой в итоге алгоритм поиска и есть ли разделения на слова? По заглавным буквам? Или нет вообще? Просто анализируются все буквы, их пропуски и перестановки?

(45) Евгений М., есть разделения на слова.

(44) tormozit, ты запускал версию? Там выдается всплывашка с временем фильтрации.

Алгоритм даже быстрее старого.

(43) bolsun, ты писал " не проверяю перестановки в первом слове, я проверяю наличие символов". Этого я и боялся. Это примитивный подход, который дает много мусора. Распиши формулу вычисления рейтинга/приоритета/порядка для каждого слова, т.е. по какому принципу ты их сортируешь.

(48) tormozit, напиши пример мусора, пока мы только теорию обсуждаем.

Что искал и ожидал, что выдало неправильно.

Главная характеристика такого "фильтра" не в отбрасывании, а в упорядочивании результатов. А оно должно опираться на сложную формулу вычисления рейтинга. Где эта формула? Я свою описывал в (10).
С более примитивным фильтром и эта формула будет более примитивной и понизит качество сортировки.

Я просил сделать одно аккуратное изменение в существующем алгоритме - учесть пропуски слов. Автор заявки просил учесть пропуск одного символа. Других острых потребностей вроде бы не было обозначено.

(51) tormozit,

Я просил сделать одно аккуратное изменение в существующем алгоритме. Автор заявки просил учесть пропуск одного символа. Других потребностей вроде бы не было обозначено.

ну я не только заявки пользователей выполняю и свои идеи реализую.

В общем подожду реальных отзывов по работе алгоритма этой версии.
Если увижу проблемы с нечетким поиском по первому фрагменту - уберу или буду улучшать.

(46) bolsun,

есть разделения на слова.

По какому принципу разделяются?

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

Почему для фильтра "РаПоФо" на первом месте оказалось "РасширениеОформляемыхПолей"?

Почему для фильтра "обмеспр" и "обспр" на первом месте оказалось "ОбъектМетаданныхПризнакУчетаСубконтоПланаСчетов"?

Почему для фильтра "сссы" на первых 3-х местах слова "Ссылка..."?

(57) tormozit, потому, что сломана сортировка в этой версии.

Исправил сортировку и подобные случаи.

(60) не та версия, выложу другую.

6.4.9229.3808
https://disk.yandex.ru/d/XRPUNWQtrbwBUw

Message: Поле не найдено: "TurboConf.Shared.DisplayedItem.Priority".
StackTrace: в TurboConf.Service.Actions.T9.d0\]fpD{8#K"Dj\[puO~\]=8Fc".MoveNext() в System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine) в TurboConf.Service.Actions.T9.SmartCompletion(IntPtr fg, MainForm mainForm, Point oldPos, NotifyIcon notifyIcon, Keys key, ScreenForm statusForm, Boolean check, String curText, Boolean allowField, Int32 moduleLength, Boolean autoInvoke) в TurboConf.Service.MainForm.9jraBv"pUx4t\&~K=\,-,gd}!.n75[3Zd8:5eU&f2e$jGOq>?J#.MoveNext()
--- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
ProductVersion: 6.4.9229.3809

(62) bolsun, из какого архива в итоге ставить? В последнем, судя по сообщению Сергея, ошибка.

(64) Евгений М., из этого, обновил архив.
6.4.9229.3808
https://disk.yandex.ru/d/XRPUNWQtrbwBUw

6.4.9229.28300

Улучшен алгоритм фильтрации
Добавлена подсветка вхождений (кроме нечеткого поиска в первом фрагменте)
Совпадения с пропусками букв или перестановками теперь имеют приоритет 0.
Убрано всплывающее уведомление с замером.

https://disk.yandex.ru/d/XRPUNWQtrbwBUw

Вижу мусор и к тому же на высоких позициях

(58) tormozit, в этом тесте теперь хороший результат.

(57) tormozit, в этом тесте теперь хороший результат.

(56) tormozit, в этом тесте теперь хороший результат.

Еще мусор на первой позиции

Тут тоже странный результат
Метаданные.СвойстваОбъектов.подре

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

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

Также можно установить приоритет -1 для таких слов. Т.к. если ты передаешь 0, то они могут оказываться выше.

6.4.9229.28300

https://disk.yandex.ru/d/XRPUNWQtrbwBUw

Улучшен алгоритм проверки опечаток, связанных с перестановками буква.
Уменьшено количество мусора из за нечеткого фильтра.
Улучшена сортировка, слова с перестановками букв теперь выводятся с приоритетом -1.

(71) tormozit, в этом тесте теперь хороший результат.

(67) tormozit, в этом тесте теперь хороший результат.

(72) tormozit, тут стало лучше но все равно видно одно странное слово

фильтр "ме" не находит слово "Камень"
СтандартноеОформление.ме
СтатусСообщения.м

(79) tormozit, так и должно быть, обязательное условие первая буква должна совпадать с началом фрагмента.

(78) tormozit, фильтр сработал правильно, из букв "подре" можно собрать "предо"

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

(80) bolsun, кто просил делать такое условие обязательным? Вроде бы никто. Наоборот - до этого всегда отмечалось, что такие слова должна удовлетворять фильтру. И так работает старый фильтр Турбоконфа и все аналоги.

(82) tormozit, это не так.

(81) bolsun, Я считаю такое поведение вредным, особенно без подсветки. Изначально речь шла только о погрешностях быстрого ввода. Опиши, как тебе кажется при быстром вводе из "подре" можно ввести "предо". Посчитаем суммарное расстояние перестановок и пропусков:

1. "о" переместилось на 4 (!!!) позиции - комментарии тут я думаю излишни
2. "д" переместилось на 1 позицию - ОК
3. "р" переместилось на 2 позиции - не бывает такого от быстрого ввода
4. "е" переместилось на 2 позиции - не бывает такого от быстрого ввода
   Итого общее отклонение 9 для фрагмента из 4 символов. Считаю что это явно мусорный результат.

(84) tormozit, что ты искал вводя "предо", почему нет других значений?

(85) bolsun, я вводил не "предо", а "подре" ("ПОДчинный РЕгистр"). Пользователю достаточно понять, что подходящих результатов нет. Жестоко заставлять его разгадывать ребусы в виде кучи бесполезных результатов, которые показываются по непонятной причине.

(86) tormozit, что ты искал вводя "подре", почему нет других значений?

(87) tormozit, но его нет в подсказке. Это слово есть без фильтра?

(88) bolsun, без фильтра его нет.

(80) bolsun, смотри на старый алгоритм Турбоконфа - у него с этим все нормально. И главное - никто просил это менять.

Все же я призываю вернуться на путь минимальных рисков - добавить то, чего остро не хватало, и минимизировать изменения, которых не просили, особенно если они отбрасывают то, что ранее считалось полезным.

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

(92) tormozit, нет, я промотал список конечно, никаких "камней" там нет.

(93) bolsun, проверил более тщательно. Да, VS Code не ищет полный фрагмент внутри слова, т.е. для "ме" не выдает "Камень". Тут я ошибся.
Но так делают

• старый Турбоконф
• EDT
• ИР

(91) tormozit, вообще я не понимаю категоричность оценки алгоритма. Это прототип. Я написал новый алгоритм, для возможности реализации пропусков букв и т.д. и выложил, чтобы улучшить его.
То что пропало вхождение подстрок - это я узнал только что, т.к. не учел это при написании.

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

(95) bolsun, по (80) я сделал вывод, что удаление проверки вхождений внутри слов было сделано умышленно и потому очень взволновался и попытался ярче донести глубину потери удобства.

(96) bolsun, призываю его отключить хотя бы на расстояниях более 1

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

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

(100) tormozit, насколько целесообразно выводить Камень при вводе "мень"?
Кто так будет делать и в чем польза?

(101) bolsun, основные сценарии такие:

• однокоренные слова с различными приставками - хочу искать по корню, например отГРУЗить-разГРУЗить-ПоГРУЗить, уБЫТие-отБЫТие
• составные слова (несколько корней) - хочу искать по второму корню/подслову, например автоподКЛЮЧЕНие-автоОТКЛЮЧЕНие, полуАВТОМАТ

(102) tormozit, ясно, никогда так не пользовался. Всегда первая буква у меня соответствует началу фрагмента.

6.4.9230.5194

Отключен нечеткий поиск (перестановки букв).
Добавлена проверка совпадений по вхождению искомой строки (подсветки в этом случае нет, как и в старом алгоритме).

https://disk.yandex.ru/d/XRPUNWQtrbwBUw

(104) bolsun, теперь во всех тестах хороший результат. Еще бы подсветку для вхождения внутри слова добавить и будет отлично.

Сломался фильтр в списке методов

6.4.9230.28584

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

https://disk.yandex.ru/d/XRPUNWQtrbwBUw

(107) bolsun, Больше не обнаружил проблем. Отлично работает фильтр.

Нашел небольшое снижение удобства нового алгоритма. Ввожу

Тип("наскомда
Тип("нкд

И вижу элемент "НастройкиКомпоновкиДанных" далеко не на первом месте.
И нет способа короткой строкой поднять ее повыше.
В моем алгоритме в ИР такая же проблема.

Нужен бонус к позиции за отсутствие пропусков начал слов (заглавных букв) и пропусков букв в начале слова (то что просил автор темы).

(109) Устранил это неудобство в своем алгоритме в ИР https://www.hostedredmine.com/issues/1004074 и очень жду исправления в Турбоконфе.

(109) tormozit, еще яркий пример подобного заметного снижения удобства.
Хочу ввести "ОткрытьФОрму". Пишу "отфо" или "откфо" и не вижу нужного слова даже на первой странице списка.

6.4.9235.32631

За каждый пропуск фрагмента начисляется 1 понижающий бал
За каждый пропуск буквы внутри фрагмента начисляется 1 понижающий бал.

https://disk.yandex.ru/d/XRPUNWQtrbwBUw

Warning: System.MissingFieldException: Поле не найдено: "TurboConf.Shared.T9Item.Priority".
в TurboConf.Service.MainForm.‍‬‎‎‮‬‭‪‪‬‮‭‪‭​‍‫‮‫‫‎‪‭‎‌‌‌‬‮()
в TurboConf.Service.MainForm.ReloadScripts(Boolean showReport)
в TurboConf.Service.MainForm.‫‌‎‪‌‏​‌‬‫‬‬‌‪‪‎​‌‍‬‌‎​‮‎‮‏‪‮()
в TurboConf.Service.MainForm.‍‫‎‫‬‭‪‭‬‭​‬‪‫‭‍‏‍‭‏‭‫‍‏‎‍‮(Object , EventArgs )

Еще сразу отмечу, что слишком большое множество значений атрибута "ПремияФильтра" - тоже плохо.
Вот как у меня выглядит сортировки списка
ТаблицаСлов.Сортировать("ПремияФильтра Убыв, Рейтинг Убыв")
Премия фильтра является главным полем сортировки. А внутри нее слова уже упорядочиваются по рейтингу соответствия контексту.
Поэтому у меня сделано всего 4 значения премии фильтра, чтобы не "глушить" роль затратного вычисляемого рейтинга соответствия контексту.

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

(113) tormozit,
TurboConf.Shared.dll

(114) tormozit, у меня нескольких атрибутов премии фильтра, приоритет фильтра - один, за ним сразу идет сортировка по приоритету слова.

(116) bolsun, у меня так же. Твое "по приоритету слова" = мой "Рейтинг". Вот роль второго критерия сортировки ("приоритета"="рейтинга") в описанном тобой в (112) алгоритме будет сильно падать из-за избыточно мелкой нарезки первого критерия сортировки (премии фильтра). Поэтому предлагаю не начислять бал за каждый пропуск, а делать более консервативно - начислять балл за отсутствие пропусков.

(117) tormozit, попробуй сначала, как работает. Будут конкретные примеры неправильной сортировки - будем решать.
Пока мне нравится работа фильтра, чем больше ошибок при наборе - тем слово ниже.

(118) bolsun, хорошо. Буду ловить примеры для эффекта (114)

Вот пример
ВидСравненияКомпоновкиДанных.Больше = срав
Тут я даю большой рейтинг за контекст слову ВидСравненияКомпоновкиДанных .
Но в списке оно оказывается дальше чем варианты с пропусками букв.

В моей реализации в ИР выглядит так

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

Моя формула подробно (варианты):
ПремияФильтра = 4; // полное совпадение в начале первого слова
ПремияФильтра = 3; // полное совпадение в начале любого слова
ПремияФильтра = 2; // полное совпадение внутри любого слова
ПремияФильтра = 1; // полное совпадение с пересечением слов
ПремияФильтра = 3; // совпадение по началам слов без пропусков слов
ПремияФильтра = 2; // совпадение по началам слов, начиная с первого, с пропусками слов
ПремияФильтра = 1; // совпадение по началам слов, начиная с непервого, с пропусками слов

(120) tormozit, у меня полное совпадение по началу фрагментов, тоже имеет высокий приоритет, но в коде оставалась часть сортировки от предыдущего алгоритма. Исправил.

6.4.9235.41578

https://disk.yandex.ru/d/XRPUNWQtrbwBUw

Проблема (120) ушла. Но поломался один старый тест

Процедура ТаблицаЗначенийИзКоллекцииЛкс()
	//такол
КонецПроцедуры

Тут слово ТаблицаЗначенийИзКоллекцииЛкс должно быть на первом месте.

Мой алгоритм выдает такое

Еще тут сломалось
// принас

// обсер

При расчете премии фильтра спец. символы в начале элемента возможно нужно пропускать, если их нет в фильтре, считая что элемент начинается с первого обычного символа.
Тут я дал большой приоритет элементу "#Если", но при вводе "Если" он все равно не на первом месте, т.е. нет возможности управлять относительным порядком таких элементов через приоритет.

Ну и хорошо бы между методами вообще не добавлять шаблоны "Если...", т.к. они там не имеют смысла.

(124) tormozit, На всякий случай сообщаю, что тогда вернулся на старый алгоритм, т.к. недоработки нового алгоритма пока перевешивают его преимущества.

(123) и (124) исправлено

6.4.9244.31039

https://disk.yandex.ru/d/sDvHyJ1geq6ncQ

(127) bolsun, другая проблема возникла. В модуле упр. формы ввожу "э" и вижу пустой список. Откатился на старый алгоритм и она показывает в том же состоянии нормальный список

(128) tormozit, не ту версию выложил (с зашитым тестовым набором данных).

6.4.9244.41299

https://disk.yandex.ru/d/XRPUNWQtrbwBUw

//сссы - не выдал слово БизнесПроцессСсылка (полное совпадение с пересечением слов)

// обсер - элемент, который не начинается с первой буквы фильтра, встал на первое место, хотя есть элементы подходящие по первой букве
ПремияФильтра = 2; // совпадение по началам слов, начиная с первого, с пропусками слов
ПремияФильтра = 1; // совпадение по началам слов, начиная с непервого, с пропусками слов

// СтатусСообщения.м - не раскрасились вхождения фильтра

Тип("комп - на первое место попал элемент, который не начинается с полного фильтра, хотя ниже есть элементы, которые начинаются с полного фильтра
ПремияФильтра = 4; // полное совпадение в начале первого слова
ПремияФильтра = 3; // совпадение по началам слов без пропусков слов

(132) tormozit, вхождения из одной буквы не раскрашиваются намеренно, это бессмысленно.

(131) tormozit, здесь сработало понижение приоритета из-за нескольких пропусков фрагментов

(133) tormozit, повышу приоритет за полное начало слова.

(135) bolsun, предлагаю все же не считать число пропусков, а учитывать только их наличие (117).

Ожидал, что модуль с полным совпадением наименования (УправлениеПечатьюПереопределяемый) будет стоять в первой строчке списка

(133) tormozit, исправил приоритет по началу слов

6.4.9246.25499
https://disk.yandex.ru/d/XRPUNWQtrbwBUw

(138) Евгений М., это конечно не относится к новому фильтру подсказки T9, который обсуждается в текущем топике. Т.к. в Навигаторе другой алгоритм работает.
Исправлю.

(138) Евгений М., исправлено

6.4.9246.26694

https://disk.yandex.ru/d/XRPUNWQtrbwBUw

(139) bolsun, проверил. Исправлено.

(140) bolsun, а почему бы не сделать один алгоритм фильтрации и в навигаторе и в подсказках? Смысл вроде бы один и тот же

(143) Евгений М., потому что при вводе в коде пробел является внешним разделителем. А в поле ввода он точно разделяет фрагменты фильтра. Это оказывает большое влияние на трактовку фильтра - как минимум есть строгое деление на слова, поэтому можно их искать в любом порядке.
Если же пробелы в фильтре отсутствуют, то тут я в общем то согласен - можно было бы применять единый алгоритм.
Но правда есть еще небольшая разница - в списке автодополнения есть второй критерий сортировки - за соответствие контексту. Поэтому там вредна излишняя детальность первого критерия сортировки (премии за соответствие фильтру) (117). А вот в бесконтекстном списке можно было бы использовать и более детальный расчет такой премии.

Не отбирает слово

ТаблицаТиповИзЗначения=1;
табизз

Ожидал такое

(145) tormozit, исправил

6.4.9248.29944

https://disk.yandex.ru/d/XRPUNWQtrbwBUw

(146) bolsun, Проверил. Исправлено.

Ввожу "Если" и не вижу на первой странице своего элемента "#Если Тогда" с Приоритет=100. Хотя почему то вижу "#ИначеЕсли". А мой элемент "#Если Тогда" оказывается в самом низу списка.

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

Еще похожая проблема. В списке есть слово "<СписокПараметров>".
Ввожу "сппар". Нужое слово не отбирается.

моим алгоритмом отбирается

Фильтр "рейс" не видит слово "РезультатРейсы".

QmHU4KTVKg.mp4

моим алгоритмом отбирается

Ввожу "ОбрОбъект".
Элемент "ОбработатьЭлементыОбъекта" оказывается ниже, чем "ИмяМетодаОбработкиОбъекта".
Не соответствует премиям фильтра
ПремияФильтра = 2; // совпадение по началам слов, начиная с первого, с пропусками слов
ПремияФильтра = 1; // совпадение по началам слов, начиная с непервого, с пропусками слов

(150) (151) (148) исправлено

6.4.9257.29959
https://disk.yandex.ru/d/XRPUNWQtrbwBUw

(149) tormozit, используй в этом случае Фильтр = "СписокПараметров".

(150) tormozit, Проверил. Исправлено.

(148) tormozit, Проверил. Не исправлено.

(153) bolsun, Проверил. Фильтр "Список" позволяет отобрать небольшой набор элементов, содержащий нужный элемент.

Но я уже наделал много таких элементов с треугольными скобками. К тому же есть еще похожая нерешенная проблема с символом "#" (148) и еще в тексте запроса встречаются параметры с символа "&" и во встроенном языке метки с символа "~". Так что напрашивается какое то универсальное решение.
Напоминаю, как сортирует мой алгоритм - он пропускает первый небуквенный символ, снижая за это один балл премии фильтра, и далее прогоняет остаток строки по обычному алгоритму.

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

(151) tormozit, Проверил. Исправлено.

(156) tormozit, причем в твоем алгоритме заполнения списка тоже используются треугольные скобки и потому там такая же проблема. Например в модуле скрипта хочу добавить обработчик и опять нужные элементы слишком низко

6.4.9264.31393

• Если первый символ - специальный символ, а вводимая строка не начинается со спецсимвола, то он отбрасывается со штрафом 1 балл.
• Исправлена сортировка в списке методов.
• Исправлена подсветка вхождений в некоторых случаях.

https://disk.yandex.ru/d/XRPUNWQtrbwBUw

Тема стала неуправляемая.
Если возникнут какие-то еще случаи неправильной сортировки, прошу создавать отдельный тикет по каждому такому случаю.
bolsun изменил статус на Закрыто

(159) bolsun, проверил изменение премии за первый спецсимвол. Работает.

bolsun изменил статус на Закрыто