View Issue Details

IDProjectCategoryView StatusLast Update
0002657Far ManagerEditorpublic2014-08-02 05:25
ReporterCavaler Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version3.0 
Summary0002657: Некорректная работа при изменении последней строки файла из плагина
DescriptionЕсли плагин заменяет последнюю строку в файле (с пустым EOL) на строку с непустым EOL, Far продолжает обрабатывать эту строку как последнюю. А после переоткрытия редактора - уже видно, что строк стало на одну больше.
TagsNo tags attached.
Build

Relationships

duplicate of 0001941 new Редактор неправильно отрабатывает ECTL_SETSTRING в последней строке 

Activities

zg

2014-05-01 09:30

developer   bugnote:0012307

3883.

shmuel

2014-05-01 10:58

developer   bugnote:0012308

3883, наблюдается следующий эффект:

1. В редакторе одна строка abc (размер файла == 3).
2. Делаю замену b на \n плагином LuaFAR Search, затем делаю CtrlEnd и оказываюсь на 3-й строке, тогда как в файле должно быть 2 строки.
3. Сохраняю файл, выхожу из редактора, вижу размер файла == 3.
4. Открываю файл снова. В редакторе 2 строки.

zg

2014-05-01 17:48

developer   bugnote:0012309

всё работает абсолютно так, как описано в инциденте.

shmuel

2014-05-01 17:55

developer   bugnote:0012310

И это нормально (то, что я описал выше)? Этого не было до 3883.

zg

2014-05-01 18:05

developer   bugnote:0012311

оно ожидаемо в терминах апи+этот инцидент. нормально ли это — не берусь судить. могу либо оставить как есть, либо откатить изменения и закрыть инцидент с резолюцией: «не баг».

shmuel

2014-05-01 18:14

developer   bugnote:0012312

Несоответствие того, что показывает редактор до и после сохранения+переоткрытия есть баг, тут двух мнений быть не может.

Только "до 3883" и "в 3883" для проявления такого бага нужно совершать разные действия. Во всяком случае у меня тест LF Search сломался.

Неужели там такие сложности, что нельзя сделать нормально? (Это не претензия конкретно в чей-либо адрес, а просто вопрос).

zg

2014-05-01 18:25

developer   bugnote:0012313

> Несоответствие того, что показывает редактор до и после сохранения+переоткрытия есть баг, тут двух мнений быть не может.
тогда наверное стоит перестать пользоваться фаром. такой макрос:
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. переоткрыть и насладиться результатом.
> Неужели там такие сложности, что нельзя сделать нормально?
что именно нужно сделать нормально?

shmuel

2014-05-01 18:47

developer   bugnote:0012316

> что именно нужно сделать нормально?

Чтобы редактор показывал то же самое, что будет после сохранения + переоткрытия.

zg

2014-05-01 18:55

developer   bugnote:0012317

это по дизайну — невозможно.

shmuel

2014-05-01 19:24

developer   bugnote:0012318

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

zg

2014-05-01 19:34

developer   bugnote:0012319

> Это так?
нет.
> Если это так, то что же есть в дизайне API такого, что нарушает это?
как бы очевидно. возможность у каждой строки иметь свой eol. в том числе и пустой.

shmuel

2014-05-01 20:10

developer   bugnote:0012320

>> Это так?
> нет.

Пример?

>> Если это так, то что же есть в дизайне API такого, что нарушает это?
> как бы очевидно. возможность у каждой строки иметь свой eol. в том числе и пустой.

И в чём проблема разрешать пустой EOL только для последней строки? То-есть при установке пустого EOL в непоследней строке немедленно склеивать её со следующей, что равносильно нажатию Del в конце обрабатываемой, возможно изменённой строки.

zg

2014-05-01 20:25

developer   bugnote:0012321

> Пример?
файл:
123\n123\n123\n123\n
меняем 2 на \n
> И в чём проблема разрешать пустой EOL только для последней строки?
тем, что этому поведению 15 лет и кто-то именно в таком виде им пользуется?

shmuel

2014-05-01 20:38

developer   bugnote:0012322

Last edited: 2014-05-01 20:39

> файл:
> 123\n123\n123\n123\n
> меняем 2 на \n

При ручной замене эффекта несоответствия не наблюдаю.

>> И в чём проблема разрешать пустой EOL только для последней строки?
> тем, что этому поведению 15 лет и кто-то именно в таком виде им пользуется?

За эти годы API менялось неоднократно. А здесь речь идёт даже не о ломке API, а о багфиксе. Редакторные плагины для 1.75 поломаются? А ими многие ли пользуются?

zg

2014-05-01 21:22

developer   bugnote:0012323

> При ручной замене эффекта несоответствия не наблюдаю.
именно при ручной замене эффект прекрасно наблюдается.
> За эти годы API менялось неоднократно.
ECTL_SETSTRING не изменился.
> А здесь речь идёт даже не о ломке API, а о багфиксе.
к сожалению — нет. да, конечно можно склеивать строки при пустом eol. но это не единственная проблема с еолами. чтобы всё красиво было, надо запретить вообще еол менять у отдельных строк — а это уже несовместимость.
> Редакторные плагины для 1.75 поломаются?
а что изменилось в 3.0 по сравнению 1.75, что 1.75 плагины сломаются, а 3.0 — нет?

shmuel

2014-05-01 21:30

developer   bugnote:0012324

>> При ручной замене эффекта несоответствия не наблюдаю.
> именно при ручной замене эффект прекрасно наблюдается.

Утверждение, к сожалению, ничем не подтверждено. Для подтверждения нужна точная последовательность нажатия клавиш, указание, что ожидается получить, и что получается. А так - полунамёки.

> а что изменилось в 3.0 по сравнению 1.75, что 1.75 плагины сломаются, а 3.0 — нет

Как автор плагина поиска и замены, могу сказать, что в нём от этого ничего не поломается.

zg

2014-05-01 21:56

developer   bugnote:0012325

code="Keys(\"F4 CtrlF7 2 Tab CtrlQ CtrlJ Enter Right Enter F2 Esc F4\")"

shmuel

2014-05-01 22:02

developer   bugnote:0012326

> code="Keys(\"F4 CtrlF7 2 Tab CtrlQ CtrlJ Enter Right Enter F2 Esc F4\")"

Под условием "вручную" я подразумевал только использование клавиш редактирования и навигации, но никак не CtrlF7. Это уже не вручную.

zg

2014-05-01 22:12

developer   bugnote:0012327

> Насколько я понимаю, "вручную" (без вызова ф-ций API)
из этой фразы можно сделать совсем другой вывод. но пожалуйста:
code="Keys(\"ShiftF4 1 . t x t Enter 1 CtrlQ CtrlJ 2 Esc Enter Up F4\")"

shmuel

2014-05-01 22:18

developer   bugnote:0012328

Нормальное редактирование не предполагает никаких CtrlQ, CtrlJ.
Они были придуманы как средство для однострочного редакторного контрола.
Какой смысл их употреблять в многострочном редакторе?

zg

2014-05-02 00:25

developer   bugnote:0012329

я подумал и откатил изменения. при надобности такое реализуется в плагине, а вреда от такого интеллекта — больше.

2useven10

2014-05-03 10:24

developer   bugnote:0012330

Last edited: 2014-05-03 10:27

>> И в чём проблема разрешать пустой EOL только для последней строки?
>тем, что этому поведению 15 лет и кто-то именно в таком виде им пользуется?
Очень трогательная забота о гипотетических пользователях весьма странной и короткоживущей (до перезагрузки файла) 'особенности' редактора фар. Но может быть лучше прислушаться к реальным пользователям, которых такое поведение не устраивает?

zg

2014-05-03 11:54

developer   bugnote:0012331

> Но может быть лучше прислушаться к реальным пользователям, которых такое поведение не устраивает?
прислушайся, какие проблемы? проблема ж не в том, что к пользователям не прислушиваемся, а в том, что пол редактора переписать надо. причём очень желательно — одномоментно. потому что в том, как оно сделано сейчас есть логика — фар никогда по setstring новых строк не создаёт и старых не удаляет. если делать, что-то другое — то только, как мне кажется, вариант, когда текущая разбивка на строки в редакторе полностью соответствует текущим данным. все промежуточные варианты — гораздо большие проблемы для плагинов/макросов, чем есть сейчас.

2useven10

2014-05-04 10:35

developer   bugnote:0012333

я тоже считаю, что показываться должно то, что есть.
но откуда 'пол редактора'?
setstring(всё что связано с установкой строк через api), замена...
что ещё может быть источником нестыковки данных и отображения.
ты с редактором знаком лучше, можешь озвучить размер бедствия поконкретнее?

zg

2014-05-04 13:14

developer   bugnote:0012334

да, действительно всё в целом чуть попроще. что нужно сделать:
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. возможно какие-то макро функции, не базирующиеся на апи.

вроде ничего не забыл.

zg

2014-05-04 13:15

developer   bugnote:0012335

по первому пункту сразу лесом идёт вот это: http://forum.farmanager.com/viewtopic.php?f=15&t=8290
может быть ещё что-то.

JohnDoe

2014-08-02 00:27

updater   bugnote:0012828

Дубль 0001941

Issue History

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