Re: bug#10238: R in gnus-summary does not pop a frame like F does

Re: bug#10238: R in gnus-summary does not pop a frame like F does

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Tue, 24 Jan 2012 16:00:46 -0600
> Cc: 10238@debbugs.gnu.org, Lars Magne Ingebrigtsen <larsi@gnus.org>
> 
> SM> IOW, just make sure that if you only read the first 80 chars of
> SM> the first line, you get something meaningful that describes the bulk of
> SM> the patch.
> 
> I'm OK with the above, as long as the Gnus developers are allowed to go
> over 80 in the first line within reason.  So we'll keep the first line
> short, but if it has to go a little over 80, we'll make sure the really
> important stuff is at the very beginning.

I have yet to see a doc string whose first line could not be made less
than 80 characters.  When in trouble, ask for help here, there are
enough native English speakers here who are proficient in making that
line clear, concise, and short.

Re: bug#10238: R in gnus-summary does not pop a frame like F does

[Ted Zlatanov]

On Wed, 04 Jan 2012 20:26:38 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>> PS: BTW, please keep commit logs comments within the usual 80 (or even
>>> 72) columns!
>> I have previously been instructed to make the first line of a commit
>> message be a complete sentence.  Making it complete, less than 72
>> characters and meaningful is a challenge.

SM> The first line doesn't need to be complete, as far as I'm concerned.
SM> And I'm more worried about it staying within the 80 columns limit than
SM> about it being a complete sentence.
SM> IOW, just make sure that if you only read the first 80 chars of
SM> the first line, you get something meaningful that describes the bulk of
SM> the patch.

I'm OK with the above, as long as the Gnus developers are allowed to go
over 80 in the first line within reason.  So we'll keep the first line
short, but if it has to go a little over 80, we'll make sure the really
important stuff is at the very beginning.

Can we highlight past the 80th char in commit log buffers?  That would
be a nice passive indicator of a problem.

CC to ding for any stray comments.

Ted

Re: bug#10238: R in gnus-summary does not pop a frame like F does

[Ted Zlatanov]

On Tue, 24 Jan 2012 23:25:48 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Tue, 24 Jan 2012 16:00:46 -0600
>> Cc: 10238@debbugs.gnu.org, Lars Magne Ingebrigtsen <larsi@gnus.org>
>> 
SM> IOW, just make sure that if you only read the first 80 chars of
SM> the first line, you get something meaningful that describes the bulk of
SM> the patch.
>> 
>> I'm OK with the above, as long as the Gnus developers are allowed to go
>> over 80 in the first line within reason.  So we'll keep the first line
>> short, but if it has to go a little over 80, we'll make sure the really
>> important stuff is at the very beginning.

EZ> I have yet to see a doc string whose first line could not be made less
EZ> than 80 characters.  When in trouble, ask for help here, there are
EZ> enough native English speakers here who are proficient in making that
EZ> line clear, concise, and short.

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.

Ted

bug#10238: R in gnus-summary does not pop a frame like F does

[Andreas Schwab]

Ted Zlatanov <tzz@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.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#10238: R in gnus-summary does not pop a frame like F does

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  10238@debbugs.gnu.org,  larsi@gnus.org,  ding@gnus.org
> Date: Wed, 25 Jan 2012 00:02:06 +0100
> 
> Ted Zlatanov <tzz@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.

100% agreement.

bug#10238: R in gnus-summary does not pop a frame like F does

[Ted Zlatanov]

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

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  10238@debbugs.gnu.org,  larsi@gnus.org,  ding@gnus.org
>> Date: Wed, 25 Jan 2012 00:02:06 +0100
>> 
>> Ted Zlatanov <tzz@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

bug#10238: R in gnus-summary does not pop a frame like F does

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> But forcing the Gnus developers to use 80 chars in their own work
> seems too harsh.

I don't mind the 80-character limit.  But it can be kinda repetitive if
the 80-character summary just repeats a shortened version of the long
explanation underneath.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

bug#10238: R in gnus-summary does not pop a frame like F does

[Ted Zlatanov]

On Wed, 25 Jan 2012 23:56:49 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> But forcing the Gnus developers to use 80 chars in their own work
>> seems too harsh.

LI> I don't mind the 80-character limit.  But it can be kinda repetitive if
LI> the 80-character summary just repeats a shortened version of the long
LI> explanation underneath.

Exactly.  A good
haiku will lift the spirit
in more than 80 chars

:) 
Ted

bug#10238: R in gnus-summary does not pop a frame like F does

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> 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.

I think it's fine for the summary line to not describe the entire
patch.  If it says something like "rfc2047 parameter fixups", and then
the rest of the commit message explains in excruciating details what's
been done and why, then that's to be preferred.  Reading the summary
lines is then fast and you'll quickly determine which patches you're
interested in looking further at, and which ones you don't care about.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

bug#10238: R in gnus-summary does not pop a frame like F does

[Stefan Monnier]

>> 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.
> I think it's fine for the summary line to not describe the entire patch.

Actually, the way to think about this is that this "summary" is really
about giving a *name* to the patch.  In this context, 80chars is usually
not that restrictive (although often a large part is taken by some kind
of context like "lisp/emacs-lisp/tabulated-list.el: ", that still leaves
40chars for the "name-in-context").


        Stefan