Re: url's in --help output

"Brendan O'Dea" wrote: > On Tue, Feb 3, 2009 at 11:07 PM, Jim Meyering wrote: >> I've just done that with a message to bug-help2man, >> but don't see a list. Maybe it's just an alias. > > It is just an alias. > >> Similarly, I looked for the upstream source of the script, >> but didn't find it.

Re: url's in --help output

On Tue, Feb 3, 2009 at 11:07 PM, Jim Meyering wrote: > I've just done that with a message to bug-help2man, > but don't see a list. Maybe it's just an alias. It is just an alias. > Similarly, I looked for the upstream source of the script, > but didn't find it. The source repository is currentl

Re: url's in --help output

Jim Meyering writes: > I've just done that with a message to bug-help2man, > but don't see a list. Maybe it's just an alias. >From /etc/aliases on fencepost: bug-help2man: b...@debian.org bugs-help2man: bug-help2man help2man-bug: bug-help2man help2man-bugs: bug-help2man -- "Im

Re: url's in --help output

k...@freefriends.org (Karl Berry) wrote: ... > What will it take to get these modifications back upstream, so that > everyone can benefit from a new release of help2man? > > I pinged Brendan (help2man maintainer, bod at debian) fairly recently > about making a new release (GPLv3 etc.), and

Re: url's in --help output

Is this something the gnulib printf module can detect and work around? Yeah, exactly! Would be much better than rewriting the world. (Sorry for my duplicate mail earlier, I hadn't seen Simon's msg yet.)

Re: url's in --help output

I really like seeing the <> around URLs in a text format; I hate it, but we've already concluded we're doing it, so fine :). I've never had trouble understanding whether a trailing period in text is part of the url (it isn't), and the simple software I use (browse-url-at-point, basically) do

Re: url's in --help output

It's a one-character addition (plus a gnulib module) to use xprintf everywhere you used to use printf Sure. But virtually every program, GNU or otherwise, uses printf. Before we change/recommend changing all the source files in the world, my question is, do the common implementations such

Re: url's in --help output

Eric Blake writes: > According to Simon Josefsson on 2/2/2009 5:16 AM: >>> In m4, I was using xprintf instead of printf. Is it worth the extra >>> security here? printf can fail for reasons like ENOMEM which do not set >>> the ferror flag and thus are not caught by the close_stdout atexit modul

Re: url's in --help output

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 2/2/2009 5:16 AM: >> In m4, I was using xprintf instead of printf. Is it worth the extra >> security here? printf can fail for reasons like ENOMEM which do not set >> the ferror flag and thus are not caught by the clos

Re: url's in --help output

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 1/30/2009 11:51 AM: >> >> 1) The two above aren't sentences. >> 2) Adding punctuation around url's just makes them more painful to cut >>and paste. It's easiest when it's bare text at the end of a line. >> > > I too h

Re: url's in --help output

Eric Blake writes: > According to Simon Josefsson on 1/22/2009 3:29 AM: >> + >> +void >> +emit_bug_reporting_address (void) >> +{ >> + /* TRANSLATORS: The placeholder indicates the bug-reporting address >> + for this package. Please add _another line_ saying >> + "Report translation bug

Re: url's in --help output

Ben Asselstine ha escrit: > On Sat, Jan 31, 2009 at 5:22 PM, Karl Berry wrote: > >The <...> markup is helpful when the URL is broken into two lines, > > > > Let's not forget about argp. Here's a patch to sync it to the new > format. That would break too many existing programs. I'd rather

Re: url's in --help output

I would not apply the <...> markup to mail addresses, only to URLs. Ok, fine by me. rms doesn't like angle brackets around email addresses either.

Re: url's in --help output

Karl Berry wrote: > How about this change to standards.texi: > > -Report bugs to @var{mailing-address}. > +Report bugs to: <@var{mailing-address}> I would not apply the <...> markup to mail addresses, only to URLs. Reason: While many mailer programs we are used to allow entering email addresses s

Re: url's in --help output

On Sat, Jan 31, 2009 at 5:22 PM, Karl Berry wrote: >The <...> markup is helpful when the URL is broken into two lines, > Let's not forget about argp. Here's a patch to sync it to the new format. Unfortunately it will require users of argp_program_bug_address who used enclosing '<', '>' to c

Re: url's in --help output

The <...> markup is helpful when the URL is broken into two lines, Ok, I give. How about this change to standards.texi: --- standards.texi.~1.184.~ 2009-01-26 10:15:16.0 -0800 +++ standards.texi 2009-01-31 14:21:34.0 -0800 @@ -1094,5 +1094,5 @@ general page for help

Re: url's in --help output

Karl Berry wrote: > Ralf pointed out to me in separate email that the <...> allow > better recognition in some contexts. I don't necessarily advocate for > never using <...>, but I don't see a specific reason to do so here. The <...> markup is helpful when the URL is broken into two lines, such a

Re: url's in --help output

Hello, * Karl Berry wrote on Sat, Jan 31, 2009 at 12:04:25AM CET: > > Ralf pointed out to me in separate email that the <...> allow > better recognition in some contexts. I don't necessarily advocate for > never using <...>, but I don't see a specific reason to do so here. Well, they allow reco

Re: url's in --help output

so would be happy to throw this patch away -- or to apply it. What do others think? Ok, I'm not "others", but of course I vote to apply it, except for this line: + printf (_("\nReport %s bugs to %s\n"), last_component (program_name), If we're going to leave out the period, I think it sh

Re: url's in --help output

k...@freefriends.org (Karl Berry) wrote: > Sorry for the delayed reply. > > > What do you think of this followup, which makes complete sentences, and > > consistently brackets URLs inside <>? > ... > + printf (_("%s home page: .\n"), > + printf (_("Gen

Re: url's in --help output

> What do you think of this followup, which makes complete sentences, and I still don't buy the periods, I think ... > consistently brackets URLs inside <>? But I guess I give on this since we seem to be more or less standardizing on <...>.

Re: url's in --help output

Sorry for the delayed reply. > What do you think of this followup, which makes complete sentences, and > consistently brackets URLs inside <>? ... + printf (_("%s home page: .\n"), + printf (_("General help using GNU software:

Re: url's in --help output

Eric Blake wrote: > According to Eric Blake on 1/27/2009 10:08 AM: >> >> What do you think of this followup, which makes complete sentences, and >> consistently brackets URLs inside <>? > > Since Jim already changed coreutils to use this proposed style, and I just > committed a patch to autoconf t

Re: url's in --help output

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 1/27/2009 10:08 AM: > > What do you think of this followup, which makes complete sentences, and > consistently brackets URLs inside <>? Since Jim already changed coreutils to use this proposed style, and I just committed a

Re: url's in --help output

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Karl Berry on 1/24/2009 5:10 PM: > printf can fail for reasons like ENOMEM which do not set the ferror > flag and thus are not caught by the close_stdout atexit module, so a > robust program should be checking for failures. >

Re: url's in --help output

printf can fail for reasons like ENOMEM which do not set the ferror flag and thus are not caught by the close_stdout atexit module, so a robust program should be checking for failures. Whoa. I hadn't seen this before. at_exit is not sufficient to check for write errors? What does th

Re: url's in --help output

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 1/22/2009 3:29 AM: > + > +void > +emit_bug_reporting_address (void) > +{ > + /* TRANSLATORS: The placeholder indicates the bug-reporting address > + for this package. Please add _another line_ saying > + "Repor