Исправление EXL, (текущая версия) :
Я лично склоняюсь к тому чтобы никак не ограничивать длину строки и считать предпочтительным отсутствие переносов. В конце концов, редактор может сделать что угодно и именно так как нужно в данный момент - спрятать хвост строки за областью редактирования, или перенести её. А изуродованный переносами текст никак уже не исправить - он тратит вертикальное пространство, не использует горизонтальное пространство и помимо этого создаёт паразитный diff.
Я в своё время наковырялся с разными типами переносов, по типу:
// 1
status |= UIS_MakeContentFromString("Mq0Sg1",
&list[APP_MENU_ITEM_VIBRATION_SIGNAL].content.static_entry.text,
g_str_vibro_signal, g_option_vibro_motor_signal);
// 2
status |= UIS_MakeContentFromString("Mq0Sg1",
&list[APP_MENU_ITEM_VIBRATION_SIGNAL].content.static_entry.text,
g_str_vibro_signal, g_option_vibro_motor_signal);
// 3
status |= UIS_MakeContentFromString(
"Mq0Sg1",
&list[APP_MENU_ITEM_VIBRATION_SIGNAL].content.static_entry.text,
g_str_vibro_signal,
g_option_vibro_motor_signal
);
И тоже пришёл к выводу, что уж лучше перелёт за 120 и более, чем эти акробатические трюки.
Сейчас все IDE и редакторы умные и Word Warp везде включается если нужно.
Исправление EXL, :
Я лично склоняюсь к тому чтобы никак не ограничивать длину строки и считать предпочтительным отсутствие переносов. В конце концов, редактор может сделать что угодно и именно так как нужно в данный момент - спрятать хвост строки за областью редактирования, или перенести её. А изуродованный переносами текст никак уже не исправить - он тратит вертикальное пространство, не использует горизонтальное пространство и помимо этого создаёт паразитный diff.
Я в своё время наковырялся с разными типами переносов, по типу:
// 1
status |= UIS_MakeContentFromString("Mq0Sg1",
&list[APP_MENU_ITEM_VIBRATION_SIGNAL].content.static_entry.text,
g_str_vibro_signal, g_option_vibro_motor_signal);
// 2
status |= UIS_MakeContentFromString("Mq0Sg1",
&list[APP_MENU_ITEM_VIBRATION_SIGNAL].content.static_entry.text,
g_str_vibro_signal, g_option_vibro_motor_signal);
// 3
status |= UIS_MakeContentFromString(
"Mq0Sg1",
&list[APP_MENU_ITEM_VIBRATION_SIGNAL].content.static_entry.text,
g_str_vibro_signal,
g_option_vibro_motor_signal
);
И тоже пришёл к выводу, что уж лучше перелёт за 120 и более, чем эти акробатические трюки.
status |= UIS_MakeContentFromString("Mq0Sg1", &list[APP_MENU_ITEM_VIBRATION_SIGNAL].content.static_entry.text, g_str_vibro_signal, g_option_vibro_motor_signal);
Исходная версия EXL, :
Я лично склоняюсь к тому чтобы никак не ограничивать длину строки и считать предпочтительным отсутствие переносов. В конце концов, редактор может сделать что угодно и именно так как нужно в данный момент - спрятать хвост строки за областью редактирования, или перенести её. А изуродованный переносами текст никак уже не исправить - он тратит вертикальное пространство, не использует горизонтальное пространство и помимо этого создаёт паразитный diff.
Я в своё время наковырялся с разными типами переносов, по типу:
// 1
status |= UIS_MakeContentFromString("Mq0Sg1",
&list[APP_MENU_ITEM_VIBRATION_SIGNAL].content.static_entry.text,
g_str_vibro_signal, g_option_vibro_motor_signal);
// 2
status |= UIS_MakeContentFromString("Mq0Sg1",
&list[APP_MENU_ITEM_VIBRATION_SIGNAL].content.static_entry.text,
g_str_vibro_signal, g_option_vibro_motor_signal);
// 3
status |= UIS_MakeContentFromString(
"Mq0Sg1",
&list[APP_MENU_ITEM_VIBRATION_SIGNAL].content.static_entry.text,
g_str_vibro_signal,
g_option_vibro_motor_signal
);
И тоже пришёл к выводу, что уж лучше перелёт за 120 и более, чем эти акробатические трюки.