FarManager
FarManager copied to clipboard
FarGroup
редактор: не запоминается позиция курсора по End и Del (при определённых условиях)
Far Manager version
3.0.6111.0
OS version
win 10
Other software
No response
Steps to reproduce
В редакторе в двух строках вводим: 12 123 Во второй строке нажимаем End, поднимаем курсор вверх Up, нажимаем End, опускаем курсор вниз Down.
Expected behavior
Позиция курсора должна быть в 3-м столбце (на "3").
Actual behavior
Курсор оказывается на 4-й позиции, в конце строки.
PS: В своё время я рапортовал, что при движении курсора вверх-вниз по строкам разной длины или с табуляциями внутри курсор мог самопроизвольно менять позицию в строке (с учётом, что он до этого сдвигался из-за табуляций или из-за коротких строк). Я не следил за изменениями фара, но, возможно, кто-то попытался исправить этот баг. Однако, в результате появился новый: с помощью End я меняю позицию курсора, но она не запоминается.
с помощью End я меняю позицию курсора, но она не запоминается.
Я бы не сказал что это баг, скорее это такое поведение по умолчанию. Да, вам оно может не нравится, но в этом редакторе - оно такое. В других редакторах может быть по-другому, стандарта нет:
VS Code - поведение как вы просите Notepad, Chrome - как в Фаре
Если уж совсем мешает, то можно намакросить workaround хотя бы для End. Костыль, да.
скорее это такое поведение по умолчанию
Это баг не в том смысле, что из-за этого всё крашится, а в том, что (1) изменено поведение на (2) не очень логичное. Насчёт изменения: я иногда использую простенькие макросы (Ctrl+.) для массивного изменения текста. И недавно столкнулся, что в новой версии фара что-то работает не так, как было, ломая мой результат. Поразбиравшись, понял, что это из-за этой фигни: если в предыдущей строке было что-то длиннее следующей, я спускал курсор, нажимал End, чтобы поставить курсор на нужную позицию (равную концу строки), спускал дальше... а оно не на той позиции, где я поставил.
можно намакросить workaround хотя бы для End. Костыль, да.
Например? Как этот костыль может выглядеть? К тому же, если мне не изменяет память, макрос не работает в макросе, так что мои ручные макросы продолжат глючить?
Да, и если поведение изменилось, то скажите в какой версии оно было другим, а желательно узнать ближе к какому билду - "сломалось".
скажите в какой версии оно было другим
Far30b5400.x64.20190523.msi в этой версии работало иначе. Более новые версии вплоть до нынешней я не пробовал.
Там где вы спускаетесь и нажимаете End, нажимайте Home End
Ах-ха-ха, начал с этим экспериментировать и оказалось, что баг обширнее, вообще полная ерунда и отсутствие логики с запоминанием позиций. Пусть есть такие три строки: 12345 67 890 Ставим курсор на 2. Спускаем вниз Down, ставим курсор в конец End. Спускаем курсор Down... Учитывая то, что описано в начале, ожидаем курсор в конце строки (после 0)? Как бы не так, курсор на этот раз оказывается на 0. Пытаясь понять, что же здесь происходит, я бы на данный момент описал это как "End запоминает столбец, но только ЕСЛИ новая позиция оказывается больше предыдущей".
Учитывая то, что описано в начале, ожидаем курсор в конце строки (после 0)? Как бы не так, курсор на этот раз оказывается на 0.
Не понял, где и что "описано а начале", но для меня поведение выглядит логичным. Фар помнит последнюю колонку.
Вот ваш пример, слегка измененный (добавил пустую строку): 12345
67 890
Ставим курсор на 2 (Фар запоминает колонку 2):
12345
67 890
Спускаемcя вниз Down, нет колоки 2, поэтому курсор прыгает в колонку 1 (Фар все еще помнит колонку 2):
12345
67
890
Спускаемcя еще раз вниз Down, есть колонка 2, Фар ставит курсор в колонку 2 (Фар все еще помнит колонку 2): 12345
67
890
Нажимаем End, курсор переходит в колонку 3 (Фар запоминает колонку 3): 12345
67
890
Спускаемcя еще раз вниз Down, есть колонка 3, Фар ставит курсор в колонку 3 (Фар все еще помнит колонку 3): 12345
67
890
Нажимаем End, курсор переходит в колонку 4 (Фар запоминает колонку 4): 12345
67
890
Поднимаемся вверх Up, нет колоки 4, поэтому курсор прыгает в колонку 3 (Фар все еще помнит колонку 4): 12345
67
890
А теперь самое интересное, вы нажимаете End, так вот для текущего Фара позиция не изменилась, он все еще помнит колонку 4 (а не якобы новую колонку 3), и если после этого поднятьcя два раза вверх Up x 2, то курсор будет стоят в колонке 4, а не 3:
12345
67 890
Как-то так.
То, что расписано в предыдущем посте, действительно логично и ожидаемо. Проблема в том, что пример, с которого я начал эту тему, из этой логики выбивается: в первой строке (в самом первом примере из двух строк) я нажимаю End и фар по идее должен запомнить колонку 3, но когда я спускаю курсор вниз, курсор оказывается в колонке 4. В этом и заключается баг.
В моем случае: 12 123
Нажимаю End, курсор в колонке 3:
12
123
Нажимаю вниз Down и курсор остается в колонке 3:
12
123
Far 3.0.6117.0 x86 / Windows 11 (10.0.22624.1391) / conhost or WT
А теперь попробуй сделать так, как описано в начале: нажми End во второй строке, поднимись вверх, и далее по своим шагам - End чтобы запомнить колонку 3 и Down чтобы перейти к колонке 3 в следующей строке.
По-моему, этот вариант мы уже обсудили, да, вам не нравится текущее поведение, но оно такое. Hо фраза "вообще полная ерунда и отсутствие логики с запоминанием позиций" - это ~несколько~ сильно преувеличенное высказывание.
Наберите ваш пример с двумя строками 12 123 прямо здесь в браузере в поле комментария и проверьте, как работает End стрелки? У меня так же как в Фаре.
То, что в каком-то другом редакторе (а браузер и редактором-то назвать можно условно) работает именно так (запоминает столбец после End если он больше предыдущего и НЕ запоминает ЕСЛИ он меньше), не делает эту работу более логичной. А для макросов костыли теперь нужно делать, поскольку ранее ведь было иначе,
Посмотрел что было ранее (точнее в 5400). Там любое нажатие приводило к перезапоминанию колонки, даже если нажатие не имело никакого отношения к редактору (как например F1). Видимо было принято решение это исправить и отталкиваться от позиции курсора, если позиция не менялась, значит не перезапоминаем.
Продолжая тему. yegor-mialyk выше указал, что ради исправления "лишних" запоминаний (кто сказал, что они лишние?) убрали сохранения позиций, если они не изменились (и в чём тут, собственно, исправление?). Я привёл один сценарий, в котором эта оптимизация проявилась в нелогичном поведении. Выше же было предложено использовать костыли чтобы это обойти. Тем не менее, мои макросы даже с костылями в виде лишних изменений позиции продолжали глючить. Я пригляделся - оказывается, сценариев, где проведённая оптимизация приводит к глюкам, оказалось больше. Вот ещё один сценарий.
Пусть у нас есть 4 следующие строки (вторая строка пустая):
11
33 44
В первой строке встаньте в начало строки (Home) и добавьте табуляцию (Tab). Спуститесь вниз и удалите пустую строку (Down Del). Спуститесь ещё раз вниз (Down). Курсор будет в начале строки. Логично? Логично. А теперь спуститесь ещё раз вниз (Down)... Ожидаемое поведение: курсор в начале строки. Реальное поведение: курсор улетает в конец строки (ну или на 9 позицию, если строка достаточно длинная).
Я не автор кода, поэтому только сделал "предположение". Ваш пример вписывается в текущую логику, нажатие Del не поменяло положение курсора, поэтому его никто не запомнил.
А на самом деле это изменение :https://github.com/FarGroup/FarManager/blob/66a12a3b2282554396e7bfcecf4c94da9cd12e1b/far/editor.cpp#L273 было сделано в рамках другого репорта #45, что говорит о том что проблем было больше чем одна, и если вернуть вами желаемое поведение, то сломается где-то еще.
Вы можете удалить эту строчку 273 и попробовать, скорее всего вы получите желаемое поведение, а вот где и что сломается, кто его знает.
Вы можете удалить эту строчку
Я не могу удалить предложенную строку, поскольку далёк от разработки фара. Я выявил и сообщил о проблемном поведении курсора, а чем это вызвано или как это починить я ничего не могу сказать.
если вернуть вами желаемое поведение, то сломается где-то еще.
В том обсуждении, на которое вы дали ссылку, говорится о другом режиме (о курсоре за границей строки). Сломается ли что-то (опять) в том режиме при починке данной проблемы, зависит от того, как её чинить. Как я понимаю, когда чинили ту проблему, просто не просчитали воздействия фикса на другие режимы.
Если открыть гигабайтный файл, это значит что нужно хранить позицию курсора для каждой строки отдельно? IMHO это совершенно лишнее. Курсор должен перемещаться либо по возможным символам в строке (чтобы не создавать лишние), либо по тому столбцу, из которого начали движение, с возможностью писать символы прямо здесь, что крайне удобно и логично.
хранить позицию курсора для каждой строки отдельно?
Зачем?! Речь о запоминании одной текущей позиции курсора после его установки/сдвига пользователем и её использования при перемещении курсора по строкам (с учётом, что некоторые строки могут быть короче, а в некоторых курсор может попадать в середину табуляции).
Так сейчас так и работает. Либо при перемещении по вертикали оно идет ровно по тому же столбцу (если выключен Cursor beyond end of line), либо, если определенная строка короче, на конец этой строки, а на следующей - назад.
Баг есть при передвижении по строкам с табом. А если табов нет, то все работает совершенно корректно. Думаю этот issue нужно закрыть и переоткрыть как новый - что при навигации курсором есть проблемы при перемещении по табуляции, а не по строкам с разной длиной.
Так сейчас так и работает.
Не работает. Перечитай с самого начала и обрати внимание на примеры. Егор даже нашёл, в какой момент это в коде фара сломали.
Попробую резюмировать то, что накопилось в обсуждении.
-
Если курсор переместить на строку, которая короче запомненной позиции (п1), то он окажется в конце строки. Нажатием End пользователь может захотеть запомнить эту позицию (п2), НО новая позиция не запомнится (поскольку End в конце строки не поменяет текущее реальное положение) и при переходе к другой строке курсор улетит на ранее запомненную колонку (п1). а не окажется в той, которую запросил пользователь End-ом (п2).
-
Аналогичная проблема с Del, поскольку эта клавиша тоже не меняет (не должна) текущую реальную позицию курсора. Если курсор стоит в позиции п1 и его переместить на более короткую строку, курсор окажется в конце строки (п2). Нажав Del, курсор останется в середине строки в п2 и, по логике, эта позиция и должна запомниться... Но нет - если мы переместимся на другие строки, то увидим, что курсор продолжает улетать на п1. Причём с Backspace этой проблемы нету.
Тогда хочу уточнить - это поведение только при выключенной опции "Cursor beyond end of line" Если опцию включить, там поведение курсора - логично
только при выключенной опции "Cursor beyond end of line"
Как там со включённой опцией - без понятия. Я когда-то в стародавние времена попробовал этот режим, мне не понравилось и с тех пор я с ним не работаю.
Если опцию включить, там поведение курсора - логично
Ну так проблема, как я понимаю, в том, что правили какую-то проблему когда эта опция включена, а при этом сломали режим с выключенной опцией и не заметили.
При [x] Cursor beyond end of line никакая логика не нужна, поэтому и работает.