Re: Another POSIX incompatibility

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Gary V. Vaughan on 11/9/2006 5:03 PM:
> Hi Eric!

Hi Gary, and thanks for a review.

> 
> On 1 Nov 2006, at 07:44, Eric Blake wrote:
>> I'm thinking that for the head, maybe I
>> should turn --synclines into an option with an optional argument, so that
>> you can turn synclines off between files as well as on by using -s0 (and
>> keeping -s as a synonym for -s1).
> 
> Is there a practical use for being able to turn off synclines?  More in
> keeping with the allow-cli-like-functionality-programatically sub-theme
> of m4-2.0 would be to add trace{on,off} inspired synclines{on,off}
> macros...

Symmetry.  And perhaps so that:
$ m4 foo --syncoutput=1 bar --syncoutput=0 blah

behaves like:
$ m4 << EOF
include(foo)dnl
syncoutput(1)include(bar)dnl
syncoutput(0)include(blah)dnl
EOF

I'm not sure whether synclineson/synclinesoff is nicer than
syncoutput(1/0), seeing as how we have documented that for interfaces new
to M4 2.0, we either give them an m4 or __ prefix, or make the macro
blind, so that new macros are less likely to interfere with plain text
that parsed succesfully in older m4 versions.  traceon has well-defined
semantics that differ depending on whether it was given arguments or not;
whereas the current syncoutput is really just a toggle, and requires an
argument.  But if we changed it to two builtins, synclineson and
synclinesoff, then we would have to make them require, yet ignore, a
single argument, if we are to comply with the goal of keeping new macros
from interfering with plain text.  I'm thinking syncoutput is more like
debugmode, which is another example of a toggle macro that requires an
argument.

For now, the patch I am in the middle of adds a new option, --syncoutput,
with an optional argument parsed in the same manner as the argument to the
current syncoutput builtin, then makes -s and --synclines be synonyms for
- --syncoutput=1.

> 
>> And maybe it is time to think about
>> adding command line options --pushdef, --popdef, and --traceoff (of
>> those,
>> only --pushdef might be a candidate for a short option -p), for even more
>> inter-file operational capability.
> 
> They sound reasonable, but either way we need to make sure we use the
> same paradigm for tracing and synclines -- both from the cli and from
> any macros we introduce/improve.
> 
> It's a pity -d is taken for --debug, since using -d/-u for push/popdef
> to parallel -D/-U for define/undefine :-( What does POSIX have to say
> about -d?

POSIX only specifies -D, -U, and -s.  So we are free to change -d, except
that there is already a big existing user base of -d (well, autom4te
spells it out as --debug), so it would take a couple of releases with
deprecation warnings if you were to get -d/-u to stand for
- --pushdef/--popdef.  Not to mention that BSD m4 provides -d (but with a
required argument) in an attempt to let their implementation substitute
for GNU M4 in autoconf.  For now, I'm just implementing -p/--pushdef, and
- --popdef with no short option.

> 
>> Head also would support -m and -r
>> between files (mainly because it was easiest to use the existing deferred
>> argument handling mechanism to achieve this patch, by treating intermixed
>> files as deferred arguments to option '\1').
> 
> If we follow this through properly, we also need a module-unload cli
> option: --unload-module with no short option seems okay to me.

Yep, I realized that, too, while working on my patch.  And that was
exactly my choice, --unload-module with no short option.  In the process,
I realized that module_init is allowed to output text to the passed-in
obstack, but main() is passing in NULL as the obstack; so that probably
needs a fix.

> 
> And similarly, we should allow -r with no argument to reset the regexp
> syntax back to the compiled in default.

OK, I hadn't thought of that one, but it makes sense.

> 
> I'll wait a few days for feedback and then add them to TODO unless you
> disagree with anything?

Other options that my patch will include:
- -g/--gnu - enable GNU extensions (undoes -G/--traditional, even when
POSIXLY_CORRECT is specified) (and matches BSD's -g option)

- -W/--warnings - enable warnings (undoes -Q/-S/--silent).


I'm debating whether to make -W take an optional argument, as in:
- -Wall
- -Wnone
- -Wcategory
- -Wno-category
- -Werror

but I will probably just check in my current patch and save -W<arg> for a
later patch.  Likewise, I could probably make -W initialize according to
the WARNINGS environment variable (both of these -W improvements are
modeled after autoreconf).

I also realized that my patch yesterday broke -i/--interactive, so my
current patch will fix that and add several tests.

I finished the bulk of the code and new tests in my current patch, but
still have the documentation to go; unfortunately I left it on a different
computer that I can't currently access, so I can't post my progress as
part of this email.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFU/Nc84KuGfSFAYARAuOBAJ0ZfvOIWImHC7OTipzyOkRgW+ghVwCg0EO9
luf+cg5kPxvsydXUsyKwKFQ=
=yNsc
-----END PGP SIGNATURE-----