[bug #62150] [afmtodit] should not write full file names to "name" directive of font descriptions

[Dave]

Follow-up Comment #1, bug #62150 (project groff):

Hey, thanks for opening this bug report!

A couple nits in the proposed patch:

> +$short_version =~ s/([0-9.]+)(rc[0-9]+).*/$1$2/;

That regex (equivalently but more simply written as

  /([0-9.]+rc[0-9]+).*/$1/

and more perlishly as

  /([\d.]+rc\d+).*/$1/

) fails to match, and thus leaves $short_version unchanged, if the version
string contains no .rc component, which a development build might not (if I
correctly recall from the very-long-ago days when we weren't in a release
cycle).

One could craft a regex to strip the git addendum whether or not the version
string contains an .rc component.  However, absent such a component, you may
_want_ to keep the git-appended portion, as this might then be the only thing
distinguishing an official release from a development build.  (If those dusty
neurons serve correctly, our pre-rc1 build version strings were of the form
1.22.4.git-stuff; turning this into plain 1.22.4 seems misleading.)  Thus,
maybe the limitation I'm noting is intentional.

But then, if you're keeping .git-stuff in some cases, why not keep it in all
cases for consistency?  Yeah, it's kinda ugly, but for the most part only
developers will see it, and they should be the people least put off by long
strings of hex digits.  (And might even occasionally appreciate the extra
precision.)

> -print("name $font\n");
> +my $name = $font;
> +$name =~ s@.*/@@;
> +
> +print("name $name\n");

Nothing wrong with this, but I wonder why it introduces a new variable.  $font
is never again used after this, so may as well hack it directly.

    _______________________________________________________

Reply to this item at:

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

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