LINUX.ORG.RU

История изменений

Исправление 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 и более, чем эти акробатические трюки.