On Fri, May 16, 2025 at 11:28 AM Eric Blake <ebl...@redhat.com> wrote: > > On Fri, May 16, 2025 at 10:45:54AM -0400, Nikolaos Chatzikonstantinou wrote: > > On Fri, May 16, 2025 at 10:05 AM Eric Blake <ebl...@redhat.com> wrote: > > > > > > On Fri, May 16, 2025 at 08:16:24AM -0500, Eric Blake wrote: > > > > Since you continue to patch things as fast as I report them (now > > > > testing with commit a4cc0f3c): > > > > > > > > > > * At the command line, m4 treats -d as taking an optional argument > > > (POSIX discourages that practice, but m4 was doing it long before > > > POSIX, and since -d is a POSIX extension, it's better to keep status > > > quo). I don't know how easy or hard it is to make a short option take > > > an optional argument with python's argument parsing libraries; and I > > > also know you are still fine-tuning how debugmode() and --debug > > > behave: > > > > Yes, I'm aware of that one. There's certain discrepancies between > > argparse and what m4 does. For now I'll try to use argparse and live > > with the differences, but if I manage to get everything else to be > > 100% compatible I will revisit this issue, perhaps write my own argv > > parser. > > The python docs for argparse mentions that nargs='?' might work (but > you can't use that with a store_const action).
Python's argparse also supports custom parsers. I'm shelving this for later but I'll come back to it. For now I'm just noting it as another TODO in the features wiki page. > > > > > * Commit 45fdad3 broke reading large files: > > > $ seq 2000 > list > > > $ git checkout 45fdad3^ > > > $ echo 'len(include(list))' | m4p > > > 8893 > > > $ git checkout 45fdad3^ > > > $ echo 'len(include(list))' | m4p > > > 8196 > > > > Oops! Thank you, I fixed it and added a test for that as well. > > Better, but not perfect: > ... > (Yes, I have scripts that use changecom inside a call to include in > order to intentionally slurp in an entire file as a comment, by using > a start delimiter present in the file and an end delimiter that I > supply after the include - it makes it possible to handle files as > text without the risk of inadvertent macro expansion and even if the > file's contents are not otherwise balanced m4 constructs) I fixed all the bugs that you've mentioned. I wonder if a plugin system that extends the language is a potential idea to explore. It could transform certain slower native m4 functions to e.g. Python or Scheme functions (because I'm considering rewriting this in Guile one day... I do not know what compels me to always think of reimplementing stuff). Of course m4-native functions can always be written since m4 is Turing complete, but they may be inefficient. Regards, Nikolaos Chatzikonstantinou
