Follow-up Comment #2, bug#65098 (group groff):
Dealing with gropdf.pl separately, I have cobbled together a document which
may help you in the task. It is a list of all the diffs with a following
comment which describes what the changes accomplish. One way of handling this
is to introduce each file as a separate commit and include a description of
what the changes in each file achieve (from the embedded comments). Note that
I have removed from the diff changes to master since deri-gropdf-ng was
branched.
Gropdf.pl is a slightly different kettle of fish, it has grown by over 25%
(over 1000 lines), and the number of new lines of code is more than that
because there has been significant code deletion as well. You may remember
there was a code freeze for over 6 months before 1.23.0 and after 3 months I
got an "itch" and wrote the new version, you then suggested I start a new
branch, so I slammed the new version into that. I have already written about
the two main drivers for the change: making gropdf subset fonts in the pdf,
and switching from a word based input model to an input stream of glyph names
(you said that my description was helpful). So just as adding a new program
to a project does not lead to a raft of commits detailing every new function
in the code, but rather the commit would describe what new features the new
program adds to the project, it would probably be best to treat the new gropdf
in a similar way - describing what has been added to groff's capabilities.
I'm afraid I did not get your red tree reference, my only experience with
red/black trees is in "binary chop" and there is a self balancing algorithm
for that.
Maintainability is more concerned with understanding the code as it is, the
git log may help you understand how it got there but understanding what the
code actually achieves can only be understood by reading the code. For example
if I want to know what ps_output::put_string does then git log tells me that
isascii got changed to is_ascii in 1994, but it tells me nothing about what
the routine does. Maintainability of code is far more about the quality of
code and the knowledge and experience of the person looking at the code.
I've had a rethink about an.tmac and stripped out all the stuff added to MR,
since it was only there to support internal links to other pages within a man
page book (such as groff_man_pages.pdf), and I have found an alternative way
of achieving the same thing without touching an.tmac. All that is left is
stuff to make it work with the new gropdf, don't use \E* do use \\*, and add
support for UR/UE and MT/ME.
I know you are working on/planning your for iterator, but please don't hold up
merging my branch to wait for it, since in its current state it all works
without it. When your code is complete we can revisit which parts are helpful
for gropdf. Just out of interest: what does ch contain if N is set (i.e. it is
a node).
(file #55511)
_______________________________________________________
Additional Item Attachment:
File name: diff.html Size:59 KB
<https://file.savannah.gnu.org/file/diff.html?file_id=55511>
AGPL NOTICE
These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-2b478236128ba85c00d8a2ecb8cf6141b8b94a05.tar.gz
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65098>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
