GNU bug report logs - #13502
24.3.50; bad formatting in recent NEWS?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13502 in the body.
You can then email your comments to 13502 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; bad formatting in recent NEWS?
Date: Sat, 19 Jan 2013 14:47:15 -0800

The longest is this one (87 chars):
 
  machine smtp.whatever.foo port 25 key "~/.my_smtp_tls.key" cert
"~/.my_smtp_tls.cert"
 
There are also entries whose first line (a sentence) does not end in a
period.  And there are entries whose first line is not a sentence, and
is continued over subsequent lines.
 
All of these seem to contradict past NEWS formatting, but I don't know
where the rules for formatting NEWS are defined, so I cannot tell
whether they are strictly wrong or just unusual.  The last one certainly
works against the use of Outline mode to some extent.
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2013-01-18 on ODIEONE
Bzr revision: 111548 sdl.web <at> gmail.com-20130118182218-6ywd47qsbnow6nsg
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
 

Message #10 received at 13502-done <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 13502-done <at> debbugs.gnu.org
Subject: Re: bug#13502: 24.3.50; bad formatting in recent NEWS?
Date: Sun, 20 Jan 2013 10:42:22 +0800

"Drew Adams" <drew.adams <at> oracle.com> writes:

> The longest is this one (87 chars):
>  
>   machine smtp.whatever.foo port 25 key "~/.my_smtp_tls.key" cert
> "~/.my_smtp_tls.cert"

It should be incredibly obvious why this line is an OK exception.

As for any other lines, they will be cleaned up when it comes time to
edit the NEWS file in preparation for the 24.4 pretest.  No point filing
a bug about this kind of thing.  Closing.

Message #13 received at 13502-done <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 13502-done <at> debbugs.gnu.org
Subject: RE: bug#13502: 24.3.50; bad formatting in recent NEWS?
Date: Sat, 19 Jan 2013 20:37:01 -0800

> > The longest is this one (87 chars):
> >  
> >   machine smtp.whatever.foo port 25 key "~/.my_smtp_tls.key" cert
> > "~/.my_smtp_tls.cert"
> 
> It should be incredibly obvious why this line is an OK exception.

In spite of your hyperbole ("incredibly obvious", indeed), there is no need for
this line to be an exception.  It is too long only because you have used
fictitious names that are too long.  Those names do not explain anything, in any
case, and they need not be that long.

In addition, the text is incorrect.  It is "incredibly obvious" that it is NOT
true that "you need to put" that line "in your ~/authinfo file instead."  It is
no doubt 100% wrong that you should use that literal text.  What should be said
is something like this:

  If you had that set then you need to put

    machine MACHINE port PORT key KEYFILE cert CERTFILE

  where MACHINE is..., PORT is..., KEYFILE is..., and CERTFILE
  is....  [Specification still missing.]

  For example, MACHINE could be smtp.whatever.foo, PORT could
  be 25, KEYFILE could be "~/.my_smtp_tls.key", and CERTFILE
  could be "~/.my_smtp_tls.cert".

No long lines needed, and incorrect and misleading statement removed.

> As for any other lines, they will be cleaned up when it comes time to
> edit the NEWS file in preparation for the 24.4 pretest.  No 
> point filing a bug about this kind of thing.

Quite a pretension.  What happened to such cleanup during the 24.3 pretest?  Or
24.2?  Same problems - same long lines even; no such cleanup.

> Closing.

Improvident.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.