Date: Wed, 05 Jun 2019 22:06:29 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: maintainer-feedback requested: [Bug 238351] x11-clocks/xclock: xclock -strftime option misinterprets/mishandles the %n specification Message-ID: <bug-238351-7141-dTSno71b2E@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-238351-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-238351-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
Bugzilla Automation <bugzilla@FreeBSD.org> has asked freebsd-x11 mailing li= st <x11@FreeBSD.org> for maintainer-feedback: Bug 238351: x11-clocks/xclock: xclock -strftime option misinterprets/mishan= dles the %n specification https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238351 --- Description --- When xclock is invoked with both the -digital and -strftime options, the man page for xclock(1) suggests that the string given as the argument to the -strftime option will be interpreted as if it were a format specification g= iven to the strftime() libc function. This is mostly true with the exception of the %n (newline) conversion specification, which is utterly mishandled by xclock. Instead of introduci= ng a newline at that point in the rendered digital xclock image, xclock instead displays something that looks like an empty box character at the correspond= ing point in the rendered digital xclock image. This is just wrong, and it obviously violates the Principal of Least Surpri= se.=20 If the user has explicitly requested a newline at some certain point in the format string, then he/she did so for a reason, and xclock should honor that request by splitting the rendered digital xclock image across two (or more) lines, exactly as the user had explicitly requested. There is no compelling reason not to do so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-238351-7141-dTSno71b2E>