GNU bug report logs - #10238
R in gnus-summary does not pop a frame like F does

Previous Next

Full log

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10238 <at> debbugs.gnu.org, larsi <at> gnus.org,
	Andreas Schwab <schwab <at> linux-m68k.org>, ding <at> gnus.org
Subject: Re: bug#10238: R in gnus-summary does not pop a frame like F does
Date: Wed, 25 Jan 2012 09:00:13 -0600

On Wed, 25 Jan 2012 01:30:49 -0500 Eli Zaretskii <eliz <at> gnu.org> wrote: 

>> From: Andreas Schwab <schwab <at> linux-m68k.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  10238 <at> debbugs.gnu.org,  larsi <at> gnus.org,  ding <at> gnus.org
>> Date: Wed, 25 Jan 2012 00:02:06 +0100
>> 
>> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> 
>> > We're talking about VCS commit messages, not docstrings.  It's a
>> > different context, and for VCS commits often there is information that
>> > needs to be distilled into that first line and 80 chars are not enough.
>> 
>> The summary line doesn't need to be precise.  It should just give an
>> informal overview of the change.

EZ> 100% agreement.

OK, but we're not talking about the destiny of the summary line in a VCS
commit, but rather whether it should be limited to 80 chars.

I think we should try to keep it under 80, and if it has to go over, the
essential information should be before the 80th char.  But forcing it to
80 will force us to write convoluted summaries that misrepresent the
commit for the sake of saving a few characters.

Please note we're talking about Gnus here, not Emacs.  We could ask
Yamaoka-san, who synchronizes Gnus into Emacs, to cut or rewrite long
commit summary lines so they don't bother Emacs developers.  But forcing
the Gnus developers to use 80 chars in their own work seems too harsh.

Ted

Previous Next

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