Total Commander

Avada писал(а):При переименовании в панели, если курсор находится перед первым или вторым символом имени файла/папки, клавиша-стрелка вправо не работает в этом поле ни сама по себе, ни с модификатором. Перемещения курсора вправо нет вообще никакого: ни посимвольно, ни по словам, ни с выделением. (На оффоруме вроде бы речь идёт только о проблемах при выделении стрелками с клавишей Shift, а не о перемещении.) Легко воспроизводится и на чистом TC. Баг есть только в 32-битной версии беты, в предыдущих бетах всё нормально. Прошу проверить.

Подтверждаю.

Но я обратил внимание вот на что. Если в файл wincmd.ini, в раздел [Configuration], добавить ключ CtrlArrow=0, то баг пропадает.
Только я не уверен, что это правильное решение.

BeTeP
Да, я пришёл к тому же результату. Значит, имеем обоснованный баг-репорт.

sa
Тем не менее, это исключение из общих правил, и как таковое должно быть документировано. Желательно, самим Гислером, а не только в русскоязычных справочниках.

BeTeP, Avada
Странно, но у меня на чистом ТС, вне зависимости от наличия самого ключа CtrlArrow, ровно как и его значения - проблемы нет.
Правильно ли я понимаю, что это касается переименования файла (Shift+F6)? Выделяется полное имя, чтобы попасть в начало имени - нажимаю кнопку Home (да или просто стрелками влево). С начала первого символа или со второго - вправо могу нажимать и курсор ведет себя как обычно. Также и с модификаторами, соответственно.

Monarch-LFV
Да, всё понято правильно. Позицию курсора в поле переименования можно, конечно, точно установить и мышкой. В данном же случае для снятия выделения и установки курсора в самом начале имени достаточно однократного нажатия стрелки влево (классическое поведение при умолчальном SkipCharOnCursor=0). ИМХО, чем именно позиционируется курсор, для воспроизведения бага никакого значения не имеет.
Я предполагаю, что это результат следующего исправления, сделанного как раз в третьей бете:

15.05.23 Fixed: Cursor movement in rename box (Shift+F6) would jump by 2 characters instead of one when using a dual byte locale like Korean (32/64)
15.05.23 Исправлено: В поле переименования (SHIFT+F6) курсор перемещался на два символа вместо одного при использовании в системной локали языков с двухбайтовой кодировкой, например, корейского. (32/64)

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