Dave and I have been discussing a change. I propose permitting soelim(1) to interpret spaces in a `so` argument as-is, and supporting `ds`-style leading double-quote removal (allowing file names that begin with spaces).
Why? To align with a proposed syntax extension to `so` and other requests in the formatter. See bug #65108. Won't this break compatibility with everybody? No. Historically, neither formatters nor soelim programs don't interpret backslash-escaped spaces as spaces, and in fact soelim programs traditionally rewrite the first space they encounter in a `so` argument as a newline (likely putting an undesired partial file name on the output as formatted text). See comments 3 and 4 to bug #65108. Won't this break compatibility with our own users' past documents? Partially. If they only ever processed such `so` "requests" with soelim(1), such that the formatter, troff(1), never saw them, and the arguments contained backslash-space escape sequences to cause interpolation of files with spaces in their file names, yes. If they tried to get the formatter to do this itself, perhaps because they didn't need a file interpolated during _preprocessing_, they were disappointed because it didn't work. The idea here is to make it work, and make it work the same way, whether soelim(1) is used or not. soelim(1) will thus be able to interpret arbitrary file names. See the bug for details, including the proposed approach to character encoding challenges. Please follow-up with feedback and comments here or in bug #66027. https://savannah.gnu.org/bugs/?65108 https://savannah.gnu.org/bugs/?66027 Regards, Branden P.S. Anyone think soelim(1) should be refusing to open file names with slashes in them by default, and should accept a `-U` option to override that restriction?
signature.asc
Description: PGP signature
