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: [gnu-prog-discuss] url's in --help output

Simon Josefsson josefsson.org> writes: > +2009-01-22 Simon Josefsson josefsson.org> > + > + * lib/version-etc.h: Add emit_bug_reporting_address. > + * lib/version-etc.c (emit_bug_reporting_address): New function. > + * modules/version-etc (Description): Reflect new features. The c

Re: [gnu-prog-discuss] url's in --help output

Simon Josefsson ha escrit: > Ah, interesting, I wasn't aware of this feature. Do I as maintainer of > projects using gnulib have to do anything special to make this usable > for translators? Nothing special, only make sure the files imported from gnulib are listed in your po/POTFILES.in. Regar

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

Re: [gnu-prog-discuss] url's in --help output

Jim Meyering writes: > Simon Josefsson wrote: >> l...@gnu.org (Ludovic Courtès) writes: > ... >>> Is there any reason this cannot be made part of `version-etc'? >> >> No reason. It seems like a better place actually. Jim, how about this >> patch? > > Hi Simon, > > That looks fine. > However, p

Re: [gnu-prog-discuss] url's in --help output

Simon Josefsson wrote: > l...@gnu.org (Ludovic Courtès) writes: ... >> Is there any reason this cannot be made part of `version-etc'? > > No reason. It seems like a better place actually. Jim, how about this > patch? Hi Simon, That looks fine. However, please make the three changes like this:

Re: [gnu-prog-discuss] url's in --help output

"Stefan Monnier" writes: + printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT); > [...] >> However, as far as I know there isn't a gnulib translation domain that >> is automatically used for messages in gnulib code when you import it to >> a project. So the strings above will end up

Re: [gnu-prog-discuss] url's in --help output

Karl Berry ha escrit: > However, as far as I know there isn't a gnulib translation domain that > > There actually is, although I admit I don't know how the messages get > integrated into the gnulib-using packages: > http://translationproject.org/domain/gnulib.html It is a "compendium" domai

Re: [gnu-prog-discuss] url's in --help output

>>> + printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT); [...] > However, as far as I know there isn't a gnulib translation domain that > is automatically used for messages in gnulib code when you import it to > a project. So the strings above will end up in every project's *.po > files,

Re: [gnu-prog-discuss] url's in --help output

OTOH, Karl's message suggests that it's the job of `--help', not `--version', so it may not be a good idea. I don't see a reason to have it in --version. But if people think it's a good idea to optionally have it there, we could ask rms. It should definitely be in --help.

Re: [gnu-prog-discuss] url's in --help output

However, as far as I know there isn't a gnulib translation domain that There actually is, although I admit I don't know how the messages get integrated into the gnulib-using packages: http://translationproject.org/domain/gnulib.html If this is incorporated into a project as a Gnulib modul

Re: [gnu-prog-discuss] url's in --help output

2009/1/22 Simon Josefsson : > > I don't follow? The comment is aimed at translators, and translators > will add the 'Report translation bugs ...' line in the particular > gettext translation file. Thus, source code is not modified. Thanks, I understand now. I thought the instruction meant to ad

Re: [gnu-prog-discuss] url's in --help output

Neil Jerram writes: > 2009/1/22 Simon Josefsson : >> Here it is. The module name and source filenames are rather long, but I >> couldn't think of anything better. Untested, beware! > >> +void >> +emit_bug_reporting_address (void) >> +{ >> + /* TRANSLATORS: The placeholder indicates the bug-rep

Re: [gnu-prog-discuss] url's in --help output

2009/1/22 Simon Josefsson : > Here it is. The module name and source filenames are rather long, but I > couldn't think of anything better. Untested, beware! > +void > +emit_bug_reporting_address (void) > +{ > + /* TRANSLATORS: The placeholder indicates the bug-reporting address > + for this

Re: [gnu-prog-discuss] url's in --help output

l...@gnu.org (Ludovic Courtès) writes: > Simon Josefsson writes: > >> l...@gnu.org (Ludovic Courtès) writes: > >>> Is there any reason this cannot be made part of `version-etc'? >> >> No reason. It seems like a better place actually. Jim, how about this >> patch? > > And while we're at it, can'

Re: [gnu-prog-discuss] url's in --help output

Simon Josefsson writes: > l...@gnu.org (Ludovic Courtès) writes: >> Is there any reason this cannot be made part of `version-etc'? > > No reason. It seems like a better place actually. Jim, how about this > patch? And while we're at it, can't `version_etc ()' print the bug-reporting informati

Re: [gnu-prog-discuss] url's in --help output

l...@gnu.org (Ludovic Courtès) writes: > Hello, > > Simon Josefsson writes: > >> I suggest a new gnulib module emit-bug-reporting-address. I have the >> following code in GNU Libidn, which is strongly influenced by GNU >> CoreUtils. Removing the 'static' keyword and putting it in a gnulib >> mo

Re: [gnu-prog-discuss] url's in --help output

Hello, Simon Josefsson writes: > I suggest a new gnulib module emit-bug-reporting-address. I have the > following code in GNU Libidn, which is strongly influenced by GNU > CoreUtils. Removing the 'static' keyword and putting it in a gnulib > module would make it easy to re-use the code, and po

Re: [gnu-prog-discuss] url's in --help output

Here it is. The module name and source filenames are rather long, but I couldn't think of anything better. Untested, beware! /Simon >From 52901a4bf1eb6dbbac9aa5a8676e120da3d3c134 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Thu, 22 Jan 2009 10:18:33 +0100 Subject: [PATCH] Add new modul

Re: [gnu-prog-discuss] url's in --help output

l...@gnu.org (Ludovic Courtès) writes: > Hi, > > Eric Blake writes: > >> Would it help if autoconf were taught to make the package homepage into an >> automatic C preprocessor macro by providing it as an optional argument of >> AC_INIT, similar to other variables like PACKAGE_NAME, PACKAGE_TARNAM