RE: usability problem of emacs describe-mode

["Drew Adams" <drew.adams@oracle.com>]

> If people think this is a problem, please perhaps file a
> bug report to FSF. (Alt+x report-emacs-bug)

Why not `M-x report-emacs-bug' yourself, rather than ask others to do so?
Quicker, and just as effective.

> There are many diverse solutions [better ways to show ^L]
> on the web, but they need to become part of emacs out of
> the box.

Filing an enhancement request through a bug report is one way to try to improve
vanilla Emacs, but discussion about such requests is typically more limited and
less fruitful than discussion in emacs-devel@gnu.org.

Reasons: (1) more people subscribe to emacs-devel, (2) people tend to look to
bug-gnu-emacs@gnu.org for bug reports, not for enhancement requests, (3)
enhancement requests are sometimes forgotten, even if not overlooked initially.

That said, I do occasionally submit enhancement requests rather than start a
discussion at emacs-devel. One reason can be to log a suggestion for later
consideration.

Wrt prettifying ^L in vanilla Emacs: I proposed that to emacs-devel years ago.
Here are some relevant threads:
http://lists.gnu.org/archive/html/emacs-devel/2006-12/msg00464.html
http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg01035.html

And here's a related thread from 2004 about the describe-mode problems:
http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00275.html 

IOW, these things have been brought up and discussed before.

Like it or not, the inescapable place to promote possible improvements to
vanilla Emacs is emacs-devel@gnu.org (not help-gnu-emacs). If you are truly
interested in changing vanilla Emacs, then emacs-devel is the mountain pass that
you must climb. 

Lowland tavern discussion among comrades who agree can make one feel good, but
it is no substitute for scaling the mountain and confronting the monstrous pass
guardians. Only those with the keys to the pass can unbar the way. C'est la
viemacs.

Soliciting more bug-report voices doesn't really help promote a given change you
want. More voices at emacs-devel can help. Instead of encouraging people to file
the same bug, encourage them to add their voices to emacs-devel.

The alternative to improving vanilla Emacs is personal customization or
providing extension libraries to share. Some people only work within emacs-devel
to improve vanilla Emacs; some people only provide extension code; some people
do both, to varying degrees. Eventually, some add-on features do get copied or
merged into vanilla Emacs. I suggest that you either code your ideas or add them
to emacs-devel.