Total Commander

Avada писал(а):Но вот почему папки тут должны обрабатываться иначе?

А я не писал, что иначе. Точки не должно быть с любым объектом.

Flasher
Почему не должно? Смысл введения двух разных полей Гислер видел в своё время в основном в том, чтобы неосторожной правкой в единственном поле не убить расширения файлов. (Поэтому [A] — факультативный вариант, а не основной.) Первое поле не зависит от второго — и наоборот. И раз уж мы что-то вводим в поле для расширения, результатом должно быть новое или изменённое расширение, а не довесок к имени без точки. Если мы что-то добавляем туда при наличии расширения (или по крайней мере чего-то после последней точки), никаких дополнительных точек быть не должно. (Их, насколько вижу, и нет.) Но если пока что никакого расширения нет, как мы можем его получить иначе, чем с автоматическим созданием начальной точки? В чём тут баг?

Avada
Не должно, потому что дописка идёт после выражения, а не в начале. Если выражение есть, и оно возвращает пустое значение, то никакой вставки точки быть не должно, т. к. подразумевается, что выбраны могут быть как объекты с расширением, так и без. [А], напомню, появилось только в TC 8, а проблема имела место быть, но добавлялось выражение не по обсуждаемой причине.

Flasher
При изначальном отсутствиии расширения и вводе в пустом поле для расширения или перед [E], например, 333, должно автоматом создаваться это расширение с точкой, а при добавлении после [E] 333 этот ввод, как понимаю, должен продолжать имя? А с какой стати?
По нескольким объектам. Выбираем несколько файлов/папок, как с расширением, так и без. Вводим это самое [E]333. Объекты с расширением получают довесок к нему — 333 без всяких лишних точек. Объекты без расширения получают расширение 333 с точкой. Всё логично. В чём проблема?
(Причины появления [А] обсуждать не будем, мы сейчас про другое.)

Avada писал(а):Объекты без расширения получают расширение 333 с точкой. Всё логично. В чём проблема?

Что же тут логичного? В этом и проблема. Нужно сделать конкретную дописку для всех объектов безотносительно наличия раширений, а он мне у части имён точки втельняшивает. Зачем, спрашивается?

Flasher писал(а):а он мне у части имён точки втельняшивает. Зачем, спрашивается?

Может, он руководствуется справкой?

Инструмент переименования создаст строку переименования в виде: Поля в маске имени + "." (точка) + Поля в маске расширения.

Flasher
В общем виде суть проблемы по-прежнему не понимаю. Дай конкретные примеры требуемой дописки и исходных имён нескольких объектов (где точки нужны и где нет), я проверю.

sa
Кстати, да, справке это вполне соответствует. Ожидается ли кем-то именно такое поведение — вопрос другой, но считать его багом пока не вижу оснований.

sa писал(а):Может, он руководствуется справкой?

А дальше написано:

Причина, по которой эти два поля разделены, состоит в том, чтобы предотвратить случайное удаление расширений файла

Т.е. разделение создано для имён с расширениями. А мы обсуждаем случай их отсутствия.

Avada
Так ты текущее поведение описал. Ты пишешь "А с какой стати?" А я отвечаю, с той, что точка возникает у части выбранных файлов без расширений после [E], а с расширением — нет, игнорируя принцип дописки к полному имени. Т.е. [N]?[E] — схема полного имени. В случае [N]?[E]_add мы должны увидеть Name.ext_add у имён с расширением и Name_add у имён без расширения. Т. е. для [E] должна учитываться ситуация отсутствия расширения. Я всегда это во всех скриптах учитываю, иначе имеем смещение логики.
А получается, нам надо тратить время на очищение второго поля, заменять в маске другим выражением, чтобы добиться, казалось бы, очевидного результата с простой допиской.

У обычного переименования, кстати, тоже есть косяк с маской.
Если мы задаём *.*_add, то всё логично, спереди в любом случае подставляется точка, т.к. она прописана. Но если мы пропишем *_add, то мало того, что _add нигде не пропишется, так ещё и расширения поудаляются.

Flasher
Да, описывалось текущее поведение, а какое же ещё?
Разделение полей, будучи когда-то введено, с тех пор работает безотносительно к тому, есть по факту расширение или нет. Может быть, с точки зрения логики скриптов тут есть какая-то несообразность, но со стороны самого инструмента я её не вижу. Если у объекта нет расширения и значением поля для расширения что-то задаётся, то объект получает новое расширение с точкой, а не дописку к полному имени. Результат соответствует месту ввода. Для меня эта логика выглядит естественной. Для тебя, насколько понимаю, нет. Очевидно, надо либо убеждать Гислера, что он где-то неправ (хотя я не понимаю, где), либо учитывать нынешнее поведение как данность.

Ни фига вы тут нагородили. Крутые слова всякие. А ведь простому юзеру лишь надо, чтоб, если он хочет получить "название"+"текст" в конце, или в начале, или в середине, то ему нафик не упирались все эти "точки". Все эти рассуждения про "справки" и "что так было задуманно"
Кому это надо?
ИМХО это есть баг, как тут и было подтверждено. И если кто с инглишем дружит - надо репортить САМОМУ.))))

Avada
Про текущее поведение ответ был на слова "суть проблемы по-прежнему не понимаю. Дай конкретные примеры ...".
Логика скриптов ничем от любой другой программы переименования не отличается. Она одна. Насчёт "что-то задаётся" в поле расширения я выше пояснял, что ключевой аспект здесь — наличие [E] спереди. Если это не так, то это уже другая история, и в ином случае данный довод окажется справедлив. А про убеждение я уже закинул удочку MVV, посмотрим, чем обернётся.

JKT
Если простой юзер хочет получить "название+текст", то, как уже написали ранее, ему нужно пользоваться специально для этого добавленным шаблоном [A], а не полями, рассчитанными на работу отдельно с именем, отдельно с расширением. Если молотком плохо получается вкручивать шурупы, то это проблема не молотка, а его нецелевого применения.

Я бы вот это назвал забиванием шурупов:

Flasher писал(а):А получается, нам надо тратить время на очищение второго поля, заменять в маске другим выражением, чтобы добиться, казалось бы, очевидного результата с простой допиской.

Как выше писал, с Shift+F6 дела ещё хуже.

Flasher
Shift+F6 — это пакетное переименование? Может быть, это кому-то и очень нужно и полезно, но я вот, например, этим диалогом практически не пользуюсь, ибо принципиальных преимуществ перед ИГП не вижу ни одного, а недостатков — массу. Это не означает, разумеется, что там не следует исправлять явные баги при их наличии и подтверждении. Но полагаю, что в любом случае обсуждение указанного диалога — не для текущей темы, где и без того фактически идёт несколько обсуждений параллельно.

Avada
Преимущества были бы, если бы не косяки. Сам диалог маленький, глаза не разбегаются по куче компонентов. Зрительный фокус на маске. Подтверждение по Enter без необходимости закрывать диалог.
А насчёт темы связь косвенная — быстро решить задачу дописки, но и тут, как видишь, не судьба.