bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #62909] [chem] does not restrict whitespace/comment changes to its


From: G. Branden Robinson
Subject: [bug #62909] [chem] does not restrict whitespace/comment changes to its own regions
Date: Mon, 22 Aug 2022 17:59:07 -0400 (EDT)

Follow-up Comment #5, bug #62909 (project groff):

[comment #4 comment #4:]
> Hi Riza,
> 
> You mentioned in http://lists.gnu.org/r/groff/2022-08/msg00199.html that you
wrote an awk script to work around this problem.  If you're willing to share
it (and legally permitted), would you mind attaching it to this bug report, so
that others who encounter the problem can benefit from your work until the
chem code can be patched?  (And even if it's fixed quickly, most users won't
run the updated code until it makes it into an official release.)  Thanks for
considering this.

There's no urgency here.  I've already started refactoring _chem_.

I suspect the state machine is a bit buggy near the top level; _chem_ should
pass through unmolested any lines that aren't in a "chem" region.

The amount of pointless work that is being done in argument processing here is
truly staggering.  But I need to make sure I don't screw anything up.

Anyway, I've got some of the refactoring set for my next push and to go
farther I need to write a regression test, possibly using the very examples
from the Kernighan _chem_ paper that we already ship.  If that doesn't already
handle cases of leading space- and hash-mark-containing lines outside of
_chem_ regions, it will be straightforward to add these.


commit b28c6b5ea7834bb25a9b5c7c704f8062fa0b6410
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Aug 18 09:06:27 2022 -0500

    [chem]: Stop copying "pic.tmac" into output.
    
    * contrib/chem/chem.pl: Stop copying "pic.tmac" (fallback troff macro
      definitions) into the output.  It might not be necessary and it is
      inappropriate to do so if a macro package offers its own definitions
      or the user has made other arrangements on the command line.  (The
      same thing can be achieved with the "-mpic" argument to the formatter
      or a front end.)  Bump version number.

 contrib/chem/ChangeLog |  9 +++++++++
 contrib/chem/chem.pl   | 10 +---------
 2 files changed, 10 insertions(+), 9 deletions(-)

commit bb329e944af54da2ae46a32555133dd2ca72d01a
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Aug 18 09:46:00 2022 -0500

    [chem]: Refactor.
    
    * contrib/chem/chem.pl: Refactor.
      - Rename scalars.
        Copyright -> copyright
        Program_Version -> chem_version
        Groff_Version -> groff_version
        Chem_Name -> chem
        before_make -> is_in_source_tree
      - Rename hash.
        at_at -> makevar
      - Drop unused hash member `$makevar{'BINDIR'}`.
      - Drop scalar `Groff_Version_Preset`, which apparently hadn't
        been updated since groff 1.20.  Instead, follow grog(1) and
        set the `groff_version` scalar to "DEVELOPMENT" if this is
        the version from the groff source tree.  Overwrite its value
        with that determined by make(1) if available.
      - Tighten usage and version messages; make the latter more
        conformant with the format recommended in the GNU Coding
        Standards.  Explicitly identify license as GNU GPLv2.
    
      (usage): Refer to "pic" with its command prefix if it is known
      to have one.  (If running "unbuilt", we have no way to know.)

 contrib/chem/ChangeLog |  23 ++++++++++
 contrib/chem/chem.pl   | 111
++++++++++++++++++-------------------------------
 2 files changed, 64 insertions(+), 70 deletions(-)


And here's what's pending with the argument processing cleanup, from my Git
stash.


 contrib/chem/chem.pl | 279
+++++++++++++++++++++------------------------------
 1 file changed, 114 insertions(+), 165 deletions(-)


That includes about 30 lines that are simply commented out.  If I can persuade
myself that we can do without them, the proportion of deletions will jump up.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62909>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]