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

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

[Stefan Monnier]

Package: Emacs,gnus
Version: 24.0.92

I have a special-display-* setting like "\\*.*\\*" that makes all
buffers named with *...* to pop up in dedicated frames.
When I follow-up with F in gnus-summary, this is obeyed just fine and
pops up a new frame where I can comfortably edit my message.
But if I use R instead, the message-mode buffer is placed in the main
Gnus frame rather than in its own frame.  I.e. it disregards
special-display-*.

This is new in Emacs-24 and is caused by the `switch-to-buffer' argument
passed to `message-reply' in gnus-summary-reply since revno 103283
(appended below).


        Stefan


PS: BTW, please keep commit logs comments within the usual 80 (or even
72) columns!


------------------------------------------------------------
revno: 103283
author: Gnus developers <ding@gnus.org>
committer: Katsumi Yamaoka <yamaoka@jpl.org>
branch nick: trunk
timestamp: Tue 2011-02-15 11:24:37 +0000
message:
  Merge changes made in Gnus trunk.
  
  auth.texi (Help for users): Login collection is "Login" and not "login".
  gnus-sum.el (gnus-propagate-marks): Default to nil.
   (gnus-summary-exit): Kill the correct article buffer on exit from a `C-d' group.
  gnus-start.el (gnus-use-backend-marks): Removed, since it duplicates gnus-propagate-marks.
  gnus-sum.el (gnus-summary-exit-no-update): Restore the group conf before killing the buffers so that a non-full window conf gets handled correctly.
   (gnus-summary-exit): Ditto.
   (gnus-summary-read-group-1): Ditto.
  nntp.el (nntp-retrieve-group-data-early): Reinstate the two-part async code again so that we can debug it properly.
  message.el (message-reply): Take an optional switch-buffer parameter so that Gnus window confs are respected better.
  auth-source.el (auth-source-secrets-search): Use `delete-dups', `append mapcar', and `butlast' instead of `remove-duplicates', `mapcan', and `subseq'.
   (auth-sources, auth-source-backend-parse, auth-source-secrets-search): Login collection is "Login" and not "login".
  gnus-art.el (article-update-date-lapsed): Don't bug out when updating multiple headers.




In GNU Emacs 24.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.24.8)
 of 2011-12-06 on faina
Windowing system distributor `The X.Org Foundation', version 11.0.11101901
configured using `configure  'CFLAGS=-Wall -Wno-pointer-sign -DUSE_LISP_UNION_TYPE -DSYNC_INPUT -DENABLE_CHECKING -DXASSERTS -DFONTSET_DEBUG -g -O1 -I/usr/include/GNUstep' 'LDFLAGS=-L/home/monnier/src/Xaw3d' 'CPPFLAGS=-I/home/monnier/src/Xaw3d' '--enable-maintainer-mode''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: fr_CH.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  diff-auto-refine-mode: t
  gnus-undo-mode: t
  electric-pair-mode: t
  electric-indent-mode: t
  url-handler-mode: t
  global-reveal-mode: t
  reveal-mode: t
  auto-insert-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
" SPC t o SPC b e SPC a SPC r e g u l a r SPC e x p 
r e s s e i o n <backspace> <backspace> <backspace> 
<backspace> i o n , SPC t h e n SPC i t SPC g e t s 
SPC a SPC l o t SPC m o r e SPC i n t e r e s t i n 
g . <right> <up> <left> <right> <up> <left> <right> 
<down> <left> <right> <down> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<right> <right> <M-backspace> <M-backspace> C-e <right> 
<up> <left> <right> <up> <left> <right> <down> <left> 
<right> <down> <left> <right> <down> <down> , SPC y 
o u SPC c a n SPC <M-backspace> <backspace> ' l l SPC 
p r o b a b l y SPC h a v e SPC t o SPC d o SPC t h 
e SPC s e a r c h SPC " b y SPC h a n d " SPC w i t 
h o u t SPC u s i n g SPC E m a c s ' s SPC b u i l 
t i n SPC s e a r c h SPC f u n c t i o n a l i t y 
. <return> <up> <up> <up> <up> <up> <left> <right> 
<down> <left> <right> <down> <left> <right> <down> 
<down> <left> <right> <down> <left> <right> <right> 
<right> <return> <return> M-i S t e f a n C-c C-c n 
k q s n <return> k q s <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> M-x r e p o - e m - b u <tab> 
<return>

Recent messages:
Saving file /home/monnier/var/newsrc.eld...
Wrote /home/monnier/var/newsrc.eld
Saving /home/monnier/var/newsrc.eld...done
nnimap read 0k
Expiring articles...done
Saving /home/monnier/var/newsrc.eld...
Saving file /home/monnier/var/newsrc.eld...
Wrote /home/monnier/var/newsrc.eld
Saving /home/monnier/var/newsrc.eld...done
byte-code: Beginning of buffer

Load-path shadows:
/usr/share/emacs23/site-lisp/bbdb/bbdb-com hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-com
/usr/share/emacs23/site-lisp/bbdb/bbdb-ftp hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-ftp
/usr/share/emacs23/site-lisp/bbdb/bbdb-rmail hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-rmail
/usr/share/emacs23/site-lisp/bbdb/bbdb-mhe hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-mhe
/usr/share/emacs23/site-lisp/bbdb/bbdb-gui hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-gui
/usr/share/emacs23/site-lisp/bbdb/bbdb-print hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-print
/usr/share/emacs23/site-lisp/bbdb/bbdb hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb
/usr/share/emacs23/site-lisp/bbdb/bbdb-w3 hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-w3
/usr/share/emacs23/site-lisp/bbdb/bbdb-sc hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-sc
/usr/share/emacs23/site-lisp/bbdb/bbdb-whois hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-whois
/usr/share/emacs23/site-lisp/bbdb/bbdb-snarf hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-snarf
/usr/share/emacs23/site-lisp/bbdb/bbdb-merge hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-merge
/usr/share/emacs23/site-lisp/bbdb/bbdb-vm hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-vm
/usr/share/emacs23/site-lisp/bbdb/bbdb-migrate hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-migrate
/usr/share/emacs23/site-lisp/bbdb/bbdb-gnus hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-gnus
/usr/share/emacs23/site-lisp/bbdb/bbdb-hooks hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-hooks

Features:
(emacsbug woman tutorial help-macro man info-look help-at-pt ehelp
apropos gnus-draft add-log log-view pcvs-util vc-annotate vc ediff-merg
ediff-diff ediff-wind ediff-help ediff-util ediff-mult ediff-init ediff
vc-dispatcher cl-specs xscheme trace testcover scheme unsafep re-builder
shadow inf-lisp ielm comint ring elp edebug cust-print cus-edit
cus-start cus-load vc-bzr filecache find-func browse-url pp mule-util
debug rect executable copyright multi-isearch diff-mode jka-compr
newcomment supercite regi flow-fill sort smiley ansi-color gnus-cite
mail-extr gnus-async gnus-bcklg qp gnus-ml nnfolder nndraft nnmh utf-7
rfc2104 gnutls nnimap parse-time utf7 netrc nnagent nnml network-stream
starttls tls gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig
mailcap nntp gnus-cache nnir gnus-sum nnoo gnus-group gnus-undo nnmail
mail-source server gnus-start gnus-spec gnus-int gnus-range message
sendmail format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
mailheader gnus-win gnus gnus-ems nnheader mail-utils wid-edit noutline
outline easy-mmode flyspell ispell eldoc checkdoc regexp-opt thingatpt
help-mode view prog-mode load-dir electric url-handlers url-parse
auth-source warnings eieio byte-opt bytecomp byte-compile cconv macroexp
assoc gnus-util password-cache url-vars mm-util mail-prsvr reveal
autoinsert uniquify advice help-fns advice-preload time-date savehist
minibuf-eldef disp-table cl cl-loaddefs all-autoloads company-autoloads
debbugs-autoloads eldoc-eval-autoloads epoch-view-autoloads
jgraph-mode-autoloads js2-mode-autoloads lmc-autoloads
load-dir-autoloads markchars-autoloads minimap-autoloads muse-autoloads
info easymenu oauth2-autoloads quarter-plane-autoloads
rainbow-mode-autoloads register-list-autoloads shen-mode-autoloads
sisu-mode-autoloads svg-clock-autoloads undo-tree-autoloads
uni-confusables-autoloads windresize-autoloads package tabulated-list
proof-site proof-autoloads pg-vars bbdb-autoloads agda2 tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> I have a special-display-* setting like "\\*.*\\*" that makes all
> buffers named with *...* to pop up in dedicated frames.
> When I follow-up with F in gnus-summary, this is obeyed just fine and
> pops up a new frame where I can comfortably edit my message.
> But if I use R instead, the message-mode buffer is placed in the main
> Gnus frame rather than in its own frame.  I.e. it disregards
> special-display-*.

I've never used any of the `special-display-*' stuff.  What's the
setting exactly for reproducing this bug?

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

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Stefan Monnier]

>> I have a special-display-* setting like "\\*.*\\*" that makes all
>> buffers named with *...* to pop up in dedicated frames.
>> When I follow-up with F in gnus-summary, this is obeyed just fine and
>> pops up a new frame where I can comfortably edit my message.
>> But if I use R instead, the message-mode buffer is placed in the main
>> Gnus frame rather than in its own frame.  I.e. it disregards
>> special-display-*.
> I've never used any of the `special-display-*' stuff.  What's the
> setting exactly for reproducing this bug?

I'm not completely sure ("emacs -Q" doesn't work too well with Gnus ;-),
but something like (setq special-display-regexps '("^\\*.*\\*$")) might
be sufficient.

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

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


        Stefan

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'm not completely sure ("emacs -Q" doesn't work too well with Gnus ;-),
> but something like (setq special-display-regexps '("^\\*.*\\*$")) might
> be sufficient.

Yes, that allows me to reproduce the bug.

I seem to recall the change here being made because a user had reported
that `special-display-regexps' was being respected, and that the Gnus
window conf wasn't.  So just backing out the patch doesn't seem like the
right thing to do, either...

(But of course, `F' and `R' should behave the same way here, anyway...)

Is there a way to have

(setq special-display-regexps '("^\\*.*\\*$"))

but still say "don't do this for the Message buffers?  If so, the patch
can be reverted, and the user who complained can just twiddle the
variable in question...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Stefan Monnier]

>> I'm not completely sure ("emacs -Q" doesn't work too well with Gnus ;-),
>> but something like (setq special-display-regexps '("^\\*.*\\*$")) might
>> be sufficient.

> Yes, that allows me to reproduce the bug.

> I seem to recall the change here being made because a user had reported
> that `special-display-regexps' was being respected, and that the Gnus
> window conf wasn't.  So just backing out the patch doesn't seem like the
> right thing to do, either...

> (But of course, `F' and `R' should behave the same way here, anyway...)

> Is there a way to have

> (setq special-display-regexps '("^\\*.*\\*$"))

> but still say "don't do this for the Message buffers?

With special-display-regexps, I think something
like the code below should do it:

   (setq special-display-regexps
         '(("^\\*unsent.*\\*$" switch-to-buffer)
            "^\\*.*\\*$"))

> If so, the patch can be reverted, and the user who complained can just
> twiddle the variable in question...

Sounds good to me,


        Stefan

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> With special-display-regexps, I think something
> like the code below should do it:
>
>    (setq special-display-regexps
>          '(("^\\*unsent.*\\*$" switch-to-buffer)
>             "^\\*.*\\*$"))

Right.  I've now removed the `switch-to-buffer' parameter to
`message-reply'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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.

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

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