Bugs / Найденные баги (1)

Russian main discussion
Locked
  • Author
  • Message
Offline
Site Admin
Posts: 6311
Joined: Thu Jul 06, 2006 7:20 am

Post by Instructor »


Offline
Posts: 1161
Joined: Sun Oct 20, 2013 11:44 am

Post by Skif_off »

Instructor
Отлично, ошибка не воспроизводится (WinXP SP3/Win7x64), спасибо.

Offline
Posts: 582
Joined: Mon Apr 08, 2013 9:50 pm
Location: Win7SP1x64, APx64

Post by Drugmix »

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

то в обоих вышеописанных случаях ни пункт "save" в меню File, ни кнопка "save" на панели - не активны, хотя ведь акелпад в обоих случаях знает, что файл был модифицирован извне акелпада.

Я знаю, что достаточно напечатать 1 символ и стереть его, чтобы кнопка стала снова активной, но ведь это же лишние шаги в истории UnDo/ReDo.

И да, по поводу варианта б: при возврате к окну акелпада появляется оповещение о том, что открытый файл был изменён извне даже тогда, когда его содержимое осталось прежним (но была изменена, например, дата последнего изменения), можно ли добавить скрытую настройку для того, чтобы в случае если содержимое файла не изменилось, то и оповещение бы не вылезало?

Offline
Site Admin
Posts: 6311
Joined: Thu Jul 06, 2006 7:20 am

Post by Instructor »

Drugmix
Infocatcher wrote:По-моему, после отрицательного ответа на вопрос, не обновить ли файл, измененный другой программой, логично было бы добавлять флаг модифицированности. А то для разблокирования возможности сохранения приходится набирать любой символ, а потом стирать.
viewtopic.php?t=1134

Offline
Posts: 582
Joined: Mon Apr 08, 2013 9:50 pm
Location: Win7SP1x64, APx64

Post by Drugmix »

Instructor
F10, выбираю файл, жму сохранить (визуально ничего не происходит), жму ОК, открываю файл заново - а он не сохранился так, как открыт в акелпаде.
И потом, к чему все эти заморочки с F10?

Ещё раздражает то, что если на вопрос "файл был изменён, переоткрыть?" ответить "да", то по ctrl+z в случае чего нельзя вернуться к тому виду, какой был ДО переоткрытия.

Т.к. в случае изменения содержимого файла и в случае, например, изменения только даты его последней модификации выдаётся абсолютно одинаковое оповещение, то пользователь не может быть уверен, что изменения файла произошли не над содержимым файла, а т.к. в случае если он выберет "да, переоткрыть" то не сможет в случае чего вернуть всё обратно как было по CTRL+Z, то получается, что очень легко потерять информацию, что со мной иногда уже случалось и это всегда очень расстраивало :(

Обходные пути - это замечательно, но вы не считаете всё же это поведение багом, который надо бы исправить?

Offline
Site Admin
Posts: 6311
Joined: Thu Jul 06, 2006 7:20 am

Post by Instructor »

Drugmix wrote:Обходные пути - это замечательно, но вы не считаете всё же это поведение багом, который надо бы исправить?
Нет, так и задумывалось при разработке. Переоткрытие файла - очищает буфер отмен.

Offline
Posts: 582
Joined: Mon Apr 08, 2013 9:50 pm
Location: Win7SP1x64, APx64

Post by Drugmix »

Instructor
Какая нехорошая задумка :)
А может можно решить вопрос скрытой настройкой? Если эта скрытая настройка присутствует, то переоткрытие файла не очищало бы буфер отмен.

DV
Offline
Posts: 1250
Joined: Thu Nov 16, 2006 11:53 am
Location: Kyiv, Ukraine

Post by DV »

Drugmix wrote:то переоткрытие файла не очищало бы буфер отмен.
Тогда при переоткрытии файла придётся держать в памяти всё предыдущее его содержимое до переоткрытия. (Так как файл мог быть изменён извне и потенциально содержит совершенно другой текст.)
А если файл был переоткрыт несколько раз подряд? Тогда хранить в памяти все предыдущие версии содержимого файла, соответсвующие состоянию до каждого переоткрытия?

Offline
Posts: 582
Joined: Mon Apr 08, 2013 9:50 pm
Location: Win7SP1x64, APx64

Post by Drugmix »

DV wrote:Тогда при переоткрытии файла придётся держать в памяти всё предыдущее его содержимое до переоткрытия. (Так как файл мог быть изменён извне и потенциально содержит совершенно другой текст.)
А если файл был переоткрыт несколько раз подряд? Тогда хранить в памяти все предыдущие версии содержимого файла, соответсвующие состоянию до каждого переоткрытия?
Да, именно так. И что, вас это пугает?
Если да, то давайте я вас ещё больше напугаю: у меня в памяти создан логический диск (ramdisk), и я туда перенаправил переменные %temp% и %tmp%, а так же кэш лисы (браузера).
Мой стиль браузинга такой для многих причудливый, что в среднем у меня постоянно открыто ~35 вкладок. А у каждой вкладки хранится ещё и история переходов в 10 страниц.
У много каких скачиваемых файлов в браузере я жму "открыть", вместо "сохранить", а значит они скачиваются опять-таки в рамдиск.

При всём при этом, в среднем у меня занято менее 40% оперативной памяти из имеющихся у меня 8 гб. Размер рамдиска при этом выставлен в 4гб, но т.к. он динамический, то из памяти он отъедает ровно столько объёма, сколько данных он в себе хранит (если диск не забит полностью, чего ещё ни разу со мной не случалось).

В связи со всем вышеописанным, для меня добавление в историю undo старой истории undo (до момента переоткрытия файла) явилась бы благом, а не проблемой.
Проблемой бы оно стало только если бы средний вес текстовых файлов с которыми я работаю исчислялся бы не в килобайтах, а в десятках мегабайт. Сейчас меня абсолютно не парит то, что у меня всегда в акелпаде открыто 10-20 вкладок.
Т.к. я допускаю возможность существования на свете людей, которые работают в акелпаде с текстовыми файлами в десятки мегабайт - то я и прошу приделать это изменение настройкой, можно даже скрытой.

И да, как итог этой страшной истории: у меня всё работает очень быстро, быстрей, чем если бы у меня не было рамдиска, ведь RAM имеет высокие скорости чтения и записи, по сравнению с аналогичными скоростями HDD (и вероятно, даже самых новомодных шустрых SSD).

Offline
Posts: 1161
Joined: Sun Oct 20, 2013 11:44 am

Post by Skif_off »

Drugmix wrote:Ещё раздражает то, что если на вопрос "файл был изменён, переоткрыть?" ответить "да", то по ctrl+z в случае чего нельзя вернуться к тому виду, какой был ДО переоткрытия.
Есть редактор, который делает иначе?

Вы упустили один момент
DV wrote:Так как файл мог быть изменён извне и потенциально содержит совершенно другой текст.
тогда будет не совсем понятно текущее состояние и предыдущее.

Offline
Posts: 582
Joined: Mon Apr 08, 2013 9:50 pm
Location: Win7SP1x64, APx64

Post by Drugmix »

Skif_off wrote:Есть редактор, который делает иначе?
Понятия не имею, но не стоит в таких вещах обращаться к чужому опыту как к аргументу в пользу своей позиции: если где-то ещё так же - это остаётся неудобным.
Сейчас перед переоткрытием файла приходится делать Ctrl+A, Ctrl+C, потом делать переоткрытие и потом Ctrl+V и тут же Ctrl+Z, на всякий случай, чтоб не потерять старое содержимое.
Если же потом отвлёкся на что-то, забыл про это, вернулся, и случайно что-то скопировал (старый текст потерялся из буфера обмена) и не дай бог напечатал хоть 1 символ (например, хоткей сорвался) в текущий текст - то всё, старый текст будет бесследно утерян.
Skif_off wrote:Вы упустили один момент
DV wrote:Так как файл мог быть изменён извне и потенциально содержит совершенно другой текст.
тогда будет не совсем понятно текущее состояние и предыдущее.
Вроде ничего не упускаю. Почему это будет не совсем понятно текущее состояние и предыдущее? Прекрасно понятно.
"переоткрыть файл?" "да" - вот тебе и новое состояние, с тем содержимым файла, которое у него есть сейчас.
Нажал undo - вернулся к состоянию, которое было ДО переоткрытия.
Нажал redo - снова вернулся к текущему состоянию файла.
По нажимабельности кнопки save можно понять какое из состояний у файла текущее, а какое нет, а по нажимабельности кнопок undo/redo можно понять есть ли какая-то история изменений сзади/спереди.

Offline
Posts: 1161
Joined: Sun Oct 20, 2013 11:44 am

Post by Skif_off »

Drugmix wrote:Понятия не имею, но не стоит в таких вещах обращаться к чужому опыту как к аргументу в пользу своей позиции: если где-то ещё так же - это остаётся неудобным.
Слово "неудобно" я не употребял :) История разработки многих сохранивших популярность редакторов не год и не два, почему-то переоткрыть можно во многих сколь-нибудь функциональных, а то, что хотите вы? Это вполне могут быть те самые грабли, на которые не обязательно наступать самому, ведь дело не только в количестве доступной памяти. В любом случае решать Instructor'у, подождем.
А позиция у меня проста: есть шустрый редактор (по настоящему шустрый, это не блокнот в Win7, который все так же подвисает при открытии файлов больше 1-2 Мб, только всю систему не подвешивает, как в WinXP, а редактор, шустро открывающий и 150 Кб, и 150 Мб, разницу можно заметить при скроллинге до конца файла - придется крутить дольше, в диспетчере задач и работе некоторых скриптов), функционал значительно расширяется за счет плагинов и скриптов (и это круто - не нужна куча кода в AkelPad.exe), и не хотелось бы, чтобы он превратился в монстра. Хотя мультиредактирование все-таки хочется :)

Буфер явно лишний, есть отличный скрипт NewFilebyRecent.js и команда

Code: Select all

-"Выдел./всё в новую вкладку" Call("Scripts::Main", 1, "NewFilebyRecent.js") Icon("%a\AkelFiles\Plugs\ToolBar.dll", 1)
в меню вкладок и редактирования (выделение копируется если оно есть, если нет - всё, вместе с подсветкой).

Offline
Posts: 582
Joined: Mon Apr 08, 2013 9:50 pm
Location: Win7SP1x64, APx64

Post by Drugmix »

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

Скрипт предложенный вами мне не подходит тем, что мне не нужно дублирование файлов, я тогда совсем в них увязну. Мне нужна эта информация в истории undo/redo и только там.

DV
Offline
Posts: 1250
Joined: Thu Nov 16, 2006 11:53 am
Location: Kyiv, Ukraine

Post by DV »

Если уж всерьёз рассуждать об идее при переоткрытии файла помещать весь текст в буфер отмен (Undo), то идея хорошая, да, но весьма затратная в плане разработки.
Пример:
Есть у нас файл размером, скажем, 10 МБ, для которого мы нажимаем кнопку Переоткрыть. При этом:
1. Текущий текст (в памяти) весь помещается в буфер отмен.
2. Содержимое файла считывается в память и отображается редактором.
Теперь предположим две ситуации:
А. Считанное содержимое файла полностью совпадает с предыдущим текстом, помещённым в буфер отмен.
Б. Кнопка Переоткрыть нажата 10 раз подряд.
В обеих ситуациях очевидно, что должен быть предусмотрен некий вспомогательный функционал, сравнивающий содержимое последнего текста в буфере отмен с текущим текстом в редакторе. Если содержимое идентично, то в Undo нет смысла, так как оно восстановит такой же текст, - и, следовательно, этот последний текст можно спокойно удалить из буфера отмен, тем самым освободив выделенную под него память. Иначе - без такого функционала - мы в конце концов используем всю доступную память.
Теперь о реализации подобного функционала. Поскольку сравнение содержимого текста в редакторе и в буфере отмен может потребовать некоторого времени, имеет смысл выполнять такое сравнение в потоке. А раз так, то любая следующая операция редактирования или переоткрытия файла должна сперва быть засинхронизирована с этой операцией сравнения.
Ну и теперь давайте прикинем, сколько сил и времени это займёт.
И даже с подобным функционалом мы всё равно можем упереться в нехватку памяти в следующей ситуации:
Шаг 1. Переоткрываем файл (предыдущее содержимое помещается в буфер отмен).
Шаг 2. Редактируем файл (теперь его содержимое отличается от того, которое было помещено в буфер отмен).
Шаг 3. Возвращаемся к Шагу 1. При каждом таком повторении буфер отмен будет распухать на глазах, хотя нам скорее всего уже вовсе не нужно содержимое файла, каким оно было 2 и более переоткрытий файла назад. А, с другой стороны, может быть и нужно...
Пожалуй, очистка буфера отмен при переоткрытии файла остаётся куда более лёгким решением.

Offline
Posts: 582
Joined: Mon Apr 08, 2013 9:50 pm
Location: Win7SP1x64, APx64

Post by Drugmix »

DV wrote:Есть у нас файл размером, скажем, 10 МБ, для которого мы нажимаем кнопку Переоткрыть. При этом:
1. Текущий текст (в памяти) весь помещается в буфер отмен.
2. Содержимое файла считывается в память и отображается редактором.
Теперь предположим две ситуации:
А. Считанное содержимое файла полностью совпадает с предыдущим текстом, помещённым в буфер отмен.
Б. Кнопка Переоткрыть нажата 10 раз подряд.
В обеих ситуациях очевидно, что должен быть предусмотрен некий вспомогательный функционал, сравнивающий содержимое последнего текста в буфере отмен с текущим текстом в редакторе.
Во-первых, пользователь включая настройку "запоминать старое состояние файла при переоткрытии" должен знать, что переоткрытие тяжёлого файла десятикратно - десятикратно утяжелит и содержимое буфера.
Во-вторых, научить акелпад при переоткрытии файла определять были ли изменения в содержимом или нет - было бы, безусловно, хорошо, но это не обязательно: я вот подумал о том, чтобы просто дать пользователю контроль над очищением этой истории.
Locked