Это не полный, проверенный ответ на вопрос q, но он может дать определенному читателю возможность перейти к функциональному решению.
Поведение TSynEdit для переноса слов определяется его текущимTSynWordWrapPlugin
.Плагин по умолчанию определен в SynEditWordWrap.Pas и содержит метод процедуры TSynWordWrapPlugin.WrapLines
, начиная со строки 512 в версии, которую я скачал вчера с помощью диспетчера GetIt D10.2.3.
Начиная со строки 560, есть блоккода, который, насколько я могу судить, учитывает пространство в начале каждой завернутой строки, как показано в q:
if Editor.IsWordBreakChar(vRunner^) then
begin
vRowEnd := vRunner;
break;
end;
Dec(vRunner);
vRunner
и vRowEnd
среди числа PWideCharпеременные, используемые в методе WrapLines
.
Наблюдая за поведением этого кода, который находится внутри цикла while
(который ищет место для переноса слов), он работает так, что когдаEditor.IsWordBreakChar(vRunner^)
возвращает значение true, указатель vRunner уже сдвинулся назад после символа разбиения по словам, поэтому он (пробел) заканчивается на следующей строке, вызывая проблему, отмеченную OP.
Изменениекод
if Editor.IsWordBreakChar(vRunner^) then
begin
{ma} Inc(vRunner); // WARNING: not fully tested
vRowEnd := vRunner;
break;
end;
Dec(vRunner);
заставляет указатель vRunner двигаться вперед за символом переноса слов, чтобы пробел был включен в конце строки, а не в sПоговорим о следующем, поэтому SynEdit затем отображает его обернутый текст, как стандартный TMemo.
Лично я бы не стал использовать это изменение, но вместо этого посмотрел бы, смогу ли я убедить разработчиков SynEdit предоставить официальное решение,если бы я действительно использовал изменение, показанное выше, я бы, конечно, не сделал бы это, изменив источник SynEditWordWrap.Pas, я бы сделал это, написав замену для TSynWordWrapPlugin
, и я бы включил проверку, чтоinc(vRunner)
не превышает допустимых границ буфера, используемого для переноса слов.