rtapi: end an error or warning that lacks the newline

[grandixximo]

Fixes #4689. @BsAtHome, this is your idea of fixing it where the message is printed. @hdiethelm, thanks for the report.

The uspace default message handlers now add a missing newline where they print: in the main thread of rtapi_app, in the queue that prints the messages of its realtime threads, and in user processes. Only errors and warnings get it. Info and debug messages and rtapi_print() may build one line from several calls, as motion's debug output, the PPMC driver and rtapi_app's cpuset report do, so they are left as they are. The 58 error and warning formats without the newline, and their translations, do not change. RTAI kernel modules are not changed.

tests/rtapi-msg-newline prints errors and a warning without a newline from the main thread of rtapi_app and from a realtime thread, and an info line in two parts. On master all of it comes out as one line. The full suite passes apart from blendmath, which does not build with GCC 14 (#4676).

[hdiethelm]

It is probably a good thing to enforce a newline but it can have side effects.

A few things to consider:

linuxcnc/src/emc/motion/homing.c

Line 282 in eab7726

rtapi_print_msg(RTAPI_MSG_ERR,_("j%d end of move in home state %d"),jno, H[jno].home_state);

The _( including #define _(s) (s) can probably be removed as long as homing.c is only used in realtime context.

There are some places like this:

linuxcnc/src/emc/motion/command.c

Line 2136 in b99baf8

rtapi_print_msg(RTAPI_MSG_DBG, "\n");

or

linuxcnc/src/rtapi/uspace_rtapi_app.cc

Line 252 in b99baf8

rtapi_print_msg(RTAPI_MSG_INFO, "\n");

This cases will now produce to many newlines or clobbered messages.

As soon as motion is running, messages go trough a different path:

linuxcnc/src/emc/motion/motion.c

Line 460 in b99baf8

rtapi_set_msg_handler(emc_message_handler);

linuxcnc/src/emc/motion/motion.c

Line 247 in b99baf8

static void emc_message_handler(msg_level_t level, const char *fmt, va_list ap)

As much as I remember, this path to the gui goes to translation and adds a newline always. That's why the GUI pop-up's often have a newline to much. But a lot was changed since I touched it in #4116.

[grandixximo]

@hdiethelm thanks for looking. In order:

• In realtime _() is a no-op, but motion passes the format and its arguments through the error buffer, and snprintdbuf() in usrmotintf.cc translates the format for the GUI. The marker is what puts the strings into the .po files, so I would keep it.
• command.c:2136 and uspace_rtapi_app.cc:252 are debug and info messages built in parts. This PR leaves those levels alone; only errors and warnings get the newline, so their output does not change. tests/rtapi-msg-newline checks that an info line printed in two parts stays one line.
• Once motmod is loaded, emc_message_handler() sends errors to the GUI through emcmotErrorPutfv() and every message to old_handler, which is the default handler this PR changes. So the console gets the newline and the path to the GUI is unchanged. reportError() already adds a newline for the console, so its messages do not change either.