[task #15816] Run time option to specify if changes should be highlighted or not

[Mohammad Akhlaghi]

URL:
  <https://savannah.nongnu.org/task/?15816>

                 Summary: Run time option to specify if changes should be
highlighted or not
                 Project: Reproducible paper template
            Submitted by: makhlaghi
            Submitted on: Fri 20 Nov 2020 02:24:04 PM UTC
         Should Start On: Fri 20 Nov 2020 12:00:00 AM UTC
   Should be Finished on: Fri 20 Nov 2020 12:00:00 AM UTC
                Category: Paper
                Priority: 5 - Normal
                  Status: Postponed
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                  Effort: 0.00

    _______________________________________________________

Details:

Currently, the core Maneage 'paper.tex' has a '\highlightchanges' macro that
defines two LaTeX macros: '\new' and '\tonote'. 

When '\highlightchanges' is defined, anything that is written within '\new'
becomes dark green (highlighting new things that have been added). Also,
anything that is written in '\tonote' is put within a '[]' and becomes dark
red (to show that there is a note here that should be addressed later). 

When '\highlightchanges' isn't defined, anything within the '\new' element
will be black (like the rest of the text), and the things in '\tonote' will
not be shown at all.

Commenting the '\newcommand{\highlightchanges}{}' line within 'paper.tex' (to
toggle the modes above) will create a different Git hash and has to be
committed.

But this different commit hash can create a false sense in the reader that
other things have also been changed and the only way they can confirm is to
actually go and look into the project history (which they will not usually
have time to do, and thus won't be able to trust the two modes of the text).

So with this task I am proposing that the definition of the
'\highlightchanges' macro be done as a run-time option to the './project'
script (which will then be passed to the Makefiles and written into the
'project.tex' file). In this way, we can generate two PDFs with the same Git
commit (project's state): one with highlights and another one without it.

This issue actually came up for me while finalizing the changes in the Maneage
paper: we need to submit one PDF to the journal/referees with highlights, and
another PDF to arXiv and Zenodo. 

If the PDFs have different commit hashes, the referees are going to associate
it with other changes in any part of the work. For example this one
<https://oadoi.org/10.22541/au.159724632.29528907> that mentions "Another
version of the manuscript was published on arXiv: 2006.03018", while the only
difference was a few words in the abstract after the journal complained on our
first submission (where the commit hashes matched).

Generally a similar scenario may happen with co-authors, so I think its a good
thing to add, please share any thoughts you may have on it here (you just need
to register on Savannah to post your thoughts here)...




    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/task/?15816>

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