-default, I think that before replying to them, we have to decide
-if we want @sc{gnu} @command{tar} to go closer to @sc{posix} on average, while
-producing files. My choice would be to go closer to @sc{posix} in the
-long run. Besides possible double reading, I do not see any point
-of not trying to save files as sparse when creating archives which
-are neither @sc{posix} nor old-V7, so the actual @value{op-sparse} would
-become selected by default when producing such archives, whatever
-the reason is. So, @value{op-sparse} alone might be redefined to force
-@sc{gnu}-format archives, and recover its previous meaning from this fact.
-
-@sc{gnu}-format as it exists now can easily fool other @sc{posix} @command{tar},
-as it uses fields which @sc{posix} considers to be part of the file name
-prefix. I wonder if it would not be a good idea, in the long run,
-to try changing @sc{gnu}-format so any added field (like @code{ctime},
-@code{atime}, file offset in subsequent volumes, or sparse file
-descriptions) be wholly and always pushed into an extension block,
-instead of using space in the @sc{posix} header block. I could manage
-to do that portably between future @sc{gnu} @command{tar}s. So other @sc{posix}
-@command{tar}s might be at least able to provide kind of correct listings
-for the archives produced by @sc{gnu} @command{tar}, if not able to process
-them otherwise.
-
-Using these projected extensions might induce older @command{tar}s to fail.
-We would use the same approach as for @sc{posix}. I'll put out a @command{tar}
-capable of reading @sc{posix}ier, yet extended archives, but will not produce
-this format by default, in @sc{gnu} mode. In a few years, when newer @sc{gnu}
-@command{tar}s will have flooded out @command{tar} 1.11.X and previous, we
-could switch to producing @sc{posix}ier extended archives, with no real harm
-to users, as almost all existing @sc{gnu} @command{tar}s will be ready to read
-@sc{posix}ier format. In fact, I'll do both changes at the same time, in a
-few years, and just prepare @command{tar} for both changes, without effecting
-them, from 1.@var{POSIX}. (Both changes: 1---using @sc{posix} convention for
-getting over 100 characters; 2---avoiding mangling @sc{posix} headers for @sc{gnu}
-extensions, using only @sc{posix} mandated extension techniques).
-
-So, a future @command{tar} will have a @value{op-posix}
-flag forcing the usage of truly @sc{posix} headers, and so, producing
-archives previous @sc{gnu} @command{tar} will not be able to read.
-So, @emph{once} pretest will announce that feature, it would be
+default, I think that before replying to them, we have to decide if we
+want @acronym{GNU} @command{tar} to go closer to @sc{posix} on
+average, while producing files. My choice would be to go closer to
+@sc{posix} in the long run. Besides possible double reading, I do not
+see any point of not trying to save files as sparse when creating
+archives which are neither @sc{posix} nor old-V7, so the actual
+@value{op-sparse} would become selected by default when producing such
+archives, whatever the reason is. So, @value{op-sparse} alone might
+be redefined to force @acronym{GNU}-format archives, and recover its
+previous meaning from this fact.
+
+@acronym{GNU}-format as it exists now can easily fool other @sc{posix}
+@command{tar}, as it uses fields which @sc{posix} considers to be part
+of the file name prefix. I wonder if it would not be a good idea, in
+the long run, to try changing @acronym{GNU}-format so any added field
+(like @code{ctime}, @code{atime}, file offset in subsequent volumes,
+or sparse file descriptions) be wholly and always pushed into an
+extension block, instead of using space in the @sc{posix} header
+block. I could manage to do that portably between future
+@acronym{GNU} @command{tar}s. So other @sc{posix} @command{tar}s
+might be at least able to provide kind of correct listings for the
+archives produced by @acronym{GNU} @command{tar}, if not able to
+process them otherwise.
+
+Using these projected extensions might induce older @command{tar}s to
+fail. We would use the same approach as for @sc{posix}. I'll put out
+a @command{tar} capable of reading @sc{posix}ier, yet extended
+archives, but will not produce this format by default, in
+@acronym{GNU} mode. In a few years, when newer @acronym{GNU}
+@command{tar}s will have flooded out @command{tar} 1.11.X and
+previous, we could switch to producing @sc{posix}ier extended
+archives, with no real harm to users, as almost all existing
+@acronym{GNU} @command{tar}s will be ready to read @sc{posix}ier
+format. In fact, I'll do both changes at the same time, in a few
+years, and just prepare @command{tar} for both changes, without
+effecting them, from 1.@var{POSIX}. (Both changes: 1---using
+@sc{posix} convention for getting over 100 characters; 2---avoiding
+mangling @sc{posix} headers for @acronym{GNU} extensions, using only
+@sc{posix} mandated extension techniques).
+
+So, a future @command{tar} will have a @value{op-posix} flag forcing
+the usage of truly @sc{posix} headers, and so, producing archives
+previous @acronym{GNU} @command{tar} will not be able to read. So,
+@emph{once} pretest will announce that feature, it would be