View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002657 | Far Manager | Editor | public | 2014-04-21 12:37 | 2014-08-02 05:25 |
Reporter | Cavaler | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 3.0 | ||||
Summary | 0002657: Некорректная работа при изменении последней строки файла из плагина | ||||
Description | Если плагин заменяет последнюю строку в файле (с пустым EOL) на строку с непустым EOL, Far продолжает обрабатывать эту строку как последнюю. А после переоткрытия редактора - уже видно, что строк стало на одну больше. | ||||
Tags | No tags attached. | ||||
Build | |||||
duplicate of | 0001941 | new | Редактор неправильно отрабатывает ECTL_SETSTRING в последней строке |
|
3883. |
|
3883, наблюдается следующий эффект: 1. В редакторе одна строка abc (размер файла == 3). 2. Делаю замену b на \n плагином LuaFAR Search, затем делаю CtrlEnd и оказываюсь на 3-й строке, тогда как в файле должно быть 2 строки. 3. Сохраняю файл, выхожу из редактора, вижу размер файла == 3. 4. Открываю файл снова. В редакторе 2 строки. |
|
всё работает абсолютно так, как описано в инциденте. |
|
И это нормально (то, что я описал выше)? Этого не было до 3883. |
|
оно ожидаемо в терминах апи+этот инцидент. нормально ли это — не берусь судить. могу либо оставить как есть, либо откатить изменения и закрыть инцидент с резолюцией: «не баг». |
|
Несоответствие того, что показывает редактор до и после сохранения+переоткрытия есть баг, тут двух мнений быть не может. Только "до 3883" и "в 3883" для проявления такого бага нужно совершать разные действия. Во всяком случае у меня тест LF Search сломался. Неужели там такие сложности, что нельзя сделать нормально? (Это не претензия конкретно в чей-либо адрес, а просто вопрос). |
|
> Несоответствие того, что показывает редактор до и после сохранения+переоткрытия есть баг, тут двух мнений быть не может. тогда наверное стоит перестать пользоваться фаром. такой макрос: Macro {area="Editor";key="CtrlShiftF11";description="test";action=function() local info=editor.GetInfo() for ii=1,info.TotalLines do local line=editor.GetString(-1,ii,0) editor.SetString(-1,ii,line.StringText,"") end end} в любом текстовом файле CtrlShiftF11 F2. переоткрыть и насладиться результатом. > Неужели там такие сложности, что нельзя сделать нормально? что именно нужно сделать нормально? |
|
> что именно нужно сделать нормально? Чтобы редактор показывал то же самое, что будет после сохранения + переоткрытия. |
|
это по дизайну — невозможно. |
|
Насколько я понимаю, "вручную" (без вызова ф-ций API) добиться несоответствия между представлением текста в редакторе до и после переоткрытия не получится. Это так? Если это так, то что же есть в дизайне API такого, что нарушает это? |
|
> Это так? нет. > Если это так, то что же есть в дизайне API такого, что нарушает это? как бы очевидно. возможность у каждой строки иметь свой eol. в том числе и пустой. |
|
>> Это так? > нет. Пример? >> Если это так, то что же есть в дизайне API такого, что нарушает это? > как бы очевидно. возможность у каждой строки иметь свой eol. в том числе и пустой. И в чём проблема разрешать пустой EOL только для последней строки? То-есть при установке пустого EOL в непоследней строке немедленно склеивать её со следующей, что равносильно нажатию Del в конце обрабатываемой, возможно изменённой строки. |
|
> Пример? файл: 123\n123\n123\n123\n меняем 2 на \n > И в чём проблема разрешать пустой EOL только для последней строки? тем, что этому поведению 15 лет и кто-то именно в таком виде им пользуется? |
|
> файл: > 123\n123\n123\n123\n > меняем 2 на \n При ручной замене эффекта несоответствия не наблюдаю. >> И в чём проблема разрешать пустой EOL только для последней строки? > тем, что этому поведению 15 лет и кто-то именно в таком виде им пользуется? За эти годы API менялось неоднократно. А здесь речь идёт даже не о ломке API, а о багфиксе. Редакторные плагины для 1.75 поломаются? А ими многие ли пользуются? |
|
> При ручной замене эффекта несоответствия не наблюдаю. именно при ручной замене эффект прекрасно наблюдается. > За эти годы API менялось неоднократно. ECTL_SETSTRING не изменился. > А здесь речь идёт даже не о ломке API, а о багфиксе. к сожалению — нет. да, конечно можно склеивать строки при пустом eol. но это не единственная проблема с еолами. чтобы всё красиво было, надо запретить вообще еол менять у отдельных строк — а это уже несовместимость. > Редакторные плагины для 1.75 поломаются? а что изменилось в 3.0 по сравнению 1.75, что 1.75 плагины сломаются, а 3.0 — нет? |
|
>> При ручной замене эффекта несоответствия не наблюдаю. > именно при ручной замене эффект прекрасно наблюдается. Утверждение, к сожалению, ничем не подтверждено. Для подтверждения нужна точная последовательность нажатия клавиш, указание, что ожидается получить, и что получается. А так - полунамёки. > а что изменилось в 3.0 по сравнению 1.75, что 1.75 плагины сломаются, а 3.0 — нет Как автор плагина поиска и замены, могу сказать, что в нём от этого ничего не поломается. |
|
code="Keys(\"F4 CtrlF7 2 Tab CtrlQ CtrlJ Enter Right Enter F2 Esc F4\")" |
|
> code="Keys(\"F4 CtrlF7 2 Tab CtrlQ CtrlJ Enter Right Enter F2 Esc F4\")" Под условием "вручную" я подразумевал только использование клавиш редактирования и навигации, но никак не CtrlF7. Это уже не вручную. |
|
> Насколько я понимаю, "вручную" (без вызова ф-ций API) из этой фразы можно сделать совсем другой вывод. но пожалуйста: code="Keys(\"ShiftF4 1 . t x t Enter 1 CtrlQ CtrlJ 2 Esc Enter Up F4\")" |
|
Нормальное редактирование не предполагает никаких CtrlQ, CtrlJ. Они были придуманы как средство для однострочного редакторного контрола. Какой смысл их употреблять в многострочном редакторе? |
|
я подумал и откатил изменения. при надобности такое реализуется в плагине, а вреда от такого интеллекта — больше. |
|
>> И в чём проблема разрешать пустой EOL только для последней строки? >тем, что этому поведению 15 лет и кто-то именно в таком виде им пользуется? Очень трогательная забота о гипотетических пользователях весьма странной и короткоживущей (до перезагрузки файла) 'особенности' редактора фар. Но может быть лучше прислушаться к реальным пользователям, которых такое поведение не устраивает? |
|
> Но может быть лучше прислушаться к реальным пользователям, которых такое поведение не устраивает? прислушайся, какие проблемы? проблема ж не в том, что к пользователям не прислушиваемся, а в том, что пол редактора переписать надо. причём очень желательно — одномоментно. потому что в том, как оно сделано сейчас есть логика — фар никогда по setstring новых строк не создаёт и старых не удаляет. если делать, что-то другое — то только, как мне кажется, вариант, когда текущая разбивка на строки в редакторе полностью соответствует текущим данным. все промежуточные варианты — гораздо большие проблемы для плагинов/макросов, чем есть сейчас. |
|
я тоже считаю, что показываться должно то, что есть. но откуда 'пол редактора'? setstring(всё что связано с установкой строк через api), замена... что ещё может быть источником нестыковки данных и отображения. ты с редактором знаком лучше, можешь озвучить размер бедствия поконкретнее? |
|
да, действительно всё в целом чуть попроще. что нужно сделать: 1. запретить пустые концы строк не для последней строки. варианты, что делать, если плагин посылает пустой конец строки: 1.1. ничего, возвращать false - я за этот вариант. 1.2. ставить дефолтный конец строки. 1.3. склеивать строки отдельно для последней строки, если не было конца, а его поставили добавлять новую строку (собственно этот топик). также наверное логично если последняя строка пустая, и для предпоследней устанавливается нулевой конец строки - удалять последнюю строку. 2. парсить заменяемую строку (ECTL_SETSTRING) на предмет \n \r и вставлять соответствующие новые строки. при этом надо учитывать, что если в начале строки \n, а предыдущая заканчивается на \r, то это надо объединять. так же не забыть про коррекцию для вертикальных блоков и закладок. 3. модернизировать поиск и замену. вынести его из класса Edit в класс Editor. скорее всего собственно замену производить лучше через ECTL_SETSTRING, а не напрямую. 4. при вставке с клавиатуры \r \n, вставлять не символ, а новую строку. учитывать объединения типа \r \n -> \r\n. 5. ECTL_DELETESTRING, ECTL_DELETECHAR, ECTL_INSERTTEXT, возможно ECTL_READINPUT и ECTL_PROCESSINPUT, а также любой ввод пользователя: учитывать объединения типа \r \n -> \r\n. 6. возможно какие-то макро функции, не базирующиеся на апи. вроде ничего не забыл. |
|
по первому пункту сразу лесом идёт вот это: http://forum.farmanager.com/viewtopic.php?f=15&t=8290 может быть ещё что-то. |
|
Дубль 0001941 |
Date Modified | Username | Field | Change |
---|---|---|---|
2014-04-21 12:37 | Cavaler | New Issue | |
2014-05-01 09:30 | zg | Note Added: 0012307 | |
2014-05-01 10:58 | shmuel | Note Added: 0012308 | |
2014-05-01 17:48 | zg | Note Added: 0012309 | |
2014-05-01 17:55 | shmuel | Note Added: 0012310 | |
2014-05-01 18:05 | zg | Note Added: 0012311 | |
2014-05-01 18:14 | shmuel | Note Added: 0012312 | |
2014-05-01 18:25 | zg | Note Added: 0012313 | |
2014-05-01 18:47 | shmuel | Note Added: 0012316 | |
2014-05-01 18:55 | zg | Note Added: 0012317 | |
2014-05-01 19:24 | shmuel | Note Added: 0012318 | |
2014-05-01 19:34 | zg | Note Added: 0012319 | |
2014-05-01 20:10 | shmuel | Note Added: 0012320 | |
2014-05-01 20:25 | zg | Note Added: 0012321 | |
2014-05-01 20:38 | shmuel | Note Added: 0012322 | |
2014-05-01 20:39 | shmuel | Note Edited: 0012322 | |
2014-05-01 21:22 | zg | Note Added: 0012323 | |
2014-05-01 21:30 | shmuel | Note Added: 0012324 | |
2014-05-01 21:56 | zg | Note Added: 0012325 | |
2014-05-01 22:02 | shmuel | Note Added: 0012326 | |
2014-05-01 22:12 | zg | Note Added: 0012327 | |
2014-05-01 22:18 | shmuel | Note Added: 0012328 | |
2014-05-02 00:25 | zg | Note Added: 0012329 | |
2014-05-03 10:24 | 2useven10 | Note Added: 0012330 | |
2014-05-03 10:26 | 2useven10 | Note Edited: 0012330 | |
2014-05-03 10:27 | 2useven10 | Note Edited: 0012330 | |
2014-05-03 11:54 | zg | Note Added: 0012331 | |
2014-05-04 10:35 | 2useven10 | Note Added: 0012333 | |
2014-05-04 13:14 | zg | Note Added: 0012334 | |
2014-05-04 13:15 | zg | Note Added: 0012335 | |
2014-08-02 00:27 | JohnDoe | Note Added: 0012828 | |
2014-08-02 05:25 | shmuel | Relationship added | duplicate of 0001941 |